I'll give you another example. In plasma cutting the machine may pierce hundreds of time per job. That requires a M3 to fire the torch. MACH is still not reliable to fire the torch 100% of the job. It WILL ignore the M3 from time to time. On a job with several 100 pierces it may miss 3-4 times and fail to fire the torch.

In running Gcode and having macros in the code it ocasionally WILL fail to run a macro IF the machine is loaded up with heavy Gcode and lots of 3-4 axis moves. AND even wait 10 lines of Gcode down the road THEN run the macro(;-) THAT was an exciting thing to watch. Scary actually.

In the early days I ran Mach3 12/7 for over a year to try and PROVE it for commercial use.  We have countless hours testing and retesting and then blind testing. REAL WORLD testing not just sitting in front of the computer watching it similate something at a snails pace.

So am I convinced of what yall  are saying about how dependable macros are running motion code ?  NOT TODAY(;-)

So is Mach3 still a great DEAL, ABSOLUTLY Yes.

(;-) TP

I'm not sure what happens under the hood on Mach3, but I know that if you omit the While IsMoving() statements, the code sort of runs away and goes out of time.  If I understand correctly, you are saying that the wait statements slow it down.  How is that?  All they are doing is simulating what would happen in GCode anyway.  Just making sure that the commands in order and one does not execute before the other.

I know for sure because I've tested it, that this code in a macro....

code "F30"
code "G31 Z-1"
While ismoving
Wend
code "G92 Z-" & offset
While ismoving
Wend
code "G00 Z" & pierceHeight
While ismoving
Wend


and this code in GCode...

F30
G31 Z-1
G92 Z-0.1500
G00 Z0.1250

Yield the same results...Or close enough to the same to not be detectable by eye.  One does not execute any faster than the other, and in 8 years or so, the macro version has been 100% reliable.  Keep in mind that we're talking about torch referencing, not point cloud probing.  A slight timing difference would be perceivable if you were running a program probing a few hundred times vs just a few times per job to reference a torch.

I'm not doubting your results, just curious as if there is a way to speed up probing, I'd like to try it.

RE: The M3 issue.  I had never seen that until the last machine we put together.  The problem was random but frequent.  I replaced the PC with another of identical make and specs and the problem went away.  M30 would also not execute.  No problem with any other M codes though.

As Terry says, I've had times when a "code" has failed. Never did manage to track down why. Just tested one of my fragments from way back in 07 and what failed then now works fine. Can't see anything of note in the change logs though. As a pro software developer of nearly 30 years - I'd say that gave fair cause for doubt. Of course if just because it hasn't happened to you means it doesn't happen at all is your kama then whatever. Bit of a jump though IMHO to say it's exclusively down to bad programming.

Cheers

Ian

It seems it is all in the timeing and how busy mach really is at teh time of the call AND how fast the Computer is CPU wise

I have seen this code work perfectly on one computer BUT on another (same version of mach) it require a sleep(10) in the loop to keep it stable

code "F30"
code "G31 Z-1"
While ismoving
Wend
code "G92 Z-" & offset
While ismoving
Wend
code "G00 Z" & pierceHeight
While ismoving
Wend

DRO and process updates are another issue you have to get the timeing just right or it can either work right, take forever or just blow right by a DRO  or Var update.

Any moreThe only way I will use macros and motion code(other than Simple 1 function moves like ZTOM or simple probe routine like center of circle or Auto G68 of the part to fit the table,etc  is IF I use the Macro to program a parameteric Gcode process or SUB and then run the Function  totally in Gcode mode, such as the Probing arrays. Then you are still limited of what you can do due to the lack of conditional Gcode.

BUT it is what it is AND still usefull but it does have it limitations,

End of Story, (;-) TP

Hi Guys,

Has anyone got the "Contact Brian - Buffer Error" message when running their Macro's yet ?

Tweakie.

NOW back to the original thread (;-)

Please lets us know the results of the G31 testing as used in the TOM routine used for plasma and run from the M3 macro.

(;-) TP

HIYA Tweaks, I have not seen that one(;-)

(;-) TP

get an isMoving in there after that code "F30" in post #23 - that should put the cat amongst the pigeons - sorry

Cheers

Ian

NOW back to the original thread (;-)

Please lets us know the results of the G31 testing as used in the TOM routine used for plasma and run from the M3 macro.

(;-) TP

I don't run the probing code inside the M3 macro.  That code sits in it's own macro.  When that code is finished, the M3 fires, which is in Gcode.

Terry, Terry, Terry..... 

Are you trying holding out a baited hook to see if I'll bite? 

HIYA DAVE,So when I do a Code"G31 X10" and the probe never stops when it hits the switch(led comes on) it is the programmer fault(;-). When I do a Code"G31 X10" and it does not make the move untill 3 OTHER commands have processed and THEN the G31 show up and is processed, THAT is the programmers fault?

I almost forgot my personal favorite. I a probe cycle with the proper wait states so the entire Cycle will work on this computer. Run it on the computer next to it and it fails by  jumping over sections of code. The wait state timing was off.

I'm not going to take that bait.   
You offer up some fragments of your past experiences and ask me if those are "the programmer's fault". I will not attempt to answer that actual question as presented - as it can not be reasonably addressed with only the information provided.

You report that have not had success in making probing work from scripts. Your have experienced what you have experienced. 

My point was that your experience does not prove that probing will always be unreliable if done from a script. 

You are essentially asserting that you have not made it work reliably, therefore it can not be made to work. You  have then stated this as an incontrovertible fact in various posts. I know your motivation is to help Mach users - and I admire that - you do a good job of it.  I am simply noting, that for this particular topic, the assertion made is not true. The assertion that probing from scripts can not be reliable made has been dis-proven by multiple "proof by example" reports - my myself and others, that probing CAN be done reliably from within scripts.

For this specific topic, I felt that readers deserved to know that there are others with different results who do not draw the same conclusion re "impossibility".

Yea I know semaphores. Dang Dave this is 2011 the Control program has to do something on its own like keeping track of its threads. (;-)

(;-)

I don't think I made any comments about what I would ***like*** to see mach include for programming support.  I have a long list of those.... pragmatically mach, is what it is at any point in time. 

I have 5 years worth of error and crash data that says otherwise. I have probably over a million (literally) probe cycles in gcode without failure.Can't say the same thing about the macro side.

OK, you have 5 years of problems with scripts and probing.
You have no problems when using G-Code.

That is your experience - it does not prove that probing is ***always unreliable*** if done from a script.

OK, now then I will shift a bit here and say this:

I tried very hard to start my post by saying that I was NOT trying to start a flame war. I meant that.
Yet as I write this post I am seeing other responses, some of which are asserting that I said things I did not actually write in my post. That is how flame wars start and grow - I have no interest in participating in the way the thread seems headed, nor do I want to be fanning the flames.

All I tried to do was
1) point out that not everyone has the same successful / unsuccessful experience when doing probing from scripts.
2) ask that those stating something as a fact to please consider not stating personal experiences as a proven fact.

There is no need for us all to create a raging argument - there is no personal challenge involved in this topic - and I certainly didn't intend anyone feel challenged by what I wrote.

Different people have had, and will continue to have, different experiences, with different aspects of Mach's features.

Dave