Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: Bx3mE on February 06, 2021, 07:35:28 PM
-
I am using the X360 plugin to control my machine and have implemented a button to execute a probe move.
If the button is pressed i run mc.mcCntlGcodeExecuteWait("G31 X-5 F20")
if i dont strike any target, pressing the button again thus executing mc.mcCntlGcodeExecuteWait("G31 X-5 F20") again does not start a probe move.
If it strikes the first time running it a second time is no problem...
Before running any GCode in the script i check various signals and make sure the machine is up for the task by checking IsInCycle, Is Enabled, Get signal state for Idle etc. which works great but none of these indicate that the machine is in any different state than before pressing the button the the first time. I suspect that i have missed someting but i dont know where to start looking.
Which variables and signals are set different when comparing a mc.mcCntlGcodeExecuteWait("G31 X-5 F20") move which strikes and one that does not strike?
-
Execute wait should really be done in a Mcode only. It will stop the Lua chunk from running. Please tell me a bit more how you have this setup. How and where are you calling this script?
-
The X360 plugin is used in a panel located like so: wx4->Default->X360_Panel
The panel script is attached
In the script i monitor Button events
- Two buttons are used as Safe grip (to avoid accidental movement)
- Thumbsticks are used for Jog Movement
- Buttons X,A,B are used for Machine Enable, CycleStart and E-Stop
- Button Y is used like button start, as a modifier button which modifies the behaviour of the DPad
No Modifier:
-DPad up/down -> Spindle Speed
-DPad L/R -> Feedrate
Y Button Modifier:
-DPad up/down -> Probe YAxis
-DPad L/R -> Probe XAxis
Start Button Modifier:
-DPad up/down -> Probe ZAxis
-DPad L/R -> Probe AAxis
When i probe using the X360 DPad i can execute the probe move.
If the probe move fails to trigger the probe
the next time i press the DPad the mc.mcCntlGcodeExecuteWait() function seems to execute, as logging before and after indicates so, but no movement is generated on the machine.
-
In cleaning up my code i found that the second time the mcCntlGcodeExecuteWait returns -18 or MERROR_NOT_NOW
Which i was suspecting but could not se because of clumsy fingers but still.... why do i get the -18 the second time?
And in what way is the first run not leaving control available?
How can I fix this?
-
I found if i did a G31 and returned a error, then G31 didn't work correct if i ran it again, after the error i added
mc.mcCntlEnable(inst, 1) and that seemed to fix it.. for me
gary
-
I tried that and it works... thanks a lot gorf23! BUT...
I feel this to be a BIG workaround... why? Because i have no way to check the underlying flag or resetting it without using a global function which does more than reset the flag causing the -18 MERROR_NO_ERROR to be returned.
@Brian: Better solution?
-
Yes your probley right, but what I think is going on is if a g31 error is returned then mach4 needs to be re-enabled. the first g31 with error seems to stop the next g31 from working endless a re-enable I'm not sure if its a bug or the way it was designed, also not sure if its mach4 or the plugin. But its does deem to work as a workaround for now.
Gary
-
There is a setting in the ESS to tell it to do nothing if a probe is not found. We don't do a disable of the machine . I think you will find that is the ESS. It is some don't estop/disable if a probe is not found setting in the ESS dialog. Could that be the issue your having?
I can have the guys test this on a machine but I don't have one at my desk I can test with.
-
Well thanks Brian :P
If you open the ESS Config Dialog it is very clerar that this behaviour is induced by the ESS, BUT the behaviour is still somewhat incorrect somewhere...
It says: 'Failure disables mach4' but it does not because from what i can see my Enable button in the control group on the wx4 Screen still reads "Disable" as if the machine was still enabled. Also my other scripts can still execute as they rely on mach4 to report correctly if the machine is enabled or disabled.
Is it the ESS plugin which needs to set some flags or is the function called by the ess plugin to disable mach4 missing to set these flags?
Should i file a ticket?
PS. I will ask Andy as well to check his implementation.....
-
Well frankly I don't really know. I would like to have the guys test it so I can see the problem. My issue is I don't have time to try everything myself :( If you can make a clear case as to how I can see the issue I am way more than happy to look at it. Only so many hours in a day and that is what I have the guys for! Save Steve and I some time getting problems so we can see them. I am willing to look at what you have if you think you have it down to a point that I can make it happen. Do I need any special hardware to make it happen?
-
Brian
i do something like this and then i can run g31 over and over and works
without cntlenable i have to hit the mach4 enable button to run g31 a second time, or i won't get any axis movement
but i am not having any real problems with the scripts setup like this its the ESS register i am reading for errors
rc = mc.mcCntlGcodeExecuteWait(inst, "G91 G31 Z-"..ZMaxTravel.." F"..SlowFeed) -- start the z probe if not hit Show not hit and exit
if mc.mcRegGetValue(hreg) == ProbeState then -- check the probe state if ProbeState error probe not hit
mc.mcCntlSetLastError(inst, "No Probe Hit Aborting try a higher ZMaxTravel, or make sure you are over the part") -- send messsage error
mc.mcCntlEnable(inst, 1)
return false -- now exit and abort
end
-- probe was hit
Gary
-
The ESS isn't actually disabling Mach4 when that option is selected, it's only issuing a cycle stop command.
-
No special hardware needed! I use a drill connected to GND and a circuitboard blank to create a short circuit when the probe touches.
To replicate the behaviour you can run the below code in a button_up script and dont let the probe trigger: (And the ESS needs to have the probe configured and options set as in the image i posted.
rc = mc.mcCntlGcodeExecuteWait(inst, "G91 G31 Z-1 F20")
rc = mc.mcCntlGcodeExecuteWait(inst, "G91 G31 Y1 F20")
The above will only generate movement in >Z direction. When it comes to the second line it will return -18.
The only way to avoid this is to add "mc.mcCntlEnable(inst, 1)" between the two lines, then it works.
I tried to dig more into the documentation and as per the statement on the config screen for the ESS it seems to claim that it uses Cycle_Stop which per the API internally Feed_hold. I dont know if this is related to my issue but it is what i have found so far.
gorf23: when you say: "without cntlenable i have to hit the mach4 enable button to run g31 a second time" i guess you mean you have to press it Twice: first to disable and then a second time to enable or does the g31 without a hit cause your enable button to change state?
-
Send it into the support guys. They can make that setup and test it :) tell them I sent you ;)
-
Is off to the support - They will Check with Andy who is already on top of things... :P
-
While i wait for the support i was chatting with Andy on the warp9td forum and this thread covers his response to my problem: https://warp9td.com/index.php/kunena/7-general-discussion/8746-probing-error-bad-behavior-when-probing-fails (https://warp9td.com/index.php/kunena/7-general-discussion/8746-probing-error-bad-behavior-when-probing-fails)
-
Blah , I don’t have an account.
-
No info on the actual problem but one workaround solution is to use GCode M2010(......) to disable "disable Mach4 on probe fail" before the routine and enable if again after using the corresponding M2010(...) call. To determine if the probe hit you can use:
hregProbingState = mc.mcRegGetHandle(inst, string.format("ESS/Probing_State"))
iProbingStateValue, iReturnCode = mc.mcRegGetValue(hregProbingState)
I is a better looking workaround but still not a solution because if Mach4 is disabled by ESS during probing with "disable mach on probe fail" enabled - Mach4 is in a state which disables the motion of the machine but without indication. Also if I use this way in my screen script and decide to uncheck the "disable mach on probe fail" it will get auto enabled when i run my script as i can not determine if the setting is enabled or not in code.