G-codes/offsets/tools with .Net

[Moray]

I'd found convert_length_units() last night when I was trying to figure out how things were handled, and seen it converts all current active offsets, but not any inactive offsets.

I'm not sure individual offset flags are needed, as I very much doubt anybody will be mixing units at that level.

My current plan revolves around being able to select the users 'Master' units.
Everything on the computer/program settings is then saved in the master units.
The program then handles any conversion needed, updating the interpreter when needed.

I've found InchesToUserUnits() and UserUnitsToInches() functions, but is there any property I can access via dotNet to find out what mode the interpreter is in?

[TomKerekes]

Hi Moray,

I've found InchesToUserUnits() and UserUnitsToInches() functions, but is there any property I can access via dotNet to find out what mode the interpreter is in?

See here.

[Moray]

Hi Moray,

I've found InchesToUserUnits() and UserUnitsToInches() functions, but is there any property I can access via dotNet to find out what mode the interpreter is in?

See here.

Thanks for that.
LengthUnits would explain why searching for inches and mm never found anything meaningful.

[Moray]

Can I just clarify, that any position returned by the interpreter, will be in whatever units the interpreter is currently set to?
I.e if the interpreter is set to mm, any value returned, such as via GetPosition, will be in mm.

[TomKerekes]

Hi Moray,

No, only the Interpreter operates in mm and inches. Calls to the Interpreter properties should return mm or inches depending on the mode.
Such as: KM_Interpreter.KM_Interpreter_SetupParams.X_AxisPosition.

The Interpreter doesn't have a GetPosition Method. There is a KM_MainStatus.GetPosition method which returns the measured position in counts from the KFLOP Status record.

HTH

[Moray]

Having just had another trace through the KMCNC source, I've got no idea how I ended up at GetPosition!

I think I now (just about!) understand how things interact.

For DROs, KMCNC handles this in SetBigValues() with the following steps-
1)gets Axis allocations via CM->GetAxisDefinitions
2)DRO position/destination are then gained from the GetAxisDRO calls for each axis.
3)Those values are than passed through the Kinematics to get the CAD space position.
(or the above two are skipped if there's no KFlop attached, or we're in simulate, in which case we just get the basic interpreter positions)
4)DRO colours are set depending on each axis status/setting
5)Axis positions are then converted to DRO values
6)DRO positions are then displayed

Now I've worked that out, I'm guessing KMCNC gets axis this way, so it's easier to manipulate the DROs depending on what option is selected, as ultimately it's starting with the raw axis counts?
I'm assuming the same DRO values could be calculated using X_AxisPostion, X_AxisOffset, X_OriginOffset, and they already allow for kinematics?


The reason I'm trying to understand all this, is I don't want to blindly go down using the seemingly easier X_Axis/Origin functions, then find I've overlooked something, and need to use a method similar to how KMCNC does things.
Plus I'm thinking further down the line, where I'd hopefully like to integrate my probing routines and have the ability to get CAD position from axis counts, without doing the whole pause and wait while DRO positions are updated.

[TomKerekes]

Hi Moray,

I think I now (just about!) understand how things interact.

For DROs, KMCNC handles this in SetBigValues() with the following steps-
1)gets Axis allocations via CM->GetAxisDefinitions
2)DRO position/destination are then gained from the GetAxisDRO calls for each axis.
3)Those values are than passed through the Kinematics to get the CAD space position.
(or the above two are skipped if there's no KFlop attached, or we're in simulate, in which case we just get the basic interpreter positions)
4)DRO colours are set depending on each axis status/setting
5)Axis positions are then converted to DRO values
6)DRO positions are then displayed

This seems correct. Much of this code should probably be moved into the Libraries so each application can make use of it more easily.

Now I've worked that out, I'm guessing KMCNC gets axis this way, so it's easier to manipulate the DROs depending on what option is selected, as ultimately it's starting with the raw axis counts?
I'm assuming the same DRO values could be calculated using X_AxisPostion, X_AxisOffset, X_OriginOffset, and they already allow for kinematics?

Well no, the Interpreter positions are basically just the values in the GCode. So for example if there is a G0X0 followed by G0X10 then the Interpreter's X_AxisPostion will suddenly change from 0 to 10. However we want the DROs to show the actual real-time commanded position as the tool moves from 0 to 10. Additionally if the tool is Jogged, using Jog Buttons (or any other means without any GCode) to some random position, we want the DROs to display the where the tool is commanded to be. Furthermore KMotionCNC DROs can display actual measured position (when the axes have feedback) which the Interpreter doesn't have knowledge about.

Something else you may want to be aware of, but should be transparent to you, is that the GCode Interpreter often looks/works ahead many lines of GCode. This can cause problems when the Interpreter changes to be in a different state from what the tool is currently executing. For example a GCode Offset is enabled/disabled or many other things. Using the current tool position and the current Interpreter's state would result in an incorrect result. The KMotion Libraries have a powerful mechanism to request the current data point in KFLOP's buffered data and rewind the Interpreter back in time to the state it was when it created that data. The GetRealTimeState() code in the Interpreter handles this. .NET calls to the Interpreter state should automatically handle this. Note this also facilitates reverse feed rates to reverse through GCode.

HTH

[Moray]

Thanks for that information Tom.

I now have a rough plan on how I'm going to handle DROs, although I started looking at tools last night, and realised they're handled differently from offsets, so that's going to be my challenge for the next few days.

[Moray]

I'm just looking for a little bit clarification on the interpreter and the tool file.

I have my program successfully outputting the tool table in the required format, however does it need sorted?

I see KMCNC sorts it, and the notes in driver.cpp mention the table is indexed by slot, but nothing mentions that it must be sorted.
I'm also assuming although driver.cpp mentions slot, it now means tool ID, given KMCNC sorts primarily on ID, and not slot?


Also, should you be able to add duplicate tool IDs?
It's something I just tried while checking out how the tool table is sorted, and realised duplicate IDs can be added, and the interpreter defaults to the one with the lowest Slot. I can think of reasons why it could be useful (keeping details for unused tools), but I would have thought the risk of potentially selecting the wrong tool in g-code, would outweigh any benefits.

[TomKerekes]

Hi Moray,

I have my program successfully outputting the tool table in the required format, however does it need sorted?

It shouldn't need to be sorted. Whenever a Tool is referenced the Interpreter searches the Tool Table for the Tool. You might see in rs274ngc.c the function:

int ConvertToolToIndex(setup_pointer settings,int number,int *index)

Also, should you be able to add duplicate tool IDs?

It would probably be better to issue a warning.