Hello Guest it is March 29, 2024, 11:21:58 AM

Author Topic: G31 Probe problem  (Read 59126 times)

0 Members and 1 Guest are viewing this topic.

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: G31 Probe problem
« Reply #80 on: August 05, 2011, 12:17:24 PM »
HIYA Ian, I had thought about that OR more likely "slaved axis" especialy with a plasma table(;-) they use Slaved axis for the gantry.

(;-) TP
Re: G31 Probe problem
« Reply #81 on: December 05, 2011, 03:53:17 AM »
Got a weird one for all you experts...

For referance I'm using a Smoothstepper.

Stumbled on this when I had a probe failure (ie probe was stuck on) and while testing found another "feature"

Here is the scenario:

Probe is already active and you issue either a G90 or G91 G31 X10 to which the machine will not move as the probe is already active and will display a warning message.

Fix probe so that it is now inactive and resend same command G91 G31 X10 and again nothing happens but no warning message... however with no other imput approximately 2 minutes latter the machine executes what appears to be a RefAll and then the original G31 move.

Want one step stranger.. issue the G91 G31 X10 command twice after the initiall fault and fixed probe and after 2 minutse it does the RefAll and return to G31 command twice!

Have I stumbled onto a Mach blackhole? Very strange... anybody else able to duplicate this "feature" ? BTW play safe and make sure that it can do the moves without crashing.

Bemused

Offline rcaffin

*
  •  1,052 1,052
    • View Profile
Re: G31 Probe problem
« Reply #82 on: December 06, 2011, 05:34:54 AM »
When CB does (for example) a setOEMDRO, CB is not setting anything, it's REQUESTING Mach to set the DRO.

More generally, the client thread (CB) REQUESTS that the SERVER thread (Mach) do something. That request sits in a buffer until the SERVING thread (Mach) has time to action it.

IF the client thread in no way depends on that request being actioned then it can just carry on. HOWEVER - If the client thread depends on that REQUEST being actioned before it can successfully continue according to the logic of the program, it MUST wait for the server thread to let it know it's done it.

There is however a second circumstance when the client thread needs to wait on Mach signaling it's completed the request. In some multi-threading apps, it's appropriate that the buffer used is a FIFO queue. This means that several requests can be sent to the SERVER. However, AFAIK, the buffer used in the Mach/CB context is a single - one-shot buffer. This means that if we want to send multiple sequential requests we MUST wait until each one has been completed before we send the next request and so on.

The mechanism that performs all this is that Mach sets a semaphore when it's completed the request and CB can monitor that semaphore until it see's it set - that's what isMoving does. Shame it's called isMoving because it has nothing to do with movement. A better name would perhaps have been MachIsBusyDoingOurRequest. As in...

while MachIsBusyDoingOurRequest() 'or perhaps something shorter maybe!!!
wend

Now that (bolded) is something REALLY worth knowing! Thank you.

Cheers

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: G31 Probe problem
« Reply #83 on: December 06, 2011, 06:52:46 AM »
Just and update to what I said about FIFO and one-shot. I'm not sure but I think this has changed at some time. I THINK you can now send multiple CODE statements without an isMoving() after each one. I THINK you can now get away with a series of CODE statements with just one while isMoving() after the last one. i.e. I THINK Mach buffers the CODE requests in order. Is it reliable? - your guess is as good as mine - which version do I think it changed in? - I don't know. I still stick an isMoving() after each one - but that's just me.

Ian

Offline Tweakie.CNC

*
  • *
  •  9,196 9,196
  • Super Kitty
    • View Profile
Re: G31 Probe problem
« Reply #84 on: December 06, 2011, 07:12:53 AM »
Quote
I still stick an isMoving() after each one - but that's just me.

Me too  ;)   (I learned the hard way).

Tweakie.
PEACE
Re: G31 Probe problem
« Reply #85 on: December 06, 2011, 04:08:48 PM »
Just and update to what I said about FIFO and one-shot. I'm not sure but I think this has changed at some time. I THINK you can now send multiple CODE statements without an isMoving() after each one. I THINK you can now get away with a series of CODE statements with just one while isMoving() after the last one. i.e. I THINK Mach buffers the CODE requests in order. Is it reliable? - your guess is as good as mine - which version do I think it changed in? - I don't know. I still stick an isMoving() after each one - but that's just me.

Ian

Ian,

That is correct.  That change was made perhaps two years ago, back around v30-something.  It was done at the request of David Bagby, to make MachStdScreen work better.  AFAIK, it does work reliably.

Regards,
Ray L.
Regards,
Ray L.
Re: G31 Probe problem
« Reply #86 on: December 06, 2011, 06:31:58 PM »
Hi Ray -
Oh NO you don't - I won't let you blame me for that one!  >:(
(well I guess you could, but I was not the instigator and am not responsible).

The history as I know it:

In days of yore (the era of Art), mach was essentially single threaded code internally. In those days all calls to the "code" API were synchronous - there was no other choice - that was how the APIs worked (whether by design or by accident).

One of the things Brian did (so he has told me) was to change a bunch of mach internals to be mutli threaded... 
AFAIK that was where the problems with the Code call began. Suddenly the Code started returning before the code string was executed - the multi-threading changes changed the semantics for existing scripts. Instant lack of backward compatibility was the result.

What I think should have happened was that Brian should have implemented the existing code call to be sync and added a new "QueueCodeAndReturnBeforeDone" call. That would have preserved the semantics of existing scripts. For whatever reasons,  Brian choose not to take that approach.

To complicate things further, after the multi threading change, there were some attempts to restore the old semantics. Some mach versions that had sync code calls and some did not - and it swapped back and forth a few times. Add to that the fact that back then there was no call to get the mach version... so you could not even check for what the semantics were on the version you found yourself running on...

All I did back then as ask for the addition of a call to get the mach version. I figured if I could get the version, at least I could code for version dependencies. (Alas, that bit of idealism on my part depends on having a good record of what changes are in each version - something that, in IMHO, is not Brian's strong suit).

After the uproar the multi threading changes caused quieted down, people started using "IsMoving" as the only sync tool available. "When the only tool you own is a hammer, all problems look like nails...." 

That led to another set of changes... when people put the IsMoving in a hard loop the CPU got starved out - so we had to add sleep statements. Then Brain forced a sleep equiv internal to IsMoving... but again you could not tell when you need to use and when you do not - so people put it in and on many mach versions I suspect the scripts end up wasting time in "extra" sleeps.

Now, then, I regurgitate all this in order to set the stage for this statement:

IsMoving really is a IsMoving wait.
It is NOT a general sync method to cause a pause until mach finishes the action you requested via a CB API.

Since the advent of the multi threading change, there is NO GENERAL WAY TO CALL MACH AND RELIABLY WAIT until the API call is complete.

I too used accept the Mach urban lore that IsMoving was was a misnamed sync call, and that it was an API sync mechanism.
It seems to do no harm if used for an API that does not cause movement, as in that case there is no movement in process and so the IsMoving call just returns false and your wait loop exits quickly. 

Here is how I learned that it really, truely, is only a wait for movement to stop.
I got into trouble when I tried to do this sequence:

Code("m6")
While IsMoving()
    Sleep 100
wend

If ISMoving really were a sync mechanism for the Code call, the script would hang in the IsMoving loop until the M6 competes.
That is NOT what happens.

M6 is particularly nasty example - from the gcode language standpoint, a single command was called for and you do not want to go on until the M6 is over, finished and done with.

Looping on IsMoving will not accomplish that desire! You will only pause until the "current motion" is complete.
Think about how mach implements M6 as a series of calls to user scripts and the problems become more apparent. In the case of M6, there is NOT a 1:1 mapping between gcode word execution and movement. The IsMoving loop technique effectively only works when there is a 1:1 mapping between gcode word execution and movement.

Alas, not even then does it always work... The problem is that an IsMoving loop depends on a motion having been started before the code call returns to the calling script - and due to multi threaded driven timing holes inside mach that may not always happen. Most of the time it does, but not all the time.

IHMO the sad fact is that this is an area where mach is fundamentally broken and there are no tools available to the script programmer to handle this reliably. Mach's script APIs (and Mach itself) has no concept of critical resources, locks, semaphores etc.

Frankly, I think it's pure dumb luck that mach scripts work as well as they do considering the multi-threading stuff and total lack of resource locking.

Dave

Just and update to what I said about FIFO and one-shot. I'm not sure but I think this has changed at some time. I THINK you can now send multiple CODE statements without an isMoving() after each one. I THINK you can now get away with a series of CODE statements with just one while isMoving() after the last one. i.e. I THINK Mach buffers the CODE requests in order. Is it reliable? - your guess is as good as mine - which version do I think it changed in? - I don't know. I still stick an isMoving() after each one - but that's just me.

Ian

Ian,

That is correct.  That change was made perhaps two years ago, back around v30-something.  It was done at the request of David Bagby, to make MachStdScreen work better.  AFAIK, it does work reliably.

Regards,
Ray L.
Author of the MachStdMill Extensions for Mach3
www.CalypsoVentures.com

Offline rcaffin

*
  •  1,052 1,052
    • View Profile
Re: G31 Probe problem
« Reply #87 on: December 06, 2011, 07:16:19 PM »
In days of yore (the era of Art), mach was essentially single threaded code internally. In those days all calls to the "code" API were synchronous - there was no other choice - that was how the APIs worked (whether by design or by accident).

One of the things Brian did (so he has told me) was to change a bunch of mach internals to be mutli threaded... 
AFAIK that was where the problems with the Code call began. Suddenly the Code started returning before the code string was executed - the multi-threading changes changed the semantics for existing scripts. Instant lack of backward compatibility was the result.
Oh dear. Multi-threading without serious internal sync? OH DEAR!

Yes, been there and seen the results before, in an IA-guided robotics project I was leading. The (fresh young) programmer management brought in for political reasons had this idea that multi--threading meant that the SW would execute more quickly, with all the threads running really simultaneously. Apparently he had not been taught that all multi-threading does is to time-slice the CPU, which actually slows the SW down.

But his version of our single-thread SW never ran successfully. One thread would die and post an error message, but the error message was usually covered up by another window. Debugging the system was impossible! So we kept running my non-politically-correct version. (Sigh - that was a long time ago ...)

I am willing to believe that Mach could use a couple of threads: the main data-generation process, the data-transmission process, and possibly the UI process. Actually, I think it would be kinda neat if Mach was simply dual-threaded, with data-generation on one core and data transmission on a second core. Plenty of dual-core systems available today very cheaply.

That would require a dual-core system of course, which some might say is a commercially non-viable requirement. But I think not so really, if Mach3 was kept for casual hobbyists on zero budget, while Mach4 was aimed at serious users for whom reliability is paramount. After all, if a dual-core system can be bought for <$700 today, and the CNC hardware costs >$7k ...

My 2c.

Cheers
Re: G31 Probe problem
« Reply #88 on: December 06, 2011, 08:57:02 PM »
Speaking of multi threading... which is possibly what I'm doing posting my bug report here is doing although suspect it is related...

Further testing exhibits the following:


Scenario 1
probe active
machine axis not referenced
issue : f1000 g31 x10
displays a probe ignored warning
delay then displays safe Z height warning
no movement
Scenario 2
probe active
machine referanced
issue g31 x10
displays a probe ignore warning
delay ~ 2.5 minutes
display safe z warning
move all axis one at a time as if in a RefAll
rinse and repeat last 4 lines
It continues to do a RefAll type movement every 2 odd minutes as if in a loop with no external inputs?????? I can hear it do its dance as I write this post

If while it is doing this infernal loop you remove the probe input Mach will (after finishing its loop into fairy land) move to its inital position prior to the G31 error and RefAll move. I have been using .037 and just updated to .053 but going back thru the change log this one caught my eye....

March 17/2009 Release 3.042.023 -- Threading bug found and fixed in Driver... -- Probe error know kills script and file execution

Is it possible that this was not fixed or has crept back int later versions?
Re: G31 Probe problem
« Reply #89 on: December 06, 2011, 09:47:05 PM »
Mark,
I'm pretty sure this is a Mach bug. I just reproduced the same symptom on a PP system.

Test sequence to demo bug:
(Feed and distance #’s are in imperial units).
1) Start machine
2) ref all home
3) zero X, Y & Z   (WC now = MC)
4) MDI: G90 G54 x.5 y-.5 z-.5    (we will call this location P1)
5) taped probe shaft over so is permanently triggered
6) MDI: F40
7) MDI: G91 G31 X1
8 ) Mach shows error about probe already being triggered on the status line. This is correct, but mach seem to then fail to abort the G31 and instead this motion sequence starts:
9) At a feed rate of about f=0.4 (as shown on run screen for actual F rate) all three axes start toward 0,0,0
10) at around 0.2, -0.2, -0.2 the F drops to about 0.0001"/sec (this is where all the time goes.....)
11) Several minutes later, it seems to give up on this slow feed rate and then at the normal home reference motion rate it does the ref all action (X then Y then X) and goes to the home position.
12) then at the 0.4 F rate it starts moving back toward P1
13) when P1 is reached, it loops back to step 9) and this seems to go on forever.

14) hit esc key to kill motion.

Verified on Mach 3.43.37

Dave

Author of the MachStdMill Extensions for Mach3
www.CalypsoVentures.com