Adjustsoftlimits.c and mpgsmooth.c not working togeather? Caused runaway!

[mmurray70]

Hi guys Im using the mpgsmooth.c program on my mill and i have soft limits set about an inch in from end of axis travel. The soft limits work perfecty if jogging in kmotioncnc or if running a g code program. When using the mpg, it doesnt start to stop until it hits soft limit so it overshoots soft limit by nearly half an inch if your really spinning the wheel fast.

This weekend i tried adding the adjustsoftlimits.c program and it appeared to be working fine at first. It would stop at the soft limit and not overshoot. But i noticed when your spinning the wheel fast on high speed (0.010" increments) it sounded a little rough. Played around with it a little more, and while spinning the mpg super fast it started to sound really rough and suddenly took off near rapid speed in the opposite direction i was feeding. Had to use E-stop to stop it. I restarted everything and tried same thing but with 0.001" increments and it did the same thing, took off in oposite direction of what i was feeding when spinning very fast.

I went back to my old init file without adjustsoftlimits.c and everything was fine. Im using Kmotion 4.33, could this be a problem? Do i need 4.34? Any other ideas or suggestions? It would be nice to stop the mpg from overshooting so i can move my soft limits a little closer to the end of travel. Thanks

Similar Threads:

• MPGSmooth.c
• What caused this?
• Damage caused by crash
• Bad ballscrew in z axis. What could have caused this?
• the straw that caused the camel to go cnc...

[TomKerekes]

Hi mmurray70,

The original MPGSmooth.c program counts the encoder pulses using software. In order to handle encoder counting higher than what could normally be handled in software (~5Hz) it uses a trick that assumes the velocity can not change instantly. Based on the previous velocity it can predict how many counts it should/must have missed. This trick can normally increase the count rate about 10X and works very well. Unfortunately if the velocity does appear to change instantly due to noise or jitter in sampling time the algorithm can get confused and think the encoder is moving rapidly (and aliasing) when it is actually still. I suspect the time to do all the AdjustLimits calculations is slowing down and/or causing jitter in the MPG sampling.

If you don't intend to move the MPG faster than 5KHz you can defeat the "trick" by changing line:

DiffX2 = 2*(Pos-PosNoWrap) + (Change2+Change1);

to
DiffX2 = 2*(Pos-PosNoWrap);

In this case there should never be any run-away no matter how instantly the MPG changes speed. If you move the MPG too fast it should result in improper counting and jerky motion but never run-away.

Another option is to use a hardware encoder counter that always counts reliably up to 1MHz. See the example: MPGSmoothHardwareEnc.c

Another option might be to run the MPG and AdjustLimits in different threads so they would have no effect on one another.

Regards

[mmurray70]

Hi Tom,

Thanks for the explanation and suggestions. My MPG doesnt have differential encoder outputs so i guess i cant use the MPGSmoothHardwareEnc.c without something to convert to differential?

I should be well under 5khz. I dont think it would be possible to spin the wheel faster then 10 times per second and that would only be 1khz. So I will try modifying the code first.

If I were to try running it in a separate thread, is there a way to launch this thread from my init file? I have seen the "Execute<N>" command but this only works if previously loaded right? Is there any way to tell KmotionCNC to run an M code from C? I could use some odd number M code to launch the program maybe. Thanks again.

Mark

[TomKerekes]

Hi Mark,

Note in most cases you can connect single ended encoder inputs to KFLOP's single ended encoder inputs. See also:
Dynomotion Motion Control Boards for CNC Manufacturing and Robotics Applications

You are correct if you want to use additional Threads then the code needs to be loaded into them somehow. You might use the KMotionCNC Startup Action to do this. Or as you describe you might use a hidden User Button or MCode to load/execute the program and have your Init C program tell KMotionCNC to "push" the button or run the MCode. See PC Commands:
#define PC_COMM_USER_BUTTON 13 // Persist+1 is which User Button to push
#define PC_COMM_MCODE 14 // Persist+1 is which MCode to execute

HTH
Regards

[mmurray70]

Hi Tom,

I did some more testing and you were exactly right. Modifying the code stopped the runaway but when turning very fast it was rough and motion actually slowed down. Tried running adjustsoftlimitstest.c in another thread and everything worked great. Im still using the modified code.

I got the adjustsoftlimits program starting automatically by assigning it to M code 101 and adding the following to my init file just before my forever loop : DoPCInt(PC_COMM_MCODE,101);

Thanks again,

Mark

[TomKerekes]

Hi Mark,

Great and thanks for posting back.

Regards