Machsupport Forum

Mach Discussion => Mach4 General Discussion => Topic started by: striplar on May 19, 2018, 04:47:59 PM

Title: Using a button script to set jog increments etc
Post by: striplar on May 19, 2018, 04:47:59 PM
I've created buttons that I want to be able to click to automatically set the Jog mode to incremental and a specified increment. I originally did this without scripts but found there's a bug that occasionally moves 1" instead of 1mm!!!
I found a post about this and another function that forces the Jog to be metric so I'd like to combine all three calls in one script.

This is what I have, but it doesn't work.

   local inst = mc.mcGetInstance()
      --First force units to metric, it sometimes reverts to inches!
   mc.mcJogSetUnitsMode(inst, mc.X_AXIS, 21)      --I don't know why 21, but that's what the post said!
   mc.mcJogSetType(inst, mc.X_AXIS, mc.MC_JOG_TYPE_INC)
   mc.mcJogSetInc(inst, mc.X_AXIS, 1)   --1mm increment
   
I know the script is being executed when I click the button, I added a 'hello world' dialog box to the start of it to check.
I presume that the calls are inaccessible from where I'm trying to call them from?

I need to do this so I know for certain what's going to happen when I'm using an edge finder, or nudging up to an edge with a cutter. 25mm unexpected moves are not acceptable!

Any help would be much appreciated.
Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 19, 2018, 05:07:45 PM
Hi,

Quote
mc.mcJogSetUnitsMode(inst, mc.X_AXIS, 21)      --I don't know why 21, but that's what the post said!

This API call is not in the API.chm list. There are a few circumstances where an API call has been created but the documentation has not....yet.
smurph did explain in another post recently that his development PC had a melt down and all his development software went with it... including
the ability to write Windows Help files like our API.chm. He has only recently started putting it all back together....he explains also that he needs
a week of bad weather before the inclination to generate documentation overcomes him!

I'm going to guess that the '21' in the API call is somehow related to G21...which is the Gcode that cause all subsequent Gcode to be interpreted as metric.

Does your build of Mach have the new Zero Brane editor? If it does try typing out the API in question and the auto complete window will come up and then
with the opening '(' a list of required arguments and their types will come up. I suspect that the bare 21 in your code is not correct, it might have to be quoted
for instance.

Craig
Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 19, 2018, 05:16:25 PM
Hi,
I've just gone and fiddled with the API and sure enough and unitsMode:number is just a plain Lua number, so 21 is acceptable, but is is the right number?

Going to take a help ticket to find out.

Craig
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 19, 2018, 05:57:02 PM
Here is the actual button down script I use. I have totally replaced the stock jog functions and this has proved reliable for a long time. This should give you some ideas from which to build, but note that I do not take any stock value for distance and jog type, as I created my own and saved them in the INI file. I call this from buttons and from keys mapped into the signal script.

Code: [Select]
--AW Jog button down initiates motion.
-- type is taken from INI if no parrameter is supplied
function Jogging.JogBtnDown(axis, direction, type)
    local inst = mc.mcGetInstance()
    if (type == nil) then
        type = mc.mcProfileGetInt(inst,'Preferences', 'JogType', mc.MC_JOG_TYPE_INC)
    end
    local dist, rc = mc.mcProfileGetString(inst,'Preferences', "JogDist", '0')
    dist = tonumber(dist)
    local defUnits = mc.mcCntlGetUnitsDefault(inst)
    rc = mc.mcJogSetUnitsMode(inst, axis, defUnits)
    if (type == mc.MC_JOG_TYPE_INC) then
        if (direction == mc.MC_JOG_NEG) then
            dist = -1 * dist
        end
        rc = mc.mcJogIncStart(inst, axis, dist)
    elseif (type ==mc.MC_JOG_TYPE_VEL) then
        rc = mc.mcJogVelocityStart(inst, axis, direction)
    end
end

My default units are set to metric, and I've never experienced a switch to Imperial units when using the ablove.

Allan
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 19, 2018, 09:16:33 PM
Striplar,

One thing to do is check the return code from any and all API calls.  These return codes will do a lot of work for you in diagnosing why something doesn't work.  Anything other than zero (mc.MERROR_NOERROR) is an error.

Allan's code is getting the return codes in the variable rc.  That is a step in the right direction, but it is still not actually checking the return code. 

Code: [Select]
local inst = mc.mcGetInstance()

rc = mc.mcJogIncStart(inst, axis, dist)
if (rc ~= mc.MERROR_NOERROR) then
    -- Error condition!  Maybe use SetLastErrror
    mc.mcCntlSetLastError(inst, "jog Start Failed")
    -- And return immediately so that things don't go all pear shaped.
    return;
end
...

It is a lot more coding, but I can promise you that it will pay off.  Things won't sneak up and bite you.  And it covers all of the bases, so to speak.  If you get into the habit of checking the return codes, it just becomes at some point.  It is especially important on API calls that are to perform an action.  Because you want to handle the case if the action didn't or couldn't happen. 

Steve
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 20, 2018, 05:04:46 AM
Thanks to you both, that's all very useful. I'll have to digest the code, I'm still taking baby steps in this.

The switch back to Imperial units might not happen when I'm not messing about with the setups, so that call to force it to metric might not be necessary

However, I still don't understand why the following call has no effect...

 mc.mcJogSetType(inst, mc.X_AXIS, mc.MC_JOG_TYPE_INC)

I've checked return code which is 0. Can anyone tell me if this function actually works, or if I'm wasting my time?

The same 0 return code comes from the other functions I called in the example, but I don't know what that means.
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 20, 2018, 05:45:42 AM
smurph

Point taken. I tend to use the return codes during debugging, but for simple calls like the above most returns are caused by parameter failures which should not normally occur once the code is stable. But I agree this is a short cut.

The probing module, which I have completely re-vamped, is another matter. Due to the likelyhood of issues, I check each and every return code associated with motion and control how errors propagate through the call chain.

Allan
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 20, 2018, 05:57:20 AM
Hi Allan,
Where did you find the information on the following function that you used?

      type = mc.mcProfileGetInt(inst,'Preferences', 'JogType', mc.MC_JOG_TYPE_INC)

I can see the details of the call in the help, but where is the list of the 'Preferences' and 'JogType'?

I get the impression that there's another large technical document that I'm missing that shows the system variables, where they're stored and what they do.
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 20, 2018, 06:54:25 AM

JofType is just the entry under the section [Preferences] in the machine.ini file. I can't remember for sure as it was some time since I did that, but if this entry is not in your machine.ini it must be one that I have added.

I have replaced the standard jog tab with one that uses a set of buttons that directly set the jog increment and type, and these are saved in machine.ini. The buttons cover increments from 0.01 to 10mm in a .01, .03, .1, .3 .. 3, 10 sequence, plus a continuous option. The values are taken from the list in Mach4's Configuration/Control. 

The jog buttons call the function listed above, plus a related button up function which stops motion. These same functions are accessed by the keyboard via signal table entries in the screen load script.

Allan
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 20, 2018, 07:26:10 AM
Ah, I see that now. I'm going to have to take a long hard look at that example you gave.

Fortunately I've managed to cheat somewhat by calling "Jog Mode Step" action when the button is down which sets the jog mode to incremental and then another one "Jog Inc.4" that explicitly sets the increment value.

Maybe it's possible to call those from a script instead, but I don't know how to do that.

I can see the various functions that have been defined in the screen script, but I can't see how you are supposed to add your own ones. The Zero Brane editor seems to be what's used, but ScreenScript.lua appears to be common to all profiles. Somehow I thought there would be one for each profile?

So presumably to create your own new functions, you have to edit the common ScreenScript.lua file and then your function appears in the list of Actions in the properties?
 
Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 20, 2018, 09:13:38 AM
Hi,
the ScreenScript.lua is the combination of ALL the smaller screen scripts combined. It is compiled at run time and it is this one chunk of code that actually
runs. Its displayed for our convenience, you can't edit it. It useful to search and find a particular bit of code or function but you have to go to the
individual script before you can edit or debug it.

It may appear that its the same script in each profile, its not. There is enough code common to all profiles that it gives the appearance of being identical
but closer inspection will reveal code which is specific to a profile.

Craig
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 20, 2018, 09:25:48 AM
Ah, so it's an amalgam of whatever screen scripts are present in all of the profiles then?

I'll have to look at how to create scripts that have function names then, because at the moment I'm just adding scripts where you access them directly from the button.
Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 20, 2018, 09:33:19 AM
Hi,

Quote
Ah, so it's an amalgam of whatever screen scripts are present in all of the profiles then?
Yes.

Craig
Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 20, 2018, 09:42:37 AM
Hi,
a button that has a script will also occur in the combined ScreenScript.lua.

You will have noticed that certain buttons have an action whereas others have a script or scripts.

Actions are selectable from a drop down list. These are standard actions that Mach developers believe will be most often required. They are within the core and are not open to view
or to edit. A script on the other hand is available to view and edit.

Craig
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 20, 2018, 10:47:29 AM
Thanks for your patience in explaining what might be obvious to a lot of users.

Just a couple of things...

For example, there's a Cycle Start function in the ScreenScript.lua that's used to select the action taken depending on what tab is active. That's clearly something added as part of the design of that specific screen. It's a named function that I can apply to any button, but how can that be edited? I can see it in the ScreenScript.lua which I appear to be able to edit and modify if I do to Operations->Open Script Editor

So it looks like you can edit ScreenScript.lua and that's where these things are defined. Am I getting the wrong end of the stick? I can't see function CycleStart() defined anywhere else.
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 20, 2018, 12:52:27 PM
The screen script is a screen resource.  Meaning it is part of the screen set.  You edit the screen to edit the script.  It has nothing to do with a machine profile other than the profile determine WHAT screen is use with it.  Fore example, multiple profile could use the same screen set.  Or each profile could use a different set. 

As Craig mentioned, the larger ScreenScript.lua is generated from smaller script snippets in the screen.  So you can't edit the ScreenScript.lua file directly.  See section 5 of "Mach4 Screen Editor V1.0.pdf" in the docs folder.

Usually, if one wants to make a function available for the screen elements, the function is put in the screen load script.  This allows for any button to call that function from their respective event scripts, etc..  So you will see the CycleStart() function in the screen load script. 

Now, do you NEED to put the code into the screen load script?  It depends.  If the code is something that is repetitive and common, then adding it as a function in the screen load script becomes desirable.  But if the button code is very specific to a certain button, then just use the button event script to do the whole job.  A LOT of times, doing all of the the code in the button event script is more clear to the intent.  Readability is important a year from now if you decide to change something and have pretty much forgotten what you are doing now.  :)  It really depends on what is most comfortable/effective for you. 

Steve
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 20, 2018, 04:59:22 PM
Hi Steve,
Now that's the document I could have used days ago! It's not in the Docs folder or anywhere else in the Mach4 download, but I've found it on the internet and now have it in there.

I see your point about scripts being largely dedicated to specific buttons. There's one case where I want to have radio button LED indicators against four buttons. You could argue that it would be neater to have a 'clear all radiobutton LEDs' function that each button could call to clear the others before setting its own LED.

While I'm on that subject, how can you write to the properties of one screen component from the script of another? Say turn on an LED or change the colour of one button from the script of another. You might want to do that if you were creating radio buttons where the background colour of the button indicates which one is selected. This sort of thing is dead easy in something like Delphi or Visual Basic, so I imagine this environment is similar.
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 20, 2018, 07:20:23 PM
Yes, you use the screen API.  It is not documented other than you will get the function signatures in the ZeroBrane editor.  The two staples are:

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.

Keep in mid that it is ALWAYS better to use the underlying data that backs the screen element instead of the screen element itself, if possible.  For instance, if there is a slider on the screen named "myFROslider" that sets the feed rate override, use mc.mcCntlGetFRO() instead of scr.GetProperty('myFROslider', 'Value").  This is part of the reason that this stuff is not documented.  Because people will use it and not use the main Mach API proper.  I JUST ran into this when support gave me a supposed "BUG" the other day.  It wasn't a bug.  The slider is imprecise because it is pixel based.  If the slider has a range of 0 to 250, but the slider is displayed in less than 250 pixels, well...  there are going to be gaps in the range when using the slider.  Meaning you can start sliding it up from zero and get counts like 1, 2, 3, 5, 6, 7, 9.  So it wasn't a bug at all!!!!  It is why the FRO slider in fresh on my mind.  Yeah, I went down that rabbit hole. 

The other reason is I just don't like writing documentation.  LOL

99% of the time, these scr.* functions are not needed.  If you find yourself needing them all of the time, take a step back and think about how it could be done some other way.  Most of the time, the ONLY time you may absolutely need them is for a screen specific function.  Like the figuring out what tab is current to make the Start Cycle button process MDI commands instead of running a file.  

Steve
Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 20, 2018, 08:34:28 PM
Hi,

http://www.machsupport.com/forum/index.php/topic,29452.msg205711.html#msg205711 (http://www.machsupport.com/forum/index.php/topic,29452.msg205711.html#msg205711)

Craig
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 21, 2018, 04:03:21 AM
Hi Steve,
Ok, I'll look into using that method. Since there's no 'Radio button' group in Mach4, there's no obvious way to turn off an LED that is now inactive unless you force it off directly. In the situation I have, the radio buttons set different values for the jog step increments so you can't just link them to a source.

I hear what you're saying about using the underlying data, but that's hard to find. Again, in the example I have, I want to use a script to mimic several functions such as the one that selects a particular preset jog increment for the jog. That's easy to do when it's selectable from a drop down list, but I can't see a way to accomplish that from a script. Maybe it's in the documentation about how to do this, but I can't find it. I also can't find out where the increment ends up after its been selected, so I can't link a text box to the current jog value.

So in general, to a newbie, there are many obstacles to doing what at first glance ought to be trivial, but it appears to be more difficult. I see there's a partial listing of some of the internal variables, but I really think there should be a complete one for cases such as this.

I know writing documentation sucks, but it would save a lot of heartache for those of us who don't have access to the source to just look this stuff up.
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 21, 2018, 04:04:01 AM
Hi,

http://www.machsupport.com/forum/index.php/topic,29452.msg205711.html#msg205711 (http://www.machsupport.com/forum/index.php/topic,29452.msg205711.html#msg205711)

Craig
Thanks Craig!
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 21, 2018, 08:29:47 AM
striplar

Sounds like you may be doing something similar to what I attempted. I also found it impossible to reconcile all of the internal values used by Mach4, which is why I decided to take an independent approach.

As the screen shot shows, I use a set of buttons to set the jog increment. I find this to be quick and convenient in use; to me it is preferable to the stock arrangement. You might reasonably conclude that I'm not a lover of the bland colour schemes that seem popular at present.

The button scripts are all one-liners. I started with the function codes in the screen load script but ultimately moved them into a separate module. I find this is easier if I want to do a quick review or edit of it, as there is lo need to invoke the screen editor.

In case you are interested, I have attached the module code, for which I make no claims, special or otherwise.

Allan

P.S. After much time and frustration trying to post this I have combined the 2 files into a ZIP archive.
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 21, 2018, 02:56:06 PM
Many thanks Allan for taking the time to do this. I'll digest it shortly. At the moment the machine is working flat out, trying to recover some of the time lost in the conversion from Mach3.

Looking at your screen, I see striking similarities in the jog buttons you've implemented. I never did see the logic in having a button that cycles between the increments stored in a table. What I need is to hit one button and know it's a continuous jog, or another and know it's a single increment of the size I choose. In my case, I've achieved that effect using actions for Mouse Down and Mouse Up, but I'll see  how you've done it since I couldn't make a script written as part of the button work.


By the way, you wouldn't happen to know how to make the spindle stop automatically at the end of a program without an explicit M5? Mach3 stops at the end, I think you can select that option in the config, but I can't see anything similar in Mach4
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 21, 2018, 03:57:30 PM
Well, I've never had to run without a final M5 but you could try writing a custom M30 macro. Essentially, this would just contain the code to stop the spindle, Mach4 would still do the essential housekeeping at program termination.

By the way, if you wanted to try my jog screen for real to see what suits you and what doesn't, I could post the actual screen tab that you could drop into the screen tree manager. I think that and the awprobing module are the brunt of what you'd need, but of course you'd need to add a require statement for the module to be recognised.

Allan
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 21, 2018, 05:00:53 PM
I use a rotary knob on my panel to set the jog increments.  And use Mach API function mcJogSetInc().  To find the current jog increment, use mcJogGetInc().  It is by axis, so to make all of the coordinated axes have the same jog increment, you have to do it for all of them.  The GUI does this for you in its' default configuration.  But if you want something different, then you have to do the legwork that the GUI does. 

So, how would one track this?  In the PLC script.  LEDs can be driven by signals.  One could grab some output signals that are not mapped to hardware outputs and use them for the purpose of driving LEDs.  In the PLC script, use mcJogGetInc() to determine which increment is in use and drive the appropriate output signal.  Say you have 3 LEDs to represent 3 different increments of .001, .01, and .1.  At this point, you may want to put this function in the screen load script and call it from the PLC script. 

Code: [Select]
-- this is in the screen load script.
currentInc = 0 -- global var to track the current increment. 

function SetIncrementLeds()
    local inst = mc.GetInstance()
    -- track using OSIG_OUTPUT61, OSIG_OUTPUT62, and OSIG_OUTPUT63 (for .001, .001, and .1, respectively)
    local hSig61 -- signal handle
    local hSig62 -- signal handle
    local hSig63 -- signal handle
    local inc, rc = mc.mcJogGetInc(inst, mc.X_AXIS)
    if (currentInc ~= inc) then -- the increment has changed, so light up the appropriate LED
        currentInc = inc;
        hSig61, rc = mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT61)
        if (rc ~= mc.MERROR_NOERROR) then
            -- Error condition.
            mc.mcCntlSetLastError(inst, "Failed to get signal handle in SetIncrementLeds()!"
            return;
        end
        hSig62, rc = mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT62)
        if (rc ~= mc.MERROR_NOERROR) then
            -- Error condition.
            mc.mcCntlSetLastError(inst, "Failed to get signal handle in SetIncrementLeds()!"
            return;
        end
        hSig63, rc = mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT63)
        if (rc ~= mc.MERROR_NOERROR) then
            -- Error condition.
            mc.mcCntlSetLastError(inst, "Failed to get signal handle in SetIncrementLeds()!"
            return;
        end
        -- No errors at this point, set all output signals to off.
        mc.mcSignalSetState(hSig61, 0) -- check the return code for production code!  This is an example. 
        mc.mcSignalSetState(hSig62, 0)
        mc.mcSignalSetState(hSig63, 0)
        if (inc == .001) then
            mc.mcSignalSetState(hSig61, 1) -- .001 is current, turn on its' output signal. 
        elseif (inc == .01) then
            mc.mcSignalSetState(hSig62, 1) -- .01 is current, turn on its' output signal. 
        elseif (inc == .1) then
            mc.mcSignalSetState(hSig63, 1) -- .1 is current, turn on its' output signal. 
        end
    end
end

function SetIncrement(incr)
    for axis=0,5,1 do
        mc.mcJogSetInc(inst, axis, incr) -- probably want to check the rc as well... 
    end
end

Put a line in the PLC script to update the LEDs
Code: [Select]
SetIncrementLeds() -- call the function that is in the screen load script

Then map output signals 61 to 63 to some LEDs.

Then put something like the following in some button up event scripts

Code: [Select]
SetIncrement(.001) -- Call the SetIncrement() function in the screen load script.  .01 and .1 in other buttons.

That is all done without scr.Get/SetProperty().  AND it has the added benefit of working along side a panel knob.  But also do realize that you also have the PMC to do all of this stuff in ladder logic as well.  Both of these should be considered preferable to using the screen API stuff.   

Steve
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 21, 2018, 06:03:56 PM
Many thanks Smurph, that's just the sort of thing I've been hoping to find.

I don't have a panel on the machine, it's a metal working Mill that I've converted to CNC, a smaller version of a Bridgeport. I was using a pendant, but that doesn't work any more with Mach4
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 21, 2018, 06:26:12 PM
What kind of pendant?  And what kind of motion controller are you running? 

Steve
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 22, 2018, 04:37:35 AM
What kind of pendant?  And what kind of motion controller are you running?  

Steve
I have the wireless WHB04-LMPG and I've tried out the driver that someone on the forum has developed for his own purposes and kindly shared. That does install and work after a fashion but the stepping through the jog increments is in the wrong direction and they're hard coded to values that don't match the display.
If they selected values from the table, that would be acceptable, and even better if they set the step to incremental. It's a pity the buttons aren't just mapped to something that you can write a script for. That way you could alter the direction of the increment so it stepped down for each incremental change, something I always need to do when using an edge finder.

The biggest misgiving I have on Mach4 jogging in general is that it's default seems to be Inch units whenever you change anything. If you're experimenting, you're likely to have a big accident when 1mm becomes a 25.4mm jog. I really think something should be done about this because it's frankly dangerous.

I'm running a CM106-ESS which I've been using for years with Mach3 and seems pretty much bullet proof.
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 22, 2018, 05:31:41 AM
Quote
1mm becomes a 25.4mm jog

Scared the pants off me a few times. This was my motivation for abandoning the stock jogging facility.

Allan
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 22, 2018, 07:23:03 AM
Quote
1mm becomes a 25.4mm jog

Scared the pants off me a few times. This was my motivation for abandoning the stock jogging facility.

Allan

Yep, especially when your machine is man enough to snap a 20mm cutter like a carrot! Seriously, this need fixing as it's a safety issue.

Another thing I don't like about the default Mach4 mill screen is the combined Cycle Start for the G-Code and the MDI. Again, I think this is dangerous and I'll be adding a dedicated one for the MDI and stripping out the MDI activation from the G-Code one.
I've already have one near miss hitting Cycle Start meaning to start the G-Code and it's been on the MDI. Yes, I know it's my fault, but it's an accident waiting to happen, just like having homing buttons next to the DRO Zero buttons.
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 22, 2018, 05:58:39 PM
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
Title: Re: Using a button script to set jog increments etc
Post by: TOTALLYRC on May 22, 2018, 09:03:31 PM
Nice panel Steve!


Mike
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 25, 2018, 05:00:01 PM
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?
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 25, 2018, 05:52:09 PM
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
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 25, 2018, 06:16:11 PM
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.
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 25, 2018, 06:32:50 PM
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
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 26, 2018, 04:08:28 PM
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.
Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 26, 2018, 04:19:54 PM
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
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 26, 2018, 04:57:23 PM
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
Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 26, 2018, 05:12:15 PM
Hi Steve,

Quote
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
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 26, 2018, 05:20:24 PM
ok, I've added this in the PLC script but it always turns the btn1000micron button green, regardless of the increment that I know is working correctly because it jogs the amount that it should.

So it looks like the line "increment, rc = mc.mcJogGetInc(inst, mc.X_AXIS)" always returns 1.
Can you see what I'm doing wrong? In a previous example you set up the function in the screen script and called that from the PLC. Maybe you can't access the increment from the PLC script directly?

Also, I'm not sure about that line in the error checking that says "return" I think that needs to go.

-------------------------------------------------------
--   Handle the radio button action of the Jog increment buttons
-------------------------------------------------------

local increment
local rc
increment, rc = mc.mcJogGetInc(inst, mc.X_AXIS)
if (rc ~= mc.MERROR_NOERROR) then
    mc.mcCntlSetLastError(inst, "JogGetInc failed")
    return;  --???????
end

if (increment == 1) then
   scr.SetProperty("btn1000micron", "Bg Color", "Green");--"ControlName", "PropertyName", "Value"    ????? this line always executed
   scr.SetProperty("btn100micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   scr.SetProperty("btn10micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   scr.SetProperty("btn1micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
elseif (increment == 0.1) then
   scr.SetProperty("btn1000micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   scr.SetProperty("btn100micron", "Bg Color", "Green");--"ControlName", "PropertyName", "Value"
   scr.SetProperty("btn10micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   scr.SetProperty("btn1micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
elseif (increment == 0.01) then
   scr.SetProperty("btn1000micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   scr.SetProperty("btn100micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   scr.SetProperty("btn10micron", "Bg Color", "Green");--"ControlName", "PropertyName", "Value"
   scr.SetProperty("btn1micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
elseif (increment == 0.001) then
   scr.SetProperty("btn1000micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   scr.SetProperty("btn100micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   scr.SetProperty("btn10micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   scr.SetProperty("btn1micron", "Bg Color", "Green");--"ControlName", "PropertyName", "Value"
end
Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 26, 2018, 05:41:19 PM
Hi striplar,
this is an ideal situation for you to use one of the 'flags' we were talking about.

Put a:
mc.mcCntlSetLastError(inst,'Jog Increment=1')
in the first if-then and a:
mc.mcCntlSetLastError(inst, 'Jog Increment=0.1')
in the second and so on.

It will indicate whether the If conditional is being executed and if it correctly decides which chunk of code to run.

Of course they can be stripped out again once you've got it to work.

Craig
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 27, 2018, 05:23:34 AM
Hi Craig,
Point taken, I can see how useful that mcCntlSetLastError() function is.

I've now moved the code called from the PLC to the Screen Load Script as shown below and incorporated the error function to show me what's going on.
The global variable to track the changed in the increment was borrowed from a previous example shown me in this thread. It makes sense to only update screen properties when they change so as to save time, and it also reduced the number of errors in the log so it's more readable.

What this has confirmed is that it all works except that the increment value read using...     increment, rc = mc.mcJogGetInc(inst, mc.X_AXIS)   ... always returns the value 1, regardless of the actual jog increment that is set using the buttons. I know they are doing their job because the jog does move the selected amount.

So the question is, why does that function not return the value that's set by the button when the button for 0.1mm for example calls the.... Jog Inc. 2 function from the Left Up Action button event? It seems to me that the variable used for jogging is cannot be mc.X_AXIS or it's somehow not available for some reason. Perhaps it's an error in the syntax?

----------------------------------------------------------------------------
--   Handle the radio button action of the Jog increment buttons - My code!
----------------------------------------------------------------------------
function UpdateJogRadioButtons()  --called from the PLC script
--currentInc = 0 -- my global var to track the current increment defined above

--local inst = mc.mcGetInstance() --apparently not required
local increment
local rc
increment, rc = mc.mcJogGetInc(inst, mc.X_AXIS)
if (rc ~= mc.MERROR_NOERROR) then
    mc.mcCntlSetLastError(inst, 'JogGetInc failed')
    return;
end

if (increment ~= currentInc) then   --so we don't unnecessarily update anything
    mc.mcCntlSetLastError(inst, "currentInc=" .. tostring(currentInc))
    mc.mcCntlSetLastError(inst, "increment=" .. tostring(increment))
   
   if (increment == 1) then
      mc.mcCntlSetLastError(inst,'Jog Increment=1')
      scr.SetProperty("btn1000micron", "Bg Color", "Green");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn100micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn10micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn1micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   elseif (increment == 0.1) then
      mc.mcCntlSetLastError(inst,'Jog Increment=0.1')
      scr.SetProperty("btn1000micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn100micron", "Bg Color", "Green");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn10micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn1micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   elseif (increment == 0.01) then
      mc.mcCntlSetLastError(inst,'Jog Increment=0.01')
      scr.SetProperty("btn1000micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn100micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn10micron", "Bg Color", "Green");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn1micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   elseif (increment == 0.001) then
      mc.mcCntlSetLastError(inst,'Jog Increment=0.001')
      scr.SetProperty("btn1000micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn100micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn10micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn1micron", "Bg Color", "Green");--"ControlName", "PropertyName", "Value"
   end
      
   --scr.SetProperty("btnContinuousMode", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   currentInc = increment   --remember what the new increment is
end
end
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 27, 2018, 06:17:49 AM
There's something definitley screwy going on. As an experiment, I put the following code into the button script that should set the increment to 0.001mm

It fails on the SetJogInc() function..... however, it does appear to have changed the mc.X_AXIS variable because now I can read back that value using GetJogInc() and it shows me 0.001mm!

However, the amount it actually jogs is unaffected by this. In other words, mc.X_AXIS can't be the value it's using when it actually goes to jog.

Any ideas what the actual variable used is called? Perhaps it is mc.X_AXIS but I'm not using the right syntax


local inst = mc.mcGetInstance()
local increment
local rc

increment, rc = mc.mcJogSetInc(inst, mc.X_AXIS, 0.001)

if (rc ~= mc.MERROR_NOERROR) then
    mc.mcCntlSetLastError(inst, 'JogSetInc failed')
   return;
end

increment, rc = mc.mcJogGetInc(inst, mc.X_AXIS)
if (rc ~= mc.MERROR_NOERROR) then
    mc.mcCntlSetLastError(inst, 'JogGetInc failed')
    return;
end

    mc.mcCntlSetLastError(inst, "increment=" .. tostring(increment))

Another thought is that the MachMill screen is using something else for the jogging increments. I see that the Left Dow Action for the X- button is calling "Job X-" action, but I've searched through the screen script and that's not in there. I can't see that anywhere listed in any of the help or scripting documents so I have no idea how it work and what it affects.
It certainly doesn't take any notice of the value in mc.X_AXIS

Any ideas?

Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 27, 2018, 09:31:26 AM
Hi,
I'm a bit confused myself.

Quote
however, it does appear to have changed the mc.X_AXIS variable because now I can read back that value using GetJogInc() and it shows me 0.001mm!
mc.X_AXIS is NOT a variable, it is an ENUM, it is the number of the X axis. Its defined within Machs core and you cant change it.

Quote
In other words, mc.X_AXIS can't be the value it's using when it actually goes to jog.
That is correct, mc.X_AXIS is of type number, I suspect its value is one, it is not a jog increment,

Craig

Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 27, 2018, 09:38:04 AM
Hi,

Quote
button is calling "Job X-" action, but I've searched through the screen script and that's not in there
While some buttons have 'left down' scripts for instance however others have an 'action' That action is programmed within Machs core where you cant see it or edit it,
and they're probably all in C++ anyway.

Craig
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 27, 2018, 12:11:27 PM
Hi,
I'm a bit confused myself.

Quote
however, it does appear to have changed the mc.X_AXIS variable because now I can read back that value using GetJogInc() and it shows me 0.001mm!
mc.X_AXIS is NOT a variable, it is an ENUM, it is the number of the X axis. Its defined within Machs core and you cant change it.

Quote
In other words, mc.X_AXIS can't be the value it's using when it actually goes to jog.
That is correct, mc.X_AXIS is of type number, I suspect its value is one, it is not a jog increment,

Craig



Ok, not well phrased. The variable that the function is directed to by mc.X_AXIS doesn't get updated. I'm trying to both set and read the jog increment variable, wherever that is, and whatever that's called, and the mc.mcJogSetInc(inst, mc.X_AXIS, 0.001) throws an error when I try to do that.

When I read back the value given by mc.mcJogGetInc(inst, mc.X_AXIS), if that happens to be say 0.001mm that's not what it jogs by.

The conclusion is that whatever is being used by the jog button to incrementally move the axis is not the value that's being read by mc.mcJogGetInc(inst, mc.X_AXIS)
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 27, 2018, 12:13:06 PM
Hi,

Quote
button is calling "Job X-" action, but I've searched through the screen script and that's not in there
While some buttons have 'left down' scripts for instance however others have an 'action' That action is programmed within Machs core where you cant see it or edit it,
and they're probably all in C++ anyway.

Craig

Fair enough, so what variable is being used by that routine so that the incremental jog knows how far to move? I've read back the value from mc.mcJogGetInc(inst, mc.X_AXIS) and it doesn't match the amount it actually jogs, so it's not using whatever is being read by that function

It seems to me that what it uses is always the value that's currently being pointed to in the table that you populate in the config for the different step.

Maybe I'm using the wrong approach and I should be trying to change that variable.
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 27, 2018, 12:46:09 PM
striplar

If you display the RegFile diagnostics, you will find entries for core/inst/JogIncX etc for the 6 axes. These are all set to the same value, as you would expect. You might like to see how these compare with the varables you are reading and writing. There are also 6 registers for the jog rates, but I have only seen these set to 0.

I initially used the values from these12  registers, but eventually abandoned that idea because their values did not always reflect what I had previously set. Sorry I have forgotTen the details.

As I said earlier, I ultimately abandoned trying to fathom out what Mach was doing and worked independently. Since then I have had no issues whatsoever with jogging. I do use the Config list as the basis from which my button names and jog increments are taken, so these can easily be changed without further coding.

It would be fascinating to see what the core actually does: I would especially like to see the logic behind Mach's state machine.

Allan
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 27, 2018, 12:54:48 PM
Hi Allan,
Can you point me to where I can see the RegFile diagnostics? I don't know where to look.

It seems to me that the SetJogInc and GetJogInc aren't related to what's used when you tell the system to set the jog increment based on what's in the table. These things seem so basic, I'm stunned that all this stuff isn't sorted out and made clear. Everyone who attempts to change the way the jog works is going to go through these mental gymnastics.

Can someone close to the code answer these questions? I've posted a request to the page indicated in the Mach 4 Bug Reports thread in the hope of getting a definitive answer.
Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 27, 2018, 02:43:16 PM
Hi,

Quote
Everyone who attempts to change the way the jog works is going to go through these mental gymnastics.
You want to CHANGE the way it works therefore you assume responsibility for the effort.

Look under Diagnostics/Regfile...expand the various categories and have a look.

Craig
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 27, 2018, 03:53:44 PM
Guys, it isn't this hard!  :)  I made a video that might help. 

https://youtu.be/hISdOAVaAbM

The registers are there for external access to the current jog increment that the screen is using.  So that some plugin or external script can tell what the current increment (the screen's notion) is. 

For example, say you have a script that needs to change the jog increment and then change it back to what it was AFTER it is done.  Otherwise, those registers are not needed.  Don't use what you don't need. 

All of this can be done with mcJogGetIncr() and mcJogSetIncr().  The screen will follow these increments, as shown in the video.  And I WILL say this...  If I could learn how to use that damned video capture software and create that video, then you guys can certainly learn this LUA stuff.  I will not fib, it was frustrating.  I made several videos that were just blank screens with audio.  But guess what?  I didn't have a clue about what I was doing!  :)  Once I figured it out, and the light bulb in my head came on, it all started working as it was meant to.  Same goes for Mach. 

Steve
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 27, 2018, 04:13:50 PM
Sorry guys, but it's not as simple as you are trying to make out from a position of knowledge. I've been programming in all manner of languages for forty years, I've written my own CNC control from scratch, so I' think it's fair to say that I'm not new to this lark.

The problem is that there's no joined up easy to understand way to find out about how Mach4 hangs together. I don't ask questions because I'm lazy or stupid, I ask them because they aren't obvious.

So far, I've not made any sense of how Mach4 decides what size jog increment to use, how to set that with a script and how to read it back. That's not for lack of trying, it just doesn't appear to work. Maybe I'm missing something that's blindingly obvious, but mcJogSetInc() returns an error and mcJogGetInc() doesn't return the value of the increment it's currently jogging at.

Do put me straight as to where I'm going wrong if this is all so easy?
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 27, 2018, 04:41:50 PM
I can go into the Debug->RegFile and see the JogIncX variable which does follow the JogSetInc even though that returns an error, assuming the error testing is correct of course. I'm using the following suggested code...

if (rc ~= mc.MERROR_NOERROR) then
    mc.mcCntlSetLastError(inst, 'JogGetInc failed')
    return;
end

... which says it's failed.

Now if I leave out the error checking, it does save and retrieve the value set, but that has NO effect on the amount it actually jogs.

As it happens, I can just use that stored information to set the colour of the Radio buttons in the PLC, but it doesn't explain why this has absolutely no effect on the jog increment it actually uses!
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 27, 2018, 05:05:20 PM
I think the error is actually that I'm testing for mc.MERROR_NOERROR and not MERROR_NOERROR, so that's probably a syntax mistake.

It still doesn't resolve the fundamental issue of the JogIncX variable in the RegFile changing but having no effect on the actual amount the jog increments by when I press the X- button for example.
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 27, 2018, 06:22:54 PM
striplar

As I said, I never managed to resolve the inconsistencies so I think you will have to hope Steve has some  idea.

Have you come across the mcErrorCheck.lua module in Mach4's modules directory? This lists the possible rc codes and can be handy in your scripts. For example you could use something like this:?

Code: [Select]
if (rc ~= mc.MERROR_NOERROR) then
    mc.mcCntlSetLastError(inst, "Jogging error:" .. ec[rc])
end

This would append the offending error message to the text of your choice.  so may make it easier for you to resolve any issues that arise.

To use the above, you must link in the mcErrorCheck.lua  module using a require statement, the typical code being:

Code: [Select]
----------AW Load error check module ---------------
local inst = mc.mcGetInstance()
local profile = mc.mcProfileGetName(inst)
local path = mc.mcCntlGetMachDir(inst)
package.path = path .. "\\Modules\\?.lua;" .. path .. "\\Profiles\\" ..  profile .. "\\Modules\\?.lua;"
package.loaded.mcErrorCheck = nil
ec = require "mcErrorCheck"

This may already exist in the screen load script: if not you can safely add it.

Allan
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 27, 2018, 07:03:34 PM
Hi Allan,
No, that one's new to me, I see that now. I've just tried that and it seems to work fine, so I'll put that in all of the button scripts.


Anyway, I've raised a support ticket asking for an explanation as to why the JogIncX variable set by the mcJogSetInc() function has no effect on the actual jog it does using the X- button. I mean, what's the point in having those registers if they don't do anything useful.

Although I can sort of get my code to work, I still can't set the initial conditions to whatever the true jog increment is, unless I somehow force the ScreenScript to set it initially. We know you can't use mcJogSetInc() for that, so maybe you can call the Action function that you can select from the drop down list of Actions in the button event tab?

I'm also surprised that there's no mcJogGetType. Again, there are individual Type variables for each axis, but those don't follow the Incremental/Continuous modes of the actual machine either! It's frankly bizarre.

Hopefully someone at Mach will be able to explain all of this.
 

Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 27, 2018, 07:12:59 PM
The problem is that there's no joined up easy to understand way to find out about how Mach4 hangs together. I don't ask questions because I'm lazy or stupid, I ask them because they aren't obvious.

So far, I've not made any sense of how Mach4 decides what size jog increment to use, how to set that with a script and how to read it back. That's not for lack of trying, it just doesn't appear to work. Maybe I'm missing something that's blindingly obvious, but mcJogSetInc() returns an error and mcJogGetInc() doesn't return the value of the increment it's currently jogging at.

Well, technically speaking, it isn't how Mach 4 hangs together, but rather how the GUI hangs together.  Mach 4 has a core that can be run by any GUI that is written using the Mach 4 API.  We ship an example GUI called wxMach.exe that is basically a static front end.  So what we are technically talking about here (now) is the functionality of the GUI.  Mach4GUI.exe is the GUI that is dynamic and can be customized.  It provides FAR more functionality than the static wxMach.exe GUI does.  For instance, there is no LUA scripting in the wxMach.exe and you can't add or change the display beyond that of any other windows program.  

So we have established that the Mach4GUI.exe provides a lot of functionality that the user needs to run a machine.  One of the functions it provides is jogging.  But it is important to note that it is a SCREEN implementation of the jog.  So the internals of the GUI keeps track of the increment in its' own container.  It calls API functions such as mcJogSetIncr() etc...  This is done per axis in the core so the GUI is actually doing something more than setting just one global increment.  It is doing it for ALL coordinated axes.  But that is not all it does.  It also keeps track of the jog mode (incremental or velocity) too.  So that when you press the jog button on the screen, it does that particular jog mode.  So there is a lot built in here.  

mcJogSetIncr() and mcJogGetIncr() are basically APIs to use to STORE and RETRIEVE a jog increment.  They don't, in fact, DO ANYTHING.  When you cycle the Jog increments in the GUI, the GUI will use mcJogSetIncr() to store the jog increment that is selected.  Mainly as a means of communication to the rest of the Mach world what increment it will use the next time an incremental jog is performed.  But it also tracks what it was told to use in its' own internal variable.  Why?  Because there may be an MPG or some other control device (panel) that has jog buttons on it.  The increments my be chosen by a buttons or some rotary knob.  Say the user has an MPG and they switch to the .001 increment.  Then they do some jogging and stuff with it and put it down.  Do they want the MPG to always control the jog increments?  Or do they want the jog increments to remain set by the device that is actually used for the current jogging activity?  Most want them separate and that is the default behavior of the screen.  

Some MPGs may only have a hand wheel and no increment switching available.  This is the reason for mcSetJogIncr().  It allows for the screen to set the increment and the increment to be retrieved by whatever is running the MPG with mcGetJogIncr().  So the GUI's stock behavior WILL update mcSetJogIncr() if you toggle the jog increments with the stock jog control buttons.  To let the rest of the Mach world know what the screen's current increment is.  mcSetJogIncr() has no other function than that.  The stock jogging implementation doesn't use mcGetJogIncr() to retrieve this increment before jogging.  It uses its' own internal variable.  So that the screen's jog increment can be different than the other devices that my be used to jog the machine.  

Now, let's take a look at the API function that the GUI (or any other thing that may be running a jog will use) uses.  Namely mcJogIncStart().

In LUA:  

number: rc = mcJogIncStart(number: inst, number: axis, number: dist)

Notice the distance parameter.  This is what drives the incremental jog's distance!  Not what was set by mcJogSetIncr().  There is no function like mcJogIncStartUsingLastSetIncr().

Mach 4 was designed so that no scripting is required to use the stock screen sets.  It is meant to cover 98% of the use cases.  One can wire up a machine to a motion controller, map the necessary I/O to signals, and run the machine from just the screen and mouse.  All of this functionality is "canned" or "shrink wrapped", if you will.  However, it also provides a means of changing the default behavior, for whatever reason.  Don't like it?  Not applicable to the task at hand?  Rather do it your own way?  All of these are valid.  But understand this:  Now the work and functionality is up to you.  So to change the jogging functionality, you will have to write your own and provide ALL of the functionality.  Fortunately, you have the tools of the API to accomplish this.  What I think you are wanting to do is do your own thing but also use the stock jog actions.  We all want to have our cake and eat it too, right?  :)

What does the stock jog functionality do?

1. Provides a jog mode variable. (incremental, velocity)
2. Provides a jog increment variable. (for the increments)
3. Provides a table of jog increments.  
4. Provides canned actions to drive the jog buttons based on the above variables. (toggle jog mode, jog an axis, toggle increments).
5. Calls mcJogSetInc() to let the rest of the world know what the screen is doing.

So all of this will need to be duplicated/provided.  Or...  you can try and use the stock functionality and merge it with yours.  HOWEVER, I do suggest that once you deviate from what is stock that you would be better off doing it all.  So that YOU know what is going on all of the time and don't get bit by some stock behavior for which you may not have accounted.  Because if you do "modify" the stock implementation, you pretty much need to know how it all works AND how to manipulate it to begin with.  That is something that is in my head and it will probably NEVER be documented because 99% of the people using Mach don't kneed to know it.  EVER.  :)  Never the less, I have attached the test file that I used in the video to show how to do what I think you are wanting to do.  But to do it right, you would need to edit all of the jog buttons, remove the stock actions, and write scripts to do all of the required functionality.  

But can you guys imagine what kind of crap would be on this board if the stock jog buttons/actions didn't exist?  I mean, it would be apocalyptic!  "You mean that I have to write LUA code to jog an axis!!!", etc...  

In the attched file, the SetJogIncrements() function now uses a screen API called scr.DoFunctionName().  You can open the screen editor and use the names of the stock button actions to get the name.  This function ONLY works with the primary instance (no instance parameter), so multiple instance controls definitely need to handle this type of thing differently.  

Steve
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 27, 2018, 07:41:48 PM
I didn't remember who said it when I was writing the above post.  But this is exactly what Craig was referring to.  Luckily, most of the stuff people want to modify is less complicated than jogging.

Hi,

Quote
Everyone who attempts to change the way the jog works is going to go through these mental gymnastics.
You want to CHANGE the way it works therefore you assume responsibility for the effort.

Look under Diagnostics/Regfile...expand the various categories and have a look.

Craig

The only mental gymnastic one has to go through is to understand this point.  And don't assume that there is a one line function call that will do what you want either.  Sometimes, that is the case though!  :)  But the stock jog actions use numerous API functions behind the scenes to give the functionality that is does. 

Developing something that works the way you want it to may not be easy.  It may require learning something and it may take a while to learn it.  And that is why this forum exists, to help people learn.  Learning is something we all can do.  Some consider it a chore while others consider it an adventure.  A lot of the time this involves some amount of experimentation.  At least that is what I tell myself that I was doing when I stuck my fingers into a light socket as a kid.  :)

Steve
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 27, 2018, 08:41:15 PM
New video:  https://youtu.be/dtEKxEudc8M

Striplar, turns out this is easy!  But...  there is a bug.  I guess nobody had tried to use this stuff before.  You are definitely a %1-er!  LOL  The bug will be fixed in the next development version.  Until then, use the method in the Test.mcs file or the new SetJogIncrements() in the video. 

Steve
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 28, 2018, 08:33:21 AM
Steve

Thanks for the insights given in the two videos. I now see that mcJogSetInc() and mcJogSetRate(), which I took out of my code thinking they seemed to serve no obvious purpose, do fulfil a potential need. Another hitherto invisible gem is scr.DoFunctionName(), which obviates the (rare) temptation to have a hidden button operated by (e.g.) scr.ButtonUp() which itself can have side effects such as transfer of focus, just to make a script take an action.

I think I'll take another look at my own jogging code to see if I might make any changes  some 6 months after it was written. A key objective, though, was to avoid any surprise switches from metric to Imperial units, so I will continue to disregard any internal increment values.

I do appreciate your giving the time to clarify some of the considerable mystique we users find in the inner workings of Mach4.

Allan
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 28, 2018, 11:20:14 AM
Hi Steve,

This is a copy of the comment I left on the video which I'm grateful for.

Actually, I've been using the same method ie I've used the left down action to change the mode from Continous to Incremental and the up action to set the Joc increment like you've showed. I did mention this in one of my many posts, but you may have missed it.

I'm glad you agree that the internal system should at the very least change the JogIncX value so you can read it using the mcJogGetInc() function elsewhere. This is how I would set radio button colours in a PLC routine.

However, that's not quite enough though, because you don't know the initial condition on startup. I think this is another bug. I think the core should update the JogIncX value etc to whatever the Jog Increment actually is when you fire up Mach4.
You don't address this issue in the video. You assume what the default increment will be.

I also notice that the JogTypeX variable also don't follow the Button Jog Mode on the screen and also don't appear to be initialised to whatever Mach4 core is going to use. Those appear to be scripted, but again, I would have thought that Mach4 core would update those to whatever the current mode is.

I'd suggest that the reason people don't use these functions is not because they don't want to, but when they experiment, they simply find that it doesn't work how they might reasonably expect.
At the very least you expect to be able to ask Mach4 what incerement it's using and what mode it's in.

Also, I would have thought that the actions, such as Jog Inc.3 would be able to be called from scripts. Maybe you can, but if not, why not? It would be so useful when you want to do seveal of these options.

Anyway, thanks for looking at this, maybe you can look at these other things too?
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 28, 2018, 02:40:45 PM

Quote
when they experiment, they simply find that it doesn't work how they might reasonably expect.

Agreed, but I tend to accept Mach4 for what it is, powerful yet amazingly good value, and use the flexible scripting to make it work as I would wish. It can be a challenge but to me that is part of the fun.

Allan
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 28, 2018, 03:12:49 PM

Quote
when they experiment, they simply find that it doesn't work how they might reasonably expect.

Agreed, but I tend to accept Mach4 for what it is, powerful yet amazingly good value, and use the flexible scripting to make it work as I would wish. It can be a challenge but to me that is part of the fun.

Allan

Agreed, it's a lot of fun playing when it makes sense. I don't mind going the extra mile to figure out how to make it do what I want. It's just frustrating when it's actually a bug that's been causing so much grief! such is life.

Anyway, here's my solution to the RadioButton type of interface that seems to work ok now.
This function is written in the SreenScript and called in the PLC loop.

Each increment button uses a Left Down Action of Jog Node Step and a Left Up Action of Jog Inc. 3 for example. There's also a Left Up script as follows...

--Set JogIncX variable using mcJogSetInc() and test it using a call
--from the PLC script to set the radio button colours
--For some reason this has no effect on the actual jog amount which is
--set from the UpAction event for this button
local inst = mc.mcGetInstance()
local rc

rc = mc.mcJogSetInc(inst, mc.X_AXIS, 0.01)

....We now know that this shouldn't have been necessary, the GUI should have done that for us.

----------------------------------------------------------------------------
--   Handle the radio button action of the Jog increment buttons - My code!
----------------------------------------------------------------------------
function UpdateJogRadioButtons()
--currentInc = 0 -- my global var to track the current increment is defined above
--currentMode = -1 -- my global var to track current mode is defined above
local increment
local rc

--See if we're in continous or incremental jog mode first
local cont = mc.mcSignalGetHandle(inst, mc.OSIG_JOG_CONT);
local jogcont = mc.mcSignalGetState(cont)

if (jogcont ~= currentMode) then   --so it's not done every loop
   --mc.mcCntlSetLastError(inst, "jogcont=" .. tostring(jogcont)); --debug only
   if (jogcont==1) then --continuous
      scr.SetProperty("btnContinuousMode", "Bg Color", "Green");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn1000micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn100micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn10micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      scr.SetProperty("btn1micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
   end
   currentMode = jogcont   --so we don't update every time
end
if (jogcont==0) then   --incremental
   scr.SetProperty("btnContinuousMode", "Bg Color", "");--"ControlName", "PropertyName", "Value"

   --NB:-The following gets the value set by the buttons, it has no effect on the actual jog amount!
   increment, rc = mc.mcJogGetInc(inst, mc.X_AXIS)   --You can see the value JogIncX in the Debug_RegFile

   if (increment ~= currentInc) then   --so we don't unnecessarily update anything
   
      if (increment == 1) then
         scr.SetProperty("btn1000micron", "Bg Color", "Green");--"ControlName", "PropertyName", "Value"
         scr.SetProperty("btn100micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
         scr.SetProperty("btn10micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
         scr.SetProperty("btn1micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      elseif (increment == 0.1) then
         scr.SetProperty("btn1000micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
         scr.SetProperty("btn100micron", "Bg Color", "Green");--"ControlName", "PropertyName", "Value"
         scr.SetProperty("btn10micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
         scr.SetProperty("btn1micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      elseif (increment == 0.01) then
         scr.SetProperty("btn1000micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
         scr.SetProperty("btn100micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
         scr.SetProperty("btn10micron", "Bg Color", "Green");--"ControlName", "PropertyName", "Value"
         scr.SetProperty("btn1micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
      elseif (increment == 0.001) then
         scr.SetProperty("btn1000micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
         scr.SetProperty("btn100micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
         scr.SetProperty("btn10micron", "Bg Color", "");--"ControlName", "PropertyName", "Value"
         scr.SetProperty("btn1micron", "Bg Color", "Green");--"ControlName", "PropertyName", "Value"
      end
      
      currentInc = increment   --remember what the new increment is
   end
end   
end

So this is pretty simple now really. I've tested the Continuous mode signal that's used elsewhere to decide whether to blank out the incremental buttons.

It's a fantastic piece of software, but I'm famous for breaking things and finding bugs that have lain dormant for years. I'm dogged an won't just give up because it doesn't make sense.

Anyway, hopefully others will be able to do this easily now all this has been thoroughly aired.

Many thanks to all who've contributed, it's been an enormous help. I'm now going to tackle the MDI box to make that less dangerous.
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 28, 2018, 03:58:54 PM

striplar

Quote
I originally did this without scripts but found there's a bug that occasionally moves 1" instead of 1mm!!!

Maybe I've lost you somewhere, but how did you avoid your problem with unexpectedly changing units?

Allan
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 28, 2018, 05:02:46 PM

striplar

Quote
I originally did this without scripts but found there's a bug that occasionally moves 1" instead of 1mm!!!

Maybe I've lost you somewhere, but how did you avoid your problem with unexpectedly changing units?

Allan


This only seems to be an issue if you play around with the Config settings and then continue without restarting Mach 4 from Windows. I haven't seen an issue when I've started Mach 4 from scratch. Is that the situation that you found?
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 28, 2018, 05:40:05 PM
striplar

Yes, I definitely saw it after a config change, though it took me a while to link the two, by which time I had decided to eliminate it as it struck me as pretty hazardous.. I was by then working on a way of using a set of direct access buttons, so combined the two objectives.

Allan
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 28, 2018, 07:07:40 PM
striplar

Yes, I definitely saw it after a config change, though it took me a while to link the two, by which time I had decided to eliminate it as it struck me as pretty hazardous.. I was by then working on a way of using a set of direct access buttons, so combined the two objectives.

Allan

Fair enough, I'll keep a close eye on it to see whether it's a problem that will recur. There must be a way to force Metric mode that could be included in the script. I know you can execute G-Code like this...

mc.mcCntlMdiExecute(inst, "G21")

... so perhaps that's all that's needed as a button script for each of the buttons

Actually, that would get executed after the move, so it would probably be necessary to call the X- button functions in the script first. They are currently done by actions selected from the drop down menu in the Mach Mill screen.

Perhaps something like this...

mc.mcCntlMdiExecute(inst, "G21") --force it to metric first
local inst = mc.mcGetInstance()
scr.DoFunctionName("Jog X-")  --then do the jog

Obviously you could get the Inch/Metric information from the ini file and make it to suit if you wanted a more general solution. This still only works for the screen buttons though, an MPG could still cause trouble.

Alternatively, maybe there's a function that's called on exit from doing a config? Or, maybe there's a flag that we can test to see what mode it's in and throw an error if it's not Metric

Or finally, perhaps someone at Mach might take this bug seriously and fix it!


Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 28, 2018, 07:24:44 PM
rc = mc.mcJogSetUnitsMode(inst, axis, mc.MC_UNITS_METRIC || mc.MC_UNITS_INCH);

Also,

unitsMode, rc = mc.mcJogSetUnitsMode(inst, axis)

The mode of the machine may override it.  Meaning if you called mcJogSetUnits() to set the jogs to metric and then executed G20 in G code, the jogs will be in inches.  And vice verse. 

Steve
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 28, 2018, 07:46:09 PM
Or finally, perhaps someone at Mach might take this bug seriously and fix it!

It isn't a bug.  I explained in a earlier post that the jog units will follow the machine units mode.  The jogging USED to be ONLY in machine native units.  But we got so many support tickets about that so we made it follow the units mode.  Damned if we do and damned if we don't...

Steve
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 29, 2018, 02:26:39 AM
Or finally, perhaps someone at Mach might take this bug seriously and fix it!

It isn't a bug.  I explained in a earlier post that the jog units will follow the machine units mode.  The jogging USED to be ONLY in machine native units.  But we got so many support tickets about that so we made it follow the units mode.  Damned if we do and damned if we don't...

Steve

I think I must be missing something, because to my mind this is clearly a bug.

1) I set the machine units to MM
2) I NEVER set the program to use anything other than MM
3) I change the config, and the machine sometimes changes to Inches

Since I never change to Inches, that must be a bug. Things shouldn't change on their own.

Is there an event that happens on exit from Config that I can go into to run the following...

rc = mc.mcJogSetUnitsMode(inst, axis, mc.MC_UNITS_METRIC || mc.MC_UNITS_INCH);

The other problem this causes is with the HB04 MPG that I had the driver for. That showed the same problem, and ideally I'd like to be able to use it. The trouble is that I'm not certain whether it's ever going to end up in Inch mode and cause a crash. In that case, I have no idea how that interacts with Mach4 and therefore whether it's possible to force Metric mode for its commands.

Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 29, 2018, 03:59:07 AM
I see what is happening now.  It is not changing on its' own.  The config process destroys the axis jog planners and recreates them with the default of inches.  Nothing, at this point, will set the jog units other than a reset.  Pressing Reset will put the control in the proper mode.  

Ok, I'll call that a bug.  But you don't press reset after a config?!?

Steve
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 29, 2018, 06:20:44 AM
The obvious question is why do the axis jog planners  not use the default units set by the user? Surely that overcomes the problem?

I don't know  why the Reset button is even there, it didn't exist in my Mach3 screen that I use. The only time I've pressed it was when Mach4 became unresponsive for any reason and I thought that might get back in control. I intend to remove it because I have no idea what it's supposed to be used for.
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 29, 2018, 06:21:51 AM
striplar

If you look back at the earlier posts you will see that I reset the jog units to the default just prior to jogging. I don't recall that there is any event (e.g. signal)
 indicating that a configuration has occurred. I think this was discussed in some earlier thread.

Code: [Select]
   local defUnits = mc.mcCntlGetUnitsDefault(inst)
    rc = mc.mcJogSetUnitsMode(inst, axis, defUnits)

I've no idea how your MPG would be impacted. I use the CS Labs module which seemingly works independently of Mach4, but presumeably takes the units default from Mach. This has never given the wrong units when jogging.

Allan
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 29, 2018, 07:21:39 AM
Hi Allan,
I see that now. It's certainly safer to explicitly state that it should use the default units, I might do that anyway. Now that Steve knows what the issue is, hopefully this will be addressed in future builds.

I don't know how the MPG driver is implemented so it's hard to know what might happen.

Of course, one way that might help in the interim is to just add this to the Enable button script since you have to have Mach4 disabled when changing the config. That way, it ought to be right for all of the things that move the machine?

Roger
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 29, 2018, 07:53:00 AM
Roger

Good idea. Adding it to the Enable button should be fine assuming Config change is the only circumstance that upsets the units. Our current state of knowledge would suggest that that is the case, but when I wrote mine I was still unsure of just what caused this and didn't want to take any chances.

Allan
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 29, 2018, 10:04:04 AM
Hi Allan,
I can't say I blame you, it's better safe than sorry since it could be dangerous. I hope I'm not being seen as a pain in the arse for pursuing these things doggedly. I think it's in everyone's interest to absolutely nail these issues once and for all.
Title: Re: Using a button script to set jog increments etc
Post by: smurph on May 29, 2018, 04:08:20 PM
The obvious question is why do the axis jog planners  not use the default units set by the user? Surely that overcomes the problem?

I don't know  why the Reset button is even there, it didn't exist in my Mach3 screen that I use. The only time I've pressed it was when Mach4 became unresponsive for any reason and I thought that might get back in control. I intend to remove it because I have no idea what it's supposed to be used for.

Mach 4 is not Mach 3.  About the only thing they have in common is that they are windows programs that run G code.  If you want to make a comparison, Mach 4 is probably a lot more like a Fanuc than it is like Mach 3.  The reset button is normally on all machine controls (Fanuc, Ysanac, Fidia, etc...), Mach 3 being an exception.  It is there to put the machine into a known state.  For instance, what if you were running a program with cutter comp and stopped it.  And you wanted to restart it from the beginning.  Well...  comp is still in effect!  Or what if you ganked the machine state running MDI commands?  Reset ensures that the machine is put back into its' know state (no comp) before you run the file again.  Reset is all about safety.  You can spot the reset button on a Fanuc quickly because it one of the most used buttons and is probably worn more than others.  

Steve
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 29, 2018, 05:39:10 PM
The obvious question is why do the axis jog planners  not use the default units set by the user? Surely that overcomes the problem?

I don't know  why the Reset button is even there, it didn't exist in my Mach3 screen that I use. The only time I've pressed it was when Mach4 became unresponsive for any reason and I thought that might get back in control. I intend to remove it because I have no idea what it's supposed to be used for.

Mach 4 is not Mach 3.  About the only thing they have in common is that they are windows programs that run G code.  If you want to make a comparison, Mach 4 is probably a lot more like a Fanuc than it is like Mach 3.  The reset button is normally on all machine controls (Fanuc, Ysanac, Fidia, etc...), Mach 3 being an exception.  It is there to put the machine into a known state.  For instance, what if you were running a program with cutter comp and stopped it.  And you wanted to restart it from the beginning.  Well...  comp is still in effect!  Or what if you ganked the machine state running MDI commands?  Reset ensures that the machine is put back into its' know state (no comp) before you run the file again.  Reset is all about safety.  You can spot the reset button on a Fanuc quickly because it one of the most used buttons and is probably worn more than others. 

Steve

Hi Steve,
Ok, I probably don't need it then. I don't use anything clever on the machine at all, it's all done in the CAM software.
The only commands I use are the following because of the pitfalls you describe.

(comment)
M3S###
G1X###Y###Z###F###
M5M30

I occasionally use M0 but that's the only other g-code I use.

I don't use rapids, so I can freely use commands like X50F30<cr> from the MDI line without any fear it will do something unintended.
I always output X,Y & Z so it's easy to restart, and I don't use arcs or any canned cycles because I don't need them.

This way Mach has a really easy time and I always know what's going on and what's going to happen. The CAD/CAM is on the same PC as Mach so it's trivial to change the compensation on the CAM and output the program again. The great thing about this is that the CAD/CAM become the documentation for any repeat jobs. Doing things quick and dirty using wizards leave no trace as to what you've done.

Doubtless I'm alone in adopting this simple approach, but I never get into trouble in the way you describe.

I adopted this really simple methodology because it's just that. No surprises and no having to keep resetting things back to a known state since that state never changes.
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 29, 2018, 06:18:35 PM
This is the Down Script I've added to the Enable button, and this seems bullet proof. Try it by entering the config, make a change then exit. Then Enable and try the jog without pressing Reset.

Hopefully this will now allow me to go back and try the MPG again.


--Make 100% certain that we always use the machine Inch/Metric system set when exiting config.
--Mach has a bug where Config defaults jogging back to Inches!
----------AW Load error check module ---------------
local inst = mc.mcGetInstance()
local profile = mc.mcProfileGetName(inst)
local path = mc.mcCntlGetMachDir(inst)
package.path = path .. "\\Modules\\?.lua;" .. path .. "\\Profiles\\" ..  profile .. "\\Modules\\?.lua;"
package.loaded.mcErrorCheck = nil
ec = require "mcErrorCheck"

--local defUnits
local rc

--defUnits, rc = mc.mcCntlGetUnitsDefault(inst)
-- c = mc.mcJogSetUnitsMode(inst, mc.X_AXIS, defUnits)

rc = mc.mcJogSetUnitsMode(inst, mc.X_AXIS, mc.MC_UNITS_METRIC)
if (rc ~= mc.MERROR_NOERROR) then
   mc.mcCntlSetLastError(inst, "Setting X-axis mode returned " .. ec[rc])
end
rc = mc.mcJogSetUnitsMode(inst, mc.Y_AXIS, mc.MC_UNITS_METRIC)
rc = mc.mcJogSetUnitsMode(inst, mc.Z_AXIS, mc.MC_UNITS_METRIC)
rc = mc.mcJogSetUnitsMode(inst, mc.A_AXIS, mc.MC_UNITS_METRIC)
   
Title: Re: Using a button script to set jog increments etc
Post by: Fledermaus on May 29, 2018, 06:34:09 PM
Quote
I hope I'm not being seen as a pain in the arse for pursuing these things doggedly.

Well you're still getting replies to your post so I guess not.

I would say that I am more inclined to accept Mach4 as is and find a way around any issues as far as I am able. But the more Mach4 can be made bullet proof the better for all of us.

Allan
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 30, 2018, 03:34:19 AM
Quote
I hope I'm not being seen as a pain in the arse for pursuing these things doggedly.

Well you're still getting replies to your post so I guess not.

I would say that I am more inclined to accept Mach4 as is and find a way around any issues as far as I am able. But the more Mach4 can be made bullet proof the better for all of us.

Allan

We all had that mindset with Mach3, because that was a lost cause. Mach4 brings a new opportunity to get it right, and it's a remarkable piece of code.

All we need to do now it convince those who wrote it to go the extra mile and fully document what's there. That way we wouldn't have to keep asking them things and trawling through forums and YouTube  videos in the hope of finding out what we need.

The MDI is a classic example of that. If there is documentation about how to clear and read the text or how to do something after the MDI has been executed then I apologise. I've looked everywhere I could think of an found nothing.
Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 30, 2018, 04:27:33 AM
Hi striplar,
I suspect the reason that has not been documented is that maybe as few as half a dozen people on the planet have ever thought about it let alone done
something with the idea.

Much of what is in Mach4 is there because that's what the developers wanted for their machines and by and large that is entirely adequate. If you want some
other behavior that is indeed possible but it does take some thinking about to implement it. For every CNC enthusiast there is a different conception of what is required
and desirable.

The next few years promise to be very interesting as all those enthusiasts implement all their ideas, all in all I think its exciting.

Craig
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 30, 2018, 04:56:15 AM
Hi striplar,
I suspect the reason that has not been documented is that maybe as few as half a dozen people on the planet have ever thought about it let alone done
something with the idea.

Much of what is in Mach4 is there because that's what the developers wanted for their machines and by and large that is entirely adequate. If you want some
other behavior that is indeed possible but it does take some thinking about to implement it. For every CNC enthusiast there is a different conception of what is required
and desirable.

The next few years promise to be very interesting as all those enthusiasts implement all their ideas, all in all I think its exciting.

Craig

Hi Craig,
I think it's more like a shop saying it doesn't sell many eggs,,,, but they keep the eggs under the counter and don't tell anyone they sell them.

Users won't even know what's possible unless they're told what all of the components and services Mach4 offer do. The's very frustrating. It feels like it's all a big secret and that you have to be an insider to get access to this stuff when it ought to be out there for everyone to see. It would not only let users customise Mach4 more easily, but it would ultimately be less work for those who don't document it because they aren't having to field questions like mine.

I would urge the developers to roll up their sleeves and document this stuff so we can all get the most from Mach4. It takes a bit of self discipline to document things when it's much more interesting to just write new stuff (and leave that undocumented too). At the moment, it's a struggle every time we want to modify the behaviour of a component, or find out what internal variables are exposed to the user and what they do.

I suspect that most users just give up on anything but the most basic customisation unless they're very determined, because it takes too much time to find the information they need. As you say, every CNC enthusiast has a different conception of what's required, so making that easy to achieve makes sense.

The future is certainly exciting, the promise of Mach 4 is enormous.

Roger
Title: Re: Using a button script to set jog increments etc
Post by: joeaverage on May 30, 2018, 05:59:10 AM
Hi striplar,

Quote
Users won't even know what's possible unless they're told what all of the components and services Mach4 offer do
The scripting manual does a fair job introducing the basics, but just the basics. Were it complete there would be so much information that the
vast majority of users would be lost.

Years ago when at University we had a VAX11-70 in the Department. The reference manuals were a rack of ring binders that covered half a wall.
As a newbie it was daunting. What various undergrads had done was condense the manuals down to a single ring binder, the basics. From there you could
get a feel for what it was you needed to know and then search the manufacturers reference as required. By the end of my four years I'd added a page or two
to the basics.

Mach4 documentation is at best the basics only, the detailed reference is some way off. Steve is our reference at this point in time....he has the time and energy to
develop new stuff but obviously loathes documenting things which are already done. That's just who he is....but I think you are coming to see the true genius
of what he is building and its truly awesome. If his inclination is to develop new stuff then I reckon 'go get'em Steve'.

Quote
It feels like it's all a big secret and that you have to be an insider to get access to this stuff when it ought to be out there for everyone to see
I agree, although its not a deliberate strategy, its just the way things have worked out. Whether you know it or not you are becoming one of the insiders!

Quote
I suspect that most users just give up on anything but the most basic customisation unless they're very determined, because it takes too much time to find the information they need.
Yes, you have to be determined. Even were there much better documentation it still requires imagination and determination to master it all.

Craig
Title: Re: Using a button script to set jog increments etc
Post by: striplar on May 30, 2018, 09:16:32 AM
Hi Craig,
I'm very impressed by the quality of the documentation that is supplied, and the new videos by Mach Support are very clear and useful, as are those by third parties.

I certainly can appreciate that you couldn't realistically put all of the information in one source, it would be indigestible and way too much for many users. It's not easy to find the right balance between not scaring people off, yet giving them the information they need to achieve what they're trying to do.

Maybe a three pronged approach would work. I think most people would be able to move buttons about and change their colours and assign different actions to them, given the information currently available.

What's needed is an 'Intermediate guide' for doing things that quite a few users would like to do, and an 'Advanced guide' that assumes you know the other stuff and takes you to another level.

Sometimes you have to tame the genius to get the most out of him, and this may well be one case where that might bear fruit. Maybe he can co-opt someone else who he can liaise with who is more of the mind to explain these things, someone who likes doing this stuff?

Personally, I have no need to master all of it, life's too short, and in the end Mach4 is a tool to get another job done. It's easy to get carried away creating the perfect machine and never make anything with it! However, I don't mind spending time and effort to make my life more pleasant by tailoring the machine to my taste. If that helps someone else along the way then all the better.

Roger