Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: rrc1962 on February 19, 2013, 11:34:56 PM
-
Has anyone ever had an issue where G31 ignored the digitize input? Basically, the G31 is inside a macro and works a few times, then the G31 will initiate, the Z travels down, the digitize signal goes active, but the Z keeps going and crashes. It seems to be a random thing. There are no errors or warning in Mach3. It acts as if the digitize signal is being ignored.
Any thoughts on the issie would be greatly appreciated.
Thanks
-
I've seen that, and worse, more times than I care to remember....
Regards,
Ray L.
-
Hi rrc,
This is an ongoing issue which will perhaps never go away.
Revisions to Mach have, at times, changed the way in which it processes the combination / mixture of VB (cypress basic) and GCode commands within a running macro / script.
I have made 4 changes to my probing script over the last 3 years in order to resolve various issues (as I updated to later Mach versions) and I am currently very pleased with the operation of the G31.
I use the probing function, for tool position setting, many times each day, 7 days a week and it is faultless, but I will never become complacent (at the suggestion of others I did fit an over-travel, e-stop, switch to my tool-setting probe but, so far, it has never been invoked).
My suggestion is that you look closely at the probing script that you are using and perhaps search other threads on the subject in order to correct it’s operation.
(If it is of any help to you, the probing script I am currently using is at the bottom of this page http://www.cooperman.talktalk.net/files/17.htm - I am not saying that this is the 'be-all' and 'end-all' because there are better scripts around but this one works for me).
Tweakie.
-
rrc1962 - LOL - tell me about it - why do you think www.machsupport.com/forum/index.php/topic,4352.0.html (http://www.machsupport.com/forum/index.php/topic,4352.0.html) is 18 pages long? ;D
Ian
-
I'm not sure we're talking about the same issue. That thread seems to focus on 3D edge probing. This is a plasma machine. What's happening is that Mach will randomly ignore the probe input (even though it is active) and crash. We have 3 machines set up with the same profiles, screensets, PC disc image, plasma power supply....These are identical machines down to the last wiring connector. Two of them run without a hitch. The third will run the TOM routine 2 or 3 times then crash o the G31.
I noticed that the thread you posted goes back to 2007. Has anything transpired since then? We've always used G31 but maybe G28 would be more reliable. I forget the limitations, but I recall that G28 also had some sort of issue.
-
Well my response above was based on what you said in your first post. In that context then yes - we are talking about the same thing - simply - can G31 issued from within a macro sometimes keep going even though it's tripped - again my answer is yes.
You've moved the goalposts by giving more info in your second post. Now you're saying why does G31 from a macro run perfectly from two machines but not from a third - that I don't know.
In answer to your last question - has anything transpired since 2007 - loads - has it absolutely, unequivocally made G31 100% reliable? - I'd say maybe/maybe not - others may not agree.
Ian
-
Do you want the long story or the short story,(;-)
(;-) TP
-
Do you want the long story or the short story,(;-)
(;-) TP
;D ;D ;D
-
IS there a reason you want to run the TOM routine from a macro instead of from Gcode ?
You may want to try G28.1 instead of the G31.
(;-)TP
-
I've decided to take G31 out of the macro and back to GCode. The reason I had it in a macro is because we had a lot of the parameters used in the G31 set on the machine by the operator. I'm doing the same thing by putting the G31 back in Gcode but using variables. I set the variables equal to screen DRO's in a macropump. I haven't looked to see if that could be done in a brain.
So far, it seems to be working very well.
-
Might try G28.1. We didn't go that route originally because of G68 issues, but I understand that this has been corrected.
-
G31 from Gcode is very dependable. From a macro NOT so much.
Problem NOW is you cannot RFH or reverse run with a G31 active in Gcode(;-).
You may want to give the G28.1 routine a try. So far it has never crashed the plasma here AND it was fixed so you can run the G68 and use the G28.1.
SIGH, IF we only had conditional Gcode life would be much simpler that using CBmacros.
(;-) TP
-
When you went back to Gcode can you still do a RFH ?? or reverse run ??
Might want to give the G28.1 method a shot it has never crashed the plasma here .
(;-) TP
-
No. I didn't try RR but RFH fails when it does the simulation. G28.1 seems to work with everything so I think that's the way I'll go. I don't think we'll miss Z homing. I'll just change the Ref All button to ref only the X and Y.
-
Here's something a little wierd. When I put the following code in a macropump, I can't scroll the code window. Every time the code executes, the code window rewinds back to the top. I tested by putting a sleep(5000) after the code and I could scroll for 5 seconds, but as soon at the code executed, it rewound to the top.
I ended up putting the code in a macro, then call the macro at the beginning of the program.
code "#1 =" & getUserDRO(1510)
code "#2 =" & getUserDRO(1508)
code "#3 =" & getUserDRO(1551)
code "#4 =" & getUserDRO(1520)
code "#5 =" & getUserDRO(1561)
code "#6 =" & getUserDRO(1570)
code "#7 =" & getOEMDRO(54)
code "#8 =" & getUserDRO(1512)
-
OK you have me curious as to WHY all the parameters to do a simple TOM
Here I use
G31 Z-5 F20 ;Probe down or use G28.1)
G92 Z0 ;Set Z zero
G0 Z.110 ;Move up for switch allowance
G92 Z0 ;Set Z0 as T0M
In macro form the G28.1 behaves
Code" G28.1 Z.500 " 'Probe down
While Ismoving()
Wend
Code"G92 Z0" 'Set Z zero
Code"G0 Z.110" 'Move up for switch allowance
Code"G92 Z0" 'Set Z0 as T0M
While Ismoving()
Wend
End
With running the macro you can then run FRH.
Just a thought, (;-) TP
-
The parameters are not just for the TOM. Only 3 of them are...Switch Offset, Pierce Height and Slow Zone. The others are for feedrates, pierce delay and safe Z. We make all of that available to the operator so it he wants to use a different material, all he has to do is change the cutting parameters on screen rather than generating a new program. The only thing SheetCAM hard codes is the kerf width. We could do that in Mach also, but then the operator would have to maintain a tool table.
I kind of like it all in Gcode. RFH works fine with G28.1 in Gcode. It seems to know not to "execute" the G28.1 when it does the simulation.