Understanding hardware stepgens

Thanks Jon, that is pretty cool! Unfortunetly I am not adding encoders. Care to help me out with exactly what is going on between HAL and your hardware? Do I have the concept correct? In my case I will be reporting the acc value for the position I assume.

Still stuck with how to generate what is being sent to the hardware stepgen, and how to generate that in HAL.

And thanks Peter. Maybe I need a simple config to look at to find the answers I seek, does anyone have a suggestion for what one I should look at?

Maybe I am starting to see this:
axis.N.motor-pos-cmd is what I "send" to my hardware?

If so, then my hardware needs to calculate the difference between it and where it is now to decide how fast/far it needs to move before the next thread read? This seems not right to me, maybe it is starting to dawn on me now. If I use axis.N.joint-vel-cmd instead of position, would this be what I have referred to as the "adder" a few posts ago? That seems easier if I am correct.

then
axis.N.motor-pos-fb is where my accumulator value is "sent" back to? or would I want to use axis.N.joint-pos-fb?

As always, thank you all for your help in trying to get this newbee on track.

btvpimill wrote:

Thanks Jon, that is pretty cool! Unfortunetly I am not adding encoders. Care to help me out with exactly what is going on between HAL and your hardware? Do I have the concept correct? In my case I will be reporting the acc value for the position I assume.

My boards all use the parallel port to communicate with. Using the EPP mode,
you can send an 8-bit address to the target device(s) and then transfer data.
So, what I have is an address counter in the board, which increments in
sync with the transfers. So, you set the address once and can then read
or write a string of consecutive registers. Our Universal Stepper Controller
has 24-bit position counts, and 24-bit step rate counters. it does not use
the direct digital synthesis scheme, but just a counter that counts up to
a limit, issues a step and then starts back at zero. This was simpler in the
early days of FPGAs. The count limit is computed as :
(FPGA clock)/(rate in steps/second)


So, the servo cycle is like this:
1. read all position counters, compute velocity, etc. in PPMC driver
2. perform trajectory interpolation, PID, etc.
3. output new velocity in PPMC driver

Still stuck with how to generate what is being sent to the hardware stepgen, and how to generate that in HAL.

That would be the value written to ppmc.xx.stepgen.yy.velocity
where xx is the parallel port number (usually zero) and yy is
the step generator number. Normally, it is a value sent directly
from the PID component to the step generator.
The HAL parameter ppmc.xx.stepgen.yy.scale
scales this velocity from user units/second to the necessary
step pulses/second.

You can browse the source code here :
<git.linuxcnc.org/gitweb?p=linuxcnc.git;a...b2e76ad09867;hb=HEAD>

sorry for the hideously long link.

You can read the univstep sample configs file set in any LinuxCNC
distro to see how it is all connected up.

Jon

Jon, Thank you for this great explanation!! So I suppose if I send the axis.N.vel to my hardware, that will be what gets added to the accumulator until the next vel comes in.

Quite intresting stuff this is

btvpimill wrote:

Jon, Thank you for this great explanation!! So I suppose if I send the axis.N.vel to my hardware, that will be what gets added to the accumulator until the next vel comes in.

Quite intresting stuff this is

Well, my USC doesn't use an accumulator, it uses a counter and a
limit comparator. When the count exceeds the limit, it resets the
counter to zero and issues a step. The driver does all the calibration
to figure out what value to send to the hardware. Then, it just keeps
on doing the same until the next value comes in.

Jon

Thanks Jon, I am trying to let your driver sink into my brain.

Thank you Andy, This may also help me get going in some(hopefully correct) direction. Of course there will be feedback, but I am guessing not the kind you are talking about.

In an effort to wrap my brain around this better - here is what I think happens:
first current position is read from hardware - This is either the current value of counter/accumulator or encoder feedback value
however the position is determined in hardware, this number is given to axis.N.fb pin. lets call this 9.997
LinuxCNC (lcnc) has on pin axis.N.cmd a value of say 10.000
current position is 9.997
in PPMC, the driver determines .003" needs to move over the next mS, so some number corrasponding to generating the steps needed is sent to hardware
in MESA, the hardware figures out that .003" needs to happen over the next mS and generates the needed steps to make that happen.

Both of course need a scale number to know how many steps it takes to get .003" of travel, so counters/accumulators/whatever are running to make those steps.

I am assuming here that axis.N.cmd is an absolute position and not an incremental one. I guess maybe that is my last bit of confusion for now. Of course if it is incremental thigs get easier, then axis.N.cmd would equal .003 instead of 10.000

btvpimill wrote:

Thanks Jon, I am trying to let your driver sink into my brain.

Thank you Andy, This may also help me get going in some(hopefully correct) direction. Of course there will be feedback, but I am guessing not the kind you are talking about.

In an effort to wrap my brain around this better - here is what I think happens:
first current position is read from hardware - This is either the current value of counter/accumulator or encoder feedback value
however the position is determined in hardware, this number is given to axis.N.fb pin. lets call this 9.997
LinuxCNC (lcnc) has on pin axis.N.cmd a value of say 10.000
current position is 9.997
in PPMC, the driver determines .003" needs to move over the next mS, so some number corrasponding to generating the steps needed is sent to hardware

No, this is NOT in the PPMC driver, it is in the PID component. PID compares the
commanded vs. actual position (instantaneous following error), the current commanded velocity, the
change in following error since last sample, etc. and computes a new velocity to send to
any of the devices (stepper, PWM servo, analog servo).

in MESA, the hardware figures out that .003" needs to happen over the next mS and generates the needed steps to make that happen.

Both of course need a scale number to know how many steps it takes to get .003" of travel, so counters/accumulators/whatever are running to make those steps.

I am assuming here that axis.N.cmd is an absolute position and not an incremental one. I guess maybe that is my last bit of confusion for now. Of course if it is incremental thigs get easier, then axis.N.cmd would equal .003 instead of 10.000

Yes, the position command is in absolute machine coordinates, in user units (typically
either inch or mm).

Jon

OK, I think this is all clear as mud now. (just kidding I do think I am starting to get it). For now I will leave it at this until I have a machine up again and can actually look at these signals as they are generated. Well maybe I can, I am sure they are hard to watch, but I could send them out the parallel port and snoop them with a logic analyzer or grab them some other way.

Anyway, thank you all fr the help given thus far, I will be back to this in a few weeks or so.