G31 Probe problem

[HimyKabibble]

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?

I'm pretty sure I was the one that isolated that problem with Brian and Greg.  I was having LOTs of probing problems back then - it would sometimes probe in the wrong direction, or on the wrong axis, or even on multiple axes at the same time!  And when a G31 failed, the script did NOT get terminated, so if you had a multi-move probing script, and ti failed, and you then re-ran it, the second instantiation would complete, THEN it would finish the first one!  However, since about that release, probing has actually been pretty solid for me.  Back then, I was breaking a probe about every week or two, but I haven't had that happen in almost two years now.

Sadly, Mach3 has a LONG way to go before it can be considered really robust, and hardly a day goes by that I don't get bit by one bug or another.  One of the reasons I'm now bringing up a KFlop on my machine (though it has a different set of issues....).

Regards,
Ray L.

[HimyKabibble]

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

Dave,

Now that you've re-told the sordid tale, some of it does sound familiar.  Seems so long ago....  But I'll still blame you - It's just easier!  :-)

We'll have to get together for breakfast again sometime.  Maybe January?

Regards,
Ray L.

[mhasting2004]

Thanks guys nice to know its not just me or my machine going crazy

I would not have stumbled on the G31 issue except for the fact that we (Dave and I) were debugging a different issue with MSM that cropped up if the probe was active prior to starting a probe routine.

That has since been fixed and as I do all my probing using the MSM interface and have had no issue with it as yet I would have been blissfully unaware of the G31 quirk.

Haven't done any point cloud type probing yet but its on the soon to do list of jobs. Hopefully this quirk won't cause dramas with that.

Cheers
Mark

[stirling]

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 understand what you're saying Dave, but if you're correct and isMoving() really is only a wait for MOVEMENT to stop. Why does this code fragment count? There's no movement here.

Code:

cnt=0
setOEMDRO(800, 1000)
While isMoving()
  cnt=cnt+1
Wend
message cnt

Ian

[BR549]

Art told me long ago that the While Ismoving() would cause the CB to WAIT until any function inside of mach was complete not just motion.



Just a thought, (;-) TP

[DaveCVI]

Ian -
interesting.... When I ran into the M6 vs IsaMoving problem, Brain told me that IsMoving only works for movement.
The counting test case shows that information to be wrong.

So that leaves us with the question of "When does IsMoving work as a sync function and when does it not?".
Alas, I don't have an answer for that question.

Terry -
Well, I've found in multiple cases that what Art said mach will do has gotten changed since the torch passed on.
The M6 vs IsMoving case is a counter example to what you report Art has said - thus we know it doesn't "always" work.
Which takes me back to the question above - for which there does not seem to be a known answer....  

If I had to guess, and it's only a guess, I'd suspect that the problems stem from the parallelization of mach - coupled with mach calling itself recursively (which assumes Mach was written to be rentrant), which I suspect is not part of the source code design.  This would match the observations that Ismoving works much of the time, but does not work, at least for situations where mach effectively calls itself (to call user scripts) - like the M6 example.

Dave

[stirling]

Ian -
interesting.... When I ran into the M6 vs IsaMoving problem, Brain told me that IsMoving only works for movement.
The counting test case shows that information to be wrong.

So that leaves us with the question of "When does IsMoving work as a sync function and when does it not?".
Alas, I don't have an answer for that question.

Dave, I've recently fallen foul myself after quoting people who are supposed to be in the know - so I feel your pain  

But perhaps the answer isn't that illusive. I first used the count approach to test whether isMoving actually did change it's return value after some iteration. I then use the logic - if it does then use it - if it doesn't either there's no point (always returns false) or you're in an infinite loop (always returns true). You can also use the count test to make a "rough" guess at the kind of sleep val is useful without being wasteful. You do of course have to be careful you're waiting on the call you think you're waiting on. Anyway - this approach has proved useful to me but as Terry would say - milage may vary etc.

Ian

[HimyKabibble]

So that leaves us with the question of "When does IsMoving work as a sync function and when does it not?".
Alas, I don't have an answer for that question.

Unfortunately, I think Mach3 has a pretty high "entropy", and each version has its own unique quirks.  You may be able to state positively how a specific version behaves, but you can't necessarily assume ANY other version will behave the same way.  When it gets down to specific behaviors, the first question you have to ask is "What version of Mach3 are you using?", because behaviors change (at times, seemingly randomly) from version to version.  Sometimes the change is intentional (though even these are not necessarily documented), sometimes it's an unintended side-effect of some other change.  But I always dread changing versions, because I know there will ALWAYS be differences from whatever version I was running.

Regards,
Ray L.

[BR549]

I would be perfectly happy IF we just had conditional Gcode. Then it would not really matter to me what CB did or did not do correctly (;-).

That is from the NONprogrammer Gcode ONLY perspective AND not to be confused with the Programmers always do it differently than Gcoders approach (;-).

(;-) TP