G-codes/offsets/tools with .Net

[TomKerekes]

Hi Moray,

btw what method do you plan to do the graphics with? OpenGL?

[Moray]

I was going to try the inbuilt Viewport3D first.

I did look at a few options, but there generally seems to be a lack of C# graphics libraries.
Most graphic libraries appear to still be based around C/C++, with anything newer opting for Unity. If you search for C# graphics, all you'll get is pages of tutorials for Unity, as it's the must use commercial library for building games.

I did find some OpenGL C# wrappers, but I couldn't find any that been updated/maintained recently, and I don't want to use something that doesn't have reasonable support.


My current plan is to use Viewport3D, as it's free, and it will at least let me understand how everything interacts. If need be, I can move to something else later, as it should be a relatively simple task to re-write the code for generating the graphics.

[Moray]

I've hit an issue with the graphics :-/

If I single step through the code (I'm using Dynomotion.ngc), everything works as I expect. I step 20 times, the handler triggers 238 times, and if I step as far as the first 'o', it's been triggered over 10'000times.

However, if I try running the code (either in simulation, or with a machine running) the handler only gets triggered 982 times.

I thought it was something to do with how I was generating the graphics, but even stripping the code back to just a simple integer counter/label that increments each time the handler gets called, the issue remains.

I'm adding the handler in LaunchExecution-

Code: Select all

KM.CoordMotion.CoordMotionStraightFeed += new KMotion_dotNet.KM_CoordMotionStraightFeedHandler(StraightFeedHandler);

Then the handler is simply-

Code: Select all

private void StraightFeedHandler(double DesiredFeedRate_in_per_sec, double x, double y, double z, int sequence_number, int ID)
        {
            handlerTest++;
            //Viewer_AddLine(new Point3D(x, y, z));
        }

With the handlerTest displayed on a label every timer tick.

The only difference I can see between single stepping and run, is the handler gets added every time single step is triggered, but from my understanding, that's how KMotionCNC does it as well...

Any ideas?

[TomKerekes]

Ho Moray,

I can't really make sense of those numbers without more info but there are significant differences between Simulation, Single Stepping, and Running free. So I would expect the counts to be different.

I think with Simulation Trajectory Planning isn't invoked so each GCode G1 should result in a single call back.

With single stepping (non-Simulation) there isn't any look ahead so each motion is a perfectly straight line and is exactly executed as specified in the GCode. Depending on length, feed rate, etc it may be subdivided into multiple line segments. Possibly generating multiple call backs per step.

With running free (non-Simulation) the Trajectory planner can look ahead and potentially combine segments based on Collinear Tolerance potentially reducing call backs. It can also round corners that would generate many more segments and callbacks.

That all being said I wouldn't expect Free running Simulation and Free Running non-Simulation to be the same. Also I'd expect free Running (non-Simulation) to generate more callbacks not less than Single Stepping (non-Simulation).

[Moray]

I've just realised what the problem is.

The handler use inches, but I've had a bug in my single step code, where the first line gets skipped, so the G21 was ignored, I've not realised, and I've not been zoomed in close enough to see anything other than a green blob in my viewer.
Plus I seem to have an issue where in simulation, the DROs get converted twice from inch to mm (i.e. 1inch = 645.16mm)

I knew it would be something stupid.
I now need to work out how I'm going to handle arcs, and fix the bug where traverse lines are always starting from the origin.

[xdmattz]

Moray,

It looks like you have made a lot of progress on converting to KMCNC to C#. Is this a personal or a work project, and if it is personal... would you be willing to share? Maybe post it on GitHub?

I've got an old Bridgeport Discovery 308 VMC machine I've been working on for about 18 months now. And it is time to decide whether or not I'm going to stick with Mach3, move to KMCNC, or try to write something custom based on KMCNC.

You can see the progress I've made at https://github.com/xdmattz/BP308.

Thanks

Dan Matthews

[Moray]

Hi Dan,

at the moment I'm undecided whether I'm going to share the full code for this or not. I've got a few ideas I'd like to implement, which will be a lot of work, and I'm not sure I'd want to publish the code for no reward.
I will certainly be uploading a complete exe so others can use the program, but only once I'm happy it's functionally able to work a machine at a basic level reliably.

I'm currently working through a list of required functionality so I can use it on my own mill, which at the moment is adding the ability to set offsets to custom values.
Next is then a tool setting screen, as I keep tying myself in knots with that when using KMotionCNC.




Tom, I'm needing to clarify something with offsets, I'm not entirely sure if I'm handling them correctly.
At the moment, when I change a work offset, I do the following after calling SetOrigin -

Code: Select all

            KM.CoordMotion.Interpreter.SetupParams.OriginIndex = -1;  // force update from GCode Vars
            KM.CoordMotion.Interpreter.ChangeFixtureNumber(1);  // Load offsets for fixture

(it's currently hard coded to 1 for testing)

Is this a reliable way to ensure the currently active offset is reliably updated after being changed, or is there a better way?

I'm also using a G52 call to set the global offset. Again, is that the best way?

[xdmattz]

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

[TomKerekes]

Hi Moray,

Tom, I'm needing to clarify something with offsets, I'm not entirely sure if I'm handling them correctly.
At the moment, when I change a work offset, I do the following after calling SetOrigin -

Code: Select all

KM.CoordMotion.Interpreter.SetupParams.OriginIndex = -1; // force update from GCode Vars
KM.CoordMotion.Interpreter.ChangeFixtureNumber(1); // Load offsets for fixture

(it's currently hard coded to 1 for testing)

Is this a reliable way to ensure the currently active offset is reliably updated after being changed, or is there a better way?

I think that's the best way.

I'm also using a G52 call to set the global offset. Again, is that the best way?

You should be able to change the G92/G52/Axis Offset with the same call as above with index of 0.

Code: Select all

      /// <param name="index">Origin index - 0 for G92 offsets, 1-9 for fixture offsets</param>

[Moray]

I'm also using a G52 call to set the global offset. Again, is that the best way?

You should be able to change the G92/G52/Axis Offset with the same call as above with index of 0.

Code: Select all

      /// <param name="index">Origin index - 0 for G92 offsets, 1-9 for fixture offsets</param>

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.