Hello Guest it is November 20, 2019, 05:41:42 PM

Author Topic: Tool probe strange behavior.  (Read 7885 times)

0 Members and 1 Guest are viewing this topic.

Offline Sam

*
  • *
  •  988 988
    • View Profile
    • hillbillyhilton.com
Tool probe strange behavior.
« on: September 10, 2009, 09:09:25 PM »
So, I finally got around to making me one of those nifty tool setters. Dunno how I got along without it for so long now. It's kinda like indoor plumbing. Anyhow, I have some strange behavior with it. I have the feed set way up in the macro (using Scott and Gregs code) , say 50 or 75 ipm. When I first start up Mach, it works flawlessly. Then I open up a file, run the file, and then, somehow, the probing routine takes the acceleration settings from the X axis to drive the Z axis. This results in a massive over-travel, and a tool crunch. After a lengthy period of trying to troubleshoot, I decide to delete everything and re-install Mach. So I get all the pins set, axis set, screens installed, script modified, ready to rock 'n roll. As soon as I hit the zero button, it once again took the X axis accel. So I load up a file, run it, and low and behold the probe function works as its supposed to. That's exactly the OPPOSITE of the way it didn't work before the re-install. Strange indeed. So, I mucked around with a gazillion different things, and it appears that some times it works one way, and other times it works another way. One thing did remain constant, however....A probe command from a fresh start-up is different from a probe command after a g-code file has been ran. Obviously, if the feed rate is set to something very slow, it works, or at least it appears to work, as the accel is really not an issue. Any ideas??
"CONFIDENCE: it's the feeling you experience before you fully understand the situation."
Re: Tool probe strange behavior.
« Reply #1 on: September 10, 2009, 11:25:02 PM »
On my side, I have a nice tool setter and probe that I can't use anymore.

Worked great before, and one day, no responce, or probing axis are reversed, when probe in z, probe back up ok then won't stop, hit the switch and all sort of others problems, re-write all the macro, work for a couple of days, then trouble again,

I do not trust it anymore

Offline Tweakie.CNC

*
  • *
  •  8,006 8,006
  • Super Kitty
    • View Profile
    • Tweakie.CNC
Re: Tool probe strange behavior.
« Reply #2 on: September 11, 2009, 07:50:57 AM »
Sam, could you post your macro code.

Tweakie.
Success consists of going from failure to failure without loss of enthusiasm.  Winston Churchill.

vmax549

*
Re: Tool probe strange behavior.
« Reply #3 on: September 11, 2009, 09:39:09 AM »
Guys PLEASE take the time to fill out a BUG report on this issue.

Thanks (;-) TP
Re: Tool probe strange behavior.
« Reply #4 on: September 11, 2009, 12:07:54 PM »
Guys PLEASE take the time to fill out a BUG report on this issue.

Thanks (;-) TP

AFTER there's reason to believe it's an actual bug!  Right now, it's FAR more likely a bug in the probing macros being used....

Regards,
Ray L.
Regards,
Ray L.

Offline Sam

*
  • *
  •  988 988
    • View Profile
    • hillbillyhilton.com
Re: Tool probe strange behavior.
« Reply #5 on: September 11, 2009, 12:52:31 PM »
Im using script number 1089 (haha Greg) with Mach 42.02

CurrentFeed = GetOemDRO(818) 'Get the current feedrate to return to later
CurrentAbsInc = GetOemLED(48) 'Get the current G90/G91 state
CurrentGmode = GetOemDRO(819) 'Get the current G0/G1 state
PlateThickness = GetUserDRO(1151) 'Z-plate thickness DRO

If GetOemLed (825)=0 Then          'Check to see if the probe is already grounded or faulty
   DoOEMButton (1010)             'zero the Z axis so the probe move will start from here
   Code "G4 P1"                ' this delay gives me time to get from computer to hold probe in place
   Code "G90 G31Z-4.0 F50"          'probing move, can set the feed rate here as well as how far to move
   While IsMoving()                     'wait while it happens
   Wend
   ZProbePos = GetVar(2002)          'get the axact point the probe was hit
   Code "G0 Z" &ZProbePos          'go back to that point, always a very small amount of overrun
   While IsMoving ()
   Wend
   Call SetDro (2, PlateThickness)       'set the Z axis DRO to whatever is set as plate thickness
   Code "G4 P0.25"             'Pause for Dro to update.
   Code "G1 Z1.0 F50"             'put the Z retract height you want here
   While IsMoving ()
   Wend
   Code "(Z axis is now zeroed)"          'puts this message in the status bar
   Code "F" &CurrentFeed             'Returns to prior feed rate
Else
   Code "(Z-Plate is grounded, check connection and try again)" 'this goes in the status bar if aplicable
End If
If CurrentAbsInc = 0 Then          'if G91 was in effect before then return to it
   Code "G91"
End If
If CurrentGMode = 0 Then          'if G0 was in effect before then return to it
   Code "G0"
End If
Exit Sub
"CONFIDENCE: it's the feeling you experience before you fully understand the situation."

Offline Tweakie.CNC

*
  • *
  •  8,006 8,006
  • Super Kitty
    • View Profile
    • Tweakie.CNC
Re: Tool probe strange behavior.
« Reply #6 on: September 12, 2009, 05:09:32 AM »
Hi Sam,
This is the code I am using without any issues. It is very similar but with slight differences.

CurrentAbsInc = GetOemLED(48) 'Get the current G90/G91 state
CurrentGmode = GetOemDRO(819) 'Get the current G0/G1 state
CurrentFeed = GetOemDRO(818) 'Get the current feedrate
DoOEMButton (1010) 'zero Z DRO
PlateThickness = 2.8 'Touch plate thickness is set here
ProbeFeed = 10 'Z axis feedrate is set here
If GetOemLed (825)=0 Then 'Check to see if plate is already grounded
Code "G31Z -15 F" &ProbeFeed 'Probing move at ProbeFeed rate
While IsMoving() 'Wait for Z move
Wend
Code "G4 P0 .25" 'Pause for DRO to update
ZProbePos = GetVar(2002) 'Exact point probe touches
Code "G0 Z" &ZProbePos 'Go back to exact point of touch if there was any overrun
While IsMoving () 'Wait for Z move
Wend
Call SetDro (2, PlateThickness) 'Set DRO to plate thickness
Code "G4 P0 .25" 'Pause for DRO to update.
Code "G0 Z5" 'Z retract height is set here
Code "(Z axis is now zeroed)" 'Message for status bar
Code "F" &CurrentFeed 'Reset original feedrate
Else
Code "(Z-Plate is grounded, check connection and try again)" 'Message for status bar
End If
If CurrentAbsInc = 0 Then 'If G91 was in effect before then return to it
Code "G91"
End If
If CurrentGMode = 0 Then 'If G0 was in effect before then return to it
Code "G0"
End If

Tweakie.
Success consists of going from failure to failure without loss of enthusiasm.  Winston Churchill.

vmax549

*
Re: Tool probe strange behavior.
« Reply #7 on: September 12, 2009, 01:08:38 PM »
Ray why does it seem that you are tryng to discourage bug reports???

Not knowing the internals of MACH how is the average user suppose to determene if it is code or bug???

Best to just let them report what they see and let others determene bug or code.

Seems to me the code should work the same way EVRY time IF not then there may be a problem.

There are plenty of bugs still there TIME to flush them out and sqiesh them.

(;-) TP
Re: Tool probe strange behavior.
« Reply #8 on: September 12, 2009, 04:30:09 PM »
Ray why does it seem that you are tryng to discourage bug reports???

Not knowing the internals of MACH how is the average user suppose to determene if it is code or bug???

Best to just let them report what they see and let others determene bug or code.

Seems to me the code should work the same way EVRY time IF not then there may be a problem.

There are plenty of bugs still there TIME to flush them out and sqiesh them.

(;-) TP

Terry,

I'm not trying to "discourage bug reports".  I've been doing software SQA for 30 years.  Anyone who has ever done software QA can tell you that 99% of all "bugs" reported by users are not bugs at all, but operator error, or a failure to RTFM.  It does not help Brian, in fact it does him a great dis-service, to file a bug report every time a user finds something that doesn't work as he expects, as *somebody* will have to spend time reading, categorizing, investigating, testing, etc., etc., and the *somebody* is most likely Brian.  We should endeavor to not pass anything along to him until we've done our own due-diligence, and made sure, to the extent we can, it's not *our* problem.  A process should be undertaken to try to *prove* that the behavior is a) reproducible, and b) has at least a reasonable probability of being an actual bug.  When it comes to macros, and it seems probing macros are about the peskiest of the bunch, we should be doubly, even triply suspicious that it is a macro problem, and NOT a Mach3 bug.  *If* nobody here is able to talk him through the problem, then perhaps it makes sense to report it as a possible bug.  The first step has been taken - he's posted his macro code, so somebody can look through it for problems, and hopefully give him some things to try to at least narrow down where the bug is, if there is one (which, personally, I very much doubt in this case).  What he describes is quite egregious, so the odds of it being an actual bug are very slim, considering how many people are performing the same operations on a continual basis with no similar problems.

Of course, I'm also totally baffled by the whole concept of probing at 75IPM.  That sounds like a terrible idea....

Regards,
Ray L.
Regards,
Ray L.

vmax549

*
Re: Tool probe strange behavior.
« Reply #9 on: September 12, 2009, 05:19:13 PM »
RAy, most people that come here are NOT programmers or seasoned Machinist. THey are beginners learning the ropes. THe whole Idea of the BUG list was set up BY BRIAN so that users could post problems they SUSPECTED were bugs. THen others would take the problem and test it to verify the bug existed.

Brian is well buffered at the end of the line. There ARE still bugs present and IF we do NOT make an effort to identify them AND erradicate them we will be plagued by them forever.

Also to say if it works here it should not be a bug is not a good example. With the many variables involved with mach some BUGS are seen by SOME and not others depending on the setup and useage.

ALSO being that Brian is a one man band it is EVERY more important that users report things as Brian does not have the personell time or equipment to do all the testing in all the ways MACH is being used.

SO YES we NEED ALL the reports we can get in any fashion we can get them to help debug mach.

Just a some thoughts, (;-) TP
« Last Edit: September 12, 2009, 05:28:50 PM by vmax549 »