G-codes/offsets/tools with .Net

[Moray]

That's the directory I have set in that .xml file I attached, but it can be set via the C Directory on the Config page -

It is however currently using a bit of bodge in order to select the directory.
The WPF OpenFileDialog doesn't directly support selecting a folder, so I either need to resort to the Windows Form FolderBrowserDialog, use a third party implementation, or roll my own.
However, I've not decided on the final layout/functionality, so I'll live with the bodge for now.

[Moray]

Time for a bit of a thread resurrection.

Life has been somewhat stressful over the past couple years, with this year having been the worst due to a few different reasons, but I've now currently got some free time, so am considering resurrecting this project.

I don't think I've made (m)any changes since my last post, but have spent this evening looking over, and trying to remember how all my code tied together.

I've got a list of changes I'd like to make in my head. The biggest is probably to re-write a lot of code to make custom screens easier, which is one of the key features I realise I should have planned from the beginning. I did choose WPF as the basic framework, for the reason it uses XAML for screens making them fairly easy to edit, but I didn't think far enough ahead to plan how to implement changing screens!

Anyway, I'm still undecided on how much effort to put into this, and have been considering moving it all on to github so others could help, but I'm not sure how much demand there would actually be for it?

[TomKerekes]

Hi Moray,

Sorry to hear about the stress. I hope that is in the past.

I agree it one thing to write a GUI for one system and quite another to write something that is configurable for any system.

I was disappointed that Microsoft no longer supports IronPython that we used for WPF. There is a Open Source version not supported by Microsoft but makes me wonder if WPF is still the way to go.

It certainly wouldn't hurt to put it on GitHub. Who knows, some others may find interest and after time it may accumulate critical mass

Thanks

[Moray]

I spent some time last night researching options, and although my initial plan of directly importing the XAML won't work, I'm going to try using a XML to store all the values, then read that in.

Then I need to add the functionality so the core code can detect and update only the components being used on the screen.

If I can manage that, it means a few ideas I have shouldn't be too much work after that.

[Moray]

Progress has been made.
I now have a screen that contains buttons that are generated from an external XML (And that XML is generated automatically should it not exist/be corrupt).

However it's got me thinking about screen functionality in general.
As it stands, I've largely replicated KMotionCNC functionality.
For user buttons that means they get hidden if there is no label/text set for them.
With my new functionality, that could remain, but I feel it would be better if you could create any buttons you like, linked to the existing functionality provided by user buttons.

The other issue involves the behind the scenes code, and linking to buttons.
I've been thinking about how to handle specific function buttons. Things like Feedhold/Estop that the colour/active state changes on depending on other status(es).
The simple option would be to limit these to one per screen, as it makes the behind the scenes coding easier, and I can't personally see a need to have things like multiple Feedhold or Estop buttons on a screen.

Does anybody have any thoughts on the above items?

[Moray]

I've been spending a bit time on this, and I now have a screen that is almost* fully generated from an XML, which has potentially opened up a lot of functionality.
I'll hopefully have this done over the next few days, then I can look at adding some form of basic screen builder/editor, along with the ability to change/select screens.


*just needs the GCode Viewer control type created, and figure out how to handle control binding.

[TomKerekes]

Hi Moray,

That all sounds very promising!

On a side note one User needed to use .NET 7.0. I discovered that Microsoft made a major .NET rewrite/changes switching from .NET Foundation to .NET Core (Or sometimes just referred to as .NET). So its not as simple as just selecting .NET 7.0. .NET Core should run on multiple platforms like Windows. Linux, MAC. There is an Upgrade Assistant that can help migrate projects from .NET Foundation to .NET Core (Right click - Upgrade on the Project in the Solution Explorer). You might consider moving to .NET 7 as I think it may be more difficult later. Attached is a C# Project file for KMotion_dotNet that should make a .NET 7 compatible Library. Here is a related article.

[Moray]

I'm actually pretty excited about the options the screen changes will create!
It will mean changing and redoing quite a lot of the things I've already coded, but I do feel it will be worth it.

My current aim is to get my mill running it, with a custom screen for initialising the tool changer, as currently unless it's in a specific state when I power the mill on, I need to manually toggle bits in KMotion, and run a C program to set positions.


I've just tried quickly migrating to 7.0, but I'll need to look into 3DTools as well as the KMotion library.
3DTools is the library I found to create 3D toolpaths in WPF, but I was having issues with it anyway, so was needing to look at either fixing it, or using something else completely. I've not looked at that part of my program for quite some time, so I'm not entirely sure I've even got 3DTools enabled just now as my last working notes says it was crashing under certain conditions.

[Moray]

Who would have thought creating a Screen Designer would be so hard?

Anyway, thought I'd give a bit of an update.
I now have the ability to edit and save generic/common properties (size, position, colour) of my pre-generated controls.
I'm currently on revision 4 of my storage structure, with all key control attributes stored in an XML file.

The major things still needing done before I publish a release to get some feedback are-
Add Drop down boxes to the screen designer code.
Add the ability to set the control specific properties.
Lock the name of dedicated controls (the code behind is hard coded to search for specific names for DROs/Sliders).
Add some way to manage bindings (Sliders for things like FRO/SSO are linked to a text box), although I may remove the binding and have it handled by Event Handlers, as managing the bindings in the screen designer may be a bit too much work for all that they actually do.

Then I'll look at how to handle adding/removing controls, and custom buttons.

[Moray]

Another quick update.

Progress on this has been happening.
There's been a few re-works to handle various things, but I can now add/remove/edit what I'm calling Dedicated Controls (things like DROs, and buttons with fixed functionality that need to tie in with handlers/functions), along with Images and Labels.

Next step is add Custom Button functionality, then test it on an actual machine.