Messages

481

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. 

Steve

482

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... 

Steve

483

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.
end

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! 

Steve

484

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. 

Steve

485

Mach4 General Discussion / Re: Is there a Gcode command to reference all axis home?

« on: March 24, 2019, 01:54:53 PM »

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).

Steve

486

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. 

Steve

487

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!!!!

Steve

488

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. 

Steve

489

Mach4 General Discussion / Re: pmdx411 cannot communicate with device

« on: February 28, 2019, 09:21:59 PM »

A choke is basically a device to prevent common mode currents on the signal lines.  Usually, all it consists of are ferrite cores.  Such as https://www.mouser.com/ProductDetail/Fair-Rite/2643625002?qs=MLldULe7zY2ZDvtexqlGbA%3D%3D.

Pass the wires from the MC-60 through the core (as many turns as you can fit).  Do all three of them.  It is important that the choke is as close to the G540 as possible.  Say within an inch or so.  Meaning it doesn't have to be .0001 close!   

http://www.w6pql.com/images/hf/hftkctrl.jpg

In that picture above, the heavy pinkish/red wires are passed through some larger cores.  And then there are a lot of signal wires or different colors being choked as well. 

Steve

490

Mach4 General Discussion / Re: pmdx411 cannot communicate with device

« on: February 28, 2019, 08:59:01 PM »

Probably the new MC-60 motor controller is noisy and wigging out the G540, PMDX-411, USB or all of them!  I would put some chokes on the MC-60 wires close to the G540.

Steve