Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: BR549 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
-
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
-
Could you also consider "Protected Move" mode for Mach4. It is a must have for protecting an expensive probe/tip.
(;-) TP
-
What the heck is a "Protected Move"
-
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
-
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
-
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
-
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
-
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
-
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
-
Well... Fanuc labels it a skip or high speed skip. You, the programmer, programs an end point in what amounts to an exact stop G01 move but a probe strike "skips" the rest of the move. The skip is not mandatory and therefore not an error if the probe does not strike in the strict sense of the move. However, that may not be what you want for a certain situation. But it can be desirable in other situations. So what do you do? Well... You can look at the G code variables where the probe position is recorded and compare them to the position. If the probe position is the same as the end point, you know that your probe did not strike. Two ways of handling this in Mach 4... custom macro B and LUA scripts are both capable.
Probe protect can also be handled in the LUA scripts. I do this on my machine. Basically I virtually "wire" the probe input into the e-stop unless I'm actually running a G31. If you sneeze on the probe, the machine will halt. I do this with probeon and probeoff scripts that are executed right before and right after a G31 (if they exist). These scripts should be placed in the macros directory.
probeoff would be a good place to compare the probed position with the end point. It is executed at the end of a G31 regardless of a skip or not.
There is a lot more power available to the user in Mach 4. So try to get into the habit of thinking outside of the Mach3 box. A lot more is possible now. Just because you don't see it in this early stuff doesn't mean that it can't be added rather easily by the end user. Mach 4 is ALL about letting the machine work for you. As you get to know Mach 4, you will start to realize where you can add this functionality most effectively and just how different it is from Mach 3. But it is sooooo hard to break out of the Mach 3 world. After all, it was a good world. But it is not the Mach 4 world.
Steve
-
HIYA Steve I believe yall missed the point entirely. PROBING is very different than all the other uses for G31 and YES I have used it on cylindrial grinders as well as torque limit skip.
WHY not let the machine do the work and take the load off the programmer/operator. Doing an error check(nontrip) at the machine level should be Easy compared to writing TONS of error checking in a probing routine. The machine is ALREADY looking at the trip flag if it does not trip simply allow it to error instead of continue.
Many probers will thank you for it
Simply make it an option that is set in systems parameters. You can have it or NOT just change the parameter value.
AND that is all from me on the subject, If you don't get it you just don't get it. After about 40 years of this stuff I guess I was wrong all this time (;-)
(;-) TP
-
Terry, I just gave the way to do it right above. I wasn't arguing. I was giving you what you wanted! Or did I miss something?
I'm talking just a few lines of code in a script file (not tons) and you can have what you want. That is why we built Mach 4. So that people could make it do the things they want without having to wait on some programmer to do it.
Now, the torque limited move is something a little harder to do because it requires that the motion controller be able to do this. But everything else you wanted can be done rather easily.
-
Hi all,
HIYA Steve I believe yall missed the point entirely. PROBING is very different than all the other uses for G31 and YES I have used it on cylindrial grinders as well as torque limit skip.
Actually,Terry I honestly mean no offense... but.... I think it's you who have missed the point that the error state at the end of a G31 movement is a separate topic from "what do you want written into a coordinate file".
I get that you only want trip coords written - and that makes sense for some situations - just not all of them
Where I think you are having a tad of trouble is in separating control of what goes into the file from the state when a G31 completes.
WHY not let the machine do the work and take the load off the programmer/operator. Doing an error check(nontrip) at the machine level should be Easy compared to writing TONS of error checking in a probing routine. The machine is ALREADY looking at the trip flag if it does not trip simply allow it to error instead of continue.
Here is the problem: you are assuming that "at the machine level" is identical to "if the probe does not trip, we must estop".
A lua script exteneion as Steve suggests is also "at the machine level".
Many probers will thank you for it
and I (and I suspect many others) will curse you and all your ancestors and descendents ( if each and every G31 move that does not trip the probe results in the machine generating an error in the control. That would mean that it would be impossible to probe a vector and determine if the path was clear w/o having to reset the cotnrol from the "auto error is no probe trigger" condition. No thanks.
Simply make it an option that is set in systems parameters. You can have it or NOT just change the parameter value.
YES! BUT.... the option you want is not to control the generation of an error at the end of each G31 movement. THe option you want is to control what gets written into a point file - based on the end state of the G31 move - where that state is "tripped or didn't trip during a move". Both trip and not-tripped are valid end states ( and therefore not errors).
In fact, what you want re point file control is a good argument for NOT building a fixed point file application into the control. It would be much better as a control extension that is configurable.
Dave
-
sounds like an easy solution might be a screen button, that when active, it does Terry's wanted Probe overtravel warning,
else it does the skip type move.......
-
HIYA Dave , NO offense taken (;-) We live in very different worlds. DID you read the part about it being an option (;-)
(;-) TP
-
Actually the way it works is this...
G31 starts move.... Makes contact and skip triggers. Position recorded. If it does not skip... The macro looks for variables for over and under run. Then either places error #3000=1(Probe never made contact) or #3000=1(Probe contact too soon)
It is the responsibility of the programmer to create points by which the MACRO decides it was an to late or too soon to make contact and then choose the error handler in the macro that will either stop the routine or continue.
If you simply write values at the skip trigger you miss the point of probing. You are either looking to find a part or the lack there of depending on what your goal is.
Macro programming is not simple. Especially when it regards to probing. Renishaw and Blum both have macro generators gor Fanuc and Siemens. But I have yet to see the perfect correlation between M4 and their versions of Macro B. There are many macro variables.
Before a probe starts to move your macro must set params in variables for both under (collision) or over(no edge found) and then probe. In the middle of those is the value you need. Then if it is successful it should record the value. Otherwise jump to the error handler.
Just my 2 cents after 30 years with Fanuc and Siemens.
Brian, when can one expect the list of macros implemented or not?
-
Hiya Don, I was making the suggestion based on about 40 years of it myself. IF you are already creating the internal code to do probing WHY NOT make an INPROVEMENT that will help EVERYONE.
NOT EVERYTHING Fanuc is a great idea. They can leave a LOT to be desired in many areas. THIS is one of them.
IF you are probing to gather points as a shape or 3d cloud and the G31 runs to end of travel it IS an error. IF you record the end point it is a phantom point that does NOT exist and it corrupts teh point cloud with FALSE data. Seeing how you may gather 100Ks of points and a % are BAD data, you have a problem. It would also reduced the amount of programming needed to record points rather than comparing EVERY G31 move to qualify it.
NOW if you are gathering metrics THAT is a different story and the needs can change. Mach4 needs to serve users OTHER than the industrial side.
The same goes for teh G31 function MOVES. Should it hit and stop OR hit stop and retract off teh trip. The later IS the most usefull as it greatly reduces the amount of Code you have to generate for shape probing. THAT is a PLUS. Could be an option, Many other controllers give it as an option these days.
ALSO there is using the G31 with an arc G2/3. The greatest thing since cotton candy for probing shapes and 3d clouds. It is a HUGE reduction in coding required and speeds UP the process a great deal. That is something Mach has never been blessed with is a FAST 3d probing routine. becuse of 1 the phantom point generated AND because Mach3 never had conditional code yuou had to rin it as a mcro with VB and THAT was dog bone slow and painful to watch. NO ONE so far has sucessfully created a fast dependable 3d probing routine for Mach3.
Mach4 could set new standards OR just be another follow the sheep controller and do nothing inovative controller.
Just a thought, (;-) TP
-
There are anyi collision modules in both Siemens and Fanuc . no matter the software or control there is no AI as to the part in the machine. The variabilty in geometry of parts is the reason all builders leave it to the end user.
You could use a base param for attachment to the G31 call for min max. This could then act as an overlay watching for colision or lack of part. But for true collision monitor the FPGA must be able to monitor this. If collision is possible it would stop. Complicated but doable.
Regardless youc an never get around the blind aspect to truepart. Location in space
-
Hi Don are you refererring to G31 Protected Move mode ? THat is where IF a probe is active and you make moves OTHER than G31( G01 G00,etc) and it trips it will STOP to protect the probe from damage. Over the years the most damage I have seen to probes is from striking something other than what you wanted when they are traveling to the next probe point. (;-) We use to call it the BHBM ( Blind Headed Boobie Move)
That also would be a great addition to Mach4. I have it for Mach3 . We created a Plugin Protected Mode version for Mach3 that works well here.
Also dealing with Probes a way to accurately qualify or calibrate the probe is required. You have centerline(XY spindle centerline alignment to probe tip ) and probe tip radius AND probe lost motion(due to switch travel) calibration.
The Ball and post "can" do ALL 3 at one time
IF you cannot probe accurately this is really no point in probing.
Just a thought, (;-) TP
-
Exactly TP. The G31 should only be used once the stylus is in a known distance from the area to probe. Otherwise oops. You are correct. You can use a probe activate to monitor tripping of the G31 is not active. Fanuc uses Macro Interrupt. A macro UI input is used to stop the active program and then call an error handler that wraps over the running probe macro. Works very well if done correctly.
When probing in point def around a radius where you continuosly trip at interval to track position this functionality would greatly enhance the sequence. Renishaw has a probe that can do this but I have only seen it work with Siemens.
No matter what I always have my clients use the probe builder plugins with either GibbsCam or MasterCam. The routines are laid into the tool paths and then posted with all the macros written to match. Works fantastically.
Mach 4 does not have Macro Interupt but I am certain it could be written into the PLC. Needs to be a high speed input channel. Hence why I mentioned the FPGA input. The plugin works faster at deciding to stop all motion. Also, having a special bit to tell Mach and the FPGA that a probe is present could then turn on protected mode and turn all rapids to a kbown safe speed matching the needed time to stop the motion as soon as the trip occurred. Very important. Siemens does this. Fanuc not so much. Lol. But it can be done. Check box for tool type is all that is needed.
Ideas?
-
Hi Don, I have a boxfull of probing ideas that I use that could make Mach4 a leader in that area. It just needs a little internal support from Mach4. mach4 is unique in a lot of ways as it HAS to support MANY type of probing from profiling and 3d to metrics for part verification.
that is a WIDE range of functions BUT it can be done well and efficently IF the added support is created . Seeing how the code is BEING developed NOW is the time to think about adding it rather than later.
(;-) TP
-
Agreed since I going to offer industrial machines with Mach 4 installed. Getting close. Otherwise M4 hits it out of the park. Probing is big. One precursor and more important is the ability to rotate G68 around Z. That is way more valuable than probing function extensions. Currently the TP only allows xy rotation. Really makes it hard to build a B rotated spindle head and drill at an angle. Tapping impossible.
I suppose we will see.
-
HI Don, Another aspect of the G68 is for plasma/laser support. You have to be able to rotate in XY ( not a problem there) AND allow it to REHOME the Z axis. Mach3 fails in that respect .
Mach4 has a great set of bones(good basic foundation) BUT as normal it is the small DETAILS and having all functions completely FINISHED that will make it or break it .
(;-) TP