'Pause' input to step generation?

Hi,

I am a new LinuxCNC user since I bought a BF20 (G0704) mill and quickly found out that adding stepper motors is just as expensive and more flexible as adding a DRO.

To keep cost fairly low (and just because I can), I designed the stepper motor drivers myself around a Microchip dsPIC33F DSP. They currently do 80 Volts/5Amps/128 microsteps/dynamic step interpolation at lower speeds/dynamic current adjustment/control loop at 60kHz/etc.



Now, the mill is running fine at the moment and the drives perform as well as they can given the limited supply voltage of 75 Volts, but somehow I don't like the fact that I have to incorporate a significant safety margin in the max. speed/acceleration to make sure that the steppers don't miss a step.

I am considering designing and building a version 2.0 of the drivers using an FPGA and more sophisticated voltage/current measurement scheme to increase loop bandwidth / chopper granularity and running a rectified and power factor corrected mains voltage as the motor voltage (400 volts). This would allow me to push the steppers to their maximum performance.

When doing so, I'd like to add an encoder to the motor shafts so I can determine if the motor has already moved to commanded position. Integrate 4 axes on one board, and it would be easy to output a signal telling whether the drives are ready for a next motion command or not. This would allow me to setup LinuxCNC to speeds/acceleration values above the physical limits and obtain maximum acceleration and speed regardless of mechanical load because the step generation would be halted when the drive is not yet ready to receive the next step pulse.

Now, how hard is it to add a 'pause step generation' input to LinuxCNC?

Hi John,

Thanks for the reply and the thumbs up on the boards. Best thing is that they work flawless

Regarding my question: would halui.program.pause give me the ~10usec granularity I am looking after? I would rather interact with the step generator itself, is that possible? It is more a 'handshake' or 'flow control' that I'm after.

motion.feed-hold is the fastest response HAL pin you have access to.

But I think you going about this the hard way.
First you don't mention the step generator settings you've tried. Step length etc. did you adjust them?
This could cause missed steps. also step on active hi or active low can make a difference depending on those same settings.

Second if you really want to try closed loop steppers then you should have linuxcnc close the loop with encoder feedback.
Which require more then a parallel port for any reasonable speed, due to the encoder reading.

Asking liuxcnc to stop and start commands while trying to coordinate multiple stepper motor just seems the wrong thing to do.
Even servos don't do that.

Sorry to be a downer, just wasn't sure if you exhausted other ideas first.
but aside from building the boards, it's not hard to try your idea !

Chris M

cmorley wrote:

motion.feed-hold is the fastest response HAL pin you have access to.

OK. At what rate is this pin scanned? Same rate as the step generation, of slower?

But I think you going about this the hard way.
First you don't mention the step generator settings you've tried. Step length etc. did you adjust them?
This could cause missed steps. also step on active hi or active low can make a difference depending on those same settings.

Sure. The problem is entirely the steppers losing torque because of high RPM in combination with limited supply voltage.
Now, this is normal. If I stretch the limits of the drive, I can go faster but the 'problem' just shifts.

The problem is: it takes more force to accelerate a 20kg load on the table than it does to accelerate a sheet of plywood. Now, I have to setup for the worst case to avoid losing steps. This is not an ideal situation.

I could have LinuxCNC close the stepper loop, but it is just as easy to let the drive handle that so one step from LinuxCNC is one step done. Having access to encoder status during stepper (or BLDC) waveform generation is also a big plus, another reason to let the drive handle that.

Now we only need a method to signal LinuxCNC that is is OK to perform another step because the drive is finished moving the motors to the desired position. This is a fast process; the drive might require only 10usec to perform the requested operation when things are already moving, or several 100's of usec when starting at v=0.

In my opinion (but I might be wrong) it would be great to setup LinuxCNC to a slightly higher acceleration and speed than the mechanics can handle, and have some form of handshake mechanism slow things down when needed.

Second if you really want to try closed loop steppers then you should have linuxcnc close the loop with encoder feedback.
Which require more then a parallel port for any reasonable speed, due to the encoder reading.

As mentioned above: having access to position information during waveform generation is also a big plus. A second feedback loop using for example glass scales, now, that is a different thing.

Asking liuxcnc to stop and start commands while trying to coordinate multiple stepper motor just seems the wrong thing to do.
Even servos don't do that.

Not stop and start commands, just pause the step generation.

Sorry to be a downer, just wasn't sure if you exhausted other ideas first.
but aside from building the boards, it's not hard to try your idea !

No problem, I might be on the wrong track too. But so far, I don't see LinuxCNC as the best candidate for running the closed loop steppers (or BLDC motors; those are steppers with only a few steps per revolution); there are just too many advantages in connecting ancoders to the drive and have the onboard FPGA handle those.

The motion component is usually run at the servo thread rate.

Ya I can't see the big plus side here (hey I'm no expert at all)
I can't see having linuxcnc ask the machine to accelerate and move faster the it can, then have the drive say stop when it gets behind.
That seems a little crazty how do you keep everything in sync? and when linuxccnc pauses everything stops - right now.
pausing the step generator will put it our of sync with the other generators ( and AFAIK there is no way to pause the step generator without losing position info)
can't see how you will get smooth movement from that.

You might as well just have your step drives do their best to stay on course and if they can't keep up throw a following error.
If your drives truly can't keep up to what you are asking them to do why would you keep asking them to do that?
The nice thing about having encoders on your steppers is you DO know when it's not keeping up.
You could also feed the pass the encoder info from the drive to linuxcnc. then the drive does speed loop linuxcnc does the position loop.

anyways there is also another pin that you may be interested in motion.adaptive-feed it will be multiplied to the current feedrate.
You could use some HAL magic to have it reduce the feedrate if a pin was true (like from your drive

I'm sure some motion control wizards will come along here and give your idea a look too. Peter from Mesa is a good motion control guru

You did some real nice work on those boards - you must do that for a living?
Chris M

cmorley wrote:

I can't see having linuxcnc ask the machine to accelerate and move faster the it can, then have the drive say stop when it gets behind.

Maybe don't think 'stop', but more 'slow down'.

how do you keep everything in sync?

Simple: all axes are good to go, or one or more are not and that's the point where LinuxCNC should slow down a little.
Now I have to adjust speed and acceleration low enough that all axes are always 'good to go' before the next step arrives.

How is it done when running servo's with linuxcnc closing the loop? When a servo has not reached it's commanded position yet LinuxCNC cannot command a new position, right?

You might as well just have your step drives do their best to stay on course and if they can't keep up throw a following error.

Following error means hard error and possibly a scrapped part. But why? Eventually the motors will reach their commanded destination.

If your drives truly can't keep up to what you are asking them to do why would you keep asking them to do that?

Because doing that and using a flow control mechanism means that the software adjusts itself to the capabilities of the hardware. If I load the table with some light sheet material, I can accelerate faster than when I load the table with a chunk of heavy metal. Acceleration rates at higher speeds is lower than acceleration from standstill, but LinuxCNC wants me to enter a fixed value. Why should I setup LinuxCNC for the absolute worst case and hope for the best?

It's the same when you load up your car for a holiday. You tell your wife to bring more luggage when you can handle it, or you tell her to wait a little while when you cannot handle the rate. You are not telling your wife: 'bring me one piece of luggage every minute, and I shall cope with it'.

You could also feed the pass the encoder info from the drive to linuxcnc. then the drive does speed loop linuxcnc does the position loop.

Would be easy to do. But if I inform LinuxCNC of a position, I'd rather feed it from scales.

anyways there is also another pin that you may be interested in motion.adaptive-feed it will be multiplied to the current feedrate.
You could use some HAL magic to have it reduce the feedrate if a pin was true (like from your drive

Might be an even better solution indeed.

You did some real nice work on those boards - you must do that for a living?

Yes, I do.
But these boards are not exactly a showcase of my abilities; they are more a 'parts bin' build. I slightly tuned the design to what I had already available. If the boards were meant for production, they would be half the size or less.