[GJeff]

I'M A MORON - This report was not accurate. PathPilot does NOT LOSE POSITION jogging to soft limits as I originally stated.

kstrauss was right. I must have had some inertial issues with my indicator. stupid, bad setup. I retested and there was no motion lost.

************this is inaccurate, but kept here to document my stupidity*****************
I'm not sure if this is a necessary PSA or something that everyone already knows, but it seems a bit counter intuitive to me. Everybody loves having their machine come to what appears to be a graceful stop at a soft limit rather than hitting the limit switch and triggering an estop, but BOTH cause significant losses in position. I don't know the details of the motion controller, but it seems like an unnecessary issue, too. I realize that it can't instantly decel (mach3 had a way to start to decel when you got close), but the machine should know how far the steppers have over rotated, no? And yet the readout makes it appear as though you stopped right at the 0 or 18, 0 or 9.5 limits. Yet every time you hit a soft limit you're going past the location PathPilot tells you that you are at.
Bug? Or natural limitation?
************this is inaccurate, but kept here to document my stupidity*****************

[Jim Dawson]

I was working with a MultiCam router today, repairing the Z axis motor. As I was rapiding up, it got near the upper soft limit and went into decel about a half inch before it stopped at the soft limit. I really didn't expect that to happen, so I tried it a few times just to be sure.

If there is no encoder feedback, the controller has no idea where the stepper is actually at. If the controller just instantly quits sending steps at the soft limit, but the motor coasts a bit, then you are going to lose position. That is a programmer being lazy. It's $&(# like this that caused me to write my own software. I can do anything except power down the computer and not lose position.

[GJeff]

I hear ya. Obviously there are limits of what to expect out of the Tormach software team. They build PathPilot on top of LinuxCNC, not from scratch, and if this is the default behavior of LinuxCNC, it's not surprising they haven't gone beyond to fix it. There are bigger problems with PathPilot right now, mainly being unable to jog during a job pause ><

Certainly not enough to make me want to back to Mach3. I'd rather have these limitations that are known than having an windows hiccup send my Z axis careening into suicide mode. Still not sure how I managed to e-stop that one in time. RIP Mach3.

[Jim Dawson]

That's crazy also. I can pause, reset, jog, park axis, estop and move axis manually, then restart from anywhere in the program. Also work in AutoCad or a CAM program while the part is running.

[GJeff]

Maybe you should market DawsonCNC Probably servo only at the moment though.

[Jim Dawson]

I have thought about it, the problem is that it will only work with Galil Motion Control products. Those are out to the price range of many hobbyists. It will run AC or DC servos in closed loop, steppers in closed loop, or open loop. It will also translate any known G-code file, no special post processors.

[GJeff]

Well if I ever upgrade to galil controllers (which would only happen if I got servos) I'll let you know and offer my free testing services

[Jim Dawson]

Sounds like a plan, I'll be happy to give you my software. Oh, and it will run on WinXP to Win10, PC or laptop.

[RTP_Burnsville]

I just checked out the Galil Motion Control products, that is some interesting stuff....... I recently retired from years of embedded control programming so am more of a geek than most here. BTW, what would a ballpark cost be to play with the Galil products?

Robert

[109jb]

I don't use pathpilot, but rather LinuxCNC that pathpilot is based on. However, in LinuxCNC, DOES NOT lose position when jogged into a soft limit. When it reaches the actual hard limit switch it does lose position because it disables the axis drives. When jogged into a soft limit it stops exactly at the boundary of the defined soft limit area and leaves the axis motors enabled.

I have been using LinuxCNC for about 7 years now, and this is the behavior I have become accustomed to but since reading this thread I decided to perform a test to verify this. I did this by powering on my machine, intentionally jogging the X axis to one end until it stopped due to reaching the soft limit boundary. I zeroed the axis in LinuxCNC at that point, and set up a dial indicator at that location. I then repeatedly jogged off the soft limit and then back into the soft limit at my machine's maximum jog rate (200 IPM). When the machine stopped, the LinuxCNC DRO read 0.0000" and the indicator also read 0. I repeated this multiple times always with the same result. I then repeated these actions at both ends of travel on all axes and got the exact same results.

The above test verified that LinuxCNC does not lose position due to jogging into the soft limit boundary. It simply makes a controlled stop exactly at the boundary. Additionally, a program move in a G-code file or MDI that would exceed the soft limits are not executed in LinuxCNC. The controller simply tells the operator that the move would exceed the limit. In the case of a G-code program, it won't even let the program start if a line farther into the program exceeds an axis limit.

Like I said, this was in LinuxCNC which PathPilot is based on. I can't say with 100% surety that it is the same in PathPilot, but I wouldn't think it is different.

Assuming that position is indeed being lost when running into a soft limit, I have a couple questions and possible reasons based on my LinuxCNC experience.

1. When it happens, does PathPilot disable the axis drives?
If the drives get disabled this indicates that the hard limit switch was activated. The soft limit boundary should not be exactly where the hard limit switch triggers. There should be a buffer area between the soft limit boundary and the actual mechanical switch. On my LinuxCNC machine I have this set up to provide 0.050" of extra travel between the soft limit boundary and the switch activation.

2. Have you verified that PathPilot is indeed losing position by using a dial indicator as described above to verify that position is lost?
If you haven't done this then you should. If it is indeed not activating the hard limit switch and losing position then you should contact Tormach because this is not how it should work.

[Jim Dawson]

I just checked out the Galil Motion Control products, that is some interesting stuff....... I recently retired from years of embedded control programming so am more of a geek than most here. BTW, what would a ballpark cost be to play with the Galil products?

Robert

The least expensive 3 axis controller from Galil is $1345

There are a lot of Galil product on Ebay for about $100 and up. Some good deals, some not so good.

[GJeff]

1. When it happens, does PathPilot disable the axis drives?
If the drives get disabled this indicates that the hard limit switch was activated. The soft limit boundary should not be exactly where the hard limit switch triggers. There should be a buffer area between the soft limit boundary and the actual mechanical switch. On my LinuxCNC machine I have this set up to provide 0.050" of extra travel between the soft limit boundary and the switch activation.

2. Have you verified that PathPilot is indeed losing position by using a dial indicator as described above to verify that position is lost?
If you haven't done this then you should. If it is indeed not activating the hard limit switch and losing position then you should contact Tormach because this is not how it should work.

*****This is inaccurate. PP does not lose position when jogging to soft limits*********
1. They are not being disabled. Pathpilot uses a buffer too, I didn't measure the exact amount, but it's staying inside the buffer for my tests.
2. Yes, I did the same test as you from the start, jogging at 110IPM to the boundaries and watched my dial indicater jump progressively higher and higher every soft limit hit.. I could have kept going to hit the hard limit, but there was no point in testing that.
Not sure how they screwed this up if the default behavior in LinuxCNC is superior. I may need to just switch to LinuxCNC... or start looking for a galil controller.
*****This is inaccurate. PP does not lose position when jogging to soft limits*********

[popspipes]

I have never had a problem with the soft limits, however I dont test them as you are doing, and if so its before I run a program, PP will throw an error if it will exceed the set point of the soft limits and will not proceed until I reposition the part and clear the error.

When I run a program, I have pre determined that it wont hit the soft limits. I have never hit the soft limits while the program is running.

Maybe I am missing something??

[GJeff]

It's not a problem during a single program run.

The problem arises if you run a program, stop it, jog an axis to a soft limit while setting up workholding, etc, then start a new program that assumes the positioning is still accurate. It'd be very common for someone to jog up to max Z for workholding adjustments if they thought it retained proper position. It doesn't.

[kstrauss]

2. Yes, I did the same test as you from the start, jogging at 110IPM to the boundaries and watched my dial indicater jump progressively higher and higher every soft limit hit.. I could have kept going to hit the hard limit, but there was no point in testing that.

I was intrigued by your report and decided to repeat the test on my machine. I have a 770 series 3 running PP 1.9.7. I ran to left X soft limit, zeroed the X-axis DRO, setup a mag base and 0.0005/div DTI with some preload against the spindle. I then backed off a few inches and jogged at full speed into the indicator. After at least a dozen tries the indicator (and the DRO) read the same so probably within 0.0001 or so. I didn't try the Y or Z axis. What is the difference between our two environments? How much does your indicator change after each run at the soft limit? Is it possible that you are getting indicator movement because of the rapid deceleration?

[GJeff]

I was intrigued by your report and decided to repeat the test on my machine. I have a 770 series 3 running PP 1.9.7. I ran to left X soft limit, zeroed the X-axis DRO, setup a mag base and 0.0005/div DTI with some preload against the spindle. I then backed off a few inches and jogged at full speed into the indicator. After at least a dozen tries the indicator (and the DRO) read the same so probably within 0.0001 or so. I didn't try the Y or Z axis. What is the difference between our two environments? How much does your indicator change after each run at the soft limit? Is it possible that you are getting indicator movement because of the rapid deceleration?

I'M A MORON - This report was not accurate. PathPilot does NOT LOSE POSITION jogging to soft limits as I originally stated.

kstrauss was right. I must have had some inertial issues with my indicator. stupid, bad setup. I retested and there was no motion lost.

The issue that originally lead me to believe that there was a problem was this:
1. Use the automatic homing feature to find the Y axis limit
2. Zero the Y Axis. When I do this it reads -0, not 0. This is probably significant.
3. Jog your Y axis toward the soft limit that you're supposedly already at. When I do this I HEAR the table move and it goes to 0. This is not repeatable, however, thus never adds up to anything significant. It's probably due to some rounding issue whereby for some reason it puts your table at -.00005 Y rather than true Y zero when homing, then allows you to reach true zero via soft limit jogging.

Edit: I believe this last issue (which is a non-issue either way) is likely caused by backlash compensation.

[109jb]

I'M A MORON

No your not. You just got deceived by a less than optimal setup. Anyone that has been in machining for any amount of time has done something like this. I could tell you stories about things I have done with a machine that make this issue a non-event.

[GJeff]

Well when it comes to making CNC mistakes, the consequences of this one were cheap for me - there's no carbide on the floor! I just want to be sure I don't cost Tormach any potential customers. I'm back to being a fan of PathPilot and the Tormach controller (worth the money for me not having to mess with Linux or hardware configs on my own), given that this is a non-issue and the "jogging while paused" limitation is workable for me even with a companion spindle. Apologies to Tormach for my doubts!