Hello Guest it is March 29, 2024, 03:25:52 AM

Author Topic: Mach4 Probing and reporting  (Read 14350 times)

0 Members and 1 Guest are viewing this topic.

Offline BR549

*
  •  6,965 6,965
    • View Profile
Mach4 Probing and reporting
« on: May 02, 2014, 10:58:58 PM »
HIYA Brian,

 I see from the probing notes you included that when a Probe file is OPEN and the G31 reaches the end point without tripping that it WRITES the endpoint values to file.

Could we PLEASE have it so that instead of writing the endpoints it writes an error code for each axis to the file. IF it reaches the endpoint then it IS an error probing wise. AS it is there is virtually no way to find the missed points in a 3d probe file.

Also could you please make that error show up as an LED flashing. It means 1 of 2 things the programming is OFF and it is missing things OR the probe TIP is broken

This was a big problem in MACH3.

(;-) TP
« Last Edit: May 02, 2014, 11:03:34 PM by BR549 »
Re: Mach4 Probing and reporting
« Reply #1 on: May 03, 2014, 08:46:27 AM »
I think we added a register to see if the probe was contacted.. I don't know at this time but the plan is to enhance the probe a bit over time.. We just want it working at this time!

Thanks
Brian
Fixing problems one post at a time ;)

www.newfangledsolutions.com
www.machsupport.com

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Mach4 Probing and reporting
« Reply #2 on: May 03, 2014, 10:12:42 AM »
Could you also consider "Protected Move" mode for Mach4. It is a must have for protecting an expensive probe/tip.

(;-) TP
Re: Mach4 Probing and reporting
« Reply #3 on: May 03, 2014, 11:06:58 AM »
What the heck is a "Protected Move"
Fixing problems one post at a time ;)

www.newfangledsolutions.com
www.machsupport.com
Re: Mach4 Probing and reporting
« Reply #4 on: May 03, 2014, 11:19:13 AM »
Hi Terry,
IF it reaches the endpoint then it IS an error probing wise.
I understand that a goal of M4 is to make the Gcode closely match Fanuc actions. Given that, I think that the statement you asserted above is incorrect. A G31 is not defined as a "probe only move which is always expected to trigger".  G31 is defined as a "Skip command" (ref smid, CNC programming techniques"). As defined, issuing a G31 to a given coord and having the controlled point reach that coord without the probe triggering is not an error condition.

A probe trigger simply causes the movement to "skip" remaining distance for the G31 (IFF the probe triggers). If the probe does not trigger, then no movement amount needed to be skipped and the end point is the programmed G31 coordinate (which is not an error condition).

Dave



Author of the MachStdMill Extensions for Mach3
www.CalypsoVentures.com
Re: Mach4 Probing and reporting
« Reply #5 on: May 03, 2014, 11:50:10 AM »
While running a routine to probe in several directions aka: hole or outside of a pin
If it goes to the max position and does not see the triggered probe signal
Sounds to me what Terry wants is something like this:
a comparison of two values to test for an Error condition for safety?
If (trigger_point == maxpoint) then
   call your Error message --"mission control we have a problem"
   stop everything
end

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Mach4 Probing and reporting
« Reply #6 on: May 03, 2014, 12:05:32 PM »
HIYA DAVE , Yes a skip command is what it is BUT when used in a probing situation it is consider and error IF the g31 reaches the endpoint without a trip.

It means you did not program the parameters of the routine correctly OR you have broken the tip off.  Writing the endpoint values to a point file CURRUPTS the data as the POINTS are not real.

Simple example You are probing a hole and you did not program the movement far enough to get to the other side of the hole so when it gets to the endpoint it records the endpoints as NORMAL but in reality it is an ERROR you need to deal with so Mach4 SHOULD alert you to the error so you can fix the problem.

Other example, You create a probe routine to check features on a part. Somewhere the tip gets broken YET the routine runs on for another hour gathering USELESS endpoint data.  Would you not want to be alerted to the problem at the FIRST error ??

3D probing, Missed points and using endpoint data CURRUPTS the point cloud . Some routines run for HOURS gather useless data IF not programmed to reach the entire shape profile to be probed.

SO yes in probing with G31 it is considered an ERROR to MISS a trip and write the endpoint values.


HIYA Brian, A protect move with a probe is where you are moving across a part in a routine with G0 or G1 OR jogging from point to point and the tip strikes the part accidently. The Machine MUST stop on the probe trip in order to try and save the TIP/PROBE from damage. AN emergency STOP is needed and the program cancelled from continuing.

We have talked about this before (;-) Scott and I had a version of this running in MACH3 via a plugin script. AND it works FINE here. Just like the big boys do it.


 (;-) TP

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Mach4 Probing and reporting
« Reply #7 on: May 03, 2014, 12:31:01 PM »
HIYA Craig, All it really needs is an option switch settable in the System parameters ( say #9999 =1 to turn on #9999 = 0 to turn it off) to allow an error IF the G31 reaches the endpoint of the call without a trip. AND stop the Program from continueing.


Keep it simple and easy to deal with
Re: Mach4 Probing and reporting
« Reply #8 on: May 03, 2014, 06:02:04 PM »
Terry,
I believe that you are mistaken when stating that a G31 that does not trigger the probe is an error condition. I have no such dependency listed in any fanuc gcode language reference I have; but I won't calaim to have all such relevant publications created since the start of time....
Since I understand that the M4 gcode interpreter has been reworked to be "more fanuc compatible", I would appreciate any pointer you have to a fanuc reference supporting your assertion re this "error condition".

Consider this common scenario: You want to know if the path from you current position to a known position crosses a part or not. This is common, for example, when finding the outline of a 2D part via probing. Common algorithms do a probe a known distance fro the current position in X or Y while looking for the part edge. It is not an error to complete a G31 and end up at the G31 commanded position. In fact, this is exactly what the move was meant to "learn" - that the G31 movement was "clear".

I suspect you are mixing two different concepts: 1) An error condition or not when a G31 movement is completed and 2) what to write into a file as a result of a G31 movement. Those are two independent topics.

#1 concerns the definition of the gcode sate machine at the end of a G31 movement. A skip command that did not skip any movement is not an error state - - it is one of two possible normal, non-error states that a G31 may end with. There are (at least) two common ways to determine at the end of a G31 movement if the probe was triggered: a) compare the current position with the commanded position and b) ask the control for the state of the probe input.

I'd note that support of b) is included in Mach 3. Brian's comment that he thinks he added such a register to indicate this in M4 also implies that M4 was intended to have the same support. When the G31 movement is complete, you inspect the state of the probe signal to learn whether the movement resulted in a trigger event or not (this is why M3 has to keep the  probe positioned with a bit of overrun - so that the probe input state will be correct after the probe movement is done - i.e. at the time an application script checks the G31 ending state).

#2 (logging of G31 end coordinates) is an additional layer added on top of the basic G31 gcode movement. M3 has such a facility and apparently M4 has something similar. However, a desire to write (or not write) a value to a file upon normal (i.e. not error) completion of a G31 is an independent topic. You may or may not want the end point of a given G31 move in the file- it all depends on what you are using the data file for.  Just as you gave an example of a situation where you would not want the ending coordinate written to the file, there are different applications where one would want various combinations of: trigger points, non-trigger points, or both written to a data file.

Please try to logically separate the behavior you may desire at an file write application level from the "error or not" ending state of a G31 movement.

FYI, yes, there are other (non-fanuc) gcode variants where the language is structured such that the gcode program uses different probe commands to handle the combinations of Triggered / not triggered and which is to be considered the "normal / desired" end state. One example I am aware of are the LinuxCNC extensions to RS274 - but I consider that not germaine to the discussion as those are not Fanuc compatible gcode interpreters.
 
Dave
« Last Edit: May 03, 2014, 06:07:53 PM by DaveCVI »
Author of the MachStdMill Extensions for Mach3
www.CalypsoVentures.com

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Mach4 Probing and reporting
« Reply #9 on: May 03, 2014, 07:09:13 PM »
HIYA DAVE , Sorry BUT IN PROBING it is an error to reach the end point without a trip. You may want to stop trying to find the answer in the fanuc manuals as they do not much pertain to probing routines. The Probing  routines are handled for the most part by aftermarket or hand written routines for specific tasks/ routines that come WITH the probes.

IF you write an endpoint instead of the trip you have just written BAD data to a point file as THAT "point" does NOT exist on the part you are probing .

IF you break a tip and continously write the endpoint what have you done other than create a lot of false data

IF you are probing for the center a hole and you miss on the width of the hole and reach an endpoint instead of trip on the far side of the hole WILL the center point of the hole be accurate ?? NOPE

IF you write a function AND it does NOT match the profile of the part you are probing and you are writing endpoint data what is the point of running it. ALL you get is a lot of INVALID data.

Everyone I know or have worked with ONLY wants good probed data AND wants to be notified IF trips are missed NO MATTER the reason and it gets to endpoints instead of tripping on the part.

In reference to you statement about it not belonging in the machine side of probing (;-) WHERE else do you propose for it to trap the error ?? In the probing routine ? that code alone would be endless to write over hundreds of thousands of probe cycles.

Where better to TRAP the error and allow the option to stop motion than the controller itself.

Why does everyone these days WANT to work for the machine instead of letting the machine work for you. THAT is a very real Job shop joke, but a serious one all the same.


 Just a thought (;-) Your mileage may vary do to local conditions. (;-) TP
« Last Edit: May 03, 2014, 07:21:47 PM by BR549 »