Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Dave3891 on July 28, 2011, 05:10:12 PM
-
I have a plasma table with a floating head. I have it set to go a G31 probe with a feed rate of 60 ipm.
The problem is that the motion is ignoring the accel / decel rates that is set it motor turning.
This causes the stop point to overshoot the sensor by almost 1 inch...
Any ideas?
Thanks
Dave
-
Are you sure it is not following the axis parameters?
Probing at 60 imp is quiet a feat to pull off as what you have found there can be a lot of overtravel due to the deacell rate.
What are your settings for accel in the axis config.
Try slowing down the probing to about 10 imp and see what the difference is.
IF it is still 1 inch then I think your probe is not setup correctly in pins/ports and the machine is not seeing the input from the probe. It is just stopping on the end of move parameter in the G31 call. G31 Z-1 means probe until you get a trip OR reach the end of move(Z-1)
Just a thought, (;-)TP
-
I have accel set to 15.
It stops fast when I am using rapid.
With a slower probe feed it does not over shoot as much, but then I am waiting longer for each cut.
The probe trip is working fine. I have a M3 macro that reads the trip point DRO and uses that to zero the Z dro and then move up to the cut height.
The overshoot will sometimes hit the limit switch on thin plates... So I was looking for a solution.
-
Accel and decell are only really a factor on commanded moves because the Mach knows where it is stopping and plan the deceleration to that point. When you probe, Mach has no idea when the probe will trigger. When it triggers, Mach says stop, but it never stops exactly on the mark. That's the same reason the THC commands overshoot. The faster the THC feed rate the more overshoot you have. The solution to both is to turn down the feedrate. I probe at 30IPM with is a acceptable compromise between overshoot and speed. The slower you make the feedrate, the closer you'll come to stopping on the mark.
-
HUM, Probing inside a Macro is always interesting(;-) you never quiet know what you will get.
Try moving it back to the Gcode side where things behave and happen at the speed of light.
I use the G31 here for the same thing you do BUT it is instant responce from the Gcode side.
You cannot compare teh G31 to the THC function they are totally different in the move aspect. The G31 will ALWAYS use the Deaccell curve to stop
The THC does NOT use any Accell/deaccell in its moves. It depends on the Arcvoltage PID to tell it to stop/go
Just a thought, (;-)TP
-
The G31 will ALWAYS use the Deaccell curve to stop
My point was that unless Mach knows where it is stopping, it can not decel to that point, thus when the probe is triggered, Mach stops, but because it has to decelerate, it never stops on the mark. Slowing the feed rate gets it closer to the mark. The OP wanted to stop on a dime at 60IPM, and that's not going to happen, regardless of where the code is.
The behavior is similar to the THC commands in that the slower you make the THC feed rate the less overshoot...or bounce, you get.
-
I understand that it will not stop on a dime. But over 1" of overshoot seems quite excessive.
When I job the Z at 150 ipm and let go of the jog button, it stops near instant.
I don't see why the G31 can not use this same deaccel rate.
-
IT DOES use the same rate. That is why I mentioned running the G31 from inside a macro it is not always the same as running it from the Gcode side.
I have a box full of broken probe tips and 1 broken probe from running the G31 from macros. NEVER have I broken one from using G31 on the Gcode side.
Try your move from the MDI line and see IF it stops as it should. From the Gcode side it will always obey the acel/deacel parameters of the called axis's.
Do a simple axis move at your probing rate of 60 see how far it takes to stop.
Then make the same axis move with a g31 and trip the switch THEN see how far it takes to stop from the same speed.
(;-) TP
-
I will give that a try on monday and make a video if the problem still happens.
Would using G28.1 in a macro work better then G31?
-
probing does not NEED to "stop on the mark". When it trips, as long as it decels to a stop BEFORE it reaches the mechanical end of travel of the probe, then all is well and perfectly accurate because it is the trip point that is stored NOT the stop point. As Terry has said, G31 and I suspect G28.1 do not fair well (at least consistantly) in macros.
Ian
-
Hi Guys,
I have seen this "mach urban legend" expounded that probing does not work reliably in macros (scripts) several times.
This time, on this morning, I choose to offer an alternate viewpoint... :D
Let me start with, I am absolutely, NOT, I repeat not, trying to start a flame war of any type.
I speak up now only because dis-information (even when made from the best of intentions), particularly from community members who I respect, concerns me a tad. For context, I've had some conversations where confused, non-expert mach users have asked me about this urban legend.
IMHO, telling people that probing can not be reliable when done from a script is a disservice to the readers of the posts. The (incorrectly IMHO) repetition of this assertion does not help users - it just makes them think that a rather significant part of mach (the entire macro scripting facility) is unreliable.
Why do I have this differing opinion?
To date, I have direct experience with a pretty good size user base that does probing operations, with mach, via scripts, day in and day out, and they have been doing this for between 1 and 2 years now.
Since I developed and market mach enhancement software, the experience has given me some reasonably broad experience from which to form my opinion. I don't have a way to know how many probing operations each user does; So I have no idea how many individual probing operations that all adds up to - but I am pretty sure that it is not a trivially small number.
During the 2 year experience since I started the software project, not one single time have I been able to identify a problem that could even remotely be attributed to the way a G31 command was submitted to mach - be it either via Code("G31") from within a script, or as a G31 block in a G-code file.
Yes, my probing software has had some (usually minor) bugs in it during the last two years, and they were always script logic bugs. At no time, has there ever been an issue, where there was as G31 command that did not work just because it was "from inside" a script.
In fact, (as I'm pretty sure you guys know) in a script, the way that a G31 operation is invoked is by issuing a G31 command - as g-code - via the Code() call. Internal to mach, the script Code() calls and the Gcode interperter both get the G31 command inserted in the code queue. The processing is identical (or so Brian tells me ) from that point on.
The reality is that a script author can write good scripts, and they can write bad scripts. Script quality is not an inherent "a script was used" issue - it's a script author skill level issue.
Are really good scripts easy/trivial to write? Not really, the difficulty level will depend on the programming skills of the author and also on their knowledge of how mach and the target machine operate.
I've looked at a lot of mach scripts in the last 2 years - and the code quality, and the reliability of the script actions varies a lot (!). Again, that's not evidence that scripts are inherently unreliable (it is evidence that the programming skill level of script authors varies).
I know you guys are both pretty good at understanding mach itself. I take at face value that you may have had problems with scripts you have written. And the details of G31 actions can be tricky.
Where I differ is with the implication that probing is not, and can not never be, reliable when used from a script.
Perhaps it would be more accurate to say that "writing complex, professional quality scripts for Mach can be difficult".
OK, I hereby turn off this mini-rant.
(sorry, it was not meant to be a rant, but I fear it could read that way) ;)
Dave
-
To date, I have direct experience with a pretty good size user base that does probing operations, with mach, via scripts, day in and day out, and they have been doing this for between 1 and 2 years now.
I agree...I've been probing inside macros for years. I don't find that it stops any faster if the same code is placed in GCode. I probe at 30IPM and typically see about 1/8" of over travel. Also running fairly high acceleration on the Z, so maybe that's why.
-
rrc1962 and DaveCVI, could you post your probe script?
-
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.
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 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.
BUT I am allways open to learn a new trick and I would be MORE than happy for you to show us the PROPER way to do the macro Probing so it NEVER fails.
NOW I will leave my soapbox,
(;-)TP
-
rrc1962 and DaveCVI, could you post your probe script?
code "F30"
code "G31 Z-1"
While ismoving
Wend
code "G92 Z-" & offset
While ismoving
Wend
code "G00 Z" & pierceHeight
While ismoving
Wend
One thing I've noticed is that G31 does not use the acceleration setting for the Z axis. It uses either the X or Y acceleration settings, even if you are probing the Z. If you have a very low acceleration setting on the X and Y and something higher on the Z, don't be surprised to see actual acceleration on Z probe not match your Z acceleration settings.
-
I have a few hundred people using my screenset with auto zero macros using G31, and a probing wizard that uses G31's, and have not had a single reported incident with probing. All are called from macro's.
Three are a huge number of router guys using G31 in autozero macro's, and I don't see any mention of failures there, which would most certainly result in broken tools and pissed off users.
Terry, are your errors repeatable at all, or totally random? If it happens as often as it sounds like, how about sharing some code that fails for you?
-
Gerry all that testing has come and gone and all the results was shared. Also I have talked to several BIG OEMs and they share the same sentiment about using the macros for motion control code. I have looked at MANY examples of everyones macro probing code and it is about all the same as to function Even Dave's(;-) There are only so many ways it can be done.
Not to mention that even Brian and Art have stated there are timig issues with VB and Mach3 and the way CB works with threading(;-)
So take what I had to say and use it for what it is worth(;-).
(;-) TP
-
OK lets expand this a bit to investigate it a little further(;-)
Do you find anywhere a 3d probing function that works all the time and does not run in Gcode? Not even Arts plugin will do that.
When Stirling developed his Crawler surface/profile routine could he do it in macro CB and have it work dependably ?
WhenI worked with the probing arrays I first tried the MACRO version, Nope it could not be done reliably in CB. I had to move to using Gcode Subroutines and stay in Gcode. AND without conditonal support that had to be done the LONG/HARD way. Now the arrays can run for millions of probe cycles without fail or error. The macro versions could not run 60 secs without getting lost.
NOW IF you work with macros and CAN load them up with wait states and while do loops and semaphores to help control the threads THEN it can be reliable BUT the motion will be as slow as a SNAIL on a winter day. GO stop wait
It is one thing to do a simple find the center of a circle or edge of material or tool offset. no big deal if that takes 1 minute to run reliably. but you cannot have motion code that pokes along at a snails pace or runs Run Stop Wait. you will never get anything done.
For an example of how it is suppose to work take a look at CUBLOCS PLC control. It integrates ladder logic with Basic language in a way that they stay in perfect time and thread sync. THAT is how we need Mach3 to work MACRO wise.
Just a thought, (;-) TP
-
Then we're talking about different things.
You're creating a point cloud, and I'm probing single points (maybe up to 4).
-
Gerry I am talking repeating a motion command from a MACRO repeatedly and reliably. Point clouds have nothing to do with the problem.
(;-)TP
-
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 ;D ;D ;D
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? :o
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. ;D
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
-
HIya DAVE Read again I said from all my experience and testing in the real world. I also said that it can be FAIRLY realiable IF you load up the Macro code with enough controls but very rarely is THAT method useful as it slows it to a crawl in the real world.
DOn't THINK I am the only one to see this as a problem I can assure you I'm not.
Bait you up ??? NAW, but I am looking forward to you showing US the proper programming to get it right(;-) You were going to do that correct?
Now that is a proper baiting if I ever did one(;-).
No flaming intended or perceived here, Just an open discussion, you are the Gameboy I am just the old chip slinger.
(;-) TP
-
HIYA DAVE, I do have a question(;-)
"2) ask that those stating something as a fact to please consider not stating personal experiences as a proven fact. "
IF you do NOT use pesonal experience to "TEST" and "PROVE" an event FIRST HAND under controlled conditions how does one learn to seperate fact from urban legend ?
(;-) TP
-
get an isMoving in there after that code "F30" in post #23 - that should put the cat amongst the pigeons - sorry ;D ;D ;D
Cheers
Ian
That hasn't been a problem, but I can see how it could blow past the feedrate update without a IsMoving(). I'll add that. Thanks for pointing that out.
-
NOw Don' take what I said WRONG as the Mach CB function is a VERY powerful tool I have macros that write a complete ready to run Gcode file that is over 900,000 lines long based on input parameters from the operator AND it only takes about 5secs to do so AND then loads that Gcode program into MACH and is ready wating for the OP to press the start button.
(;-) And if we had conditional Gcode we would not be having this conversation as I would never need to USE a macro to do anything seroius with motion code.
But I have learn over the years and with PRIOR experiences to NOT trust CB with Motion code.
Your Mileage May vary based on actual conditions at time of use, (;-) TP
-
This sounds kind of like my problem
http://www.machsupport.com/forum/index.php?topic=2965.0
"Here is the real problem ,if I Ref'd Z 0.0 say 1" to 8 " off of the plate the Z Axis starts to move down trying to find the switch or 8 " and it does ,then once the switch closes the Z Axis takes forever to come to a stop(say about 1") ,"
-
HIYA DAVE, Could you post your version of the macro used? Maybe we can find something to help your situation.
(;-) TP
-
I will not be able to post it untill monday. But I will also post a video of what the machine is doing.
Thanks
Dave
-
This sounds kind of like my problem
http://www.machsupport.com/forum/index.php?topic=2965.0
"Here is the real problem ,if I Ref'd Z 0.0 say 1" to 8 " off of the plate the Z Axis starts to move down trying to find the switch or 8 " and it does ,then once the switch closes the Z Axis takes forever to come to a stop(say about 1") ,"
What's your X and Y acceleration set at? G31 uses that, not the axis that the G31 is using. If you have a slow accel and a high probe feedrate, it WILL take forever to stop.
-
HIYA DAVE, That is not a problem. Get it when you can so we can maybe help you get this thing to work properly. Plasma cutting is a really FUN process to create metal art and such.
It does not matter who may be right or wrong or not as long as we get you cutting like it should.
(;-) TP
-
What's your X and Y acceleration set at? G31 uses that, not the axis that the G31 is using. If you have a slow accel and a high probe feedrate, it WILL take forever to stop.
If that's the case, it's a serious bug that needs to be reported to Brian.
-
What's your X and Y acceleration set at? G31 uses that, not the axis that the G31 is using. If you have a slow accel and a high probe feedrate, it WILL take forever to stop.
If that's the case, it's a serious bug that needs to be reported to Brian.
I'm reminded of it every time I reset acceleration so X and y are significantly lower than Z. Perhaps someone who is doing G31 probing can verify. Just reset the X and Y acceleration to something very slow...like 5 or less,and set the Z at 30 or 40. Run a G31, then bump the X and Y back up and see if the G31 accel increases.
I mentioned it back in 2009 in this thread....
http://www.machsupport.com/forum/index.php/topic,13364.0.html
-
Hi rrc1962 - Just tried this on my R3.042.020 and G31 uses the correct axis accel setting. Is this a version issue maybe?
Ian
-
I'm on 3.043.022. I'll test some more but I noticed it again yesterday when I slowed the X and Y way down.
-
I tested again today. I set all accels at 50 and did a G31 Z-1. Motion was as expected for an accel setting of 50. I then reset the X and Y accel to 5 and did the same G31 Z-1. Accel was very slow on the G31. I reset X and Y back to 50 and the G31 returned to normal. Seems like it's definitely using the accel setting from another axis. I normally run all accel settings fairly close to each other and fairly high, so this is not an everyday issue.
-
Just loaded 3.043.022 and tried it and accel follows the correct axis just fine for me.
Ian
EDIT: Now back to 3.042.020 - can't be doing with that slower screenset loading...
-
ok, my script is as follows
PierceHeight = GetUserDRO(1000)
CutHeight = GetUserDRO(1001)
PierceTime = GetUserDRO(1002)
If GetOEMLed(825) = 0 Then
Code "G31 Z-4 F30"
While IsMoving()
Wend
CurrentZ = getDRO(2)
ProbeTrip = GetVar(2002)
SetDro(2,-((ProbeTrip - CurrentZ) + 0.15))
Code "G0 Z" & PierceHeight
While IsMoving()
Wend
DoSpinCW()
While Not isActive(Input1)
Wend
Code "G4 P" &PierceTime 'Pierce Delay
Code "G0 Z" & GetUserDRO(1001)
While IsMoving()
Wend
Else
Code "(Torch is On Surface Hit STOP and Fix)"
End If
Here is the video
http://www.youtube.com/watch?v=2CPgk_kCH20 (http://www.youtube.com/watch?v=2CPgk_kCH20)
It does the same thing if I just issue a G31 command by itself
Thank
Dave
-
Not sure if this is your particular problem or not but whenever you SET a DRO via CB and then do something that depends on the value of that DRO you MUST do a check via isMoving() that Mach HAS actually finished updating the DRO before you continue your script.
Ian
-
What are the motor settings accell/vel and what is the turns per inch on your feedscrew for the Z?
It looks and sounds like you are combatting inertial overrun and having to run slow accel rates to avoid loosing steps. Common with useing High speed stepper values to make axis speed.
As Stirling noted The Macro needs a few more checks / wait points in order to insure it stays in sync. NOTE:Some machines require it some get away with out it. It all depends.
AS a reference(;-)
In the Gcode side all that is replaced with
G31 Z-5 F20
G92 Z0
G0Z.080
G92 Z0
G0Z.100
M3
G4 P1
And is only run after the machine has moved a predeteremend amount of travel. Not at every piercing.
To do what you do it would look similar to this and there is NO CB involved in the motion code. The macropump will keep the #vars up to date with your DRO entries.
G31 Z-5 F20
G92 Z0
G0Z#500
G92 Z0
G0 Z#501
M3
G4 P#502
-
On a side note(;-) This brings up one of the reasons that many choose to use the G28.1 method to find the TOM (top of material). The G28.1 cycle stops on contact THEN backs up to reset the switch. This takes out the overun, loss motion, switch travel and material flex variables. When the cycle stops you are at the TOM all that is needed is to Set Z, move to pierce hieght and go.
The G28.1 speed is also presettable in config as a percentage of Rapid.
What you do loose with it is the ability to use the G68 to do coord rotation as the G28.1 will NOT run in coord space. AND it does NOT error out, it just hops over it and continues the Gcode (that needs fixin to allow Z to home in G68)
Just a thought, (;-) TP
-
My accel setting it 15 and the screw is 12 TPI. The motor is a 287 ozIn with a G540 and 48 volt PSU.
The rapid jog stops almost instant, and it is set to 150 IMP
-
OK what are the acell values for the X and Y (;-) just in case.
Try this as a test. lift the head up to the top. Reset Zero Then do a fast Down and stop with G1
G1 X-3 F150 (Do not let it hit the table)
See IF the slowdown at the end is quick
Next do the same with a G31 Z-3 F150 (do not trip the switch)
See if the slowdown at the end is the same as the G1.
Next do the G31 again only this time trip the switch on the way down and look at the deacell rate.
Next try it with G0 Z-3.
Somehwere inside the testing should be the answer hopefully.
(;-)TP
-
If you listen to the vid carefully you can HEAR the difference in the G31 and the G0(;-)
If you would like to try the G28.1 in the macro let us know and we can help you if you need it.
(;-) TP
-
Could you post a quick tutorial on setting up 28.1?
I tried a little last week and I could see it tripping the home led, but it would not stop at the point so I had something set wrong...
Thanks
Dave
-
Set up the switch as the Z home in Config/ Ports_pins/inputs. Test it by tripping the switch and looking on the diag page to see IF the Zhome led comes on.
You will need to set up Zhome in Config Homing to setup the correct Zhome direction AND speed. The speed is based on a % of rapid of the Z. MAKE sure there is no offset value for Z home and make sure that the AUTO Zero is checked on.
Check to make sure the function work testing them in the air first as you go. Making sure that the Zhome is going in the right direction(;-)That way there should NOT be any surprises when you start/test the routine.
The motion is as follows. The G28.1 will go to the midpoint as defined by the Call G28.1 Z.500 this is normally a safe position in plasma. Next it will start the home routine and move to the Zhome switch. When it trips it comes to a controlled stop then reverses UNTIL the switch resets(makes contact). Then the Z dro is reset to ZERO ( or the correction value). Next the Z rapids UP to the pierce height and fires the torch. Then the pierce dwell takes place and the torch lowers to cut height and away you go.
IF the switch stays tripped after the routine then then your else statement will take you to the end and post the message to the error bar
NOTE: I would test it first from the CB CODE editor stepping 1 line at a time (F7) to ensure it does what is needed and does work(;-)
This macro should be very close to the same function as your G31 setup. You will notice that the Z will FIRST go to Z.500 on its way to home that is a safety of sorts that we use. the idea is that the Z.500 should be a safe point to start the routine above the Material. IF the torch is below that point it raises first if above it lowers to that point first. You can use it OR not your choice.
PierceHeight = GetUserDRO(1000)
CutHeight = GetUserDRO(1001)
PierceTime = GetUserDRO(1002)
If GetOEMLed(836) = 0 Then ' Checks the Home LED if active then goto else
Code "G28.1 Z.500" ' Set up the Zhome for the correct direction and speed
While IsMoving()
Wend
Code"G92 Z0.000" ' Set the Z value +/- to insure the pierce height comes out correct
' The correct value depends on the lost motion of the switch assy
Code"G0 Z" &PierceHeight
While IsMoving()
Wend
DoSpinCW()
While Not isActive(Input1)
Wend
Code "G4 P" &PierceTime 'Pierce Delay
Code "G0 Z" & GetUserDRO(1001)
While IsMoving()
Wend
Else
Code "(Torch is On Surface Hit STOP and Fix)"
End If
Hope that helps, (;-) TP
-
Haven't looked at the logic of the code BUT without the indicated "isMovings" the code will be completely un-predictable.
PierceHeight = GetUserDRO(1000)
CutHeight = GetUserDRO(1001)
PierceTime = GetUserDRO(1002)
If GetOEMLed(836) = 0 Then ' Checks the Home LED if active then goto else
Code "G28.1 Z.500" ' Set up the Zhome for the correct direction and speed
While IsMoving()
Wend
Code"G92 Z0.000" ' Set the Z value +/- to insure the pierce height comes out correct
****************** WHILE ISMOVING WEND **************************
' The correct value depends on the lost motion of the switch assy
Code"G0 Z" &PierceHeight
While IsMoving()
Wend
DoSpinCW()
While Not isActive(Input1)
Wend
Code "G4 P" &PierceTime 'Pierce Delay
****************** WHILE ISMOVING WEND **************************
Code "G0 Z" & GetUserDRO(1001)
While IsMoving()
Wend
Else
Code "(Torch is On Surface Hit STOP and Fix)"
End If
-
Hi Guys,
Mind if I add my 2 cents.
I don't know why we do it but we always seem to keep our broken probe tips, perhaps it is to teach us a lesson or so we don't forget. ;D
Anyway, i can't remember which Mach revision started it all but since then every Macro / Script needs a "while.....wend" between every write and every check to keep the CE speed in line with Mach execution. As Ian has said, without it the code will be unpredictable (work just fine on one machine but not on another and even then you can't count on it).
I have a sneaky suspicion that when we all eventually agree on this - Version 4 will come along and change everything. ;D
Tweakie.
-
Hiya tweaky,I treat that problem just like I do the depreciated calls in CB they have been going to go away for about 5 years now(;-) but they are still here and going strong (;-).
Yes I agree perhaps we need a few more wait states. BUT the more you add the slower the routine can get. So I try to balance speed and reliability.
Sometimes you even have to add a sleep() here and there.
(;-) TP
-
There really is no big mystery to this - it's standard inter-thread communication - as practiced in a gazillion systems from enterprise data bases to games. There is no need to "sprinkle" waits here and there, just put them where they're needed and not where they arn't. This isn't alchemy. ;D
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
So, using the above code as an example...
Code"G92 Z0.000" ' Set the Z value +/- to insure the pierce height comes out correct
Code"G0 Z" &PierceHeight
Two things MAY happen here. One is that the G0 request actually corrupts the G92 request. The other is that the G0 request may happen BEFORE the G92 request. It's perhaps unlikely if you have a good fast system, but that is BAD programming.
The other example is even more obvious perhaps.
Code "G4 P" &PierceTime 'Pierce Delay
Code "G0 Z" & GetUserDRO(1001)
Here, we're asking Mach to perform a dwell. You can virtually guarantee that the G0 will be executed BEFORE the dwell is over. You're also risking buffer corruption again. It might - it might not. Who knows.
If you have a fast system and if the request that you're making is a quick one - then you MIGHT get away with it - then again you MIGHT get away with it MOST of the time. But sooner or later it's going to bite you in the **s*.
Sorry - lecture over - hope it helps.
Ian
-
It's also poor form to use:
While (IsMoving)
Wend
You should instead use
While (IsMoving)
Sleep (1)
Wend
This turns control back to Mach briefly, so it can do other things, rather than spending 100% of the CPU time in the loop. This is particularly important when the operation it's waiting for takes a long time (like a long move).
This is covered in the Mach3 Macro Programmers Reference I wrote several years back....
http://www.machsupport.com/docs/Mach3_V3.x_Macro_Prog_Ref.pdf
Regards,
Ray L.
-
Actually Brian supposedly added in a built in Sleep() to the While Ismoving() a long while back. I have it in the trouble notes somewhere.
ALL of this is WHY I try to do everything that involves Motion totally within the Gcode side IF possible.
Take this routine, it can be done completely from the Gcode side and from there it is as fast as the machine can move. (;-)
BUT we just have to learn to work with what we have to work with.
(;-) TP
-
I was staying off the sleep thing to try to avoid getting too heavy with the principle of the semaphore thing.
That said sleep does NOT return control back to Mach per se. What it does is say to the (windoze) scheduler, "nothing to see here - please move on". So if you imagine the scheduler splitting time between all the windows processes, when it comes to the CB thread it effectively skips it and moves on to the next process in the list (and even in a "bare" system there are a lot more processes vying for the CPU than just Mach). Without it, the CB thread would accept it's "turn" and waste CPU cycles doing several iterations of a loop.
So.... what value should we give to sleep? Well it's an eductated sort of guess. If the REQUEST we've made is something like code "G1 X10" then we can bet it's going to take more time than (say) setOEMDRO. So in the former we might choose a sleep 100, whereas for the latter we might choose sleep 10 or even sleep 1 - it's a game of compromise. The name of the game is to try to save CPU cycles without causing too long a wait AFTER the semaphore has been set by Mach. Note that this does NOT change the logic of the program. We're only trying to be nice to the CPU.
If Art DID build a sleep into isMoving then I would humbly suggest that it was a mistake and not documenting the fact a further mistake. But that would just be MHO if in fact he did.
Ian
-
I think we need a CB /Gcode traffic cop (;-)
I don' t think it was ART as the while Ismoving would hog the CPU without a sleep(). I may be wrong and it was only a test version that had the built in sleep() . I have years of trouble notes in several volumes of books. The longer I stay away from them the fuzzier they get.
I was looking at the Cubloc PLC system and they seem to have figured out the integration between their ladder logic and their basic language. It stays in thread sync with each other. Otherwise havic would be the results.
(;-) TP
-
I think it was this Version update.
January 29/2009
Release 3.042.021
-- Bug fix to some Arcs feedrate..
-- Installer was missing a file, making a false error message popup
-- CPU usage lowered on Macros that fill Mach3's buffers
-- Macro's can no longer overrun the buffer when adding moves
-- Feedhold fixed to pause motion coming from the script buffer
-- Ismoving() script call no longer will tax the CPU
My other point has always been IF mach3 had condition Gocde most of this would be a moot/mute? point as most would not need the CB side for machine work. You will notice that Fanuc MacroB is a VERY useful macro language for Gcode and it HAS access to all the system parameter/var 's.
Then the CB would be basically for system enhancements. (my opinion (;-) )
(;-) TP
-
Hi Guys,
So, should we be using the Sleep() command within the while...wend or not ??
Tweakie.
-
Hi Tweakie
Yes. - and be creative with the value.
Just for fun - here's an alternative view of how you can use it. Suppose we guess or by experience know or perhaps even work out, that some "code" request is going to take for arguments sake in the order of 10 milliseconds. How about the following?
code "something"
sleep 9
while isMoving()
sleep 1
wend
This attempts to "rest" the CPU optimally whilst giving the fastest response. Is it worthwhile or anal? ;D - you decide.
Ian
-
Thanks Ian.
Tweakie.
-
my rule of thumb is USE Sleep() when there is an update to a VAR or DRO or LED to take place and something has to take place based on those updates.
The Gcode seems to be stacked into a Que and seems to stay in order most of the time the CB updates and calls are all over the place and need supervision(;-)
I would be nice if someone were to actually MAP out the process so we would KNOW how the process really works. CB all by itself works well. It is when you mix it with Gcode that most problems occur. Perhaps a GATE can be created to keep the process stable????? I know it works to keep goats in the barnyard(;-)
(;-) TP
-
SIDE BAR: Has anyone ever tried a G31 with an arc?
(;-) TP
-
geez, i have been jinxed! never had a problem with the g31 until i read this thread. headed out to the machine to cut and what happened? mach ignores the g31 at the start of the m3 macro and just fires the plasma torch. changed the g 31 to g28.1 and still happened. put the g28.1 into the gcode and works flawlessly. using the g28.1 also got rid of the ramping problems of the z axis probing. with the g31 could only probe at 40 ipm reliably. with g28.1 probing at 100 ipm.thanks for the info Br549.
-
HIYA Triple, You were not jinxed you were enlightened(;-) THe stars aligned properly and you saw the light.
(;-) TP
-
but just for the hell of it can you post your macro please?
Ian
-
Everything is working great with 28.1 now. The plate height check is very fast.
Here is my macro
PierceHeight = GetUserDRO(1000)
CutHeight = GetUserDRO(1001)
PierceTime = GetUserDRO(1002)
CurrentZ = getDRO(2)
While IsMoving()
Wend
If GetOEMLed(825) = 0 Then
Code "G28.1 Z" & CurrentZ
While IsMoving()
Wend
Code "G92 Z0.0"
While IsMoving()
Wend
Code "G0 Z" & PierceHeight
While IsMoving()
Wend
DoSpinCW()
While Not isActive(Input1)
Wend
Code "G4 P" &PierceTime 'Pierce Delay
While IsMoving()
Wend
Code "G0 Z" & GetUserDRO(1001)
While IsMoving()
Wend
Else
Code "(Torch is On Surface Hit STOP and Fix)"
End If
-
Glad you got it shooting sparks like you want it.
(;-) TP
-
It shoots sparks, but not quite like I want since I get to start a new battle with the high freq plasma noise interfearance ... yay
-
Sheilding and grounding are your best buds
(;-) TP
-
So G28.1 fixes it. Can we conclude that there is a problem with G31? for whatever reason...maybe a config setting...on my machines, Z axis G31 accel follows the X or Y axis. If memory serves, it follows the X. I was hoping to see a G31 fix come out of this thread.
-
YEP, I will agree there is a problem with G31 as you stated(;-). You may want to run this by Andrew for further testing before they will consider a fix.
The main reason I would never had seen it is I run all the axis's at the same parameters for accel/velocity.
Good Job, (;-) TP
-
The main reason I would never had seen it is I run all the axis's at the same parameters for accel/velocity.
So do I. Every now and then I play around with the accel settings. That's when I notice it. Other than some random testing, I run all axes at 30. Stirling tested this and said it was fine on his machine...Z axis G31 followed the Z axis accel settings. That's why I was wondering is it was a config setting.
-
I am not sure I know of any config setting that would effect it that way. I do not have a machine setup here at the house to test probing with Mach3 and Vista64 do not get along (;-) and will not simulate correctly. SO I cannot say one way or the other. BUT looking at the test vid would indicate there IS a problem. You can see and hear the difference. I used a sound analyser to see the ramp and decay of the sound the motors made.
Many years of loud noise leaves you half deaf in many freq ranges so I have to SEE the sound sometimes.
(;-)TP
-
Certainly a strange one. I too normally run all three at the same settings but played with them to test this out. Like I say - all seemed well. Just a shot to nothing - you guys haven't got/had anything going on with swapAxis() by any chance? (clutching at straws here).
Ian
-
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
-
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
-
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
-
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
-
I still stick an isMoving() after each one - but that's just me.
Me too ;) (I learned the hard way).
Tweakie.
-
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.
-
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.
-
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
-
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?
-
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
-
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.
-
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.
-
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
-
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.
cnt=0
setOEMDRO(800, 1000)
While isMoving()
cnt=cnt+1
Wend
message cnt
Ian
-
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
-
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
-
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 ;D
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
-
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.
-
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