Messages

1

Mach4 General Discussion / Re: Mysterious signal set when probe fails ESS + G31

« on: February 15, 2021, 04:08:00 AM »

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:

Code: [Select]

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.

2

Mach4 General Discussion / Re: Mysterious signal set when probe fails ESS + G31

« on: February 13, 2021, 02:41:10 AM »

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

3

Mach4 General Discussion / Re: Mysterious signal set when probe fails ESS + G31

« on: February 12, 2021, 04:08:16 PM »

Is off to the support - They will Check with Andy who is already on top of things...

4

Mach4 General Discussion / Re: Mysterious signal set when probe fails ESS + G31

« on: February 09, 2021, 08:29:30 PM »

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?

5

Mach4 General Discussion / Re: Mysterious signal set when probe fails ESS + G31

« on: February 09, 2021, 05:34:34 PM »

Well thanks Brian

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

6

Mach4 General Discussion / Re: Mysterious signal set when probe fails ESS + G31

« on: February 09, 2021, 10:01:10 AM »

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?

7

Mach4 General Discussion / Re: Mysterious signal set when probe fails ESS + G31

« on: February 08, 2021, 07:09:47 PM »

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?

8

Mach4 General Discussion / Re: Mysterious signal set when probe fails ESS + G31

« on: February 08, 2021, 06:37:42 PM »

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.

9

Mach4 General Discussion / Mysterious signal set when probe fails ESS + G31

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

10

Mach4 General Discussion / Re: How to use the TouchOff UI with TLO

« on: February 04, 2021, 09:21:54 AM »

Ok so i cracked open the touchoff UI and understand why it goes wrong but I have a hard time wrapping my head around how to properly fix it.

In the TouchOff UI when using FindZ it probes and then sets the fixture offset. setting the offset is done using a helper function called SetFixOffset(Axis, Direction).

If i have tool to probe with using a circuitboard blank as touchoff plate this will not work if i use tool offsets because SetFixOffset(Axis, Direction) uses mc.mcAxisGetProbePos to determine the Z offset. The definition of mc.mcAxisGetProbePos is composed of Machine pos + Work offset (in my case an old value i want to update)  G92 (which is irrellevant here ) head shift and workshift.

To me MachineCoordinates are current offset from home switches,
Work Offset is the position in MachineCoordinates a ncprogram should use as origin when spindle is centered over the Work Offset origin and gaugeline touches the Work Offset Z0,
Tool length offset is the length of a tool measured from the gaugeline as a negative value

Having the above definitions how should i set the work piece?