Machsupport Forum

Mach Discussion => General Mach Discussion => Topic started by: Erichtg on August 20, 2007, 12:35:00 AM

Title: Accurate homing
Post by: Erichtg on August 20, 2007, 12:35:00 AM

Ok I've started a new topic as I bogged the last one down in tangents.

I'd like to brainstorm methods to enable Mach to accurately maintain home position. I believe this is a noble cause. Doing so would lower the bar for accurate custom-built-machines even more. Also, I like Mach and would like to keep using it. Currently my lack in confidence at maintaining an accurate home is bringing me very close to abandoning Mach. This is because e-stop and Limit events are very common, and after which Mach requires re-homing.

Requirement: The only time a CAM system (without absolute positioning) should require homing is at power up, after a motor drive failure, or when the operator decides it's necessary (after a crash). 

I think there are three VIABLE philosophies one could adopt when building a system:
 1) Continuous absolute feedback. (Many (most all?) modern professional systems do this)
      Homing mechanism: n/a
 2) Continuous incremental feedback.
      Homing mechanism: Accurate as the system builder wants it to be (mechanical switch, encoder index pulse...)
 3) Open loop system. (risk of error decreases as the system is driven at a smaller % of max operating conditions)
      Homing mechanism: same as #2 

Mach doesn't currently support any of these options. I'm not putting Mach in catagory #3 because because #3 systems have been around for at least 10+ years (pretty sure 30+ years). AHHA systems, for example, don't loose home with e-stop or limit events. Now that I think about it, from my experience, Mach is the ONLY system I've seen with the capability to control professional systems that DOES require homing after an e-stop or limit event.

Re-homing is risky and takes time.
In opinion, e-stop and limit events are so common that they should not be allowed to compromise work quality or productivity.


Now to the actual brainstorming...


So there are really two homing issue that I've dealt with while building my own machine: Mach's action during error states (discussed above), and accurate homing mechanisms. The more accurate the homing mechanism is, the less risky Mach's behavior becomes.

So I can only try to make an accurate homing mechanism while I wait and hope that Mach changes the way it handles e-stops and limits differently.

If the system has encoder feedback then Mach has the capacity to be close to #2 (above), correct?
 - Wire the encoders into Mach for DRO feeback
 - If servo driven, then the servo driver signals Mach in the case of a drive error.
 - If using steppers + encoders then use a board like the one sold by rogersmachine.net to signal drive error.
 - Home machine.
 - Any time after homing, one could then copy the encoder DRO values to the machine DRO fields.
(Are e-stops and limit events interrupts? --Are encoder DRO values guaranteed consistent across these events?)

Accurate homing. There are few mechanical switches that I'd trust. Even if an optical switch is fully enclosed, a discontinuous mechanical interface still has the capacity to get crud caught in it.

The best way to home IMHO is to use and encoders index pulse. The board from http://www.cncbuildingblocks.com/homeindex.html looks like a great solution for interfacing index pulses with Mach. It hides the home signal from Mach until it found the index pulse by generating it's own pulses. (Not sure I'd use this system with glass scales as I'm not certain how it would handle backlash).

I'm still not clear why Mach can't "see" an index pulse (it shouldn't be any harder than an encoder pulse).

Comments? Any more ideas?

-Ted

Title: Re: Accurate homing
Post by: Chaoticone on August 20, 2007, 09:18:27 AM

Hey Eric,

Quote

Currently my lack in confidence at maintaining an accurate home is bringing me very close to abandoning Mach. This is because e-stop and Limit events are very common, and after which Mach requires re-homing.

Why are e-stop and limit events very common? I run for hours on end with no e-stop or limit events. I would guess that most users do.

Quote

1) Continuous absolute feedback. (Many (most all?) modern professional systems do this)
      Homing mechanism: n/a

Statement 1 is not true. Most all modern professional systems do use a homing mechanism. This is how they work. In the homing routine, they move until they see the switch, almost allways Prox. switches. Once they see the switch then they start looking for the index pulse of the encoder.

Quote

Mach doesn't currently support any of these options. I'm not putting Mach in catagory #3 because because #3 systems have been around for at least 10+ years (pretty sure 30+ years). AHHA systems, for example, don't loose home with e-stop or limit events. Now that I think about it, from my experience, Mach is the ONLY system I've seen with the capability to control professional systems that DOES require homing after an e-stop or limit event.

Really? Hmmmmmm, I have been doing CNC maint. for 13 years on large professional systems, Okuma Howa, LaBlond, Makino, Doosan, Mori Seiki to name a few. Any time there is a limit trigger or e-stop, you should re-refrence the machine before you try to continue. I have never heard anything else from any machine builder. Even the coustom built PLC based machines we have recommend this. I have had to spend many hours putting machines back together after a crash when the operator forgot this little step.

My machine homes accurately. Im not sure it would be closer if I used encoders and picked off of the index pulse. It's never been an issue for me as it will repeat, dead nuts using only prox switches reading the head of a screw on a stepper system. If yours doesn't, I think you have something in the system that is letting you down. I don't think it is Mach. Stranger things have happened I guess so keep us posted on your findings.

Brett

Title: Re: Accurate homing
Post by: Brian Barker on August 20, 2007, 10:19:45 AM

Have a look at the encoder board from Rogers machine.. I think it is what you are looking for.
thanks
Brian

Title: Re: Accurate homing
Post by: MikeHenry on August 20, 2007, 10:55:19 AM

FWIW, I'm using Mach2 with a Tormach CNC mill and other users report that it homes very accurately and repeatably, though I haven't tried to confirm that myself yet.  Assuming those claims are true it would suggest that even the lower end commercial CNC mills are capable of accurate homing.

Mike

Title: Re: Accurate homing
Post by: vmax549 on August 20, 2007, 12:11:40 PM

I think my oldest son said it best" POP, If you build your machine and program your code to the same level of accuracy and dependability that you WANT the software to maintain then you will rarely have trouble(;-) "

The Estop and limits are there for a last measure to HELP prevent damage to the operator and machine not save your project from disaster

ANY time you estop or limit stop a machine, and it does not matter WHO made it, you should  reference it back to home to verify that it is still accurate.

If you are running into situations that require constant estops then you need to whack the programer in the head(;-). If you are constantly hitting the limits then you need to whack the operator in the head(;-)

There IS a SOFTLIMITS you can set up that will HELP  prevent the limit crashes. Heck it will even show you the softlimit boundary on the screen when you load the code. If your part goes outside the limits the operator should see it. Can't ask too much more from Mach(;-)

HUM i'll have to test the estop and limits to see if MACH really looses position. I know I have estopped and resumed without loss of position.  I don't recall having tested the limits situation.

(;-) TP

Title: Re: Accurate homing
Post by: Jeff_Birt on August 20, 2007, 01:10:18 PM

Quote

Currently my lack in confidence at maintaining an accurate home is bringing me very close to abandoning Mach. This is because e-stop and Limit events are very common, and after which Mach requires re-homing.

I can understand your frustration, but I don't think you fully understood the problem before trying to develop a solution.  Starting at the beginning, e-stops and running into the limits should not be common events.  Both are there for the safety of the operator and machine.  When these events occur a control should shut down the motors, period.  The motors and driven mechanism WILL continue moving some unknown distance (dependant on velocity at the time of shutdown etc).  Again, an emergency event such as E-Stop or limit switch should not have occurred, even with incremental/absolute encoders in the system the control has no way of good way of knowing exactly where the machine is at.    The homing process ensures that the machine knows where its parts are at.  Even robots, which have very good absolute encoders, will home and look for an index pulse within a certain range of the home position.

Quote

Requirement: The only time a CAM system (without absolute positioning) should require homing is at power up, after a motor drive failure, or when the operator decides it's necessary (after a crash).

Again, E-stops and limit switches should not be common events.  If one of these events has occurred the operator may have no way of knowing if something was damaged in the incident or if the machine is still where it should be.  Even absolute encoders do not guarantee that you are really at a certain point, if the encoder or wiring is faulty you can get bogus readings to the control and the control will not know where you are at.  The homing process insures that the machine parts are physically in a known starting position.

So to get you off on the right foot here are two suggestions:

1) Figure out why E-Stops and limit events are common and fix it.  It could be a combination of your process and operator training.
2) Investigate the board from Rogers machine that Brian mentioned.  It combines the index pulse and limit sensor giving you a very accurate home.

Title: Re: Accurate homing
Post by: Erichtg on August 20, 2007, 07:33:19 PM

Ok Chaoticone, I was talking a little out of my A** there ;)

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.

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

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).

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?

-Ted

Title: Re: Accurate homing
Post by: Chaoticone on August 20, 2007, 08:39:22 PM

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.

I don't know if the index pulse of an encoder could be used as a home switch. I would think it would be possible with some VB codeing, not sure though.

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.

Brett

Title: Re: Accurate homing
Post by: poppabear on August 20, 2007, 08:40:08 PM

Erichtg,

    Eds boards, (from cncbuildingblocks.com), are most excellent. Your back doesnt effect the Homing process just the accurcy, (like any machine). My BP II, (retrofitted), can home repeatable in 0.0002.  I dont use glass scales, I just use the Encouders (with index), on the servos.  Really depending on whose drives/systems you run. I use ADC "Sure Servo" system. You can feed back all kinds of information to mach through the modbus, directly through the servos, or better throgh a pLC, both operational control, diag, and feedback. But that is getting off of the topic.

With Eds boards you homing accuracy, comes down to the mechanical accuracy of the axis.  The way his board works is, when your Home switch is hit, the board has the axis continue until it sees the "Index" pulse, then (and you set this by a binary counter swith bank), you set how many encouder counts you want the machine to back the other way, off of the switch, but it counts down from the index pulse. this value will vary depending on your ppr, and your drive screw/mech transmission ratio. Once it move the servo back off of the home switch, it tell mach it is hommed.

As far as parts are concerned, the are on spec.

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.  Newall makes some that you can read their serial output via a PLC convert that to a binary value and then send it into mach via modbus. But Brian or someone would have make a C++ plugin for this type of feed back to be usefull to mach, in which it would take this value as actual axis postion value.....

Currently though, you best bet would be Ed's board, (he now makes one with JUST the homing function), and figure out why you are crashing so much!!!  You might be better off Using Quantum, since it has a double S curve trajectory planner for accel/decell, and at the speeds your talking about, this might be a better option for you.

Scott

Title: Re: Accurate homing
Post by: vmax549 on August 20, 2007, 08:42:38 PM

There is a HUGE difference in STOP and Estop( or should be) THe Estop should kill all power to all drives in the event of a runaway situation(worst case) THat should allow the brakes to engage and stop the movement. You did install brakes for the high speed/ high inertia movement correct?

 In a true Estop situation it should fail safe. Never depend on the electronics alone to Estop the system. Your best friends  life may depend on it.

Stop means to come to a controlled stop. Maybe this is what you need to use instead of Estop for minor problems that need attention

If you set up the softlimits then MACH will not LET you get to the hard limits unless something is really wrong and then the limits should take over.

It might benifit you to move the tool change position away from the home position to prevent tripping the limit or use a return to position Mcode to auto return the machine back to the position before the tool change.

Just some thoughts (;-) TP

Title: Re: Accurate homing
Post by: Jeff_Birt on August 20, 2007, 09:01:56 PM

Quote

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.

Quote

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.

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).

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.

Quote

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.

Quote

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. 

Title: Re: Accurate homing
Post by: Erichtg on August 20, 2007, 10:21:26 PM

Quote from: Chaoticone on August 20, 2007, 08:39:22 PM

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).

Title: Re: Accurate homing
Post by: Erichtg on August 20, 2007, 10:30:01 PM

Quote from: Jeff_Birt on August 20, 2007, 09:01:56 PM

...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.

Title: Re: Accurate homing
Post by: Erichtg on August 20, 2007, 10:36:44 PM

Quote from: Jeff_Birt on August 20, 2007, 09:01:56 PM

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

Title: Re: Accurate homing
Post by: Erichtg on August 21, 2007, 12:09:19 AM

Quote from: poppabear on August 20, 2007, 08:40:08 PM

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)

Title: Re: Accurate homing
Post by: motorhead101 on August 21, 2007, 01:26:58 AM

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 

Title: Re: Accurate homing
Post by: Hood on August 21, 2007, 03:04:40 AM

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

Title: Re: Accurate homing
Post by: Erichtg on August 21, 2007, 03:29:30 AM

Quote from: Chaoticone on August 20, 2007, 08:39:22 PM

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?

Title: Re: Accurate homing
Post by: jimpinder on August 21, 2007, 04:46:49 AM

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.

Title: Re: Accurate homing
Post by: motorhead101 on August 21, 2007, 05:05:36 AM

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

Title: Re: Accurate homing
Post by: Erichtg on August 21, 2007, 01:02:59 PM

Yes, my limits are junk. No question there. E-stop halts the pulse stream cold and hard. No question there.

Does Mach have the capacity to do all I'd like it to do? That is the question.

To that end,
Does anyone know if the encoder DRO's are consistent across error/reset events?
(So far the consensus is "yes," they are consistent. Does anyone know for sure?)

Ps, And philosophically, Mach is not about getting what you pay for (a cheap controller). It's about lowering the barrier of entry for quality machine control.

-Ted

Title: Re: Accurate homing
Post by: vmax549 on August 21, 2007, 01:27:28 PM

OK so WHY do you use the ESTOP to stop the machine???  WHat you are saying doesn't make a whole lot of sense, please explain a little futher maybe we are missing something here. You can EASILY set mach up to do a controlled stop with a switch. You can call the switch anything you like even WHOA if you want.

Do your limit switches stop the machine when you hit them? Obviously they do or you would not be complaining about them(;-) They are not home switches they are limit switches. If you need accurate home switches install accurate home switches??????

Everything you have asked about is possible but you still refuse to adknowledge it????????

Ya might want to reread the part about building the "machine and program code" to be as dependable and reliable and accurate as you WANT the software to be(;-)

(;-) Are you sure you are not my youngest son hiding behind that screen name(;-)

(;-) TP

Title: Re: Accurate homing
Post by: Chaoticone on August 21, 2007, 02:12:00 PM

Quote

Does anyone know if the encoder DRO's are consistent across error/reset events?

Ted,
    I will find out the definitive answer ASAP and let you know.

Brett

Title: Re: Accurate homing
Post by: jimpinder on August 21, 2007, 02:19:30 PM

I  wasn't infering that Mach3 was a cheap controller - it has all the features of the professional systems I have seen - Fanuc being the leader. What I was saying is that the machines I have seen are way in advance of mine. They have feedback, proper limit switch systems etc etc. I saw one the other day with two chucks, that could pass the work from chuck to chuck. I haven't got that because I don't want to pay for it.

As far as I can see, the DRO's have no feedback (certainly using steppers). Logically they must therefore take their position from the pulses put out to the motor (try running the program without the miller connected - the DRO's still register) - they know how many pusles move the axis how far. BUT if the computer puts out a pulse which the motor misses - for what ever reason, then the DRO IS NO LONGER ACCURATE. As an alternative - if you press E-Stop - and the computer instantly ceases putting out pulses - yet the momentum of your system carries the motor over a few steps (4.8 to the thousanth of an inch on mine) then the DRO (which registers to 1/10th of a thousanth) can no longer be accurate. I suppose in theory if you belt the E-Stop at one end of travel, then belt the E-Stop at the other, the two could cancel each other out.

If you set up a key on your keyboard to stop travel - (I was going to suggest the space bar but this might not be feasable) - then that is quicker and easier to get to the trying to click a mouse on a screen icon. That would take care of E-Stop and cut out a lot of problems. If you set up your soft limits that should take up another problem (because you shouldn't bang your limit switches anyway).

The other question about homing - have you set up your homing as per the tutorials - and seen if it works. You can use your limit switches - because when homing the limit switch function is cut off - until the homing is complete - and then it resumes.

I think you have to do all you can before adding other bits and pieces to try to fix a problem that may not be there.
To my mind , keep it simple.

Title: Re: Accurate homing
Post by: Erichtg on August 21, 2007, 02:34:13 PM

Quote from: Chaoticone on August 21, 2007, 02:12:00 PM

Quote

Does anyone know if the encoder DRO's are consistent across error/reset events?

Ted,
    I will find out the definitive answer ASAP and let you know.

Brett

Thanks Brett,

For the record, I'm curious about both encoder feedback DROs as well as Machine XYZ DROs - - Does Mach keep track of exactly how many pulses were sent or received across error/reset events?

-Ted
 

Title: Re: Accurate homing
Post by: Chaoticone on August 21, 2007, 02:38:03 PM

I understand what you are trying to do, will let you know ASAP.

Brett

Title: Re: Accurate homing
Post by: Chaoticone on August 21, 2007, 03:01:05 PM

Yup. Mach always knows and tracks the number of pulses. The only reason position is ever lost is if the motor itself cannot stop that fast. Another way to test what you are trying to accomplish I think,  hook up an encoder, assign it a DRO, place in e-stop and see if the encoder dro updates as you turn it. I don't think you need to test it though. That answer came from one of the immortals.  ;D

Brett

Title: Re: Accurate homing
Post by: ART on August 21, 2007, 03:03:32 PM

Hi:

  Just to kick in.. ( Thanks brett fro steering me to this post..)

  Estop and limit events shoudl not be prevalent on any system, BUT, if for whatever reason they are..

Estop is just that, an emergnecy, all power shoudl be cut, ( which woudl release brakes on a bug system, thats truly safe..). Mach3 keeps track of all pulses at all times. The DRO's are always accurate as to the pulses put out. Doesnt matter what you do. Postion is lost only when a motor cant keep up. If using servo's, the Rogers baord makes it pretty much infalible. Brian has demonstrated at shows with grabbing the axis and stopping it, thus causing an estop, when the rest is pressed, the DRO's go to the actual motor position, and no homing in necessary. That having been said, Homing shoudl never be risky, it shoudl be accurate. Mine is accurate to .01mm's. If yours isnt, then you need better switches.

   Now it IS possible to home to an index using macro's. All it takes is a "move to index " macro. A very slow move that stops when an input sees a pulse woudl do. Slow, but do-able, Ive never bothered as my homing always seems so accurate I woudlnt gain from the complexity. KISS is always a good idea if you can do it IMO.

  When hitting stop, many steppers will lose position due to abrupt stopping. Many servo's will not. Alot depends on the system.

>>they know how many pusles move the axis how far. BUT if the computer puts out a pulse which the motor misses - for what ever reason, then the DRO IS NO LONGER ACCURATE. As an alternative - if you press E-Stop - and the computer instantly ceases putting out pulses - yet the momentum of your system carries the motor over a few steps (4.8 to the thousanth of an inch on mine) then the DRO (which registers to 1/10th of a thousanth) can no longer be accurat

  Both true statements. BUT , and this is where the theory breaks, it is just as likely for a system to miss a step pulse as an encoder pulse. Both are similar in nature, and both happen. Since nothing, ( truly nothing ) can see the missing encoder pulse, no system, closed or open loop, servo or stepper, is immune to lost pulses. Whiel its true that in true closed loop only 1 weak link exists, any chain is only as strong as its weakest link, so closed loop is questionably better. The true ( and to my mind only )  advantage to a closed loop system with fuill encoder feedback, is that Estops, and sudden stop button presses will not lose position. That having been said, that situation shoudl be a rare one. And homing will cure that in a properly setup system.  I may make some changes soon in the stop system, but Estop will always be a problem.. and should be. :-)

Art

Title: Re: Accurate homing
Post by: Erichtg on August 21, 2007, 06:25:50 PM

WOOOOOHOOOOOOOO!!!!!!!!!!!!!!!!!!!!!!!!!!

Thanks so much Art and Brett!

That's really great news. That really opens up the possibilities.

I'm upgrading my BP to AC drives and will look into writing a macro for finding the index pulses on the encoder lines for super accurate homing.
Probably something like:
 - fast "ref all zeros" to limit switches
 - custom jog to get close to the index
 - slow find index.

I probably won't end up using Rogersmachine encoder board because it does the same thing as the error signal from the servo drives. I can wire the encoders to an additional parallel port myself.

But to be sure. Steppers + encoders + Rogersmachine encoder board is a great solution I wish I knew about a long time ago.

Art, you should advertise the DRO functionality (input and output) in the documentation. I have friends who are slow to adopt Mach because they aren't sure of what is going on under the hood.

Yeah I've been abusing the e-stop for a while. What function was attached to the space bar in the standard screen for Mach2? I don't trust it for some reason -- can't remember why exactly, but I do know for sure there were a few occasions when hitting the space bar didn't have the desired stop/pause effect to make me go for the ESC key by default.

For everyone worrying about the safety of my high speed system: It is unsafe, in that it has no breaks. However it's a bench top system, so it can't kill anyone, AND it has an enclosure that must be locked for motion to occur.

Thanks everybody!

Ted

Ps While I've got Art's attention... Is it possible to enter numbers in Mach 3 using the keyboard's number keys? I haven't figure out how and it's my biggest obstacle to upgrading from Mach 2. I've only a greasy touch-pad attached to the controller now (but would prefer keyboard only).

Title: Re: Accurate homing
Post by: Chaoticone on August 21, 2007, 06:37:36 PM

Np Ted,
   

Quote

Is it possible to enter numbers in Mach 3 using the keyboard's number keys?

Do you mean in a dro? Hmmmmmmmmmm not sure if you don't have a mouse. I just click in the DRO, type the number and hit enter. I can't remember trying it any other way.  ???

Brett

Title: Re: Accurate homing
Post by: Chaoticone on August 21, 2007, 06:43:44 PM

I think I found something to help. In config, system hot keys, DRO select can be a scan code (and key or combo key, a or alt a) I think.

Title: Re: Accurate homing
Post by: Chaoticone on August 21, 2007, 06:55:40 PM

Yup, that works. It will take some getting use to. Assign a key to the scan code. If you go to the Gcode window, the only way I have found to get to the other DROs is to use the mouse. Once on a DRO, use the right arrow key to go to other sections, Feedrate, spindle, machine DROs. If more than one dro in the section, use the up or down arrow keys to get to the one you want. Left arrow key takes you to the g-code screen. Stay away from it.

Brett

Title: Re: Accurate homing
Post by: Erichtg on August 22, 2007, 12:59:13 PM

Thanks,

Been busy making money.  Give me a couple days to try this out.

-Ted

Title: Re: Accurate homing
Post by: Bertho on August 22, 2007, 11:08:31 PM

I tested opto-interrupters.  It turns out that they are amazingly accurate.  See:

http://www.vinland.com/Opto-Interrupter.html
Bertho

Title: Re: Accurate homing
Post by: motorhead101 on August 23, 2007, 07:00:00 AM

I don't know what made me think of it, but is the NISAT 6 axis controller still available?  If you want  a high end system for free, try that one, if it's even still around.  I remember running accoss it years ago, atleast 5 years, only catch is it runs under Linux, and I highly doubt it has a support forum such as Mach, but what other company does?  It was supposed to set the standard for PC controllers, issued by the NISAT, and was free to download, fully functional.  Does anyone remember this or even know what I'm talking about?
Michael

Title: Re: Accurate homing
Post by: vmax549 on August 23, 2007, 09:11:17 AM

Are you referring to EMC2 under Linux. It is a very interesting format IF you are a linux guru. It lately has been updated from the original EMC. It is better than the original but nowhere near MACH in user freindly. But it does have an interesting s curve axis accellaration curve tuning. (;-) TP

(;-) TP

Title: Re: Accurate homing
Post by: Jeff_Birt on August 23, 2007, 01:46:03 PM

This thread really hit a sensitive spot with me.  After working for years on many types of equipment, seeing how large machinery manufactures can make a really fantastic machine and then REALLY screw up the safety related aspects of the design.  I've worked on a $300K seam welder that the mfg fitted with N.O. mechanical home/limit switches.  When the cabling wore through due to poor cable management (another beef of mine) , the machine would not stop when the head homed and consequently $2,000 (or more) worth of TIG and plasma torches were ripped off the machine.  This situation was not only costly but dangerous for the operator.  When I asked the mfgs. engineers about reprogramming their controller to work with N.C. switches I was told that their controller DID NOT have the ability to work with N.C. switches, and they looked at me like I had two heads.  My point is that safety of the machines operator (or bystanders) and secondly the machine should be paramount.  It's important to understand what the different safety system are for and what they should do (and not do).  Here are a few links to that effect:

http://www.designnews.com/article/CA6250678.html
This article talks about a drive system that allows the drives to remain powered in a safe stop condition.  There are two very relevant paragraphs toward the end:

Quote

Peabody distinguishes between a safe stop and an e-stop. A safe stop allows a machine to return to a known position from which it can commence working without an elaborate reset process. An e-stop removes power to the machine immediately, stopping it but possibly scrambling programs. After an e-stop, a machine needs time to gather its wits.

With robots, an operator can push a safe stop button and a locked perimeter guarding will remain that way until the robot has come to a controlled stop. Only then will the guard unlock.

Here is a small PDF from a E-Stop mfg.  This paragraph titled "How shall an E-stop stop the?
http://www.baumerelectric.com.au/pdf/ENG_Chapter_E_Stop.pdf

Now there are different regulations depending on your location and/or the machines function.  Different industries have different requirements.  The gist of it is that an E-stop should safely stop the machine as quickly as possible and remove power to the drives.  With our small table top machines we can be a bit lax and not spend much time worrying about this.  When we build bigger and faster machines we need to take it seriously.  Stopping a machine (through feed hold or similar functions) is not the same as an emergency stop (limit).  Other features in machine controls like feed hold, homing sensors and soft limits are there to keep us from hitting the limit switches or the need to hit E-stop.  I guess my big point is, we should not try and design around the intended function of an emergency stop circuit.   Use it for only the correct purpose and be safe.  OK, I'll get off my soap box now... :-X

Title: Re: Accurate homing
Post by: bowber on August 24, 2007, 07:20:29 AM

My CNC is a small industrial unit, most likly used for training originally, it's a Denford Easimill.

I've just recently removed a Ahha system from my cnc and installed new drivers and Mach3, my system was setup with the Estop removing power from the drives and sending a signal to Ahha, so it lost steps anyway. It did remember the dro readings when shutdown but not when it crashed, which it seemed to do any time it got a bit of code it didn't like.
Mach does have a persistant DRO setting so when you shut it down and then restart it it does show the same position but with microstepping drivers you lose position anyway when the power is removed from the drives, not sure how this would work with feedback from encoders but again I'm not sure I'd trust the position.

I use micro switches for Homing and it's repeatable < 0.0005" so I'm happy with that.

So as has been said I think Estop is just that, an emergency! and I would never trust a computer or electronics to control that stop as they may have been the reason for the Estop.

Steve

Title: Re: Accurate homing
Post by: neilw20 on September 01, 2007, 12:20:25 PM

Quote from: vmax549 on August 20, 2007, 12:11:40 PM

I think my oldest son said it best" POP, If you build your machine and program your code to the same level of accuracy and dependability that you WANT the software to maintain then you will rarely have trouble(;-) "

The Estop and limits are there for a last measure to HELP prevent damage to the operator and machine not save your project from disaster

ANY time you estop or limit stop a machine, and it does not matter WHO made it, you should  reference it back to home to verify that it is still accurate.

If you are running into situations that require constant estops then you need to whack the programer in the head(;-). If you are constantly hitting the limits then you need to whack the operator in the head(;-)

There IS a SOFTLIMITS you can set up that will HELP  prevent the limit crashes. Heck it will even show you the softlimit boundary on the screen when you load the code. If your part goes outside the limits the operator should see it. Can't ask too much more from Mach(;-)

HUM i'll have to test the estop and limits to see if MACH really looses position. I know I have estopped and resumed without loss of position.  I don't recall having tested the limits situation.

(;-) TP

I get E-stop occasionally from the safety swing open perspex guard on my Super X3. I don't lose position. It only happens when I am changing a tool when not moving. No problems resuming, nothing lost. But we cannot assume microstepping is not screwed if power to stepper system goes off. If the E-stop just stops the drives without killing their brains, then there should be no problem, else reference it again. My limit (read reference) switches are optics, and resolve position edge to within the same narrow (1 step (not microstep) on the stepper I think) and repeatbility is excelent. Tight window on refence switch edge is important. Mach3 seems to get it right.

Title: Re: Accurate homing
Post by: Promech on May 17, 2010, 11:08:59 AM

You are mostly concentrating on e-stops and accidental limits, and that is not the point. When you turn off the machine from one day to the next or for the weekend you want to home again so the the machine continues to run with accuracy (just as if have never turn it off). In the case of a lathe, the only way you can be precise is using the index pulse from the incremental encoder.

In my case I will use Teco drives. I read the documentation and I see the servo drives come with preprogramed home routines which use the index pulse. Has anyone interfaced mach and teco drives so as to take advantage of the routinces which come with the drives?

Title: Re: Accurate homing
Post by: Hood on May 17, 2010, 01:50:55 PM

I do Index homing in my drives, they are Allen Bradley but I suspect they will work the same way as your Teco drives. I will explain how mine work, I send a signal to the drives to start homing and off they go seeking the home switch, the switch is seen and the motors instantly reverse and seek out the Index pulse, once that is seen then the drives will move a user preset distance and then stop and that is the axis homed. The drive now sends out a signal saying it has homed and Mach sets that as home position. In fact there are quite a few different ways my drives can be configured for homing but that is how I have mine configured.
 To do this in Mach I have just altered the VB in the Ref All button, I use ModBUS via my PLC to activate the output and read the input but you could use normal I/O from a parallel port, problem however with that is your drives I/O may be like mine and 24V so you would also have to convert that to the 5v of the parallel port.
 The VB I have in my Ref All button is very simple and is as follows. (below is for my lathe, my mill is similar but I have the Y axis also)

DoOemButton (240)                     'De-Reference All axis
 Sleep(10)
 If GetOemLED (809) Then               'Check that Ref Z LED is RED
  Do
   Call SetModOutput (21,1)             'Activate ModOutPut 20
    If GetInput(19) Then Exit Do       'Loop until ModInPut 18 is seen
    Sleep (10)
    Loop
    End If
    Call SetModOutPut (21,0)            'DeActivate ModOutPut 20
    DoOemButton (1024)                    'Set Z axis Home

   
 If GetOemLED (807) Then
  Do
   Call SetModOutPut (20,1)
    If GetInput(18) Then Exit Do
    Sleep (10)
    Loop
    End If
    Call SetModOutPut (20,0)
    DoOemButton (1022) 

Hood

Title: Re: Accurate homing
Post by: Hood on May 17, 2010, 01:54:38 PM

Oh meant to say you do NOT set up any home switches in Mach when you are doing this external homing, as far as Mach is concerned it knows nothing about it.
Hood

Title: Re: Accurate homing
Post by: Promech on May 17, 2010, 04:56:20 PM

Thank you very much for the information. It all sounds very logical and I am sure it will work.  I am installing a Machmotion control with Teco drives on to an old Emco 340 lathe which is in perfect mechanical condition. I am setting up a bench for simulation first. I have the following challenges ahead:

Homing with index pulse
Management of backlash (wonder if Mach3 manages this, have not read all the documentation yet)
Programming for control of the original Sauter turret (it comes with an A.C. motor inside).
Controlling a hydraulic unit which controls the chuck, parts catcher and tailstock.

Looks like  PLC programming will be lots of fun !!!!

Title: Re: Accurate homing
Post by: Hood on May 17, 2010, 05:02:18 PM

Not sure how the MachMotion stuff works but if it doesnt have a PLC already and you dont already have a PLC then look at the DL06 from Automation Direct. Thats what I use and if you need help I can probably do so, though I am not an expert, I can usually muddle through :)
Hood

Title: Re: Accurate homing
Post by: rokag3 on June 25, 2010, 06:34:23 PM

Hello,
I have a Milll equipped with 3 servo equipped with 3 rotary encoder
We also have 3 DRO linear encoder 5micron
The index of the Dro linear encoder is on the middle
Due to the short time available to see the index I have made a little electronic using a flipflop and opto so when the pulse appear(even at full speed) it stay on. Mach then get enough time to see it stop go reverse very low speed and when he reach the index again stop.
The problem :
I use a bob where the limit switch and the home switch are linked . So if i send a home signal it's equivalent to a limit.
I have put a relay that inhibit the entry of the opto so even if the home signal is deliver the flipflop will not see it

I must write a macro  for homing:
I activate an output that will select a relay and energized my opto
 Since i do not know where i am :go left if i reach home stop reverse slow if i reach soft limit i go reverse until i find my home 

But i do not know how to write a macro in mach (list of instructions, environments variables, editor) since i used to program in C , i am not too affraid but i need to get the starting point

Title: Re: Accurate homing
Post by: Hood on June 26, 2010, 11:56:57 AM

Ray Livingstone wrote a draft manual for VB, you should find it here http://www.machsupport.com/forum/index.php/topic,12740.0.html

Hood

Title: Re: Accurate homing
Post by: stirling on June 27, 2010, 07:13:54 AM

Also take a look at the cypress VB manual in the wiki

Quote from: rokag3 on June 25, 2010, 06:34:23 PM

i used to program in C

Then it's like you used to fly jet fighters and now you're about to learn how to flap your arms (but with one of them tied behind your back) - you'll be fine.

Cheers

Ian

Title: Re: Accurate homing
Post by: rokag3 on June 27, 2010, 08:29:08 PM

Ray Livingstone wrote a draft manual for VB, you should find it here http://www.machsupport.com/forum/index.php/topic,12740.0.html

Hood

Thank you very much This is exactly what i am looking for .
About jet fighters, unfortunately(?) it's not the language that make the program ! and a precise idea of what you want to do + a good knowledge of what can be done may compensate a n heavy syntax also our computers are very fast now so i think we can handle it.
I also meet guy who where programming in c VERY inefficiently !
And since some manage to do it so i can do it too(hopefully)

Title: Re: Accurate homing
Post by: stirling on June 28, 2010, 04:56:23 AM

Quote from: rokag3 on June 27, 2010, 08:29:08 PM

About jet fighters, unfortunately(?) it's not the language that make the program ! and a precise idea of what you want to do + a good knowledge of what can be done may compensate a n heavy syntax also our computers are very fast now so i think we can handle it.
I also meet guy who where programming in c VERY inefficiently !
And since some manage to do it so i can do it too(hopefully)

I stand corrected - sorry for my attempt at encouragement by way of a little joke...

Title: Re: Accurate homing
Post by: rokag3 on June 28, 2010, 08:49:45 PM

I stand corrected - sorry for my attempt at encouragement by way of a little joke...

I did like the joke, but i have met so many young guys programming with high level language but making a good job feel complexed in front of old horses (like me) who have made assembly, c, lisp(yes) and i say to them go buy a little arduino and discover that 95% (at least) of your job is not requiring  low level so if and only if you have timing problems then dig it.
I am convinced that a good analyst programmer with whatever language can make a good job, and, in front of a real problem will be much more easily able than they think  to program in c Kerningham& ritchie will help  ;D