Hi,

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

Craig

Thanks Craig!

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.

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

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

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. 

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

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

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

What kind of pendant?  And what kind of motion controller are you running? 

Steve

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.

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

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.