Machsupport Forum

Third party software and hardware support forums. => Galil => Topic started by: CNCToolDie on January 22, 2014, 11:23:46 AM

Title: Problems with losing position
Post by: CNCToolDie on January 22, 2014, 11:23:46 AM
Hi,

I have an 1842 PCI controller setup to a CNC servo wood router.  In GalilTools I have the PID set so that I can bore a 1/4" hole move 6" bore another 1/4" hole and repeat this loop 300 times in X or Y axis.  I only gain .001 in hole size and the distance between holes is exactly right, which tells me my mechanical is very good and my PID is very good (of course I did a BN).  In Mach3 I get up to .125" off just boring 6 holes on a grid, the first is in location, the 3rd off by .02", the 6th by .125.  How much it is off is not consistent either.

When I run Gcode in Mach3 I might get way out of position when I click Stop, hit a limit, press escape... I have read of this on other Mach3 forums, I understand it is a limitation due to Mach3s open loop nature... Ok I can avoid doing those things, so in my above bore Mach3 bore test I was careful to not do any stop event.

I have run my Galil DMC bore test in SmartTerminal vs old ST Mach3 plugin and with the GalilTools vs the new Mach3 GT plugin.  I get spot of perfect results in the Galil DMC but very erratic results thru Mach3.  All my Mach3 speeds, ac and dc are set below what they are in GalilTools.  I am at a loss for what can be causing this, any advice is appreciated.  My theory is the open loop nature of Mach3 is causing these errors.

As a test I set my ER tighter to 20 and now Mach3 won't move much at all before the drive goes into an error state.  In GalilTools I scope no more than an Error of 1 to 2 counts while moving, none when arriving at location.  So for some reason Mach3 is getting quite far off.

Thank you in advance for any advise!
Title: Re: Problems with losing position
Post by: smurph 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
Title: Re: Problems with losing position
Post by: CNCToolDie on January 27, 2014, 04:40:03 PM
Thanks for your great and useful reply Steve  8)

I am pretty confident the mechanical is correct, although was willing to take it all apart if the following test failed...

I have access to another Galil system with the same wiring schematic, so it is was a simple matter to take my computer/controller, power suplly and amps to this other machine and plug it it.  I BN the PID, AC, DC, SP this machine usually uses.  I placed a mark on both lead screws, I then in Smart Terminal ran a 5" square 100 times, it came out spot on.  I programmed a 5" square in Mach3, ran it 100 times it came out perfect.  Ran it 3 more times, perfect!!!  At this point I was strongly suspecting it must be mechanical.  Then I started pressing stop while G code was running in Mach 3, rewinding and starting over, the first time no error, the second 1/8" off in Y, the 2nd time 1/2" off in Y.  X was perfect but it was moving in Y every time I pressed stop.  Next I reset 0,0 and pressed stop while moving in X, Off 1/4" the first time.  To summarize pressing Stop while an axis is moving almost always makes that axis "off".  Also the the problem traveled with my PC and controller, so is independent of the mechanical.  While at this location I had an electrical engineer review my setup and it seems good.  I was using daily production mechanical, motors and wiring in the above test, so those are good.

You said "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!"   Is there a way to check if the license is legit?  I have upgraded Mach3 and Galil plugin both without issue,seems that would catch an illegal license?

Thank you for any help :-)
Title: Re: Problems with losing position
Post by: Tweakie.CNC on January 28, 2014, 03:02:05 AM
Quote
Is there a way to check if the license is legit?  I have upgraded Mach3 and Galil plugin both without issue,seems that would catch an illegal license?

Check with licensing http://www.machsupport.com/contact-us/

Tweakie.

Title: Re: Problems with losing position
Post by: CNCToolDie on January 28, 2014, 10:31:09 AM
Thanks, I just sent a note with my license info, hopefully they will get back to me soon.

Update: Also I did more tests in Smart Terminal where I moved in a 5" square repeatedly. Then I made it stop using ST, AB, and obstructing the movement causing Abort due to obstacle.  I did this a dozen times it never lost position this fairly well narrows it down to Mach3.  So maybe a bad license or maybe something got corrupted and I need to reinstall, I have seen this help on other applications.
Title: Re: Problems with losing position
Post by: CNCToolDie on January 28, 2014, 02:12:08 PM
Update: I very quickly heard back from Mach3 support (thank you!), my license is valid.

I am going to format the drive and start over installing XP and doing everything from Step 1.
Title: Re: Problems with losing position
Post by: CNCToolDie on January 29, 2014, 12:30:27 PM
Seeking and Destroying as ordered!!!  ;D  My next steps:  I formatted the PC, installed XP pro, DMC-ST, connected  (Note: my firmware was one revision out so updated that and reset my PID and BN).  Installed Mach3 and Galil plugin, did not use my old XML (in case there was something wrong)  Went thru and set up the Galil config and the Mach3 settings pages.  Ran my 5" square 100s of times no error.  Press stop and it is off every time in the axis that I hit stop. 

For these tests the Galil, PC and Mach3 are connected to a known good production machine with good mechanical.  Running a 5" square pattern in DMC-ST works great. In ST Pressing ST, AB, causing an OE all has zero position loss.  In Mach3 position is lost every time I press stop, when I go back to DMC -ST the TP is off.  I am 100% sure that pressing stop in the Mach3 is resetting the Machine Coordinates, I confirm this in DMC-ST by checking TP.

I note that when I press stop the machine decelerates violently. As a test I set the Mach3 AC/DC really soft so that it is nice and lazy around the corners (even rounds them), but when I press stop it really jerks hard, now this should not cause a Galil position loss but it is.  I reviewed the Galil Plugin Log and note a ST then an AM, but see no indication of other cause.  I also note the AC and DC are set to the default of 30,000,000, lowering this does makes the Stop smooth, but position is still lost (but by even more).  Again with the Galil you can stop it with a sledge hammer and it still knows where it is thru any other software.

I have worked with Galil controllers for almost a decade now, I know they do not exhibit behavior like this, they are in my opinion the best controllers in the world!  I know that many many people use Mach3 successfully with the Galil.  Is there any setting that might be BNd into my controller that could cause this behavior?

Ahhh reviewing the log I think I found the cause!!!  After I press stop this is the string of commands the Plugin is sending: ST, AM, CS S, CS T, ST, AM, "DP -8421, -19672, 0, 0"  ***This DP is bad, the DP should Never Ever happen unless the user presses "Ref All Home".  I can see on Steppers this may be desireable but on Servos it is not good.  As you said Steve the Galil always knows where it is, Mach3 should never ever change that except after the home move.  I never once pressed home in the attached log.  I have attached the log for your review, so you can see what I am seeing.  The only cause for this that I can think of is on the 1st page "Motor Options" (both are unchecked), 2nd page (all set to Servo).  I am anxious to see what you find out.

Here is my Gcode just in case:
%
O0000
N100 G20
N102 G0 G17 G40 G49 G80 G90
N108 G0 G90 G54 X0 Y0 S8556
N116 G1 X0 Y-5 F300
N120 X-5 Y-5
N122 X-5 Y0
N124 X0 Y0
M30
%

I reduced it to this, still got out with a stop press:
%
O0000
N116 G1 X0 Y-5 F300
G4 P.1
N120 X-5 Y-5
G4 P.1
N122 X-5 Y0
G4 P.1
N124 X0 Y0
G4 P.1
M30
%

Highest regards, thank you for any help that can be provided.
Title: Re: Problems with losing position
Post by: CNCToolDie on January 29, 2014, 12:50:52 PM
Here is my Mach3 config, perhaps that will help see if a setting I have done is causing the DP.

Thank you.
Title: Re: Problems with losing position
Post by: CNCToolDie on January 29, 2014, 03:22:28 PM
For further testing I tried a CNCs Mill with a DMC2132 that is normally run in production using Galil Tools. I installed Mach3 with the GT plug in, (the other tests are with a 1842 ST plugin).  I ran a small square successfully, every time I press stop I lose position slightly in the axis that was moving, just like the other CNC.  I went into the log and I see a DP sent everytime I press stop.  The way I think it needs to be is Mach3 needs to be asking the Galil,  "After that stop I just told you to do, where are you?" (TP) "Thanks I will use that to update my DRO", not the way it seems to be going of "Hey Galil stop... Here is my DRO" (DP).  I also see every time the reset is pressed a DP is sent. It is looking to me like the Plugin needs a tweak, commenting out all the DP commands should do it, other than the DP associated with the home move.

Please do not take offense to what I am saying above, I have been a Galil developer for many years, so have a fairly high experience level with Galil commands.  I am just trying to be as helpful as I can be for troubleshooting this issue.  I am really hoping  that I have a basic setting wrong and the problem is on my side, that would be awesome. 

Highest regards!
Title: Re: Problems with losing position
Post by: Machinehead57 on February 10, 2014, 12:55:58 AM
I have a large 3axis mill I retrofitted to Mach3 myself. It runs very accurate as long as you don't hit the stop button. If I use the stop button like you the axis its traveling in will loose position.
I get a harsh stop that I feel causes a delay between Mach and the actual servos. The Mach DRO's stop instantly the servo's stop a few miliseconds later causing a loss. You will also find they don't like
to hear anything bad about the Mach software.
Try your same test with a feedhold stop instead of stop, bet you won't get any loss that way.

Steve
 
Title: Re: Problems with losing position
Post by: smurph 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!

Title: Re: Problems with losing position
Post by: smurph 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
Title: Re: Problems with losing position
Post by: Machinehead57 on February 10, 2014, 08:15:43 PM
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

Title: Re: Problems with losing position
Post by: smurph 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
Title: Re: Problems with losing position
Post by: smurph on February 10, 2014, 10:12:59 PM
CNCToolDie,

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

See if it fixes the stop problem.

Steve

Title: Re: Problems with losing position
Post by: Machinehead57 on February 10, 2014, 10:55:53 PM
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
Title: Re: Problems with losing position
Post by: smurph 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
Title: Re: Problems with losing position
Post by: CNCToolDie on February 11, 2014, 10:04:55 AM
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
Title: Re: Problems with losing position
Post by: bubba on February 11, 2014, 01:21:10 PM
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
Title: Re: Problems with losing position
Post by: Machinehead57 on February 12, 2014, 10:44:45 AM
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
Title: Re: Problems with losing position
Post by: CNCToolDie on February 12, 2014, 11:20:53 AM
Steve,  I got try your new plugin on a 1843 last night and it was spot on.  Now when I press stop, then Goto Zero it is correct!    I hope try this on a 2133 soon, I will report the results.  I also note that the Stop event seems smoother now, not such an abrupt stop.  All in all a definite improvement!

Thank you for the fix and all your efforts,
Matt
Title: Re: Problems with losing position
Post by: bubba on February 12, 2014, 12:11:23 PM
Thanks Machine head Steve,

I was reading in another thread that the MPG hand wheel is the problem.I hope I read wrong.

Thanks for your help and i will have to remember that you and Smurph are both Steve!

Joe
Title: Re: Problems with losing position
Post by: bubba on February 12, 2014, 12:29:59 PM
I posted this in another thread, but this thread that is the only one getting any action so I am going to ask again here.

I am setting up a new dedicated computer now for Mach3 . I was able to pick up an Optima 1830 Pci
I had some new unused parts available even though they are dated by todays standards.

Intel q6600 Gigabyte board 500 gb 4gb DDR3 1600 ram 750 Watt Power Supply

So I can now run a faster computer than the one with my Galil ISA card

Do I install Smart term still or the new galil Suite?

Thanks,
Joe
Title: Re: Problems with losing position
Post by: CNCToolDie on February 12, 2014, 03:01:51 PM
Hi Steve (Smurph),

Tried the new plugin on a 2133, it works great, after Stop it is able to return to zero  ;D.  Tried several times to make it loose position and could not loose position.  Plan to cut a bunch more in the next few days so will keep an eye on it.  Also I searched the log on both DMCs and only saw a DP on start up, which seems acceptable...

Note: If you did not do a DP on start up and instead use the position that is already in the Galil to update Mach's DRO it would be a bit better.  Then a user could go into and out of Mach without loosing position.  I would not classify this as a bug, more a potential enhancement.  With this change only a Ref Home would do a DP.  Again not a big deal, the way it is works (might even be best practice to force users to Home on Mach start up), just a thought.

Thank you,
Matt
Title: Re: Problems with losing position
Post by: smurph on February 13, 2014, 12:11:49 AM
Nice!  I'm glad it works for you! 
Title: Re: Problems with losing position
Post by: smurph on February 13, 2014, 12:25:34 AM
I posted this in another thread, but this thread that is the only one getting any action so I am going to ask again here.

I am setting up a new dedicated computer now for Mach3 . I was able to pick up an Optima 1830 Pci
I had some new unused parts available even though they are dated by todays standards.

Intel q6600 Gigabyte board 500 gb 4gb DDR3 1600 ram 750 Watt Power Supply

So I can now run a faster computer than the one with my Galil ISA card

Do I install Smart term still or the new galil Suite?

Thanks,
Joe

What OS?  Smart Term only works up to XP.  Anything newer and you will have to use Galil Tools and the non Smart Term Galil plugin.  This MAY work for you.  I just have never tested it.  In any case, stick with a 32 bit OS as the code in the Galil plugin has a better chance of working with that.  I have tested the Galil Tools based plugin with a 18x6 Accelera PCI controller and it worked.  But I have no Optimas or Econos to test with. 

The no nonsense combo that WILL absolutely work is Windows XP32 with Start Term (version 7) drivers. 

Just a heads up...  For the future, I am thinking about dropping support for all bus based controllers.  This is not a decision I took lightly.  And I actually haven't decided yet.  But it is getting increasingly harder to support the bus based controllers.  Namely because I don't have one of each (and they all act a bit differently with data record retrieval) and my latest PC doesn't even have a regular PCI slot!  Conversely, nearly ALL PCs have Ethernet cards in them and the Ethernet cards all work the same.

That and the fact that I don't believe Galil even plans on releasing another bus based controller.  Meaning PCI-e is not in the cards.  :(

Just something to think about...

Steve
Title: Re: Problems with losing position
Post by: CNCToolDie on February 13, 2014, 10:02:29 AM
Hi Smurph,

I know what you mean about the Bus controller handling the DR differently, I had to come to a similar conclusion.  Dropping support for them is the right decision because the way you have to process the DR on a BUS controller is so much slower than the old methods of retrieving records that it really handicaps those controllers.  So even if you took the time to code DR handling for the BUS controllers the results would be a less responsive controller.  In my opinion you are better off leaving them using the current plugin and leave them at Mach3.  The DR is just such a powerful tool to the programmer that using that exclusively will improve performance.

I don't say that lightly either because my hobby CNC uses an Econo 1843   :-\  But you got to do the right thing.

I will say this I have only dealt with the econo series Bus controllers, I do believe the accelera bus controllers can handle DR using the same programming techniques that ethernet controllers use.  So you might just be able to drop the econo bus and not have to do any special coding for the accelera bus controllers...  I checked and Accelera Bus does except the DR command.  Also checked and the Econo Bus controllers have to use the QR command which is not efficient and takes extra coding effort.

Matt
Title: Re: Problems with losing position
Post by: bubba on February 13, 2014, 11:40:25 AM
Smurph thanks for your response.

If you drop support for the Bus Based Galil cards us Folks who have them will still be able to use Mach3 as long as we do not update Mach3 should be ok still using them yes?

So what card do you recommend getting?

Thanks,
Joe
Title: Re: Problems with losing position
Post by: smurph on February 13, 2014, 12:08:27 PM
Yes.  But you can only be assured it works with XP32 and Smart Term.  :(  XP is a bit long in the tooth these days and MS will drop support for it in 2 months!  But if you get a machine that is stable with it, you should be able to run Mach3 on XP for quite a while.  Just remember that if something goes "poof", you will have a hard time getting it replaced as compared to just buying a new PC and going from there.  Most new PCs don't even have the good 'ol PCI slots anymore.  :(

I recommend any Ethernet controller.  21x3, 21x0, 22x0 for the older ones.  41x3 and 40x0 for the new ones.  The new controllers are really fast.  They take input from the command line approximately 10 times faster.  They also have a new motion mode called PVT (vs. linear interpolation) and can also use contour mode.  Ethernet will be around for a really really long time.  And it requires no driver from Galil that may become antiquated by new Windows versions or hardware changes.

Steve
Title: Re: Problems with losing position
Post by: bubba on February 13, 2014, 12:18:12 PM
Yes I guess I should just sell the Galil cards on ebay and start over.

It has been so long since I have used XP PRO I hope I can still remember how to use it!  ;D ;D
Title: Re: Problems with losing position
Post by: HillBilly on February 13, 2014, 02:34:12 PM

The no nonsense combo that WILL absolutely work is Windows XP32 with Start Term (version 7) drivers. 

Steve

Steve (Smurph),

Is there a version of Mach you prefer with this combination?

Thanks Darek
Title: Re: Problems with losing position
Post by: smurph on February 13, 2014, 07:21:33 PM
I'm running Version R3.043.062.  But I'm sure the newest Mach3 Rev. would also work.

Steve
Title: Re: Problems with losing position
Post by: bubba on March 01, 2014, 12:48:17 AM
CNCToolDie,

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

See if it fixes the stop problem.

Hey Smurph has the Plugin in the Downlaods section been updated to this?

Steve


Title: Re: Problems with losing position
Post by: smurph on March 01, 2014, 12:29:24 PM
No, it has not been updated.  I will have to build a full release and get the web gods to comply with a small sacrifice of some inanimate object.  :)
Title: Re: Problems with losing position
Post by: bubba on March 01, 2014, 04:29:58 PM
Ok got it!
So we should use this oneYes?
http://www.smcomp.com/~smurph/galil/Galil-st.zip

Thanks,
Joe
Title: Re: Problems with losing position
Post by: CNCToolDie on March 03, 2014, 10:51:22 AM
Follow up, that may help somebody else following this thread.  With this new plugin I was cutting a small circle .400 with 1/4EM, then moving off 5" in Y to change the part then repeating many times (x100), I found I was losing location in Y.  Knowing Galil pretty well I carefully reviewed the Galil plugin log and saw no cause for the drift.  I then recreated the arc program in DMC language and ran it in DMC smart terminal (ST), it did drift in Y although a factor of 10 less over the same number of cycles, but still not right.  Neither Mach or ST ever drifted in X, even when I made the 5" move in X.  I think this proves what Steve originally suspected that I must have something mechanically wrong with my CNC.  Over the weekend I took Y completely apart and did find a point of slip, I am fixing that.  Thank you Steve! ;D  

Any thoughts why the mechanical would cause a greater position loss in Mach3 than it would in ST...  Hmmm as I write this I think the difference could be the motion profile dynamics are different in Mach3 than they are in ST, so it makes sense that the mechanical flaw would show it self differently.  To show a flaw in ST you need to push the motion profile harder with more complex moves, this is why I did not originally see the problem.  It is like a car with a mechanical flaw may not show when a Granny (ST) drives it, but will show when a race car (Mach) driver drives it.  You can push ST harder with greater AC SP and more moves, you just have to do that in testing like this.  I could have saved myself some time by pushing things harder in ST.  I learned something here.

Also while I am redoing things I am changing the gear ratio of Y to match X.  I advise somebody building a machine to do this because it makes it much easier to use ST to test (or use for production in a pinch) since you can not easily have a different pulses per inch in ST like you can in Mach3.

Matt
Title: Re: Problems with losing position
Post by: bubba on March 03, 2014, 11:37:36 AM
Thanks for that Matt.

If you would not mind could you try to explain the gear ratio part of Mach.
I keep reading that section, but I just do not really get it

Thanks,
Joe
Title: Re: Problems with losing position
Post by: smurph on March 03, 2014, 11:45:30 AM
Matt,

I'm glad you found the issue!  Those things can be hard to diagnose for the very reasons you stated.  

And you also raised a really good point about drive ratios!  Galil does provide some relief for mismatched ratios or encoder counts with the ES command.  But it is limited to Vector Mode operation.  So it is best to have the ratios the same to reduce headaches.  Trying to code a circle in Galil code with different axis ratios can make one's head explode...

Steve
Title: Re: Problems with losing position
Post by: smurph on March 04, 2014, 02:38:49 AM
If you would not mind could you try to explain the gear ratio part of Mach.
I keep reading that section, but I just do not really get it

In Mach, we need to know the amount of encoder counts that results in 1 unit of measure.  If you set your machine up for inches, then we want to know how many encoder counts/steps it takes to move the axis exactly 1 inch.  Hence the term Steps per Unit.  One of my machines is 12700 steps per inch.  This is inclusive of any gear reduction!  But in the end, we don't care about the gearing.  Only about how many steps it takes to get to one inch.  If you set Steps Per Unit in "Config -> Motor Tuning" to this value for each of your axes, you can't go wrong. 

Mach allows each axis to have a different steps per unit.  In a simple scenario like a 45 degree angle cut, X may move 2000 counts and Y may move only 1000 counts.  But if the steps per unit for X and Y are correct, they will both move the same distance and thus produce the 45 degree angle.  This works fine in Mach because we told the machine to move a certain distance that is based in the user units for X and Y.  This is a lot tougher to deal with on the Galil because you are not dealing with distances.  You are working in encoder counts!!  1000 counts on X would be exactly half of the distance of 1000 counts in Y in the 45 degree angle scenario. 

So in Galil code, you have to do a little math in your head to extrapolate a distance based on the number of counts it takes to get there for any particular axis.  In stead of saying "G01 G91 X1 Y1" in Mach, you would give the Galil a command of "PR 2000, 1000" to do the same move.  PR is "Position Relative" (incremental move) and is equivalent to G91 in G code.  So you can see here that having the same number of counts to move each axis a certain distance is VERY beneficial when working in the Galil environment.  It makes things a lot more simple.  Now, how about plotting a circle with X and Y counts per inch being different?  Boom!  Mushroom cloud!  At least in my head it is. 

This is not an issue in Mach because Mach does all of the math for you.  Isn't Mach wonderful?  Thank you Mach!

Steve
Title: Re: Problems with losing position
Post by: bubba on March 04, 2014, 07:59:37 PM
Thanks
Title: Re: Problems with losing position
Post by: CNCToolDie on March 18, 2014, 10:39:33 AM
Steve,

I finished rebuilding my Y axis to be identical to the X, same counts per inch, brackets, etc..  The problem of losing position (thru DMC Smart Terminal) got worse and more erratic!  An electrical engineer I consulted with said he has seen this when there is a floating ground.  SO I plugged in an extension cord and took an Ohm meter from that ground to the motor body, router, frame, etc, all seemed well grounded.  The cable shields connection to my 100 pin break out box were also grounded.  The problem was the cable going from the 100 pin break out to the amps was shielded but not grounded, I grounded that reran the test in DMC terminal cutting the same hole 70 times and the size only grew .001.  Next in Mach3 programmed a a loop to cut a hole measured it, then put it in a loop to cut the hole 50x, again only grew .001. So the ultimate issue was a floating ground.

For somebody in the same boat of losing position here is a list of things I did when trying to fix this problem.
>Try a test cut in DMC ST or Galil Tools  (Problem showed there when I increased AC and SP, which rules out a Mach3 setup). Be sure that you have your Galil setup properly good PID, AC, DC etc and BN.
> Replaced all the cables with shielded and grounded cables.
> Formatted and rebuilt my PC. (probably should have been the last thing I tried, the PC does not have much effect on a Galil)
> Checked and rebuilt my mechanical drive to make it as good as possible.
> Tested the ground of all components.  (Found the shield on the cable going to the amps was not grounded, this caused my position loss issue).

All is well now, now I get to cut some cool stuff, can't wait!!
Thank you so much!
Matt
Title: Re: Problems with losing position
Post by: CNCToolDie on March 18, 2014, 10:42:05 AM
The electrical engineer also said be sure to only ground your encoder shield on the controller side not the motor side.  Just leave the aux encoder shield loose on the motor side.  Mine was already this way, but maybe that will help somebody in the future.

Matt
Title: Re: Problems with losing position
Post by: CNCToolDie on March 19, 2014, 11:32:06 AM
Follow up, cut a sign that takes 1/2 hour each last night on 3 different boards, they were all spot on, to the .001 of each other.  This sign in the past would get off from 1/8" to 1/4" over the length of the sign, cutting this same g-code successfully proves the open ground caused this problem.  If you have a position issue, I definitely recommend checking your grounds and use shielded cables with the shields grounded.

Matt
Title: Re: Problems with losing position
Post by: steve_p on July 11, 2014, 11:25:01 PM
I had similar issues when setting up my Mach-galil machine. Everything was fine when doing 2.5D work, but when I did a 3D surface what should have been a rectangular file was cut as a parallelogram. The drift was about one inch in the Y for every 12 inches of X travel, always in the same direction. After weeks of pulling my hair out trying to eliminate mechanical slip and retuning the servos countless times, I narrowed it down to noise, which I think was being emitted by the z axis motor (hence the problem with 3D files) and adding spurious counts to the Y encoder input. After making sure all proper grounding recommendations were followed, and even replacing the z servo and cables ($$!) the problem was reduced but not eliminated (it is a commercial machine I converted so the wiring/earthing was well laid out anyway.)

I eventually solved it by swapping from an Ethernet controller (2160) to a PCI one (1860). Something to do with the galil having its own ground independent from the machine, I guess?

So 1. noise can indeed cause major problems. And 2. please don't drop PCI support!!