Hello Guest it is April 19, 2024, 01:43:28 PM

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

0 Members and 1 Guest are viewing this topic.

Offline smurph

*
  • *
  •  1,546 1,546
  • "That there... that's an RV."
    • View Profile
Re: Mach4 Probing and reporting
« Reply #10 on: May 04, 2014, 12:52:04 AM »
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

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Mach4 Probing and reporting
« Reply #11 on: May 04, 2014, 01:24:35 AM »
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



Offline smurph

*
  • *
  •  1,546 1,546
  • "That there... that's an RV."
    • View Profile
Re: Mach4 Probing and reporting
« Reply #12 on: May 04, 2014, 02:17:50 PM »
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.
Re: Mach4 Probing and reporting
« Reply #13 on: May 04, 2014, 02:23:16 PM »
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
« Last Edit: May 04, 2014, 02:25:03 PM by DaveCVI »
Author of the MachStdMill Extensions for Mach3
www.CalypsoVentures.com

Offline poppabear

*
  • *
  •  2,235 2,235
  • Briceville, TN, USA
    • View Profile
Re: Mach4 Probing and reporting
« Reply #14 on: May 04, 2014, 03:49:44 PM »
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.......
fun times

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Mach4 Probing and reporting
« Reply #15 on: May 04, 2014, 06:32:02 PM »
HIYA Dave , NO offense taken (;-) We live in very different worlds.  DID you read the part about it being an option (;-)

(;-) TP
Re: Mach4 Probing and reporting
« Reply #16 on: July 29, 2015, 06:48:21 AM »
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?

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Mach4 Probing and reporting
« Reply #17 on: July 29, 2015, 09:59:22 AM »
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





Re: Mach4 Probing and reporting
« Reply #18 on: July 29, 2015, 10:07:19 AM »
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

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Mach4 Probing and reporting
« Reply #19 on: July 29, 2015, 11:30:33 AM »
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