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

101
The motion controller plugin will always "set" the positions.  The mcMotionGetPos() is for OTHER plugins to get the positions, if needed.  Things like the ModuleWorks cut simulator, etc...  The counts are doubles because to some controllers use real numbers for their counts!  To me, a count is a count is a count.  There is no in between.  As in, you will never see a quadrature encoder give a count like 1024.765!

But the world of stepper motors begs to differ.  The Ethernet Smooth Stepper is one that uses real numbers for counts.  And it DOES smooth out the pulse train.  Somehow.  I haven't quite figured out how and honestly don't want to hurt my brain trying to.  :)

Probing.txt is old and the gospel should be the one in the API manual under the plugin development category. 

Steve

102
The motion controller plugin should only deal in counts (or steps) so that it remains unit agnostic.  So this is usually an integer number, but it can be a real number as well (micro stepping, etc..).  All of the conversion to the native machine units is done in Mach.  The position (in counts) is then divided by the counts per unit in the motor tuning tab to derive a position in the native units of the machine.  

For the case of a probe strike, the motion controller should:

1. Latch the probed strike position (in ABS counts) for each motor.
2. Decelerate all of the motors involved in the probe operation to a stop.
3. Report the probed positons (in ABS counts) to Mach.
4. Report its' current positions to Mach (because Mach doesn't know where it all stopped!)
5. Tell Mach that the probe operations is complete. (This will sync the real world position to Mach's planners.)
6. Ack the stop report requests.  

All of this is documented in the API manual if you want a more technical explanation with the API calls that are to be used.  

Anyway, the Mach 4 motion control plugin paradigm is designed to be dumb as a rock.  All a motion plugin needs to do. basically, is follow the ball.  And tell mach when the requested movement is done, in most cases.  Homing and probing as about as complex as it needs to get, as these are real-time processes that just can't be handled in Mach.  

What is reported by the motion plugin ends up in 5071-5076.  The actual machine positions with no offsets applied.  Then the current offsets are applied to those and they go in 5061-5066.  So Michael is correct in stating that if what ends up in 5071-5076 will affect what is in 5061-5066.

Steve

103
Yeah, I don't know why people use the message box.  There is NOTHING more aggravating.  You can paint yourself into a corner quickly if you move some code from say like a macro script to the PLC script!  mc.mcCntlSetLastError() is a much better choice.  Or mc.CntlLog() and watch the diagnostic log window. 

Also, in the new builds, I have put in:

number: rc = mc.mcCntlMacroAlarm(number: inst, number: error, string: message)
number: rc = mc.mcCntlMacroStop(number: inst, number: error, string: message)

Using mc.mcCntlMacroAlarm() basically does the same thing that writing a number to #3000 does in G code.

#3000 = 16 (Error 16 condition)

is the same as

mc.mcCntlMacroAlarm(inst, 16, 'Error 16 condition')

This will cause "Error 16 condition" in the status history, stop the cycle (not E-Stop), and raise the OSIG_ALARM signal.  The alarm can only be canceled by hitting reset.  OSIG_ALARM can be used to drive a yellow beacon light or similar that is commonly found on production CNC machines. 

Using mc.mcCntlMacroStop() basically does the same thing that writing a number to #3006 does in G code.

#3006 = 12 (Error 12 condition)

is the same as

mc.mcCntlMacroStop(inst, 12, 'Error 12 condition')

This will cause "Error 16 condition" in the status history and stop the cycle (not E-Stop) without raising the OSIG_ALARM signal.  It does not need to be canceled by a reset.  Basically, it is the same as hitting the cycle stop button. 

These functions are good for M code scripts because they will stop the machine if they are used for error conditions.  The rest of the script may process, but the control will not advance to the next line of G code.  But typically one would return from the script right after calling one of these functions.  Of course, in order to use these functions, you have to write scripts that check for error conditions in the first place, right?  :)  If you are going to write scripts, it doesn't really matter if it is for a hobby machine or an industrial production machine, do it right.  People sometimes say "it is just a hobby machine", etc...  And I call BS!!!!  Doing things the right way will save you time and money in the future.

Steve

104
The scripting manual shows where to go to edit all of the scripts.  It is in the screen editor.  Screen Load script, PLC script, Singal script, screen unload script, timer scripts, etc...  Even the control event scripts.  They are all in the screen editor.  The latest release (3804) on the website has all of these documents in the Docs folder of the installation directory. 

"Mach4 Screen Editor V1.0.pdf" and "Scripting Manual.pdf" are of particular interest. 

The scripts will be in the property/event grid (events button).  Go to the top element of the tree (the screen object) and then click on the events button in the grid. 

Steve

105
For that, you will most definitely have to use the screen API.

string: value, number: rc = scr.GetProperty(string: ctrlName, string: propertyName)

number: rc = scr.SetProperty(string: ctrlName, string: propertyName, string: value)

The control name is the name you have given the screen element in the Name property.  It is case sensitive. 
The property name is the name of the property as spelled in the property grid.  Value, for example. Or Top, Left, Width, Height, etc...

The value of the property is always a string.  Use tonumber() to convert a string to a number in LUA.  Conversely, use tostring() to convert a number to a string.  Some properties are lists, which have values associated with the string description in the list.  In this case, you will get the value instead of the string description.

If you open up the screen editor and look at the properties of a regular button, you will see a property called "Bg Color".  This is the property you will want to set with scr.SetProperty().  The property is editable in the screen editor with a color picker control.  But it is actually stored as a string.  A call to scr.GetProperty("myButton", "Bg Color") will reveal the stored value.  If the returned sting is blank/empty, then the default color based on the current Windows theme will be used.  Otherwise, it will return a value in HTML RGB format like "#RRGGBB"  #FF0000 is pure red, #00FF00 is pure green, #0000FF is pure blue.  Any color can be represented with this syntax. 

An easy way to get the value for the color you want is to open the screen editor, set a button's "Bg Color" to the color you want, and then use scr.GetProperty("myButton", "Bg Color") to get the value.  Record it, and then maybe change the color and get more values.  Otherwise, there are probably lots of color picker tools out there that are capable of doing this too. 

Once you have your color values, then you can set the button color based on the current jog increment in the PLC script.
Code: [Select]
if (incr == .001) then
    rc = scr.SetProperty("myButton", "Bg Color", "#FF0000") -- set button color to red if incr == .001
elseif (incr == .01) then
    rc = scr.SetProperty("myButton", "Bg Color", "#00FF00") -- set button color to green if incr == .01
elseif (incr == .1) then
    rc = scr.SetProperty("myButton", "Bg Color", "#0000FF") -- set button color to blue if incr == .1
end

Steve

106
Allan is 100% correct on this.  And he also tested empirically.  Good job!  

A G31 move will either skip, or not.  Meaning probe strike, or not.  If the probe strikes a surface, the G code variables are filled with the strike position.  If the probe does NOT touch a surface, the G code variables will contain the end point of the move.  Normally, this is the ONLY way to know if the probe has touched a surface in G code is by comparing the G code variable positions to the end point of the move.  If different, the probe struck a surface.  

Since Mach is not running on a real time OS, it can't possibly capture the strike position accurately.  So this job is delegated to the motion controller, which is a real-time device.  So if the values in those G code variables are not correct, then I would suspect an issue with the motion controller or its' plugin.  

If there is a hang waiting on a set still, then the motion control plugin is not working correctly.  Again, since Mach is not running on a real-time OS, and Mach doesn't know the outcome of the G31 move, it will ask the motion controller/plugin to tell it when the move is complete.  It could have reached the endpoint of the move or stopped somewhere in between.  Mach just doesn't know.  So Mach will wait indefinitely for a response back from the motion controller. If no response is given, hang.  

Fanuc only specifies the variables #5061-#5066, which should be the position with all current offsets applied.  Mach also gives you #5071-#5076, which should be the machine position.  All of these positions are in native machine units.  Meaning if you setup the machine for inch, then inches is what you will see in those variables, even if you are probing in G21.  

On an inch machine:
G90 G21
G00 X0
G31 X10 F1000 (probe does not strike)

At the end of the move #5071 == .393701 (inch value for 10mm)

Steve

107
Thanks for the input Steve,

Just curious, why is anything under 16 GB bad for windows 10? 

When it comes to regenerating my toolpath, I've gotten in this cycle start habit of Regen --> Cycle Start.  Just to be safe.

Because a stock Windows 10 installation on a new machine (Dell, etc...) idles at 12GB.  They put all of that bloatware on there.  Plus all of the MS telemetry stuff.  If you are persistent enough to remove all of the crap, then 8GB might be ok.  All it takes is a quick look to the task manager to see how well the machine will perform.  Virt mem vs. Physical mem.  If your virt mem is higher, expect the machine to be sluggish.   My machine is idling at 21GB as we speak!  Now, it is a development machine.  But let's face it, that is the amount of memory my machine REQUIRES to operate like I want it to.  All that is running is Visual Studio, email, web browser, file manager, Skype, and Mach.  The big ones are Skype and the web browser.  Next is the Visual Studio.

Steve

108
Mach4 General Discussion / Re: IMTS 2018
« on: May 24, 2018, 04:57:13 PM »
I don't know what our plans are for IMTS this year.  When I find out, I'll let everyone know. 

I like going and meeting the people I converse with on this board.  I missed it last time around because it fell on my 10th wedding anniversary.  :(

Steve

109
It is not a 32 vs. 64 bit thing.  It is a processor/memory thing.  Mach 4 does things differently than Mach 3 did on the file loads.  The capabilities of the interpreter are far more advanced and requires a LOT more switch code.  Thus it does take more processor power to generate the tool path.  The newer builds will be an improvement in this regard, as I optimized it as much as I could.  

With the latest build, on my desktop machine, I can process 1000 lines of G code per second or 1 G code line per millisecond.  Now, my Atom board WILL NOT do this.  :)

The files are memory mapped.  This enables files that are far larger than the 32 bit address space.  However, if your machine is swapping memory to disk, well...  it is GOING TO BE SLOW.  I agree that 8GB of RAM is not sufficient for a Windows 10 machine.  Anything less than 16GB is uncivilized.  

If you change an offset, you MUST regenerate the tool path.  We don't auto regenerate because you may need to change several offsets and would then have to wait on each offset to regenerate the tool path.  

Steve

110
The stock jogging will follow G20/G21.  Also, the increments are defined in the General setup tab.  Define them in the order and content that you want. 

The common cycle start is on 95% of the commercial controls.  There is usually a switch on the panel to direct the cycle start to run the MDI.  All the YASNACs, Fanucs, and Fidias that I have run have been like that.  In this case, the "switch" is the current tab.  But I don't use the screen for these functions at all, because of some of the same concerns.  I use a panel to run my whole machine just like I did when the control was a YASNAC.  No mouse clicky stuff.  It is a touch screen and I do use that to load files, etc..  But that is the extent of it.  Basically, the screen is there for display purposes and I run the machine with the panel.  MPG, FRO, SRO, jog buttons, cycle start/stop feed hold.  Like God meant for CNC machines to be run.  :)

Steve