Hello Guest it is July 21, 2019, 05:38:29 AM

Author Topic: Error Trapping in Button Script  (Read 4295 times)

0 Members and 1 Guest are viewing this topic.

Error Trapping in Button Script
« on: July 24, 2009, 03:31:44 PM »
The G31 code (linear probe) refers to errors that may occur if the program point is less than .01" from the start point. Is there a way to add error checking in the VBscript button code to trap errors?
Re: Error Trapping in Button Script
« Reply #1 on: July 24, 2009, 03:39:07 PM »
The G31 code (linear probe) refers to errors that may occur if the program point is less than .01" from the start point. Is there a way to add error checking in the VBscript button code to trap errors?

Save the current position before doing the G31.  Then, after the G31, look at the probe point DROs (2000-2002), and see how far it actually moved.  If the probe triggered too close to either the start or specified end point of the move, then assume something went wrong.

Regards,
Ray L.
Regards,
Ray L.
Re: Error Trapping in Button Script
« Reply #2 on: July 24, 2009, 03:48:52 PM »
I have had a problem where the probe actually drives the bit toward the workpiece when retracting after the probe touches. The retract code uses G0 to re-position. I have seen the it uses the appropriate z coordinate for the G0 comand, yet it travels the wrong direction. I was wondering if an error occurred and if I could truly trap that error then I could abort the retract portio of the code. I am new to button scripting so I was wondering if there is an onerror type capability in the button scipting.

vmax549

*
Re: Error Trapping in Button Script
« Reply #3 on: July 24, 2009, 04:51:54 PM »
THe only time I have seen that is playing around axis zero and forgot which side of Zero I was on (+/-) and which way to code it to retract.

I use probing every day and don't see your wrong direction error occur when the code is correct for the application.


IF you have a piece of code that causes this please post it and I can test it here.

Just a Thought, (;-) TP

(;-) TP
« Last Edit: July 24, 2009, 04:54:53 PM by vmax549 »
Re: Error Trapping in Button Script
« Reply #4 on: July 24, 2009, 05:04:21 PM »
Here's a more detailed description. I have a zero touch plate routine that many have been using. This code should never drive the bit into the workpiece. I am also using a SmoothStepper (SS) which may actually be the problem. However, I am aslo doing something that I am suspecting may be casuing an error and cofusing Mach or the SS. Rather than use a touchplate, I have simply shorted two wires togther to simulate the plate being touched while testing this feature. I have read that the G31 code will actualy retract the bit a very short distance after the probe fires. My hand shorting of two wires wouldn't simyulate the probel breaking contact at just the irght time for this small retraction so today I started wondering if I was causing a problem with my test method and then wondered if I could error trap. I am not at the machine today, so I can't simply try a real touchplate, although that scrares me a bit since this sometimes drives toward the table when the button routine performs the final retract. Another person also sent me a message that they were using the same routine I am using and it normally works OK. However, one time they had the touch plate so far away that the bit failed to contact the plate by the end of the G31 move. They hit zero again and after the bit hit the plate, the machine then drove the bit very hard into the touchplate/workpiece. They are not using a SS, so I thought that perhaps he too had an error condition that our button routine needs to trap.

Sorry for the lengthy explanation. Just thought it better to give the full picture.

vmax549

*
Re: Error Trapping in Button Script
« Reply #5 on: July 24, 2009, 05:13:15 PM »
THe G31 code does NOT do the retract.

G31   Move in direction of command. Stop on trip and record VARs.  YOU cannot probe OFF the trip point you must first move off with G0/1 until the probe resets then you can resume probing.

If the g31 travels the full commanded value without a trip, stop.

That is all the G31 can do. ANY other movement is controlled by the person writting the macro.

(;-) TP
« Last Edit: July 24, 2009, 05:18:35 PM by vmax549 »
Re: Error Trapping in Button Script
« Reply #6 on: July 24, 2009, 05:28:53 PM »
Here's a more detailed description. I have a zero touch plate routine that many have been using. This code should never drive the bit into the workpiece. I am also using a SmoothStepper (SS) which may actually be the problem. However, I am aslo doing something that I am suspecting may be casuing an error and cofusing Mach or the SS. Rather than use a touchplate, I have simply shorted two wires togther to simulate the plate being touched while testing this feature. I have read that the G31 code will actualy retract the bit a very short distance after the probe fires. My hand shorting of two wires wouldn't simyulate the probel breaking contact at just the irght time for this small retraction so today I started wondering if I was causing a problem with my test method and then wondered if I could error trap. I am not at the machine today, so I can't simply try a real touchplate, although that scrares me a bit since this sometimes drives toward the table when the button routine performs the final retract. Another person also sent me a message that they were using the same routine I am using and it normally works OK. However, one time they had the touch plate so far away that the bit failed to contact the plate by the end of the G31 move. They hit zero again and after the bit hit the plate, the machine then drove the bit very hard into the touchplate/workpiece. They are not using a SS, so I thought that perhaps he too had an error condition that our button routine needs to trap.

Sorry for the lengthy explanation. Just thought it better to give the full picture.


I use G31s for touching off many, many times a day, with a SmoothStepper, running my own macros.  Never had a problem, *except* one time on a previous version of Mach which *did* have a bug that resulted in breaking my probe.  That bug was fixed within hours or my reporting it, and a new version of Mach posted.  What version of Mach are you using, and what SS plug-in?

Regards,
Ray L.
Regards,
Ray L.
Re: Error Trapping in Button Script
« Reply #7 on: July 24, 2009, 05:34:31 PM »
Here's what is in the Mach Manual:

"In response to this command, the machine moves the controlled point (which should be at
the end of the probe tip) in a straight line at the current feed rate toward the programmed
point. If the probe trips, the probe is retracted slightly from the trip point at the end of
command execution. If the probe does not trip even after overshooting the programmed
point slightly, an error is signalled."

However, I believe what you are saying is correct, because I have not seen it move due to G31 after the probe touches. But again, I was simulating the probe by touching two wires together so I thought perhaps it was moving ever so slightly and when it did not see the probe break contact it raised an error. Assuming you are correct, I am guess I will have the same wierd probel with the moves after G31 when I truly do use a touch plate. I suspect this may be a SmoothStpper issue, but will investigate more to see if I can better characterize exactly what is happening.

Re: Error Trapping in Button Script
« Reply #8 on: July 24, 2009, 05:41:51 PM »
Here's a more detailed description. I have a zero touch plate routine that many have been using. This code should never drive the bit into the workpiece. I am also using a SmoothStepper (SS) which may actually be the problem. However, I am aslo doing something that I am suspecting may be casuing an error and cofusing Mach or the SS. Rather than use a touchplate, I have simply shorted two wires togther to simulate the plate being touched while testing this feature. I have read that the G31 code will actualy retract the bit a very short distance after the probe fires. My hand shorting of two wires wouldn't simyulate the probel breaking contact at just the irght time for this small retraction so today I started wondering if I was causing a problem with my test method and then wondered if I could error trap. I am not at the machine today, so I can't simply try a real touchplate, although that scrares me a bit since this sometimes drives toward the table when the button routine performs the final retract. Another person also sent me a message that they were using the same routine I am using and it normally works OK. However, one time they had the touch plate so far away that the bit failed to contact the plate by the end of the G31 move. They hit zero again and after the bit hit the plate, the machine then drove the bit very hard into the touchplate/workpiece. They are not using a SS, so I thought that perhaps he too had an error condition that our button routine needs to trap.

Sorry for the lengthy explanation. Just thought it better to give the full picture.


I use G31s for touching off many, many times a day, with a SmoothStepper, running my own macros.  Never had a problem, *except* one time on a previous version of Mach which *did* have a bug that resulted in breaking my probe.  That bug was fixed within hours or my reporting it, and a new version of Mach posted.  What version of Mach are you using, and what SS plug-in?

Regards,
Ray L.

I am using R3.043.000. This is the development release, but Gerg of Warp9 told me to use it as it is the best version to run with a SS. I am also using the latest SS plugin. What versiosn are you using? Also, could you post your button code so I can review it to see any difference mine may have. Finally, the Mach manual says in many places 'It is an error if:" Surely there is a way to trap those errors in the routine and handle them. I'm not saying that is my problem in this case, but if errors can occur it is good practice to handle them. Perhaps the manual is ismply saying that the operation is not valid rather than anacutual an error raised.
Re: Error Trapping in Button Script
« Reply #9 on: July 24, 2009, 05:55:04 PM »
Here's a more detailed description. I have a zero touch plate routine that many have been using. This code should never drive the bit into the workpiece. I am also using a SmoothStepper (SS) which may actually be the problem. However, I am aslo doing something that I am suspecting may be casuing an error and cofusing Mach or the SS. Rather than use a touchplate, I have simply shorted two wires togther to simulate the plate being touched while testing this feature. I have read that the G31 code will actualy retract the bit a very short distance after the probe fires. My hand shorting of two wires wouldn't simyulate the probel breaking contact at just the irght time for this small retraction so today I started wondering if I was causing a problem with my test method and then wondered if I could error trap. I am not at the machine today, so I can't simply try a real touchplate, although that scrares me a bit since this sometimes drives toward the table when the button routine performs the final retract. Another person also sent me a message that they were using the same routine I am using and it normally works OK. However, one time they had the touch plate so far away that the bit failed to contact the plate by the end of the G31 move. They hit zero again and after the bit hit the plate, the machine then drove the bit very hard into the touchplate/workpiece. They are not using a SS, so I thought that perhaps he too had an error condition that our button routine needs to trap.

Sorry for the lengthy explanation. Just thought it better to give the full picture.


I use G31s for touching off many, many times a day, with a SmoothStepper, running my own macros.  Never had a problem, *except* one time on a previous version of Mach which *did* have a bug that resulted in breaking my probe.  That bug was fixed within hours or my reporting it, and a new version of Mach posted.  What version of Mach are you using, and what SS plug-in?

Regards,
Ray L.

I am using R3.043.000. This is the development release, but Gerg of Warp9 told me to use it as it is the best version to run with a SS. I am also using the latest SS plugin. What versiosn are you using? Also, could you post your button code so I can review it to see any difference mine may have. Finally, the Mach manual says in many places 'It is an error if:" Surely there is a way to trap those errors in the routine and handle them. I'm not saying that is my problem in this case, but if errors can occur it is good practice to handle them. Perhaps the manual is ismply saying that the operation is not valid rather than anacutual an error raised.

I'm not using a button macro - I'm using a whole suite of probing macros I posted some time ago here:

http://www.machsupport.com/forum/index.php/topic,10931.msg68619.html#msg68619

You will quickly find using button scripts is a Royal PITA.  MUCH better to just write your macros as M-scripts, and let the button call them.

Regards,
Ray L.
Regards,
Ray L.