Well probing was fun while it lasted!

[derek]

Ouch


Here is a screen shot after the carnage



Pin number 11 on the LPT3 column of the UC300 input monitor is the probe input. It is lit when the probe is closed and unlit while it is open. As you can see Mach is registering properly. I emailed the MFG on the UC300 and probing.

Mach was registering the probe contact the whole time it was crunching.

Back to the edge finder I guess.

[DaveCVI]

Sorry to see a picture like that - I've done it too (developing all the MSM probing routines taught me to have a supply of probe tips handy).

Looks to me like the best solution to that problem would be to dump the UC300.
The reality is that there are a bunch of cheap USB Mach motion control devices that have come on the market and many (most) of them are being found to be a bit poorly implemented. G31 probing in particular is a function that they tend to screw up - and the results are not pretty as you've found.

This type of problem is why we had to limit support to the parallel port (the "gold standard" for Mach operation) and the Smooth Steppers (USB or Enet).

Dave

[DaveCVI]

I forgot to mention:
You may find this site useful: http://www.itpstyli.com/
They are my favorite source for replacement tips and it looks from the pic that your probe can use standard tips.

Dave

[derek]

Thanks for the link.
The offending probe is in the trash can as it was a piece of crap and a serious time vampire. Calibrating it was a nightmare as the circuit board wasn't spring loaded so it would constantly loose continuity while you were adjusting it. I was kind of glad when it crashed. I could never trust it.

When I hear back from CNCdrive about the probing I'll decide what to do next. That probe was so crappy it may have been part of the problem but I'd like a clarification from the MFG before I replace it. I have the smoothstepper and the uc300 as well as a Kflop and hands down the UC300 has been the best board for me. The Kflop is awesome but it's just too complicated for my pea brain!

Thanks
Derek

[Analias]

You have my sympathies, I have destroyed so many probe tips that I have spent more on replacement tips than the cost of the original probe.

Dave, I was curious how hard it would be to add a check in the probing code to require triggering the probe by hand before the probe operation would proceed? I have always suspected that would have avoided all my destroyed probe tips since they were caused by some form of continuity issue (I forgot to plug in the probe, etc.). The check would have verified that the probe was functioning before I could put it in harm's way. A nice touch would be to add a control to the UI to toggle the check.


Freeman

Sent from my Xoom using Tapatalk 4

[DaveCVI]

Dave, I was curious how hard it would be to add a check in the probing code to require triggering the probe by hand before the probe operation would proceed? I have always suspected that would have avoided all my destroyed probe tips since they were caused by some form of continuity issue (I forgot to plug in the probe, etc.). The check would have verified that the probe was functioning before I could put it in harm's way. A nice touch would be to add a control to the UI to toggle the check.

Are you talking about a hand check before every G31 probe move or only at the start of a probe operation sequence (for example "find the corner") ?

Dave

[Analias]

Are you talking about a hand check before every G31 probe move or only at the start of a probe operation sequence (for example "find the corner") ?

Dave

In this case, only before the start of a probe operation from the WC Offset screen. The purpose would be to verify the probe is functioning and the operation will succeed when the probe is triggered.

I have asked Brian at Artsoft for the opposite, that a fault or error be thrown if the probe is triggered during any other operation other than a G31 or a probe sequence. This would protect the physical probe if left mounted during a job run or during jogging. Papa Bear (sorry I can't remember his real name on the Mach3 mailing list) tried writing a plug in to implement protected mode for the probe, but ran into a problem with Mach3 that prohibited its implementation.

Freeman


Sent from my Xoom using Tapatalk 4

[rotorfixer]

Interesting......

I Just installed MSM (trial), and I am using a Tormach probe with my CNC G0704.

I only had the probing working for a short time when I commenced a Z probe op and I looked away. Next thing there were probe parts bouncing off the roof of the shop.

I assumed I did something wrong, and on top of it I had no idea why the probe plunged into the stock because I wasn't looking. Pretty quick way to blow $100. I had a spare tip so I installed it. I then paid close attention to the probe and strangely everything seemed fine. Then I moved to a part in the vice and it started doing it again, and I think it is the same thing the OP is posting about.

On the Z probe op the probe comes down in fast probe and touches, stops, pauses, backs off, then comes down in slow probe and touches, STOPS, PAUSES, then continues to move down even the probe active light is ON as the OP stated. Failure to hit escape would cause the probe to explode as it did the first time. This was not an intermittent scenario, it did it every single time in this position.

I did some googling and found a similar thread. It was suggested that the Z axis should be zero'd before initiating the probe op. I haven't tied to figure out why, but since I started doing this I haven't had a problem. The person suggesting this said that the code for the probing op should contain this zeroing step.

Do you have any insight into this? Is there something else I am missing?

Thanks, the software looks great, I love the probing screens, it is making it easy to get this all figured out.

Peter.

[DaveCVI]

Hi,

Interesting......

I Just installed MSM (trial), and I am using a Tormach probe with my CNC G0704.

Let start with getting the basic information:
1) What version of MSM?
2) what version of Mach?
3) what version of windows?
4) What are you using for a motion controller? (PP, Smooth stepper, something else?)

I only had the probing working for a short time when I commenced a Z probe op and I looked away. Next thing there were probe parts bouncing off the roof of the shop.

I assumed I did something wrong, and on top of it I had no idea why the probe plunged into the stock because I wasn't looking. Pretty quick way to blow $100. I had a spare tip so I installed it. I then paid close attention to the probe and strangely everything seemed fine. Then I moved to a part in the vice and it started doing it again, and I think it is the same thing the OP is posting about.

Until I know what you are using for a motion device, I'm unsure what to say as the original poster had a problem with a UC300 controller. I understand from another thread that the UC300 (and UC100) controllers have been updated and there are reports of this problem having been fixed by the controller update).

On the Z probe op the probe comes down in fast probe and touches, stops, pauses, backs off, then comes down in slow probe and touches, STOPS, PAUSES, then continues to move down even the probe active light is ON as the OP stated. Failure to hit escape would cause the probe to explode as it did the first time. This was not an intermittent scenario, it did it every single time in this position.

I did some googling and found a similar thread. It was suggested that the Z axis should be zero'd before initiating the probe op. I haven't tied to figure out why, but since I started doing this I haven't had a problem. The person suggesting this said that the code for the probing op should contain this zeroing step.

If you can reproduce the problem at will, we can get a debug log of the actions. This sounds like a controller bug to me, but again I need to know controller you're using.
Please refer me to the thread that says things "Need to be zeroed" so I can read that.
NOTE that the "gold standard" of controller behavior is the parallel port. If a controller acts differently than what mach does for a parallel port, then by definition the controller is the fault point.
I can find what a controller is doing that varies form a PP, but the controller vendor is the only one that can change the controller's actions. Some vendors are quick to fix bugs, others simply don't care.

Do you have any insight into this? Is there something else I am missing?

Thanks, the software looks great, I love the probing screens, it is making it easy to get this all figured out.

Peter.

Dave

[rotorfixer]

Hi Dave,

Again, let me state I am very happy with your software. I am a very logic driven person so seeing a few of these instances makes me believe there might be something else going on. Sorry for not posting the usual info.

I will have to get you the exact MSM version but I only downloaded it a week ago, not sure how often you update it.
Same with the mach version, though I remember verifying it to be above the spec MSM required, if that helps.
This is windows 7 ultimate (it actually might be running in test mode but I doubt that has anything to do with it, mach runs just fine).
I am using the Ethernet smooth stepper. (I am using the probe directly with the smooth stepper pins (not through the breakout board I also have. There is an internal pull up just like on the real parallel port, again , I can't see this having anything to do with it because it DOES catch the probe hit every time).

I just was looking at the fact that it appears his might have done the exact thing mine did. That is why I posted this on the same thread. I have found another instance of the same condition, I will post the link.

I am a little versed in programming, and well versed in hardware. You would know better than me but, since the probe DOES register both touches (fast and slow) (it stops after both hits) but then instead of retracting to the clearance distance it goes backwards that sure seems like a programming issue as opposed to anything else???

As far as being able to reproduce, I am not sure I can make it happen on command, but once it is in this mode it will repeat every single time. I hope that makes sense. I will try it tonight and see if I can find out the exact right conditions.

Here is the link to the thread that dealt with the same type of issue:

https://www.machsupport.com/forum/index ... ic=17591.0

Not sure it is a coincidence, but I started zeroing before the probe sequence and haven't had an issue since.

Can you tell me how to produce a debug log?