1211
Galil / Re: Problems with losing position
« on: February 11, 2014, 12:42:28 AM »
The communication between Mach3 and the Galil is handled by the the plugin. No serial. Only Ethernet or bus. Serial is too slow.
Galil can output Step/Dir for steppers or position controlled servo drives. It will also do analog out for analog command servo drives. Your choice per axis. However, step/dir has no feedback loop, so you loose that! It is no better than any other stepper system. To use the Galil to it's full potential, it requires that the encoders are connected to the Galil and analog commands are sent to "real" servo drives. I'm not a fan of the position control "step/dir" drives. Better than a stepper as far as losing position is concened, but Galil is not closing the servo loop at all with that kind of drive. With that kind of drive (or steppers for that matter) Mach gets no position feedback from the Galil and it can only maintain a calculated position of where the motors should be.
But with analog drives, the encoders are hooked to the Galil, right? Well, the plugin has access to the Galil's encoder data. It simply forwards it on to Mach.
Encoder -> Galil -> Plugin -> Mach DRO is the path. The DROs don't control the movement. The Galil does. Mach only references the position in the DRO (that it got from the Galil) when it wants to know the start point at which to plan a trajectory. Other than that, it is for display purposes only. But the DROs are indeed fed from the encoders.
1. Mach constantly gets updated with the encoder position (in machine counts). It takes those counts and figures the position in user units based on the motor tuning and applies the current fixture offset to it.
2. Say you have the part zero set (G54) at X 0 and you want to move to X1. "G01 X1 F20" then you hit Cycle Start (or enter on MDI) Mach then looks at the current position as fed from the Galil and plans a trajectory to get to X1. Say this total distance is 10000 counts.
3. Mach begins streaming a trajectory down to the Galil. Lots of points make up this trajectory over the time and distance to get there. But in the end, 10000 counts will be doled out to the Galil.
4. Now, the Galil has to execute the trajectory. PID setup willing, it will arrive at the X1 destination. The Galil is at X1 and updates Mach's DRO to X1 and the table is at X1. So the tool is at X1.
Now, if the PID is too soft and the Galil can't get the table to X1 (too much dampening and not enough gain with no integral), that is NOT Mach's fault. This is an extreme case but I have seen really bad servo tuning! Most cases is that the PID overshoots (too much gain, not enough dampening and the servo may "hunt") and then settles to the commanded position. In this case, position is never a problem. You hit the mark. In EITHER case, the Mach DROs will show exactly where the tool is.
The problem with the Stop() was that the DROs were not synchronized with with the Galil. Because the DP command was used to apply an offset. Thus Mach lost it's correct reference. Basically, it was like applying an arbitrary fixture offset. Any movements planned from then on would have this offset applied. It was NOT that the DROs were not getting updated.
Steve
Galil can output Step/Dir for steppers or position controlled servo drives. It will also do analog out for analog command servo drives. Your choice per axis. However, step/dir has no feedback loop, so you loose that! It is no better than any other stepper system. To use the Galil to it's full potential, it requires that the encoders are connected to the Galil and analog commands are sent to "real" servo drives. I'm not a fan of the position control "step/dir" drives. Better than a stepper as far as losing position is concened, but Galil is not closing the servo loop at all with that kind of drive. With that kind of drive (or steppers for that matter) Mach gets no position feedback from the Galil and it can only maintain a calculated position of where the motors should be.
But with analog drives, the encoders are hooked to the Galil, right? Well, the plugin has access to the Galil's encoder data. It simply forwards it on to Mach.
Encoder -> Galil -> Plugin -> Mach DRO is the path. The DROs don't control the movement. The Galil does. Mach only references the position in the DRO (that it got from the Galil) when it wants to know the start point at which to plan a trajectory. Other than that, it is for display purposes only. But the DROs are indeed fed from the encoders.
1. Mach constantly gets updated with the encoder position (in machine counts). It takes those counts and figures the position in user units based on the motor tuning and applies the current fixture offset to it.
2. Say you have the part zero set (G54) at X 0 and you want to move to X1. "G01 X1 F20" then you hit Cycle Start (or enter on MDI) Mach then looks at the current position as fed from the Galil and plans a trajectory to get to X1. Say this total distance is 10000 counts.
3. Mach begins streaming a trajectory down to the Galil. Lots of points make up this trajectory over the time and distance to get there. But in the end, 10000 counts will be doled out to the Galil.
4. Now, the Galil has to execute the trajectory. PID setup willing, it will arrive at the X1 destination. The Galil is at X1 and updates Mach's DRO to X1 and the table is at X1. So the tool is at X1.
Now, if the PID is too soft and the Galil can't get the table to X1 (too much dampening and not enough gain with no integral), that is NOT Mach's fault. This is an extreme case but I have seen really bad servo tuning! Most cases is that the PID overshoots (too much gain, not enough dampening and the servo may "hunt") and then settles to the commanded position. In this case, position is never a problem. You hit the mark. In EITHER case, the Mach DROs will show exactly where the tool is.
The problem with the Stop() was that the DROs were not synchronized with with the Galil. Because the DP command was used to apply an offset. Thus Mach lost it's correct reference. Basically, it was like applying an arbitrary fixture offset. Any movements planned from then on would have this offset applied. It was NOT that the DROs were not getting updated.
Steve