Messages

1

Mach4 General Discussion / Re: Mach sometimes ignores mcCntlGcodeExecuteWait() without an error

« on: April 21, 2021, 07:15:01 AM »

I agree that the script shouldn't be stopped by Mach, it was just a bit of a surprise back when I wrote the script, as the custom M6 example in the manual makes no mention of this.

This time, however, the API function doesn't even seem to set an error. I'll see if updating Mach solves this.

In order to totally fool-proof the script, I thought of adding checks to make sure that the machine really is at the destination after a move. If it isn't, I'd stop the machine. I'd implement this by reading the actual machine coordinates and checking if they are within a small enough distance from the requested location. This comes with quite a bit of added complexity, though, so if anyone has any suggestions, I'd be happy to hear them.

2

Mach4 General Discussion / Mach sometimes ignores mcCntlGcodeExecuteWait() without an error

« on: April 19, 2021, 05:58:22 AM »

I have a complex M6 script for a mill. The script moves over to the tool rack and releases the current tool, then moves over to the requested tool and grabs it.

Sometimes the script just seems to jump over the "move" part of itself - it doesn't execute G-code, but does set (some) outputs as if nothing had happened. This is weird, as I do actually check the return value of all mcCntlGcodeExecuteWait() statements I issue and essentially halt if it's anything but 0.

Here's the G-code execution wrapper function I use:

Code: [Select]

function toolchange_callGcode(gcode)
    if toolchange_is_action_allowed()==true then
        local inst = mc.mcGetInstance()
        mc.mcCntlSetLastError(inst, gcode)
        --wait for the machine to be
        local rc = mc.mcCntlGcodeExecuteWait(inst, gcode)
        if rc ~=0 then
            toolchange_stop_safely()
            mc.mcCntlSetLastError(inst, "Something went wrong with executing G-code from within M6. The machine was disable for safety. Error state: "..rc)
        end
    end
end


toolchange_stop_safely() is a function that sets a global variable toolchange_action_allowed_flag to false. I read that flag in toolchange_is_action_allowed(), before any calls that impact the machine (like switching output signals or executing G-code, as shown above):

Code: [Select]

function toolchange_is_action_allowed()
    local inst = mc.mcGetInstance()
    if (toolchange_action_allowed_flag==true and toolchange_machine_enabled()==true) then
        --mc.mcCntlSetLastError(inst, "Action allowed")
        return true
    else
        --mc.mcCntlSetLastError(inst, "Action not allowed")
        return false
    end
end

I've had a similar issue in the past (https://www.machsupport.com/forum/index.php?topic=36577.20), where the script didn't stop execution after a "stop" or "disable" but that behaviour was completely deterministic and always happened. This was solved and the complete solution is in the last post.

The current issue, however, only happens rarely, both in MDI and from G-code programs, and Mach seems to get stuck in this state. It keeps jumping over the G-code calls until I restart the whole machine (including the DSMPC motion controller). Mach4 is version 4.2.0.2872, which is quite old. Here's the whole M6 script, for which I'm happy to provide additional explanations for: https://pastebin.com/244jsUyR.

Are there any other errors I should check for, or am I missing something basic? I'd also be thankful for any other suggestions for making my script error-proof.

3

Mach4 General Discussion / Re: Lua script detect when the cycle is running

« on: February 18, 2018, 12:59:37 PM »

Thank you for your time. Here's what I ended up doing:

A function to ask if the machine hasn't been disabled or stopped, used each time there is a signal change or any other physical or Mach-related change, except some specific cases, more on them later.

Code: [Select]

function toolchange_machine_enabled()
    local inst = mc.mcGetInstance()
    local mcState = mc.mcCntlGetState(inst)
    if mcState==mc.MC_STATE_IDLE then
        return false
    else
        return true
    end
end
An example of its usage:

Code: [Select]

function toolchange_boringhead_motorOFF()
    if toolchange_machine_enabled()==true then
        local inst = mc.mcGetInstance()
        mc.mcSignalSetState(mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT4), false)
    end
end
The reason I didn't return out of the script if this function returned false, is that G-code states (like whether G90 or G91 is currently active) get recorded at the beginning of my M6 script, and have to be returned to afterwards. The script is complex enough that is actually has its own G-code safe start line similair to one in a G-code program. This is also the specific case during which I don't check if the machine hasn't been stopped - I need the machine returned to the previous state regardless of what happens in the meantime.

For safety regarding mc.mcCntlGcodeExecuteWait(), I made this function that I replaced every direct call of mc.mcCntlGcodeExecuteWait() with:

Code: [Select]

function toolchange_callGcode(gcode)
    local inst = mc.mcGetInstance()
    local rc = mc.mcCntlGcodeExecuteWait(inst, gcode)
    if rc ~=0 then
        mc.mcCntlEnable(inst, false)
        mc.mcCntlSetLastError(inst, "Something went wrong with executing G-code from within M6. The machine was disabled for safety. Error state: "..rc)
    end
end
Knowing the rest of my code can handle the machine stopping, I stop the machine directly from this function, which also saves me from having to track another error flag.


I also found out that if you call a custom M-script from within another custom M-script, Mach freezes, not taking any G-code anymore, yet not stating that there was an error, jogging also retains its function. Consider I was using Mach4 version 4.2.0.2872, and newer versions may not have this issue.

4

Mach4 General Discussion / Re: Lua script detect when the cycle is running

« on: February 16, 2018, 03:04:26 PM »

Now, is it clear what the problem is? Prints happening like that are harmless. However, if you were to have a call to change a signal there instead, say for releasing a tool from the spindle, it becomes quite dangerous, doesn't it?
Checking if the machine hasn't been stopped each time I need a signal switched would solve the issue, and something to check for that is what I requested assistance with at the beginning.

FYI, I'm running Mach4 version 4.2.0.2872.

5

Mach4 General Discussion / Re: Lua script detect when the cycle is running

« on: February 16, 2018, 02:20:01 PM »

It doesn't stop. Maybe I've made a rookie mistake somewhere along the line though, that causes it to not stop properly.

Nevertheless, I've tested it, and you can too. Try this M-script. if you press either disable or stop while G4 is delaying (any other G-codes that take up time also work), you still see the prints near the end.

function m401()
    local inst = mc.mcGetInstance()
    print("starting")
    mc.mcCntlGcodeExecuteWait(inst,"G4 P3")
    local mcState,rc=mc.mcCntlGetState(inst)
    if (mcState==mc.MC_STATE_IDLE) then
        print("IDLE")
    else
        print("ELSE")
    end
    print("end")    
end

6

Mach4 General Discussion / Re: Lua script detect when the cycle is running

« on: February 16, 2018, 02:10:47 PM »

https://pastebin.com/QcUSfu7E

Here you go. This one still has a lot of print() uses instead of mc.mcCntlSetLastError(), shouldn't really matter though.

7

Mach4 General Discussion / Re: Lua script detect when the cycle is running

« on: February 16, 2018, 09:50:46 AM »

I'm not talking about separate scripts, but rather a single M-script and code within it. There are 2 ways this can work out:

1. M6 gets called by either MDI or G-code and nothing interrupts it. The execution starts at the top of the script and ends at the bottom, with nothing left out in between.

2. M6 gets called by either MDI or G-code but the machine is stopped or disabled halfway through by the operator. The execution starts at the top, YET STILL ENDS AT THE BOTTOM, since Mach actually doesn't stop executing until the whole thing has been gone through. AND, G-code calls won't do anything, because they actually seem to check if the machine is enabled and not stopped. This means that some things will be left out, yet others (like signal changes) won't be. This is an obvious problem since no-one wants to have a script execute only partially with some things arbitrarily left out.

What I wanted to do was simply make everything else in my M6 script also check if the machine was enabled and not stopped, so after the latter, nothing inside M6 would actually be executed. I'm sorry if I wasn't clear on this. Your solution is still appliccable, though.

8

Mach4 General Discussion / Re: Lua script detect when the cycle is running

« on: February 15, 2018, 02:07:07 PM »

Thanks, it seems to be suitable. Just to clear it up, for me it would be the opposite:

local mcState,rc=mc.mcCntlGetState(inst)
if (mcState==mc.MC_STATE_IDLE) then
    --
    -- Don't execute code, as the program was terminated (either the machine was disabled or the stop button was pressed) and the M-script should not proceed.
    --
else
    --
    -- The program is still running, and therefore it is safe to proceed execution
    --
    --
end

Now this might not be totally safe, as there may be other states under which code should not execute, yet which will take the 'else' route in this example. Is there a list of states and their descriptions? I couldn't find one in the docs or by using Google.

9

Mach4 General Discussion / Re: Lua script detect when the cycle is running

« on: February 15, 2018, 12:24:09 PM »

I think we might be getting a bit overcomplicated here. What I need would just be something to check so as to not execute a piece of code, if a Gcode or an MDI program isn't running. In other words, if the G-code or MDI program is stopped during executing an M-script, the script could know and halt itself. Checking mcCntlIsInCycle() works for G-code programs, but I couldn't find anything that would work for MDI.

The piece of code isn't related to the motion planner, rather changing the state of signals.

However, I'm really thankful that you mentioned GcodeExecuteWait() could return an error, which I had overlooked since it had never happened to me.

10

Mach4 General Discussion / Re: Lua script detect when the cycle is running

« on: February 13, 2018, 01:56:02 PM »

I don't check anything before calling mc.mcCntlGcodeExecuteWait(), Mach seems to be taking care of stopping any actions specified by it whenever required. I call my function before changing signals, as in outputs. However, now I'm thinking that maybe I should, if an error like you described could pop up.

Your example, while it seems to work for G-code files, doesn't work if ran under MDI (returns 1 if G-code file, 0 if MDI or machine disabled or stopped).

Here's what I used to test it - an M-code. I tested it by stopping or disabling the machine during the G4 time delay and comparing the results to occasions on which I let it complete.

function m400()
    local inst = mc.mcGetInstance()
    print("starting")
    mc.mcCntlGcodeExecuteWait(inst,"G4 P3")
    cycle, rc = mc.mcCntlIsInCycle(inst)
    print("cycle: "..cycle.." rc: "..rc)
    if (cycle == 1) then
        print("Cycle running")
    else
        print("Cycle not running")
    end
end