Messages

1211

Galil / Re: Problems with losing position

« on: February 10, 2014, 10:12:59 PM »

CNCToolDie,

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

See if it fixes the stop problem.

Steve

1212

Galil / Re: Joystick connection, Idiots guide needed please. 2160 and 1900icm

« on: February 10, 2014, 09:17:16 PM »

John,

You are pretty much hosed because there is nothing in that setup that will synch Mach and Galil after the position change from the joystick. 

The best way to handle this is to run the joystick anaolgs into some analog inputs and use a brain file to convert the signals into velocity jogs.  This way Mach/Galil are aware of it.

Steve

1213

Galil / Re: Problems with losing position

« on: February 10, 2014, 09:11:46 PM »

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

1214

Galil / Re: Problems with losing position

« on: February 10, 2014, 06:24:13 PM »

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

1215

Galil / Re: Problems with losing position

« on: February 10, 2014, 05:34:38 PM »

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!

1216

Galil / Re: Migrating to newer computer

« on: January 26, 2014, 04:12:03 PM »

Mark,

Try this: Disable soft limits and see what you get.  That may make a difference on the homing and the JG only valid when running in jog mode.  Are you running a gantry axis?

Steve

1217

Galil / Re: Migrating to newer computer

« on: January 25, 2014, 12:07:56 AM »

I'm pretty excited to get it homing and indexing so I can test it and see how accurate it can be.  I'm hopeful that I can put a fixture on the table, indicate to a known point on it, completely shut the system down, start it back up, home, and then accurately bring it back to the same point without having to indicate it each time.

That is exactly what it will do!  I love having that capability.  My machine homes at 100 IPM, so homing and getting back to my fixture is pretty damn quick.  Hit the "Goto 0" button (500 IPM) and you are done!  I used to check it to make sure it was correct.  I don't anymore because it is so repeatable.  Yeah, it might bite me one day, but until then I will enjoy the convenience.

Steve

1218

Galil / Re: Migrating to newer computer

« on: January 24, 2014, 10:51:03 PM »

Mark...  I thought I would give you someone else besides yourself to talk to.  Because I don't want your to end up answering yourself.  That is a bad sign, you know! 

The home direction is controlled by the polarity of the home switches.  If POS is wired to LSCOM, then the axes will home one way.  If NEG is wired to LSCOM, then the axes will home the other way.  This is only useful with the Galil HM and FS commands.  This makes these commands tricky as just by changing polarity of the switches makes the axis travel one way or the other.  So we don't use them.  We control the homing direction with what is defined in Mach.  It is is going the wrong way, simply reverse the direction in the Mach settings.  Now, that should get you moving in the right direction, but then you have to play with the switches a bit?  So the wiring polarity thing can come back and bit us here.  If the switch is a NC one, it may be represented in the data record as 0 or 1 depending on the LSCOM polarity.  All home switches should be wired the same.  There is no support for having one home switch NC and another one NO.  And hopefully, that is the case for you.  Assuming so, there is a check bock in the Galil plugin config that says "Homes active low" or something to that effect.  Toggle that one way, test, and if it doesn't work, toggle it back and test.  You have to play around to find the combination that works for your machine.

As to which direction the machine homes, I have found that it really doesn't matter.  But most of the production machines that I have worked with all seem to home to the top right hand corner of the table.  The spindles switches can be anywhere though.  Top or bottom.  Depends on the machine.  My Matsuura has the switch at the top of the Z travel. 

Steve

1219

Galil / Re: Problems with losing position

« on: January 24, 2014, 10:28:47 PM »

Well...  Mach3 with a Galil is not the same as Mach3 controlling a stepper system.  Mach3/Galil is a closed loop system!  The servo PID loop is closed on the Galil.  And there is another important distinction; Mach3 gets its position from the Galil!!!  This is in contrast to a stepper system where Mach3 has it's own notion of where it thinks the table should be.  What is displayed in the Mach3 DROs comes from the Galil (which comes from the encoders).  This can be verified by disabling the servo drives and turning the motors by hand.  You will see the position updated in the Mach axis DROs.

So something is amiss here...  Are your motor tuning counts set right?

While all of the issues you described above might throw a stepper system for a loop, I have never seen any of them get my Galil and servo system out.  I can hit e-stop, escape, hit a limit, stop and everything in between and Mach always knows where the motors are.  I find it VERY repeatable and reliable.  If I set a part zero, then slam into a limit, all I have to do is hit GOTO 0 and I'm back to my part 0 with amazing accuracy.  If I hit e-stop and blow my axis reference away, all I have to do is home the machine and hit GOTO 0 and I'm right back at my previous part 0.  Again, with amazing accuracy.  (I do use index homing.)

What you are describing sure sounds like a mechanical issue to me.  Another fellow just had similar issues and he found his slip.  (http://www.machsupport.com/forum/index.php/topic,25998.0.html)  It may work in Galil Tools for a bit and then start acting up.  My advise is to take a hard look at the motion system.  Because I have never seen what you are describing come from any other source.  Mechanical issues can be tricky.  I have seen a slip in one direction and not another.  Inconsistent slips.  Slips more on direction sometimes and then reverses, etc...  Very frustrating.  But I really think this is your problem.  For several reasons...

1) I don't experience what you are describing at all. 
2)  There are a LOT of Mach3 Galil users and they are not experiencing this (or else I would be flooded with complaints!).  We have a customer that sells engine block boring machines that use Mach3/Galil.  If things were not as they should be, there would be a bunch of ruined engine blocks laying around.
3) I have solved a LOT of mechanical motion issues in the past that were deemed "impossible".

I'm not ruling out some strange occurrence though.  Also, hacked versions of Mach3 do strange things.  So make sure your license is valid.  Some users have gotten bilked by purchasing Mach through less than ethical people.  They may have a bad license and not even know it! 

Good luck hunting.  Seek and destroy! 

Steve

1220

Galil / Re: Galil + Mach3 slowly losing position

« on: January 19, 2014, 02:13:28 PM »

Glad to see you got it sorted!!

Steve