Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: Raymondo on July 26, 2019, 03:01:20 AM
-
I have done a update to current mach4 from version ending in 3804
Installed over the top but backed up the profile first and reinstalled the profile
when I had problems I did a fresh install then installed the license files the ESS and the penant ec then loaded my machine profile it comes up then with a lua problem message I then delete all the lua in macro's directory with the extension MCC the lua problem message goes away
But when I run a m6 tool change it starts the process then the program Mach4 terminates part way through the tool change
If I run a M6 with the same tool number of the tool in the machine I get the message "nothing to do tool already that number" so I know it is getting some way into the tool change script.
I have the earlier mach4 program and it runs fine in that
any idea's on where to start trouble shooting or what happening
Regards Ray
I have attached the m6 file I had to rename to do this
-
After some more testing it seems Mach4 terminates when it runs into a command like this
mc.mcSignalWait(inst,mc.ISIG_INPUT7 ,1,0)
the previous mach4 version t read the inputs in the m6 script and worked fine
-
Hi,
have you tested the return codes?
There is one in particular that crops up 'MERROR_NOT_NOW'. You need to check for it.
Craig
-
I don't know how to test for return codes
But as soon as the program hits the line in the M6 script with that input line it terminates Mach4 and I obviously have to restart Mach4
How do I test for Return codes are they stored some where at program failure ?
Regards Ray
-
I have had time to have a think about the problem
I think it must be some sort of problem in the new version of Mach4 the version ending in 3804 handles the M6 tool program I have but the new version ends when the command in the M6 file reaches
mc.mcSignalWait(inst,mc.ISIG_INPUT7 ,1,0)
or also
mc.mcSignalWait(inst,mc.ISIG_INPUT12 ,1,0)
if mark these out so they are not used the program runs past if I leave them in it instantly ends with no chance to see error messages
Have the use of mc.mcSignalWait() or mc.ISIG_INPUT12 been changed in the new version of Mach4 ?
even it i has the program should not I believe just terminate and end but come up with a error message of some sort or even hang but it ends
Regards Ray
-
Might this be the Lua 5.3 vs Lua 5.2 issue? Try going in your profile, delete your m6.mcc file, or move it/rename it, and start Mach4 and let it recompile. If that works, you may need to do the same with other macros, too.
I could be completely wrong, but doesn't hurt anything to try.
Tom
-
Hi,
every Mach API function has a return code. When programming you should get into the habit of testing the return
codes to trap errors. Aside from anything else it will help you identify the offending function call.
LUA Syntax:
rc = mc.mcSignalWait(
number mInst,
number sigId,
number waitMode,
number timeoutSecs);
Description:
Wait on a signal to change state.
Parameters: Parameter Description
mInst The controller instance.
sigId A valid signal ID. (NOT a signal handle)
waitMode An integer specifying whether to wait on the signal to go high (WAIT_MODE_HIGH) or low (WAIT_MODE_LOW).
timeoutSecs A double specifying a timeout period.
Returns: Return Code Description
MERROR_NOERROR No Error.
MERROR_INVALID_INSTANCE The mInst parameter was out of range.
MERROR_INVALID_ARG sigId or wiatMode is out of range or timeoutSecs is negative.
MERROR_NOT_ENABLED The control is not enabled.
MERROR_TIMED_OUT The timeout period was reached without a change of state.
Note the syntax:
rc=mc.mcSignalWait(.........)
rc is a numeric value, with each number meaning a different thing.
And note the possible return code enumerations:
MERROR_NOERROR
MERROR_INVALID_INSTANCE
MERROR_INVALID_ARG
MERROR_NOT_ENABLED
MERROR_TIMED_OUT
Of these MERROR_INVALID_ARG and MERROR_TIMED_OUT are likely to give you most grief.
The return codes are a number, MERROR_NOERROR is equivalent to 0 whereas MERROR_TIMED_OUT is
equivalent to -40. A full set of return codes and their numeric equivalents are here:
https://www.machsupport.com/forum/index.php?topic=40051.0 (https://www.machsupport.com/forum/index.php?topic=40051.0)
To test a return code do something like this:
local rc=mc.mcSignalWait(inst,mc.ISIG_INPUT7 ,1,0)
if rc==0 then --No error
end
if rc== -2 then
wx.wxMessageBox('Function failed-invalid arg')
return
end
if rc== -40 then
wx.wxMessageBoox('Function failed-timed out')
return
end
Craig
-
is there a way to put just the error number in the message box that would seem easier to me then listing all the messages in the code I could then look up that number
I will have a good play with the machine today and see what I can find but if Lua has changes versions that would explain me having to delete all the .mcc files and let it recompile them and it may be some part of the current problem
regards Ray
-
Either of these should work for checking your rc.
wx.wxMessageBox(mcErrorCheck[rc])
mc.mcCntlSetLastError(inst, (mcErrorCheck[rc]))
-
HiHi
-28 MERROR_IPC_NOT_READY The Interprocess Communication subsystem is not ready.
this is the error then the program terminates
Where do I look it worked in the previous version with no problems
I have attached a cut down version off m6.msc that I use for testing it just opens the tool door and reads the input and now catches the error
-
Hi,
-28 MERROR_IPC_NOT_READY The Interprocess Communication subsystem is not ready.
What API resulted in this code?
I noted that in your previous post you had a command:
mc.mcSignalWait(inst,mc.ISIG_INPUT7 ,1,0)
This allows for a time out period of 0??? Is that what you meant. If you are going to wait for a signal you should have
some time frame in mind.....a few milliseconds even??
Craig
-
Hi it is this that it terminates the program
mc.mcSignalWait(inst,mc.ISIG_INPUT7 ,1,0)
But I also tried
mc.mcSignalWait(inst,mc.ISIG_INPUT7 ,1,4)
it then terminates with a error -40 a time out error so I believe there is some thing wrong with the way it gets the input or actiually fails to get the input
I copied the machipc.dll from the version of mach4 where is works but it made no difference I have now put back the correct machipc.dll they are 2 different date stamps and file sizes
Regards Ray
-
Hi,
so you extended the time out period to 4 milliseconds??? Can you be sure that a signal operates in that time frame?
Why not extend it to 1000 milliseconds and see what happens.
Craig
-
The wait period must be larger than the minimum time it will take your motion device to receive, process and return it. 4 is not enough.
-
Hi
I set it to 4 seconds not milliseconds and setting it to zero means it will wait for ever until a signal arrives
it now waits 4 seconds the mach4 program terminates and the message box pops up with error -40 as the command has waited its 4 seconds and then drops out as it should but with or with out a signal it should not terminate the mach4 program
I need it set to zero and this worked fine in 3804 version I do not want tool changes happening unless the tool door is
open
I went into diagnostics and can operate the door and see the input signal come on and off
I am not sure where to go there is probable another command I could use or I may start looking in ESS set up and see if some thing there effects a error -28
any thoughts and idea to test are more than welcome
-
Hi,
then drops out as it should but with or with out a signal it should not terminate the mach4 program
What would you expect Mach to do? You have asked it to wait on a signal, if the signal has not occurred within a specified time
what should Mach do?
You may note than in my thumbnail sketch of testing for return codes that on detection of a fault:
if rc== -40 then
wx.wxMessageBoox('Function failed-timed out')
return
end
Note in particular the <return> command. That should terminate the macro gracefully. Unless you give Mach such an alternative
what is it supposed to do next when an expected signal does not materialize?
Craig
-
With version 3804
if I put say a 2 second delay in and if the signal did not arrive in that time it would run down the script to the next command which in my case was to raise the tools loading bar and operate that output
I did not have any error message etc installed in the script as I set it to zero so it would wait until the door opens
The program did not just disappear of the screen and need to be reloaded each time as is does now
the error -28 I will set the program to 10 seconds delay and take the lid of the control so I can see ESS I think it has a led for the inputs and can then confirm the input is on in diagnostic it certainly comes on
Specifying 0 for timeoutSecs will wait indefinitely until the signal changes state. Decimals are allowed. e.g. .5 is half of a second.)
This is the advice on the delay and from looking at it when I set it for 4 seconds it seems to take about that long
-
I had a bit of a think and I can turn that input on check it is on in diagnostic then run the signalwait command also the second last digit determines if it accepts a high or low signal I will try that both ways as well
It might show some light on the problem
Though it was all working fine till the update
It is sunday morning here so will not be at the factory till tomorrow
-
Try updating to the latest development version.
ftp://anonymous:guest@ftp.machsupport.com/Mach4/DevlopmentVersions/Mach4Hobby_Installer-4.2.0.4261.exe
Let me know if it helps please.
-
Hi
we have the tool changer working again Whoo Hooo but after a lot of testing and playing around with ver 4261
But I believe there is still a bug
mc.mcSignalWait(inst,mc.ISIG_INPUT7 ,1,60)
I now use this and it works if a signal comes within the 60 seconds but the description for use says
Specifying 0 for timeoutSecs will wait indefinitely until the signal changes state. Decimals are allowed. e.g. .5 is half of a second.)
Using mc.mcSignalWait(inst,mc.ISIG_INPUT7 ,1,0) this did work as described in the 3804 ver now it will cause Mach4 to crash even if there is a signal there before call or after the command it does not matter using the command this way it will crash mach4 every time
just another question if I use this
if rc== -40 then
wx.wxMessageBox('Function failed-timed out')
return
end
just where does it return to ? does it just exit the m6 function ?
I would like it to return to a function where I can close tool doors retract they tool etc and exit the tool change nicely
Regard Ray
-
Hi,
just where does it return to ? does it just exit the m6 function ?
It returns to the calling program....if the calling program is the main Gcode program then yes it just exits m6.
Note that it will not return, in this case, until you dismiss/close the message box, ie it should come as no surprise.
If you wish to exit in another manner that can also be done, just don't use 'return' but instead program the behavior
you want.
Craig
-
Thanks Craig
I noticed the message box had to be closed this is a great function I was using this function to trouble shoot the program I could but a wx.message in before and after the calls here and there to make sure where the program was up to at each stage and it stops the program and you can tell what piece of code was to be next
I allowed me time to for instance turn on the input just before the waitforinput call is made and I could confirm that the input was in fact on before the call
regards Ray
-
Hi,
yes I use the wx.wxMessageBox for that purpose too.
Just be warned......DO NOT USE IN IN A PLC SCRIPT!!. I know eventually you will....I fell into that trap not once but twice!
Craig
-
Hi
I did notice some thing a bit different with this version when I set the timeout to zero I am not catching a error message
mc.mcSignalWait(inst,mc.ISIG_INPUT7 ,1,0)
mach4 stays open but if you click disable or stop it immediately crash's and no error messaged is displayed
It does the same in simulation mode on my home test computer
Regards Ray