Hello Guest it is October 16, 2019, 11:14:50 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - smurph

Mach4 General Discussion / Re: Using the Serial plugin from a macro
« on: April 01, 2019, 06:24:21 PM »
I would use the laurs232 module instead.  Do it all in your M3/M4/M5 mocros.  The serial plugin is old... pre LUA modules.  Once we put LUA modules in, it pretty much eliminated the need for the serial plugin. 

Mach4 General Discussion / Re: How do I make the Extents mode visible
« on: April 01, 2019, 12:16:24 AM »
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.  :D  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.


Mach4 General Discussion / Re: How do I make the Extents mode visible
« on: March 31, 2019, 01:42:59 PM »
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. 


Mach4 General Discussion / Re: How do I make the Extents mode visible
« on: March 30, 2019, 11:37:04 PM »
The most recent builds of Mach have a lot more settings in the tool path control's properties in the screen editor.  Color pallet, line widths, etc... 


Mach4 General Discussion / Re: Mach4 Lua for Dummies
« on: March 29, 2019, 08:07:03 PM »
That is a good notebook! The only think I would comment on is that it is MUCH better to get or change the data that drives a DRO or LED than getting/setting the value with scr.Get/SetProperty().  One of your examples was getting the current Y position:

Code: [Select]
local StartPos = scr.GetProperty (‘dro Current Pos Y’, ‘Value’)

The better solution is to use the main API:

Code: [Select]
local StartPos, rc = mcAxisGetPos(<instance>, mc.Y_AXIS)
if (rc == mc.MERROR_NOERROR) then
    --We successfully got the Y axis position.

Why is this better?  Well...  Because the screen controls are updated on an interval.  This is called the screen refresh interval.  It may not be the MOST current value of the data.  The system may have a value of 3.401" for the Y axis but the DRO may have not been updated to that value because the screen has not refreshed yet when the code was run.  Also, the main API functions return defined error codes that can be checked for success or fail after calling the API function.  Checking the the API return codes is VERY important for developing robust processes.  I like to say "If you check the return codes, there will be no mysteries."

As mentioned in another post, this is why the scr.* functions are not documented.  Because there is a better (and documented) ways to do most things.   

But that is a fine collection of useful information! 


Mach4 General Discussion / Re: scr list
« on: March 29, 2019, 07:44:25 PM »
The reason they are not documented is to discourage their use.  Because most of the time, there is better way to solve the problem.  Some of them were for Mach 3 like behavior.  The only ones I would even suggest for general purpose use are the scr.GetProperty(), scr.SetProperty() and scr.ExecMdi().  There are plenty examples that use these.  The ones prefixed with "Editor" are for industrial licenses only where an in screen editor can be present. 


The home speed is configured in Homing/Softlimits tab as a percentage of the axis' maximum velocity.  The axis maximum velocity is derived from the slowest of the motors that run the axis (Motors tab).


Mach4 General Discussion / Re: Windows 10?
« on: March 24, 2019, 01:37:40 PM »
Just for you guy's information, Mach 4 is developed on Windows 10. 


Mach4 General Discussion / Re: pmdx411 cannot communicate with device
« on: March 14, 2019, 02:37:48 AM »
Don't you just love it when something works?  :)  Ham radio to the rescue!!!!


Mach4 General Discussion / Re: last line not executing
« on: March 04, 2019, 05:55:32 PM »
I'm not sure what your end goal is, but you won't be able to home an axis in an M code script.  The script you posted would work (with modifications) in a button script though. 

Why do we not allow homing in M code macros?  Well..  it is because the machine is not in the IDLE state.  It is in automatic mode.  You can't do a manual mode function (jog, MPG, homing, etc...) while in automatic mode. 

The thing that isn't happening with the script is waiting for the home ops to complete.  You can wait on them by checking the state of the machine with mc.mcCntlGetState().  The first thing to do is call the home ops (checking the return codes to make sure there are no errors).  Then loop until the state is not equal to mc.MC_STATE_IDLE.  Once the state is no longer IDLE, loop and wait for it to return to idle.  The home ops will have completed at that time. 

None of that script checks any return codes.  There are no mysteries if you check the return codes.  :)