[ger21]

Mach 3 profile is set up for 6ms (150 units) debounce time.

For the record, in Mach3, Debounce does not affect the probe input.
Older versions can be found on the FTP site. You can find the link on the Machsupport page, under Mach3 downloads.

[paulcc]

For the record, in Mach3, Debounce does not affect the probe input.
Older versions can be found on the FTP site. You can find the link on the Machsupport page, under Mach3 downloads.

It is interesting that debounce does not effect probe input. I got 3.043.062 installed and then tested simple zero just now with same erroneous behavior. Any ideas for next step?

[ger21]

I need a better explanation of exactly what is happening, and what messages you are seeing displayed during the probing. If you email me your .xml file, I'll take a look at your settings.

[RCaffin]

WXP, .062, ESS, probe with serious electronic filtering: can run for hours.
I suspect that the Mach3 internal error recovery against noise for the g31 is not all that good, so you need to present a really clean probe signal.
Works for me.

Cheers
Roger

[paulcc]

I need a better explanation of exactly what is happening, and what messages you are seeing displayed during the probing. If you email me your .xml file, I'll take a look at your settings.

Gerry, I sent XML by email. When probing for Z zero, the Z axis moves down until it touches the plate and then stops, After about a second, it attempts to move further down and the sound of the stepper skipping is heard. This, rather than moving up and probing slower to test again as is expected. “Probe ignore, activated at call for probe” is displayed as it attempts to continue down.

Yesterday I constructed a Schmidt trigger debounce circuit on a bit of strip board with a 74HC14. I used a 1uF cap and 6.7kOhm R to give 6.7mS debounce. I installed it this morning and although the little circuit works as designed, it had no effect on the Z probe issue.

[paulcc]

WXP, .062, ESS, probe with serious electronic filtering: can run for hours.
I suspect that the Mach3 internal error recovery against noise for the g31 is not all that good, so you need to present a really clean probe signal.
Works for me.

Cheers
Roger

Yesterday I constructed a Schmidt trigger debounce circuit on a bit of strip board with a 74HC14. I used a 1uF cap and 6.7kOhm R to give 6.7mS debounce. I installed it this morning and although the little circuit works as designed, it had no effect on the Z probe issue. Is this approximately what you are referring to as serious electronic filtering?

[ger21]

Noise won't cause what you're seeing.
All noise will do, is trigger the probe input before contact, which would result in Z zero being too high up.

Are you seeing this with both the Simple Auto Zero, and the Initial Auto Zero?

If you're using 3.043.066, first try 3.043.062.
If that doesn't help, my recommendation would be a complete uninstall of mach3, and a new reinstall, set up with a new, clean .xml.

I'll look at the .xml when I get home from work, but there are no settings that would cause what you're seeing. Unless the Z axis is stalling during the retract, and not lifting?
The probe LED on the run screen does light up when you touch the plate to the tool, right?

[paulcc]

Noise won't cause what you're seeing.
All noise will do, is trigger the probe input before contact, which would result in Z zero being too high up.

Are you seeing this with both the Simple Auto Zero, and the Initial Auto Zero?

If you're using 3.043.066, first try 3.043.062.
If that doesn't help, my recommendation would be a complete uninstall of mach3, and a new reinstall, set up with a new, clean .xml.

I'll look at the .xml when I get home from work, but there are no settings that would cause what you're seeing. Unless the Z axis is stalling during the retract, and not lifting?
The probe LED on the run screen does light up when you touch the plate to the tool, right?

Gerry, thanks for lightning fast reply! answers to questions:
- The behavior is exhibited during both Initial and Simple Auto Zero.
- I installed 3.043.062 two days ago, replacing 3.043.066. Should I still remove and reinstall?
- The probe LED lights as expected

[ger21]

Re-install is really the only thing I can think of, except maybe a corrupt .xml file.

Watch the Z axis DRO when it goes down to touch the plate. After it touches the plate, does the value go up at all, or just down?

[paulcc]

Re-install is really the only thing I can think of, except maybe a corrupt .xml file.

Watch the Z axis DRO when it goes down to touch the plate. After it touches the plate, does the value go up at all, or just down?

Surprisingly the Z DRO goes back up!! And the Stepper is going up as well, but it is as if it is just getting one step every 500mS. I am using G540 with 10 micro steps, so one step is almost unnoticeable. The ticking had me believing that it was try to go down. My poor observation bit me. So this is getting more interesting. As a note, the Z goes up just fine at normal rate when I jog it up.

Lastly to remind you, this issue is intermittent, it occasionally works as it should...

[ger21]

Then Mach3 and the macros are working correctly.
Your issue is either mechanical or electrical. And you appear to know a lot more about electronics than I do.

Actually, try setting your pulse widths to 10 or 15 in motor tuning, and see if it helps?

[RCaffin]

Hi Paul
Yeah, that's 'serious'.
I use about 1 mS, and that seems to be just fine for me.
Cheers
Roger

[paulcc]

Then Mach3 and the macros are working correctly.
Your issue is either mechanical or electrical. And you appear to know a lot more about electronics than I do.

Actually, try setting your pulse widths to 10 or 15 in motor tuning, and see if it helps?

Tried upping Z motor pulse to 5mS (as high as it goes) and get same results. I have noticed that the probing is actually doing the correct motions, just at extremely slowly speed after the first touch. the speed strangely slows even further in an approximately smooth curve over 15 or 20 seconds until it almost stops. I can conceive of nothing in hardware that could cause this behavior. It must be pulsing issue from Mach 3. I will hang the scope on the printer port to see what step and direction are doing.

[ger21]

Tried upping Z motor pulse to 5mS (as high as it goes)

It goes to 15. Try typing in 15. But it sounds like that's not the issue.

Run Drivertest.exe in the Mach3 folder and see what the results look like.

[RCaffin]

Hi Paul
You must (imho) have a seriously faulty installation of either Windows or Mach3, or a faulty CPU chip. What you are descrbing is not a Mach3 'feature'.

To explain very briefly: Windows is a time-share system, and can NOT handle a real time system like a CNC. What Art did was to find a way to push Windows XP down in interrupt priority and put his driver at higher priority, so it could preempt the Windows CLOCK. When you are running Mach3, it is Mach3 which is driving the PC, and Windows XP just fills in the gaps (so to speak). It was a really cunning concept.

If the Mach3 LPT driver is not issuing pulses at the right speed, something has pranged (is pranging) the Mach3 driver. I don't know what, but it is probably either an aberrant CPU chip or some other SW you have on the machine.

Can you run the Driver Test program for half an hour and see what it does?

NB: Art could do this with WXP as it did not prevent the installation of such interesting drivers. Later versions of Windows do not permit you to install such drivers, so you need to use an external pulse engine such as the ESS with them. (With the possible exception of Darwin: I don't know what he did there.)

Cheers
Roger

[adam_m]

Thanks Gerry, exactly what I was looking for.

Adam,

Find this block of code, and change this line.


Right now it moves 2x the probe diameter.
You can replace "2*ProbeD" with a value, like 1.5.
Code "G0 Y" & 1.5 + Clearance

There are 4 corner macros, M905-M908.

[paulcc]

It goes to 15. Try typing in 15. But it sounds like that's not the issue.

Run Drivertest.exe in the Mach3 folder and see what the results look like.

I did get the scope on the LPT port and confirmed that the step pulses are the issue. Direction acts fine. Results of the Driver Test:
Attachment 353456

[paulcc]

Roger,

Great explanation of the Mach3 LPT driver. It could be as you say, but I reinstalled the driver 3 days ago after a fresh install of -062 version of Mach3. See results of the driver test I sent to Gerry. If there is anything there that you see as hinky, let me know.

Thanks!

Paul

[ger21]

I did get the scope on the LPT port and confirmed that the step pulses are the issue.

Are you checking them right at the port?
And what exactly is the issue? Is it not sending pulses?
My understanding of Mach3 is that if the DRO's are correct, then the correct steps are being sent. Whether your seeing them or not is a different situation.


I can't really see in the pic, but in the Drivertest, is the pulses per second 25200? If so, then the driver test looks OK.

There are some PC's that just will not work with Mach3, but I'd expect very poor drivertest results if that were the case.

[RCaffin]

Hi Paul

Driver Test looks OK, but how long had the program been running for? If Mach3 is 'dying' after 1/2 hr but not always immediately, then you need to leave the DT running for at least that long as well.

Thing is, Mach3 does not do this for 99.9% of users. My feeling is that it must therefore be something other than the Mach3 SW - possibly associated with the PC hardware. Desperate measures to be sure, but can you find a different box to run it on? Even an old retired WXP box?

Cheers
Roger