However, the Trak system at one of my clients never requires homing, and both a friend’s AHHA system as well as his modern Akira-Seki VMC don't require homing after e-stop or limit events.

Naturally, Improved confidence in my homing repeatability will help for safety as I'd rather not second guess the ramifications of hitting the e-stop.

I think the key word here is 'require', what's required and what the best operational procedure is are sometimes two different things, and to some extent its also a subjective thing.

And, yes. I do occasionally jog in the wrong direction and hit the limits as my tool change position is at machine 0,0,0

You should try using soft-limits.  Mach will decelerate as you approach the soft limit when jogging.  Works great.

Also, for servo systems, an uncontrolled e-stop is downright unsafe. I made a custom 1800IPM gantry system for a client this year using a National Instruments motion card, servomotors and Gecko G340 drivers. Controlled motion on e-stop and soft limit events were a requirement. Suddenly stopping the pulse stream resulted in a drive error/shut-down allowing the carriage to freewheel and do (more) damage. (I wrote my own g-code CAM software in LabView for this project - - a far cry from Mach in features but not bad, I think).

You right, safety is the key issue.  Many machines also employ axis brakes as a safety feature.  What if the control or drive is failing and when you hit e-stop you may not be able to safely decelerate.    The old Bridgeport VMC I'm working on now, has axis brakes and the Galil motion control card will allow you to decelerate on E-stop or to go dead stop.  I'm considering trying to employ a rapid deceleration with the Galil , flowed by a short time delay before the braking relay (which also removed power to drives) kicks in.  If I have to choose, I'll go with the brakes.

Why can’t the index pulse of an encoder be fed in as a Mach home switch?

Right, the roigersmachine error detection board is a great idea for a stepper system with encoder or glass scale feedback.

Why can’t the index pulse of an encoder be fed in as a Mach home switch?

Does anyone know if Mach's encoder DROs are consistent across e-stops and limit events?

To be accurate the the controller needs to see the edge of the index pulse, (edge triggerd).  There is no guarantee that all parallel port inputs will latch at the same time so trying to edge trigger on a fast signal, w.r.t another input would be at best, tough.  Also the parallel port can start out in an unknown state, if you are making use of the 'charge-pump' you will have the ability to disable the drives when Mach is not actively driving the parallel port.  On my little DynaMill I can E-Stop from a stop and restart Mach and never notice the difference.  If it was moving I would not take the chance.  On the Bridgeport conversion I have the luxury of the Galil with closed loop control.  I still would home after an E-stop though.

Does anyone know if Mach's encoder DROs are consistent across e-stops and limit events?

In my experience, I think so.  Still, the question is IMHO, should you trust it?  Take a look at the G100 and Galil motion control boards if you have needs that go beyond what a few parallel ports will do. 

Quote

Also, for servo systems, an uncontrolled e-stop is downright unsafe. I made a custom 1800IPM gantry system for a client this year using a National Instruments motion card, servomotors and Gecko G340 drivers. Controlled motion on e-stop and soft limit events were a requirement. Suddenly stopping the pulse stream resulted in a drive error/shut-down allowing the carriage to freewheel and do (more) damage. (I wrote my own g-code CAM software in LabView for this project - - a far cry from Mach in features but not bad, I think).

Ok so your typical home-build machine doesn’t do 1800IPM. But the speeds are getting to the point where controlled stops are going to be an important requirement (especially w/ the G100).

I think most controll the motion on e-stops and limits by using enable pins to fault or disable the drives.

...

Brett

Er, ok. Rather my error condition was an unintentional side effect of stopping the pulse strem. Ideal drives would handle instantanious change in acceleration (not like I would actually expect this).

...Take a look at the G100 and Galil motion control boards if you have needs that go beyond what a few parallel ports will do.

Yup. Doing this now as I'm upgrading my BP to AC drives (good e-bay score on some Copley drives and a line on some motors.) & friends w/ Rick who makes the Pixie board.

To be accurate the the controller needs to see the edge of the index pulse, (edge triggerd).  There is no guarantee that all parallel port inputs will latch at the same time so trying to edge trigger on a fast signal, w.r.t another input would be at best, tough.

Right, So this is an issue with timing? Hypothetically, if the system were homing at a sufficienlty slow speed, the index pulse can be used as an index pulse. Home within +/- 1 pulse Right? (assuming a little mach scripting to tweak the homing algorithm)

Are these correct assumptions?

-Ted

From what I am reading that you wrote, I dont think the homing accurcy is your complaint. I think what you want is after a crash/E-stop condition, you want to be able to restart the program from where the problem occured without losing your position. You could re-home, BUT, for what you want, you would need to have "Absolute" Encouders.

Exactly!

Because it's really hard to compare apples to oranges I've tended to talk in terms of "systems."

There are systems with many types and combinations of drives, encoders and controllers. Some drives take step and dir, other drives take high level commands. Some encoders are quadrature, others are absolute. Some controllers output step and dir others close control loops.

One kind of absolute encoder system might be:
A "decoder module" of dedicated hardware within a controller that keeps tracks of encoder pulses. (Galil ?). This module is isolated from error states experienced by other modules within the controller.

Another kind of absolute encoder system could be:
- A servo drive that is responsible for keeping track of encoder pulses and erroring if it can't keep up with command pulses.
  (servos + Gecko G320,  or stepper driver + encoders + rogersmachien.net encoder interface).
- And a controller that knows exactly how many pulses it's sent, even during error conditions. (AHHA did this, I think. Is this Mach?)

Does the interrupt that stops Mach's motion engine during e-stop and limit also interrupt the DRO functions?

If "No" then Mach has the CAPACITY to be an absolute encoder system.
If "Yes" then regardless of what hardware I add, I'm still homing every time I hit a wrong button!

-Ted

Ps. IMHO it doesn't matter what hardware I add (Roger's encoder interface included). This would only INCREASE the numer of error states in which I'd wind up re-homing the machine (obvious logic error ignored)

I have 2 retrofitted bridgeports.  One runs the Mach controller and one runs AHHA! 

The Mach controller dead stops the servo's when you hit the e-stop.  If the servo's are in motion, more than not, they will fault because they cannot de-accelerate fast enough, it's a saftey thing.

The AHHA! contoller is actually running a stepper system, and the way the contoller is set-up right now, it de-accelerates the steppers when the e-stop is pushed, no loss of position.  The controller can be made to dead stop the system when the e-stop is activated, it's in the parameters somewhere, but as you know AHHA! is not interactive as Mach 3 is, I'd have to get the book out. 

I'm also guilt of using the e-stop to stop the machine.  On the AHHA! system, I use the e-stop if I want to clean the chips off a drill.  Can't do that with Mach.  I have a Logitol series 3 pendant and use the "pause" button to stop the mach 3 controller, works great.

As for the homeing, you get out what you put in.  Garbage mechanical switch's are good for limits, not homeing.  They don't work for crap on either of my machines.  They get you to within .005 in most cases.  If I have to e-stop the Mach controller, I re-home the machine, then re-indicate or edgefind and reset my work coordinates.  Pain in the ass, yes.......  And when I shut down the Mach controlled machine and power back up, I always reset zero.  The servo's tend to jump a bit when they are powered up which sometimes throws the position a couple of thousands.  The AHHA! stepper machine keeps it's position for as long as you don't stall the steppers, even after power down and restart.  But the AHHA! contoller is no comparison to Mach 3.

I don't think it's going to matter what contoller you use if your limit switch's aren't accurate.  Try inductive switch's or using the reference from the encoders.

Michael 

Erichtg
 To my mind yo are talking about the E-Stop as if it were the FeedHold. The E-Stop in my opinion should bring all Axis to an abrupt stop as it is used as a last resort. As has been said if you have high speed low friction axis which will move a considerable distance after power has been removed then you should equip these axis with brakes.
 Seems to me what you are wanting is the Feed Hold, if this is so then you can re design your screen to make the Hold button more prominant and can change its name to Stop if you wish. You can also wire up physical buttons and have one as a feedhold that you use in the situations you describe above
 As has been said, from your description of your problems it would seem that the soft limits would be of great assistance to you. Set them up and most of your problems will be gone.

Hood

I'm not certain if the encoder dros are consistent across an e-stop. I wouldn't think so. Maybe someone else will reply with this info.

The following comment from Rogersmachine.net sounds pretty promising.

  Update as of 9-15-05.  Using the encoder, closed loop board on one Bridgeport for five months
  and for one month on another. Have not spoiled any work-pieces due to loss of machine
  position.  On occasion have over-driven an axis and the interface did its job and halted
  everything until the positioning was corrected. Wouldn't assemble a control without one.

Are they using the Encoder feedback to reset the machine DRO after event's that would normally require re-homing a machine?

Are the encoder DRO's consistent across error/reset events?

I have read the post, but , I think, most are loosing the idea of Mach3 in the first place - Convert your PC to a CNC controller for $***.
I am quite sure that the idea was just that - your PC becomes a CNC controller with the addition of a few, cheap bits and pieces - in the same way that my other computer is now performing like a Wurlitzer theatre organ - with the addition of jOrgan software.

The jOrgan cost me £600 against a price of several thousand in the shops. Mach 3 CNC has cost me about £200 against £4000 - £5000 for a professional machine.

In return I have a CNC controlled Lathe/Mill. I have just run off 16 handrails stanchions, and cut 11 window openings in the side of a miniature railway locomotive, and the results were acceptable. I won't say perfect, but I put that down to my expertise, which will improve. I keep the speeds of the machine down to within the tolerances I know my machine will accept, and I find it accurate.

I will agree with those on the forum who say that your limit switches (or soft limits) should never be hit, because that implies some error.
(Since I have never hit them (because I don't have any), I don't know the answer - but presumably when Mach 3 reads the G Code, it will not start up if any position is outside the limits set)

On the lathe, the example given, in the tutorials, on how to position a workpiece is simple and accurate. My method is similar in that I tell the tool to go to a set position, and set the workpiece to touch it which amounts to the same thing and is perfectly accurate.

With the mill, then the start place is somewhat up in the air. If you are milling a blank sheet of material, where you start seems not to matter all that much. If you are milling one pattern on another then the important thing is that the mill is in the correct position in relation to the work, not the machine - so I would have though it essential that some location device on the workpiece would be accurate. If I drill a hole in the workpiece - and the cutter tool will locate in that hole, then I know the cutter is accurately aligned with the work.

YES - it would be fine to have a perfect machine that always knew exactly where it was, in relation to all the other things around it and all you had to do was to throw material at it, which would align perfectly first time, and then the machine would cut it at the speed of light.
ALL FOR $200 - I think not.

Mach 3 is a fine program and I thank Artsoft for bringing me the pleasure of having a CNC contolled machine. I have no doubt that there are limitations, although with my little experience I haven't found it yet. If you need all these gadgets attaching to your machine, go out and spend the money, but I am quite sure that you will be able to work round them, with acceptable results.

I must admit I have though long and hard about putting an accurate homing device on my machine - but then I have to make sure the work is in exactly the right position to benefit from that. I might as well put the tool in such a position that I line the work up to the tool - it comes out the same in the end.

I don't think that any of his problems are with the mach program or using Mach 3 as a controller.  I think he just needs to accept the fact that the E-stop is going to dead stop the motors, they will lose position, and his limit swith's are junk which have nothing at all to do with Mach 3.
Michael