The probe sensor was active. The operation was aborted

[sebmay]

Hello,

I am doing automation in my plugin.
Sometimes the UCCNC refuse continue after a G31.

The first problem is in "Sometimes".

Another point, in the sequence :
N01 G31 Z-10 F200 // first fast probing
N02 G91 G0 Z3 G90 // Go up 3 mm in order to restart veeeeeery slow
N03 G31 Z-10 F30 // to get maximum accuracy.

By definition, when entering line 02, the probe sensor is active.
How can i handle this case ?
C#

Thanks,

Seb

[cncdrive]

You can read the variable #5060 when the probing finished to see if the operation was successful or not.

The related text from the UCCNC manual:

the axes coordinates variables the variable #5060 is written to value 0 if the probe input was triggered and therefor the operation ended with success. It is written to value 1 if the probe was not triggered and the probing ended with reaching the programmed endpoint and it is written to value 2 if the probe input was already active when the G31 command was issued and therefor the movement was aborted.

[sebmay]

I understand that.
But the question is : why does the "G91 G0 Z3 G90" did not execute ?

I could understand if i mistakenly executed two G31 in a row.

The fact is that waiting for IsMoving() gives two problem :

Maybe i should wait after sending any "non-move" Gcode (G90, g91, g92 z0)

I just broke my probe : the G91 was "skipped", or i did not wait enough after. I exected the nex G0 Z3 to move up, but it went down !

The question is still : How can i send **ANY** GCODE (or Txx or Mxx), then make sure all the operation are completely finished.

I moved from codesync to code, to make sure i take CPU. Maybe this is wrong.
In case the gcode execution takes a long time (a long move), i do not know what would happens if i exit the loop many many seconds while waiting for code sync.

For example, is it possible to enter another Loop() while i am waiting for code sync ?
Seb

[dezsoe]

The question is still : How can i send **ANY** GCODE (or Txx or Mxx), then make sure all the operation are completely finished.

Yes, you are right. You must not use G90 and G91 in one line. They are opposites and both belong to modal group 3. By the standard you must not use more than one member of a modal group in one line.

The best practice is to use Code with one command and wait while ismoving().

[sebmay]

Thanks for that hint.

While i was waiting for answer, i did this modification. (And i will respect rule from now on anyway !)

But i still had the problem. Then i made an additional modification :

Sending (plugin loop):
If the code contains G90 or 91, i use "codesync", else "code"
nota : I am asking myself.. and you.. if i should better call codesync for all non-moving GCODE, and code for moving code (G0-3, drilling etc...)

UI form side :
After sending the line, i get into my "waitforexec", and i made a modification:
if (!ismoving)
wait 5 loops // i expect this case handle the non-moving gcode : give time to uccnc to do his job
while (ismoving) // if still !ismoving, i just waist few µsec, else i wait for the cnc being Idle
Application.DoEvents();

Thanks for your help.....

Still, i think a plugin example starting a little gcode script like: home axis, go to some place (X10 Y10 for example), go somewhere with relative displacement, some G31 etc... We can always execute that "in the air" by touching the probe with our sticky fingers !

seb

[dezsoe]

nota : I am asking myself.. and you.. if i should better call codesync for all non-moving GCODE, and code for moving code (G0-3, drilling etc...)

One more note: don't bother about moving or non-moving code. Ismoving() was one of the first functions and it's name remained as is, but it could be named like isdoingsomethingyouhavetowaitfor(). So, if you call Code with any command (or even a Callbutton, SetLED, Setfield or anything else that sets something in the main program), the best practice is to wait for it to finish with ismoving(). (With you own fields, LEDs etc. it is not necessary, but with the built-in controls it's the best way by my experience.)

[sebmay]

i read somewhere that there may be a delay between the code or codesync until issmoving is actually raised. Is it true ?

Seb

[dezsoe]

i read somewhere that there may be a delay between the code or codesync until issmoving is actually raised. Is it true ?

I really can't imagine, but we'll have to wait for Balázs to get the exact answer.

[dezsoe]

i read somewhere that there may be a delay between the code or codesync until issmoving is actually raised. Is it true ?

I really can't imagine, but we'll have to wait for Balázs to get the exact answer.

I was thinking wrong and you are right if you call Code. There are two possibilities:

1. If you call Code, the execution comes back to your program and there can be a delay before ismoving() gets true.
2. If you call Codesync, the execution comes back only when the code is compiled and sent to the motion buffer. When something gets into the buffer, the ismoving() will return true.

So, if you want to do the right way then you create a new thread and there you call Codesync and wait for !ismoving(). Do not call Codesync from the UI thread, because it can freeze the whole GUI. And, because you called a new thread, you don't even need to call DoEvents().

[Dan911]

Sounds like a AutoResetEvent or ManualResetEvent may be what your looking for.