Well...  now that the tool paths have been moved entirely to the GUI, mcToolPathGetDrawLimits() isn't used by the GUI anymore (And that was a predominantly GUI API function call, as plugins and motion controllers would never use it). 

The limits do indeed use the soft limits and there is nothing that can change that at the moment.  Or the line style.  I may put something in the tool path properties for the line style.

I'll also think about adding a collision boundary that can be set independently of the soft limits. 

Steve

Hi Smurph,
thanks for that explanation.

Does the fact that the tool path display is moved into the GUI in its entirety mean that the mcToolPath* APIs no
longer work or perhaps clash with how the GUI is operating?

Most of my machining, excluding PCB isolation routing, is pretty simple, face the material, two pockets and a row of holes....
sort of thing. I use MillWizard, I like it, and its so simple.

I have a hankering to do something similar but rather than a wizard it would be another page (tab) in Mach4. Getting the
required input data and using Lua to generate the Gcode would be long winded but eminently possible. In order for the
operator (me) to confirm the Gcode prior to machining I would like to use Machs tool path display, maybe even interactively.
Is it possible for me to seize control of Machs tool path window or alternately create a new one for the purposes of my
Gcode visualization pane?

I would also like to take the opportunity to thank you, and if you would be kind enough to pass on my thanks to other
members of the development team, for the advances made to Mach4 in recent times. You may have noted I have been
vociferously (who me?? ) promoting Mach4 recently. The most recent developments Surface Map, script based THC
and Trace now put Mach4 squarely ahead of Mach3 functionality. Not only is Mach4 more functional than Mach3 but
those things that Mach3 does are so much better in Mach4, the Modbus plugin is one example and the use of Lua is another.

Do you have any more developments in mind for the near future?

Craig

The inside the core tool paths still use the API tool path functions.  And the core tool path properties (color, line width, etc..) will be the default for any newly instantiated tool path control in the screen editor.  We decided to move the tool path code directly in the GUI for a variety of reasons.  Not the least of which is making a remote GUI that can operate the control on the machine.  It is in the latest builds.  I call it Mach4GUIR.exe.  Very original.  Not many people would have thought about appending an R to the Mach4GUI.exe.    Anyway, all jokes aside, GUIR doesn't currently have a tool path.  But it will soon!  And that just couldn't be done with the tool path in the local core.

But a version of the tool path does still exist in the core.  It is just that our main GUI doesn't use it anymore.  However, the static wxMach.exe GUI still uses the core's tool path.

We originally put the tool path in the core so that people who wanted to write their own GUIs didn't have to mess with OpenGL.  They simply use our API. 

You can't really create a new tool path control on the fly.  But you can have one that is hidden and then show it.  Mach Motion uses that technique in their screen sets. 

I loved Mach 3.  What a masterpiece it was.  Art simply did an amazing thing when he created it.  But Mach 4 is doing really well now as most newcomers are simply not going for Mach 3.  And despite what people post here, there are a lot of people that were running Mach 3 making the move to Mach 4.  Especially if they need something custom. 

You are welcome for the new stuff.  It is my pleasure.  Stuff I have in mind for the future is 3rd order planner, tie the multiple instances together for true multi-path capabilities (Screw machines, Mill/Turns, etc..), and kinematics.

Steve

Hi Smurph,
all very kool.

I'm going to experiment with the tool path and see what happens. You pegged me correctly, I don't have the first
idea about using OpenGL, if I can't use a solution like Machs tool path then my idea will probably progress.

I find that I have to reduce the acceleration of my machine because it tends to shake itself and wander around the bench
despite the steppers being capable of rather more. It may be that a 3rd order planner would tame it somewhat, I loo
forward to it.

Craig

Stuff I have in mind for the future is 3rd order planner, tie the multiple instances together for true multi-path capabilities (Screw machines, Mill/Turns, etc..), and kinematics.

Steve

Looking forward to what you guys bring in the future!  Especially multiple instances and kinematics.

I may put something in the tool path properties for the line style.

I'll also think about adding a collision boundary that can be set independently of the soft limits. 

Steve

I know this is an old thread but yes, please add ability to change the line weights, colors and styles of each type of movement. Maybe even the size or type of crosshair cursor.
It's either the monitors or my eyes but it's tough to discern cuts when rapids are written all over the top of them.
And then there is the colorblind argument....

Hi,
in Screen Editor mode look at the properties of the toolplath window, per attached.

You can edit colors for contrast etc.

Craig

Yes, but not granular enough, can't change widths for each line type separately.

Hi,
you can change the path width, axis width, and soft limit widths, is that not enough?

Mach4 is a CNC software solution not a graphics application!!

Craig

Hey, I'm new to this and I was offering a suggestion, to a graphics related post, as it appeared was asked for. Rapids crisscross the tool path and can make it unreadable. If you make the rapid the same color as the background, as was suggested elsewhere, the tool path lines are broken up because the rapid is on top of the path layer giving the same result.