G-codes/offsets/tools with .Net

[Moray]

Moray,

Thanks for the response. I can certainly understand you not wanting to give away all that work, or putting something out there that you don't feel isn't quite finished. But it never hurts to ask. Hope you can get things running how you like. Maybe you can post a short YouTube video of your machine running when you get everything figured out.

I don't know how Tom K. Finds the time to answer all these forum posts. Kflop must be a labor of love for him. But I'm grateful that he does.

Dan Matthews

I would upload the current program, but it's needing the layout fixing, as I've still got the screen randomly extended to try and get the graphics working how I'd like (which have been placed on the back burner for now, as I don't see them as essential at the moment).

[TomKerekes]

Hi Moray,

I'm sure I tried that while loading offsets, and any change in the global offset never took effect, so I had to use a G52 call.
And having just re-checked, that method doesn't work. The offset itself gets updated (i.e. the new/updated offset value is returned with a GetOffset), but the active offset doesn't get updated (the DRO value doesn't change to reflect the change in global offset).
It's only an issue with the global offset, as there is no way to trigger a reload that I know off, whereas with the work offsets you simply switch offset and back again to reload the new offset values.

Ah. I see KMotionCNC updates the Axis Offsets with:

Code: Select all

		settings->axis_offset_x = Vars[5211];
		settings->axis_offset_y = Vars[5212];
		settings->axis_offset_z = Vars[5213];
		settings->AA_axis_offset = Vars[5214];
		settings->BB_axis_offset = Vars[5215];
		settings->CC_axis_offset = Vars[5216];

In your case since you just changed the Axis Offsets you should have them handy so probably don't need to read them back, just set them also into the current Interpreter Setup Parameters with code like:

Code: Select all

            _Controller.CoordMotion.Interpreter.SetupParams.X_AxisOffset = 10.0;
            _Controller.CoordMotion.Interpreter.SetupParams.Y_AxisOffset = 20.0;
            _Controller.CoordMotion.Interpreter.SetupParams.Z_AxisOffset = 30.0;
            _Controller.CoordMotion.Interpreter.SetupParams.A_AxisOffset = 40.0;
            _Controller.CoordMotion.Interpreter.SetupParams.B_AxisOffset = 50.0;
            _Controller.CoordMotion.Interpreter.SetupParams.C_AxisOffset = 60.0;

HTH

[Moray]

I was about to post and say that doesn't work, but then realised you mean to use SetOrigin to set the global offsets, then use that code to make them active, which it does.
At least in simulation (I've not got a KFlop handy to test it while connected), although the DRO doesn't immediately reflect the change, unlike when using the G52 call, but my temporary DROs showing offsets and doing a G0 G53 X0 shows the offset is being applied correctly in simulation.

Thanks for that.

[Moray]

So I've spent the past few days ironing out some bugs in my existing code, and finally hunted down a bug that has been annoying me.

I've attached the latest build, which I think should work if you copy it to the KMotion/Release folder (I'm still using 4.35b, and the default file to open is hardcoded to that version, but the required setting file should be created in the current Release folder.

At the moment, the very basics work.
Layout is largely similar to KMotionCNC for now, with the main exception being everything is done via tabs.
You can config the interpreter for 3axis.
You can open GCode files, but not save any changes made in the viewer.
You can set the interpreter up in either Inch or MM (Master Units box on the config/trajectory planner page)

All settings/tools/offsets are stored to the default KMCconfig2.xml file, which should be created the first time any settings/tools/offsets are saved. This file can be changed, although I've just realised I've not added the required code so the latest config to be loaded is saved, so even if you create a new config file (you'll need to copy the default one manually for now), when you reopen KMoCNC it'll open the default file.

And having just tested that, I've realised I've not fully quashed that bug that was annoying me, so if you use the radio buttons to change between G20/21 or run an MDI, the g-code viewer will jump to line 2, and you'll need to click the restart button to reset to line 1

The viewer tab will possibly produce something viewable if your sample file sizes are big enough, but getting it working is well down my list of things I'd like to add, as I really need a clear run to try and learn about the C# drawing/graphics options.
The Tool Setting tab also does nothing, it was just thrown together a couple months ago so I could think about how it would work.

My next steps are to quash that &£"*£$*£ bug that's now annoying me more, then think about layout.
My goal is to have this touchscreen friendly, but I'm still quite undecided about offset/tool page layouts. The existing page layouts were just a lazy way to implement the mechanics, but it is all done in XAML so changes should be fairly easy.
For the main screen, I'm thinking more off a proper machine control type layout, with lots of buttons.
If anybody has any suggestions/ideas for the layout, I'd be interested to hear them.

I also have a couple ideas brewing for removing a lot of the need for manually created C programs, whereby you set everything via the app, and the app generates the required C program(s).


I don't expect anybody to spend much time testing this version, as it is very barebones just now, but if people could at least copy it to their Release folder, and at least let me know it runs, I'd be grateful.

[TomKerekes]

No it won't run for me. Copied it to c:\KMotion435b\KMotion\Release. Nothing appears to happen and no files created in that folder. Probably missing a DLL. Dependencies says missing 3DTools.

[Moray]

Ah. That'll be the graphics library I used for the viewer.
I forgot that relied on a separate DLL, which should be attached to this post. It'll need copied to the Release folder, and hopefully should work.
I've also uploaded a version with the current line and config saving bugs sorted.

Tom, I'm just looking at how the whole KFlop to PC commands work.
Am I correct this is all handled via Persist variable 100, and ServiceKFlopCommands()?

ServiceKFlopCommands monitors the persist variable 100, does what it needs to, then sets Persist Variable 100 back to 0 on success, or -1 on failure?

[TomKerekes]

It runs! Although I had to create a emc_test.var file.

[Moray]

Tom, I'm just working through testing the my whole mm/inch mode, as I knew there were some aspects I hadn't got fully converting when needed.

The big issue I've noticed just now, is tool offsets don't get converted when the interpreter switches between mm/inch.
I.e. I load a tool in mm with an offset of say 5mm and have the machine coords at zero, the Z DRO shows -5 as expected. However if I change to G20, the DRO remains at -5. It's like the interpreter doesn't convert the tool offsets. The same issue applies if I setup tools in inch, and switch to mm.

I have tested with work offsets, and they work as expected.

I am using CoordMotion.Interpreter.SetupParams.SetTool to set the tools, and not via the tool file.
And having just tested using KMotionCNC, it has the same problem.

I see some tool table changes were made in 4.55c, but did they fix this problem?

[Moray]

Actually, having done a bit more testing, the same problem does partially apply to offsets.

I thought when the interpreter changed between inch/mm, the already stored offsets got updated?
When you switch between inch/mm, the existing offset updates as expected, but if you then reload that offset, the conversion doesn't happen.
I.e. if you have an active G56 offset of 1 inch in G20, and issue a G21, the DRO updates to 25.4mm, but if you then call G56 again, the DRO switches to 1.

[TomKerekes]

Hi Moray,

Unfortunately the Nist EMC Interpreter didn't handle units well. The offset tables don't have any units. They are all just numbers. The basic idea is that the units of each value in the table are assumed to be in whatever units of the Job they will be selected with.

Incidentally one related issue on program launch was recently fixed in Version 4.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.

That required an additional Interpreter parameter length_units_of_origin.

I haven't thought of a simple solution that allows backward compatibility. One thought was to allow each value in the table to have a mm or in suffix. If not present than the current behavior would be maintained. But if added then the appropriate conversion would be performed if the current interpreter mode differs from the suffix. But that seems messy.