Hello Guest it is May 19, 2019, 03:07:27 PM

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

21
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

22
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


23
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

24
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

25
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

26
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

27
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

28
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

29
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

30
Mach4 General Discussion / Re: Mach 4 homing erroer
« on: February 28, 2019, 07:39:36 PM »
Also check

Configure->Control->Motors  And make sure the check boxes are checked by all of the motors that you use.

Steve