G-codes/offsets/tools with .Net

[Moray]

I'm currently looking as the feasibility of making a custom C#/WPF version of KMCNC, as for a couple of upcoming projects I'm looking to expand on the tool handling functionality within KMCNC.

Anyway I'm trying to work out how G-codes, tools, and offsets (both tool, and work coordinate offsets) are handled within KMCNC, but I'm completely failing at trying to understand how things are done via MVC, or find any kind of simple guide as to how MVC works.
I suspect my biggest issue is as MVC has been deprecated, VS2017 isn't showing everything, or I'm missing something blatantly obvious.


Are these all handled internally within KMCNC, or are some of them done via the .Net interpreter?

If I was to write my own program, how much could I rely on the .Net interpreter?
I.e. would I be restricted by having to use the EMC style tool table, or can I use my own tool tables and only pass the required offsets?

How are G/M codes handled?
Could I add/edit existing G codes?

[TomKerekes]

Hi Moray,

I'm currently looking as the feasibility of making a custom C#/WPF version of KMCNC, as for a couple of upcoming projects I'm looking to expand on the tool handling functionality within KMCNC.

That would be great. But it might be a significant effort. KMotionCNC involves about 45,000 lines of C++ code. However using C# and .NET should be far less.

Note there is a C#/WPF example SimpleGCodeWPF but it is extremely primitive:
(oops just noticed the title should say WPF not Forms)

Anyway I'm trying to work out how G-codes, tools, and offsets (both tool, and work coordinate offsets) are handled within KMCNC, but I'm completely failing at trying to understand how things are done via MVC, or find any kind of simple guide as to how MVC works.

These are handled and maintained by the Interpreter. KMotionCNC just provides the GUI to allow you to view and change them. You might look at the file \PC VC Examples\KMotionCNC\EditToolFile.cpp to see how KMotionCNC reads/writes/displays the Interpreter's Tool Table file.

For Tool offsets the Interpreter reads the EMC style Tool Table File that supports up to 99 Tools. Actually it supports two file format Versions. The original EMC style and a newer format that includes more info such as the image file for the Tool. See the Interpreter Code in \GCodeInterpreter\driver.cpp that reads the Tool File

int read_tool_file( /* ARGUMENT VALUES */
char * tool_file, /* name of tool file */
setup_pointer settings) /* pointer to machine settings */

If I was to write my own program, how much could I rely on the .Net interpreter?

You could rely on the Interpreter to handle any Tool Offsets.

How are G/M codes handled?
Could I add/edit existing G codes?

The Interpreter handles these. To add/edit G or M Codes you would need to modify the C++ Interpreter Code. See the tables const int _gees[] and const int _ems[] in file: \GCodeInterpreter\rs274ngc.cpp

Besides allowing the codes in the tables the code to handle them must also be added. For example see the code in static int convert_g in the same file which then does something like:

if (block->g_modes[0] == G_4) {
CHP(convert_dwell(block->p_number));

etc.


HTH

[Moray]

Thanks for that info Tom.

I'm well aware it could be quite a big undertaking, which is why I've been trying to understand how the key things interact, and try and workout a general overview of how I'd go about implementing them.

I think I've been through all the examples now, and have already copied that WPF example to do some initial coding/testing.

I'll go and do some more code reading.

[Moray]

I've made a start on this, but have hit my first problem.

I'm trying to implement User Buttons with similar functionality to KMCNC, however I'm struggling to understand how best to implement it.
I see KMCNC stores all the relevant information in an MCODEACTIONS array, and that is accessible to the interpreter (or is at least set within KMotionCNCDlg.cpp).

Is there something similar available using C#, or will I have to use SetMcodeAction for each M code?

[TomKerekes]

Hi Moray,

Since you are writing your own C# code you could simply write C# code to do whatever you want directly. Set a bit, run a C Program, set an Interpreter offset, etc.

But if you wish to use the Interpreter's Action mechanism that is used by the Interpreter for MCodes and that KMotionCNC uses for User Buttons you may do this also. Yes you will need to fill in the parameters in the Action Array for any Action you will be using with SetMCodeAction. The Action Array layout is described here. Note array indexes 11-20 are available for use by an Application. You will also need to setup any MCode Action that you use.

After an Action is configured and you want the Action to be performed (ie. Operator pushed the button) you can use InvokeAction.

The KFLOPWebNC C# example does this in:
\PC VCS Examples\KFlopWebNC\KFlopWebNC\Model\Device Interop (Scripting Object)\DeviceInteropHandler Interpreter.cs

BTW to facilitate KMotionCNC Screen Scripting the Interpreter was modified to allow Actions to be performed dynamically. An action can be created and then invoked without using the Action Array by passing an Action to InvokeAction instead of the Array Index. This allows an Application to invoke unlimited Actions. But that method has not yet been exported to .NET. It would be easy to export if necessary.

HTH

[Moray]

Thanks for the information.

I'm still not sure how I ultimately want to implement user buttons, so I'm currently trying to replicate how KMCNC does things to get a functional base to work from. I've only added two user buttons so far anyway, as I'm still working on how best to achieve handling the required variables to avoid having to copy/paste code for every button.
I think ultimately I'd like to be able to dynamically create user buttons, so having that functionality you mention added to .Net would be helpful, but I'm happy working with the current options for now. I need to be able to configure the default G/M code actions anyway.

My aim is to have a machine running g-code this week, then gradually add the required functionality.

[Moray]

I'm gradually chipping away at this project, and now I've got all the M-code setting functionality in place, I'm looking at how to implement all the TP/Motion settings.

One thing I really want to improve on, is Inch/MM functionality, so want to think about how to implement that just now.

I see that KMCNC simply issues a G20/21 command to the interpreter, which I've traced to convert_length_units within rs274ng.cpp, which applies a conversion only to axis positions/offsets. (I've not found the tool handling code yet..)

I know in the past you've said KMCNC is essentially unitless, so I'm trying to think of how best to handle this.
Obviously I'd want to have the tool/offset tables set up in a defined UOM (unit of measurement) within my program, and then have the option to have the DROs in G20 or G21, with any offset/tool changes to be converted as appropriate.

Am I correct in assuming that for that to work, when switching modes, I would have to reload the tool/offset tables into the interpreter, with the correct UOM applied to the relevant values?

[TomKerekes]

Hi Moray,

I don't really have any specific recommendations.

In other applications what seems to have worked well was to have all the math work in one set of units and have the GUI do conversions in inputs and displays to the User based on current mode. The advantage is the mode can be changed at will without any effect on the Job in progress. Our Coordinated Motion Library works like this, always in Inches.

But the EMC Interpreter doesn't work this way. It does calculations in the current mode and if the mode changes it attempts to "fix up" any intermediate variables.

Any offsets are assumed to be numbers in whatever units that will apply when they are loaded/used. Some numbers might be used in mm Jobs and some in Inches Jobs. It seems like the only way to handle things more properly would be that the units for every number would need to be somehow specified and maintained for each offset.

[Moray]

That's what I thought, so what it really needs is to have the interpreter re-written?

What I'm leaning towards, is you set up tools/offsets in either mm or inch.
Then at G-code run time, if mode changes, any offsets get re-loaded to the coordmotion library.

However, I don't think I fully understand how the offset values operate from KMCNC, through the interpreter, and into the CoordMotion.
I normally setup my machines in mm. Now I'm aware offsets are then transferred from KMCNC to the interpreter as undefined units, so say an offset is 25mm, it gets transferred as 25. That offset remains in the interpreter as 25.
Now I'm assuming that if the interpreter mode is then changed from mm to inch, that 25 gets converted to 1 (I'm rounding for simplicity!), however the value will still be stored as 25 within KMCNC, which isn't a problem, until you edit the offset table, at which point the 25 then gets re-loaded to the interpreter, but because the interpreter is now in Inch, the offset now becomes 25 inch, instead of 25mm?

If that is the case, I think I have an idea of a plan..

[TomKerekes]

Hi Moray,

I think another part of the puzzle/issue is that there are times when the offsets are read in and when they are activated for use. The offsets are selected from the various tables and saved locally when active. If Units are changed with a G20 or G21 the function convert_length_units() is called to convert the local values.

Note a related change was made in V4.35a:
Issue with saved Origin offsets being incorrectly converted between mm/Inches solved. When offsets were saved in one unit but KMotionCNC starts up in another unit, and the same origin was selected as the default, the offsets were incorrect.

A new Interpreter setting was added to help with this. It records the units at the time the fixture (origin) offsets were selected:
CANON_UNITS length_units_of_origin; // millimeters or inches

The only way I see to handle this properly is to add a Units setting to all the individual offsets (Tools, Fixtures, and G92). For compatibility they could be either mm, or in, or unknown. If unknown they would work as they do now and just assume the number is in the appropriate units to match the current mode. But if known to be mm or in, then the appropriate conversion could then be made to the current mode.