Hello Guest it is March 28, 2024, 03:42:44 PM

Author Topic: MERROR_NOT_NOW from GcodeExecuteWait() API Call  (Read 1984 times)

0 Members and 1 Guest are viewing this topic.

MERROR_NOT_NOW from GcodeExecuteWait() API Call
« on: February 03, 2018, 06:50:45 PM »
Hi All,
have run into a problem with some code.This is a snippet, I've left the wxMessage boxes etc in there, they are for testing purposes only.

Code: [Select]
        --Mach enabled but servos 'offline'
        --Need to restore current position and reset servos 'online'
        local Xpos=mc.mcCntlGetPoundVar(inst,500)
        local Zpos=mc.mcCntlGetPoundVar(inst,501)
local state=mc.mcCntlGetState(inst)
local statename=mc.mcCntlGetStateName(inst,state)
wx.wxMessageBox(statename)
local rc=       mc.mcCntlGcodeExecuteWait(inst,'g53 g0 x'..Xpos..' z'..Zpos)
wx.wxMessageBox(tostring(rc))
        mc.mcSignalSetState(hsigbuttonstate,1)
    end

What appears to be happening if there is a Gcode file loaded and has partly run then Stopped, the control is Idle,
but when I execute the GcodeExecuteWait() statement it returns -18 or MERROR_NOT_NOW. My guess is that the Gcode interpreter is still loaded with
the Gcode file and is unavailable to execute the Gcode within my API call in MDI context?

Has anyone encountered this? Is my guess as to why the GcodeExecuteWait() API call does not complete correct? That same stament does execute correctly
under other circumstances so I am reasonably confident that its not some syntax error in my code.

If my guess is correct is there some way to shove the Gcode file out of the way, have the MDI Gcode execute, then shuffle the Gcode file back in?

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: MERROR_NOT_NOW from GcodeExecuteWait() API Call
« Reply #1 on: February 04, 2018, 01:30:02 AM »
Hi,
have done a little more experimenting and found a workaround.

The problem is that if a Gcode file has been loaded and run, then stopped in cycle that an API call which requires MDI support to execute fails.
Closing the Gcode file does not restore MDI functionality. It requires either a RegenToolpath or a MachDisable/MachEnable cycle.

A Disable/Enable cycle preserves the Gcode file at its current line and is therefore suitable for my purpose.

The workaround goes something like this:
1) Try the GcodeExecuteWait() API
2) Test the return code, if rc=0 the call has succeeded. If rc=-18 then mc.mcCntlEnable(inst,0) mc.mcCntlEnable(inst,1)
3) Try the GcodeExecuteWait() API call again
4) By now the return code should be rc=0 so re-enable the servos

This sequence allows the machine coordinates to be restored and yet preserve the part completed Gcode job.

Still interested to hear an explanation for this behavior....hint...hint Daz and Smurph.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'

Offline DazTheGas

*
  •  778 778
  • DazTheGas
    • View Profile
Re: MERROR_NOT_NOW from GcodeExecuteWait() API Call
« Reply #2 on: February 04, 2018, 04:08:38 AM »
The only way I can answer that is if a workaround works safely then its ok.

DazTheGas
New For 2022 - Instagram: dazthegas
Re: MERROR_NOT_NOW from GcodeExecuteWait() API Call
« Reply #3 on: February 04, 2018, 06:07:38 AM »
Craig

I too have experienced this sort of behaviour. It begs the question when does Idle mean Idle? One answer, as you have found, is when it is followed by Enable.

I have a tool height measuring function, based on the mcProbing module (though I have totally restructured/rewritten the first 2000 lines or so) that lifts the tool, sends it over the sensor, does a 2 strike G31.1 probe down to the sensor , then lifts and returns the tool to its starting position. If it succeeds, it sets the Fixture offset or Tool table entry (user has the option) for length compensation.

On my office PC, it runs perfectly in the SIM, though of course the probe strike does not occur.  It runs from a screen button push either from an Idle state or when code has been halted in the File Run state by an M6 macro. (The macro uses SignalWait().)) I am not using coroutines as the GUI does not appear to freeze. With a coroutine approach, I found that the code ran fine normally, but froze the screen when run during the M6 hold.

On my CSMIO system, the same code lifts the tool and moves it over the sensor, but then fails with that infuriating errorMERROR_NOT_NOW. As yet, I haven't drilled down further to see what's happening., but it's on my list for attention.  

Allan
Re: MERROR_NOT_NOW from GcodeExecuteWait() API Call
« Reply #4 on: February 04, 2018, 03:08:35 PM »
Well I found my error that was frustrating the tool height measurement.  I had requested a probe move that would have taken Z below the minimum soft limit. Once I fixed that, the routine worked repeatedly and well, whether called from a screen button in the Idle state, from a screen button during an M6 File Run state, or from within the M6 macro itself. The macro was held using  mcSignalWait.

I am beginning to think that MERROR_NOT_NOW is simply a catch-all message, meaning that as a diagnostic aid it is next to useless. I say this because the same error was produced when attempting to run the button script when Mach4 was disabled.

Allan
Re: MERROR_NOT_NOW from GcodeExecuteWait() API Call
« Reply #5 on: February 04, 2018, 03:33:11 PM »
Hi Allan,
yes I find that my improved code for the Offline Button project I've been helping out with works much much better
but still from time to time fails, I suspect due to that same MERROR_NOT_NOW despite having been passed
thru the disable/enable cycle, as if some other condition prevents my API cal from completeing and as you say this
is the catch all return code.

As another issue I found that mc.SignalWait() was limited to input signals of signal IDs less than 64. That is input#0
thru input#64. Any input out of that range has a signal ID of greater than 64 and the mc.SignalWait API will fail.
I got so desperate to work out what was going on I opened a support ticket and got that wee gem from NFS Support.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: MERROR_NOT_NOW from GcodeExecuteWait() API Call
« Reply #6 on: February 04, 2018, 04:24:51 PM »

Yes, I remembered your post re limited range for mc.SignalWait(). Thanks for saving me from that pitfall.

MERROR_NOT_NOW does seem to crop up occasionally. It is frustrating because one is usually mystified as to its cause and yet it provides no clue as to the solution.

Allan