[oly2brf5]

I've had a bit of a problem with my Tormach yesterday in that twice it has gone to positions that are unrelated to the numbers in the G-code. The machine has been working pretty well so far, 12 hours a day for several weeks. I have had all the usual boo-boos, mostly finger trouble on my part, but this is the first time it doesn't seem to have followed the G-code. I've already successfully made four of the part in question, so I don't think there's anything wrong with the code. The numbers in X, Y, Z boxes on the computer screen seem to agree with where the tool actually is, it just isn't where it should be. I might admit to the fact that I have been running unreferenced. Also, when the machine had the first problem it had been powered up for over 6 hours. A shut down seemed to cure the problem; the second occurence was after another 5 or so hours. When I spoke to Tormach a few days ago on another matter they did suggest if the system was powered up for a long periods it may increase the chance of a software glitch. I should say I'm not using a Tormach supplied computer. How the PC has been reformatted and a minimal XP version installed. The PC only runs Mach3, no IE, no Firefox, no internet or network connections. I don't even store my G-code files on it.

I do have a suspicion that the limit switches are not working correctly as I have recently had one crash where I was a bit surprised that the limit switch didn't stop the motion. First thing to do this morning is to clean and check all the limit switches and reference the machine.

Any other suggestions gratefully received.

Regards,

Andrew

[LeeWay]

I have one computer that runs Vista. Sometimes if it sits idol for awhile, it won't like jumping right into a cycle. I first hit the reset button on the screen to alert the computer that someone is about to fool with it. Then hit reset again and load gcode as normal. This procedure has stopped a few gremlins I had in the past with that particular computer.

[MarkWink]

When it's "off" - is it all axis or just one?

How far is it off (miss steps - or truly gone a muck)?

Jog the machine with a hand on the table - you can feel and hear missed steps.

I leave the machine on all the time without a problem, although the computer needs rebooted once in awhile - "I'm a PC".

[oly2brf5]

Checked the limit switches, voltages in the cabinet and a few wires this morning, everything looks fine. So far the machine seems to be running exactly as expected.

To answer a few questions:

Both the X and Y axes were off

Long way off, 50mm in X and 20mm in Y

Jogging by hand is spot on, very smooth, no unusual noises

Referencing by hand and jogging across the part was within 0.01mm over 300mm

The really odd thing is the thing went too far yesterday; I can think of lots of mechanical reasons for losing steps, but it's more difficult to think of a mechanical reason for gaining steps. I suspect it's a PC or Tormach control or software issue, or finger trouble on my part. The second time I had just had a TTS collet come adrift and had hit STOP; which I now gather is not a good idea. Should have used PAUSE.

Next stage is to run the program in 'air' until it gets to the toolchange it failed at last time and then set the Z so it starts cutting metal again.

Regards,

Andrew

[saabaero]

You mentioned about not referencing your machine. I used to do the same thing but was having issues with my "Y" axis loosing position by (by random amounts) between .005" to .035". After I would run a short program it would consistently be out of position on the "Y" axis only when I returned and re-probed my origin point.

I checked the motor coupling, wiring, rebooted but nothing seemed to help. Then for the heck of it, I referenced the axes. After that the problem seemed to disappear. Coincidence maybe, but it was repetaably out of position prior to that.

My machine is still pretty new and I haven't run a lot of parts since but anymore I reference the axes and haven't seen the problem reoccur.

Yes, I know, it shouldn't have any effect, but...

[philbur]

I'm no expert but my understanding is that the control system needs a machine reference as all the calculations are done according to machine reference not the user defined part reference. Where the machine gets these references from if you don't assign them I don't know. Possibly they are arbitrary. If one of these arbitrary references are within you part reference envelope then the machine will get into negative number calculations, which it may not be very happy with.

The manual makes it very clear that setting machine reference is important although it is not exactly clear why.

Just a thought from a hack
Phil

I might admit to the fact that I have been running unreferenced.

Regards,

Andrew

[LeeWay]

I never use machine coordinates at all. Not yet anyway., When I start having tooling offsets and things like that, then I might have to start using that and home switches.
If you have servo motors, I think it is more important as well, so that you don't tear up a machine or motor. With steppers though, they are perfectly happy hitting a hard stop with no damage. On my mill, the home is always different depending on what kind of part or fixture I am using, so I have no switches on the table or Y axis. Only a limit at the top of Z.

I do understand the reasoning behind the machine coordinates, but if Mach 3 is setup not to use them at all, there should be no issues with it.

[RTP_Burnsville]

Did you by chance happen to use the MACH stop command in the middle of a program and then try to continue? I found that using stop and then attempting to continue results in where the machine thinks vs where it actually is can be greatly different. Using the pause and continue commands generally yields much better reults.

I always reference my machine before starting and have never had the issue other than what I explained above.

[mactec54]

Hi oly2b2f5

I'm not sure the reason you would not reference/HOME the machine before you start
this should always be done (on every start up) or you will crash the machine as you have done, Once the machine has been homed out then the limit switches & soft limits will work as they should (if Tormach is using soft limits it has to homed for them to work)

If you don't home the machine at start up then it will not know were it is at Tormach should of told you this when you were talking to them

Once the machine has been homed then you set your work offset (X0Y0) & then your tool offset then you are ready to cut

[Don Clement]

And why don't you reference your machine? Alway the first thing I do is reference the machine and I don't have the strange problems you are having.

[LeeWay]

If you aren't using machine coordinates, Mach 3 opens up at home. If you have to move around to find your zero's, which I usually do, then once the dro's are zero'ed, thats it. It's home.

[saabaero]

I for one never used machine references because I saw no value to them for me. For one the Tormach doesn't use soft limits since they offer nothing over tripping a limit in the way of stopping speed without loosing position. Two, I don't find the limit switches accurate enough to use for repeating part reference consequently I always reference from the part or workpiece. Three, I don't have a tool changer. But in defense of this last one... Sprutcam adds a goto tool change position command into the toolpaths which shows as an error when the code is loaded without the machine being referenced. also, It is nice if the machine does return to a high enough Z to allow for changing the tool manually so having this command work is a plus.

Despite that, all I know is that is that, referencing the axes cured my issue with the Y axis loosing position. As I mentioned, it may just be coincidence but until someone can explain to me positively why it wouldn't have any effect I will continue to reference the machine for that reason alone.

I have designed and built several multi-axis trimming machines for manufacturing in the past and I have programmed them to automatically reference themselves to a "Home" position on startup and each time a program is changed. They have very accurate home/limit switches so the operator just installs the appropriate holding fixture for a given part and loads the correct program and the machine is ready to cut.

If referencing is important, I am surprised that the Tormach doesn't reference itself as part of the startup procedure. There can be a machine pause (for safety) so that machine motion doesn't start until the operator either accepts of declines the homing/referencing step.

[LeeWay]

There are many reasons that you would want to use machine coordinates. One reason is when you have a glitch or just need to shut down in mid cycle somewhere, if machine coordinates are used, then Mach 3 should open back up in the same area with the same dro values and maintain it ref'ed points. You certainly can't do that if you don't use machine coor.

I do use offsets from time to time, but that gets pretty confusing as well without a ref. home.

If I can find and install some decent limit's, then I may start using machine coordinates.
It would be extremely beneficial on my router that maintains the same origin for all my parts, but I can see where it might be beneficial even on my mill. Though home positions vary quite a bit according to the fixture I am using. Most of my fixtures are pinned so they would maintain the same offset each time.

[saabaero]

Yes, LeeWay... The key would be to have accurate limit switches. Otherwise machine coordinates are of limited value even with a machine shutdown during mid cycle.

I think one of my next projects will be to install reed or proximity sensors.

[Don Clement]

I find the limit switches have a limited accuracy of +-0.002". If the highest accuracy is needed then after referencing I calibrate using my #1 TDI tool and edge finder to obtain better than what the stock limit switch has. I would suspect that in addition to better limit switches a new referencing algorithm would be needed for better accuracy than +-0.002".

[mayhugh1]

Phil may have a good point for referencing the machine from a software perspective.
I think it is also a good idea, mechanically, for the machine to visit and oil the extremes of its motion as often as possible. Most of the machine wear is going to happen in the center of the envelope where the machine is most often used and eventually you are going to need to tighten up the gibs to adjust for wear in that area. If no wear, not even initial run-in wear, is ever allowed to happen at the extremes then after that gib adjustment you may be so tight at those extremes that when you do have to go there for some reason you might see lost steps. I always reference my machine on power-up and hit the one-shot oiler at the same time. I then hit the oiler again once more before jogging back toward the work envelope.
In answer to your question about the mysterious loss of position there are a few things to think about. Never use the STOP button to pause a program. You have to use the PAUSE button. PAUSE causes Mach to stop all motion but in a controlled manner using the manufacturer's deceleration parameters in the config file. STOP tells Mach to 'stop now' ignoring any deceleration constraints and any axis in motion at the time of the STOP will likely lose steps. That said, I believe there are known possible issues with any feedhold operation in our version of Mach. They can be consistently demonstrated in the lathe code and others have reported occasional problems in the mill code. I think they were addressed by the Mach authors in later versions of Mach but it must be a difficult problem to solve because I still see occasional problems reported even in the latest version. So, use feedhold with care. There are also occasional problems with 'Run from here'. Again the story seems to be the same as for feedhold. Use with care.
You sound like you greatly reduced the chances of an interfering application. I have also; but once in the three years that I've been using my machine I, too, saw an incorrect move that gouged a part that had some 5 hours of maching in it. I was sure it was a postprocessor issue and spent many hours trying to figure it out but could see no reason for it. After giving up, I made 4 more identical parts using the exact code without reboot or restarting Mach and saw no further problems. Go figure.
If none of the above seems to apply, I would suggest going through the machine and tightening all the screw clamps holding all the control signal wires especially those on the controller board and the stepper drivers. I would also double check (and change if you happen to have a spare) the parallel port cable between the computer and the machine. A noise source that some have seen is an inadvertent grounding of the shell of the parallel port cable to the machine chassis. It is easy to check - just make sure there is adequate clearance. If you are sure the limit switch that didn't seem to function properly is, itself, OK, then I would assume a commonality between the missed limit indication and the incorrect axis indication. (Go to the diagnostic screen and hand trigger the switch(s) many times making sure the led flashes as it should everytime.
Is the axis position problem always on the same axis or is more than one axis involved? Knowing this should might help to localize the problem. - Terry

[btu44]

I too was having trouble with my limit switches. Mostly the X axis switch would get gummed up and get held down.

My fix was to purchase 3 high quality switches (I don't care about the lower Z switch) from Digikey.com (part # Z2729-ND). These are fully sealed switches that have slightly more spring pressure but are a little larger. So the X axis switch needed to be repositioned to the left edge of the table slide.

The benifits I have noticed is the X switch being further from the major coolant dribble, it stays cleaner. I also did over 20 re-home referance to G54 measurement tests and they never deviated more than 3 tenth's. The stock switches were over a half a thousands.

[oly2brf5]

First, thanks for all the replies; they have certainly given me a few things to think about.

I never referenced the machine in the past because I didn't realise I was supposed to. I've made a couple of hundred parts of about twenty different designs in the last few weeks without seeing this particular problem. Plenty of other problems, but all down to me! Having said that, I did wonder why the computer displayed readout varied a few thou against the part from day to day on start up, as mentioned by a previous responder.

To answer another question, yes, I had hit STOP before the machine went AWOL. Won't do that again, I'll use PAUSE.

So, what have I done in the last day or so? Last night I referenced the machine and re-ran the code on the old part, absolutely no problems. Ran a complete new part, also with no problems.

This morning went to reference the machine and the X axis switch didn't work. Took it apart, cleaned it and hey presto, it works again. Started on a new part and promptly badgered a 16mm rippa mill. Re-referenced to the part and cut air until the next tool change, all apparently fine. After the tool change the tool took off to the middle distance; the same problem. Having shut everything down and restarted everything worked fine and continued to do so for the next eight hours.

The conclusion I reach is that the problems I have been seeing are caused by finger trouble on my part rather than an inherent problem with the machine. I am running on quite a high voltage (246.4V at the moment) but in my experience weird behaviour caused by genuine glitches are fairly rare. In one sense the conclusion makes me happy. I can sort out my lack of knowledge, it's much more difficult to track down intermittent faults.

So, I suppose I need to rigourously reference the machine each time I turn it on and see how things go.

Thanks for the help everybody.

Regards,

Andrew

[oly2brf5]

The machine has run flawlessly for over 11 hours today, largely unattended, except for changing parts and a check every so often to make sure the cutter hadn't broken, after all it's only 2mm in diameter. The machine was properly referenced this morning and the parts indicated individually. So I am now convinced that my problems of the other day were finger trouble on my part, in particular not referencing the machine.

I've certainly been impressed with the machine and its performance today.

Best Regards,

Andrew

[oly2brf5]

After further investigation it turns out the problem was nothing to do with any of the above. The machine was actually going into incremental mode after a toolchange, albeit only occasionally. Tormach had a look at my G code and cannot see anything amiss. As a temporary cure I've altered the postprocessor to put a G90 into the code after every tool change. Longer term I've ordered the Tormach machine controller as the suspicion is that the non-Tormach PC I'm using is having trouble running the VB scripts associated with tool changes.

As an aside I ordered the Tormach controller, plus the load meter and upgraded door latch, on a Tuesday and it was delivered to me in the UK on the Thursday; delivery charge was about $130, very good service in my opinion. Note that the delivery charge was significantly cheaper than that quoted by going through online shopping on the Tormach website.

Regards,

Andrew