Let's try and start over.



I have removed the ATZ macro and all related items.

This is the same download of Mach that I have installed on three computers.

The computer I am using now is a fresh rebuilt PC, there is no internet connections or other programs running other XP and Mach. This is also a fresh install of Mach on this PC.

There is nothing else running in the garage or house electrically that I know of that is different from a week, month or six months ago.



Now here is what is happening:

Usually I experience a problem (about 90% of the time) after a tool change. The DROs will read whatever the related G Code states. I will change the tool and either manually or using the ATZ feature zero the Z axis. The Z DRO will read 1.000 if I use the ATZ feature. I then push Cycle Start and I can tell instantly that the toolpath is headed in the wrong direction. I have never looked to see if the display screen shows the toolpath in the wrong location. The DROs will read where the tool is sitting at the time of that I stopped the program run. What I do know is that the 0,0 is NOT wher it should be. This is where the problem is (or so I think). If I understand this correctly every machine move is related to an origin, it doesn't have to be 0,0, but there has to be a common known location to base every move from.

This is why I am obsessed with the origin changing. Now the DROs do not change. It seems like some how the origin location is changed in memory or wherever Mach keeps it. Now this doesn't happen every single time I run a part. On Tuesday I ran for over 10 hours with no troubles, this was two parts, each about 4.5 hours each. I started a new part and everything was going fine until I realized that I needed to make a programming change. I stopped Mach, pushed Go To Zero, Closed the G Code. I then made my programming change and loaded my revised G Code. I pushed Cycle Start and the program was running fine. Then I heard the cutter getting bogged down and it then took the huge pass that you can see in my photos that I posted. There was no tool change when this happed. I have since removed the ATZ macros and tryed to run the same part. The first time I ran the part the drilling cycle ran for about four holes, on the fifth hole the drill bit was drug acrossed the work piece instead of being .25 safe Z height, I stopped the program run. I tried a second piece after resetting the DROs and Zeroing the Z axis. This time the drill bit plunged quickly into the work piece and I saw the DRO change and it was about .625 below what the original Z height.

I haven't run anything since, I did try to run my Driver Test and I always get Puling Too Fast. I have run the Driver Test with Mach running and without, always the same results.

What I meant is the DROs read what the G Code is, then when the machine starts to move the DROs change, but the DROs do not try to catch up like if you had feedback. They are reading where the tool bit is. There is no consisteny with what is happening. Sometime using the ATZ feature causes a problem, sometimes it doesn't. Sometimes there is a problem after the second tool change, sometimes it is after the fifth tool change. I watch very carefully to try and remember what was happening at the time there is a problem. But there is no consistency so one time it is this way and another time it may be a different scenario, but there is some overlap or similiarities. 

I am getting confused, one minute the DROs are the same the next they are moving.
Really I think you have to be very methodical in noting down what you see and describing it when things go wrong. What you need to note is where the DRO and Toolpath say the axis is and whether or not it is actually there. Forget the return to zero as all that is telling you is you have lost position, we need to try and work out why you have lost position.

As for the pulsing too fast, was Mach running at the time?
Hood

Do you have home switches on the machine?
Hood

This thread is like a deja vu for me.  

It seems I am suffering from a very similar trouble also on my machine: After performing a toolchange, sometimes something goes wrong.
The crazy thing is: I was (and I still am) not able to recognize any pattern in the accidential loss of position, except that it happens after tool change, when pressing "Cycle start" to perform Auto-tool-zero.

-The machine is equipped with home switches on all axis' and tool height sensor.

And here is, what should happen:

G-Code runs
Tool change commanded in G-Code
Z, and then X and Y are moved to a convenient tool change position (by M6Start-script)
---
   Manual tool change
---
Home Z axis
go 20mm above tool height sensor
then do the whole referencing stuff...
(In fact, this doesn't matter, because it seems, that the "M6End-Script is not even executed, or something bad happens before mach3 can execute the script..)

... and this happens after Manual tool change

maybe an unexpected movement to somewhere in the center of the stock, 
maybe there appears the "preparation move" dialog before the unexpected movement will take place... 
What I can state:
- The Z Axis is homed by my M6End script before the tool leght is measured, so, if this homing is not performed, I KNOW, that the movement is NOT caused by my script
- This "terrible accident" happens SOMETIMES not ALWAYS, whenever:
  - G-Code remains absolutely unchanged (same part)
  - XML remains absolutely unchanged
  - NO ONE button is pressed during program execution

---> This is the whole story...

This, I feel, is a real quirk, and I know for sure, it will be very hard to find and repair what is causing this trouble.
(maybe some race-condition in mach 3 code, or some other timing problem which also might not be reproducable on any hardware...)

After spending lots of working hours in researching this damned mis-behaviour, I decided to keep my hand just over the emergency-off after tool change and wait for the release of Mach3 V4... (by the way: when...??)

regards,
Konrad

No home switches, no limit switches

No home switches, no limit switches

So, it can be stated that electric noise does NOT cause the trouble we have  ;-)

(In deed, I also made test runs with de-activated switches to isolate "noise" from the possible causes...)

Ok do you ever home the machine by pressing the Ref All button?
Reason I ask is because you were saying about the zero position and about how Mach must reference to somewhere. Well what Mach references to is the  machine coordinates and these are set by homing and the offset coordinates that you use (G54, G55 etc) all reference to them.
So just wondering if this could be a problem, now on a rotary axis I could see it being an issue, especially if you only rotate one way as the number will get so big and may roll over so Mach may have issues. With a linear axis it should not get so big but it may do if you are always resetting your offset zero and it just happens to be that you always move the same way when setting the zero.

As said this is just a stab in the dark but as a test how about moving your machine so the tool is fully negative in X and Y and fully positive in Z (table fully right and fully towards column and z fully up)_and then press Ref All, you can then move to where you want your offset zero to be and zero each axis and then see if there are still issues. As said its a long shot but the problem is a very weird one so everything should be considered.

If it does happen again make sure you look at the DROs and also the Toolpath and see whether they show that the Mach knows where the cutter is, ie it shows it going wild, or if they show that it is where it should be but obviously is not.
Hood

Ok do you ever home the machine by pressing the Ref All button?

For my machine, I can confirm that homing is regularly done by "ref all" and home switches. So, my machine coordinates always refer to the same mechanical position reliably...

I also confirmed (by watching DROs) that MACHINE coordinates remain correct when the big accident (TM) occurs. i.e. the machine does NOT get out of reference by itself (of course, after hitting the stock and trashing the bit, everything stalls and is de-referenced)

Next step will be to run programmes from the diagnostic screen and check offsets and so on...

Konrad
so your DROs and Toolpath show where the tool is supposed to be but its not?
Hood