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

Nice panel Steve!


Mike

Ok, I'm gradually getting to grips with this having re-read the above posts and tried a few things that actually work!

One thing I can't figure out is the following. I've now got buttons on the jog panel for setting the increment for the jog step. I want those to work like Radio Buttons and I can now see how to set the background colours of the buttons to show which is active.

I take on board that the information about which is active should be linked to the actual increment that's set in memory, and for that I can see I can use the following...

increment, rc = mc.mcJogGetInc(inst, mc.X_AXIS)

... to find the increment on one axis which should be the same as all of them.

However, I can't see how to set the colour of the buttons on starting Mach4. I need to add something to some kind of initialisation script which I presume runs when the screen is displayed for the first time.
I've looked through all of the screen object and there doesn't seem to be a container that has such a script.

Can someone point me in the right direction as to how to set initial values for the button colours based on the actual jog increment value?

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

Hi Steve,
That all makes sense, but where is the PLC script? I don't know where to find that and edit it.

I also notice that the Feedrate % and the Spindle % values in the Mach4Mill profile stay mostly at zero then flicker to some other unreadable value. I'm not sure why that's happening, but I need to fix it.

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

Thanks Steve, I couldn't see those scripts anywhere. I've had a look at the Scripting Manual before, but it makes more sense now.
Hopefully I now have enough to have a proper attempt to customise this how I want.
Many thanks for your help.

Hi striplar,
you're on the right track.

It is common to use wx.MessageBox() statements throughout your code as a diagnostic aid to indicate the program having progressed. The only place you cannot do
that is the PLC script, and I see that part of your work will bee in the PLC script. Remember DONT use wx.MessageBox() there, mc.SetLastError() is fine though.

Craig

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

Hi Steve,

Yeah, I don't know why people use the message box.  There is NOTHING more aggravating

I found that when I was starting to code in Lua that I tended to copy what others had written previously and adapt it to what I was trying to achieve.
wx.MessageBox was and to my knowledge still is used as a diagnostic flag. It has its drawbacks, I found one by putting a wx.MessageBox() in the PLC
script for instance. So the reason I used it was simplicity and I copied what I had already seen.

I tend to use mc.CntlSetLastError() now.

I like those new APIs....no doubt they'll flow into the API.chm at some future date....

Craig