I see the DP in the stop code in the Galil plugin.  It is indeed doing the wrong thing.  I would have never noticed it because I don't have a use for the Stop button.  Not sure I know anyone that does, actually.  I really don't know why it is there.  On my machine, I have no Stop button.  Even on the original YASNAC panel there was no Stop button.  There is an E-Stop button, but no stop button.  E-Stop, Cycle Start, and Feed Hold.

So what do you do/accomplish with the stop button?

And yes, stop is harsh.  Again, I don't see the need for it.  Not when you have feed hold and nice controlled stop with that.

In the mean time, I will fix the stop code in the Glail plugin.  Thanks for the find!

You will also find they don't like to hear anything bad about the Mach software.

That is not a very constructive statement.  Where did that come from?  The Galil plugin is not Mach software.  It is written by a few of us that want to run our Galil equipped Mills/Lathes with Mach3 and we give it back to the community.  We don't make a dime off of it.  Yet people run the Mach3/Galil combo and make lots of money with it.  And honestly, we love that!

But if someone comes on here and DEMANDS that we put something in the plugin or tells us it NEEDS to do something special for them then yes, we may not jump.  We may not even acknowledge it.  Or we may say something stating our "thoughts" on the matter.  For me, I don't have a whole lot of time to deal with that.  Life is too short.

Conversely, if someone asks nicely and we can work it in we will try to accommodate if we can.  If someone finds a bug, the we will try and get it fixed as quick as possible as well.

Steve

I wasn't refering to the Galil software, I don't use it. I have several things about Mach3 that is a little quirky. When I ask for help that I feel is a software issue I get pointed in every other direction.
Don't get me wrong its great software especially for the price but if it was perfect Mach 4 would be an upgrade to 3 not a complete revamp. Non OEM Mach3 has a stop button right over the reset button. This is the one that causes the harsh stop and if you use you can loose position.
Thanks for the help you provide.
Do you or someone else know that if the encoder inputs in Mach are connected to the servo will Mach use these input as closed loop control? Right now my feedback is into the sevo drives with no direct communication back to the Mach sofware. If there is an error in position the system stops and alerts you that your out but won't correct it.

Thanks in advance
Steve

I was talking about the Galil plugin.  It is not written by Galil or Mach.  It is written by several (primarily two, me and Kenny Crouch) people.  But others have helped out.

Mach uses the encoder as input.  But only if it is synchronized.  Mach is not ever controlling the PID loop.  That is done on the Galil.  Mach is a trajectory planner.  The way it works is the position is fed into Mach from the Galil and the planner's position is set to that (synched).  Then the G code is interpolated and a trajectory is planned FROM that initial agreed upon position.  This is what is fed to the Galil for motion input.  If that trajectory is not followed by the Galil, there will be a position error and Mach and Galil will have differing opinions of the machine position.  It should be detected on the Galil if it is running analog servos with feedback.  However, depending on Galil settings, it may not be setup to do much of anything regarding a position error.  Mach's planner never re-plans based on a position error.  If you do a G01 X1 from X1 and your PID settings are not adequate and the destination is never reached, Mach is not going to re-plan the trajectory and give it a bump to get it there.  Why?  Because it should not have to.  The PID problem should be solved.

I like to use a car and driver analogy.  Say you want to drive to the stop sign at the end of the street.  You plan your route (trajectory).  The route involves stepping on the gas, traveling for a distance, and then hitting the brakes.  Then you get in the car and follow that route/trajectory.  If you stop 30 ft. in front of (or beyond) the stop sign, is the route/trajectory wrong?  No.  You, the driver, need your PID/head examined!    Because you did not follow the route/trajectory.  The route/trajectory had all of the information in it needed to get you to your destination.  As a unit of work, it is complete.  Nothing else needed.  This is how all motion control systems work.  Fanuc, Fidia, even EMC.

I will say this and every now and then people will tell me I'm wrong.  They will say that EMC will re-plan the trajectory.  It does not.  What it is doing is the motion control aspect of EMC (the real-time component) is adjusting the command voltage based on the output of the PID filter looking at the following error.  If the PID settings are not correct, EMC may never reach it's destination either. 

You can never have a situation where you tell a motion controller to move 15000 counts, oops I didn't get there, move another 1000 counts for a total of 15000 counts.  Because you have really asked the motion controller to move 16000 counts!!!!

So Mach, being just a trajectory planner, should NEVER be involved in closing the position loop because it is NOT a motion controller.  EMC is a trajectory planner AND a position loop motion controller.  It uses no real-time to plan the trajectory.  However, it does use the real-time component to follow the preplanned trajectory.  The Galil is the real-time component in the Mach/Galil combination so it has the same duties as the real-time component of EMC.

CNCToolDie's observation was that when hitting stop, the Galil plugin effectively lies to Mach about where the machine position is thus creating a discrepancy between what Mach thinks the position is vs. where the machine actually is.  This is pretty much unrecoverable at this point.  Only resetting the fixture offset or re-homing the machine will correct it.

Steve

CNCToolDie,

Try out this plugin: http://www.smcomp.com/~smurph/galil/Galil-st.zip

See if it fixes the stop problem.

Steve

So there is 2 way communication between the Galil controller and Mach3? This obviously done through serial or ethernet connection. Does the Galil use sep/dir outputs or +/-10V to the servo drives?
So the commands are sent to the Galil controller from Mach the Galil sends these on to the servo drives the encoders feedback their position to Galil which informs Mach of the actual position and updates the DRO's to match or what?
What I'm trying to figure out is why the DRO's arn't ditectly fed from the encoders. If they were then position couldn't be lost through misscommunication in the software or lost because Mach assumed the drive moved like it was commanded. My understanding of the PID settings was to control the current accross the H bridge in the drive to match the motors to the loads when decellerating and reversing so its not to harsh causing excessive overshoots then returning to the commanded point on the encoder and holding it there.
I feel the DRO's should read where the tool is not where it is expected to be.

Thanks
Steve

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

Wow Steve that is great!  Thank you for getting this fixed so quickly!

I will test this version thoroughly today on an 1842 and a 2133, will plan to report by Wednesday morning.

Thank you for what you and Ken do to make the world of motion control better!

Matt

Hi Steve/ Smurph,

If I have a Galil optima 18x3 set up with steppers and use linear encoders will Galil and Mach see this as closed loop?

I know this is a noobish question, but even after using Galil with 2 software packages gCNC and Camsoft for over a decade I still do not really understand the configuring of it that well.


If I am going to run steppers without encoders and want spindle control (I bought the cnc4pc c6 board ) with Mach3 would I actually be better off using the smooth stepper Ethernet board?

I also noticed reading last night that with the Galil I am not going to be able to use a MPG hand wheel pendant without much tweaking.

The handwheel pendant is a must for me!

Thanks for your input. I am about a weeks time away from testing, I am waiting until I figure out a few more things before I install Mach3 on the Mill computer.

Oh during testing and config is it Ok to run the Demo version of Mach? Ihave not bought a license yet. I thought I read it does a bunch of lines of code without a license.

Thanks,
Joe

Bubba I would think that a pendant fed into Mach should run through the Galil, how would the galil know what generates the signal or care. I use the shuttle pro and can control all 4 of my axises from rapid to 1/10,000 inch steps. If your spindle doesn't have an encoder on it and you want to control speed and direction a VFD is a easy way to go. The VFD can be controled straight from Mach3 gives complete control of the spindle and with minor mod will run 3phase on single phase nicely.
Far as the compatability with the Galil lets see what smurf says about that he is quite fluent with them.

Steve