How to configure for spindle motor - DC brushed servo w/encoder step/dir

Why not use siggen and the digital output?
m5c
MIKE

Mike_Eitel wrote:

Why not use siggen and the digital output?

The siggen component is servo-thread floating point, trigonometric, and oversampled (less than 1 kHz bandwidth), while stepgen is integer and base-thread.

The stepgen base-thread bandwidth of (10s of kHz) is needed to generate spindle motor signals to run the spindle at decent rpms.

If you meant to suggest freqgen, that has been subsumed into stepgen's velocity mode.

Even at optimistic base-thread rates, the square wave frequency will be aliasing the sum and difference of the nominal frequency and the base-thread rate, introducing heterodyne harmonics that can transmit through the servo controller and make the motor sound strange. A better-featured servo controller would have a speed mode that avoids this artifact of step synthesis.

I've taken a half-witted stab at something.
I generated a vanilla hal file with PWM spindle and xyz axes, then removed what seemed obvious unneeded PWM lines and edited in some lines that I thought might be pointed in the direction of what I need. I'm sure a lot of it is wrong, but if you could take a browse at it and nudge me in a better direction it would be appreciated.
The lines I edited/added are bracketed between the ########## lines for clarity.
Please be gentle.
Oh hell with it! I can take a punch.
Thanks

p.s. I assume that[AXIS_0]SCALE and [AXIS_4]STEPGEN_MAXACCEL are variables which will be found (once I enter them) in the .ini file... if these variables even still exist by the time I work this out.

A couple notes
#spindle things

net spindle-cmd-rpm => stepgen.4.value
^^^^^^^^^^^^^
should be
net spindle-cmd-rpm => stepgen.4.velocity-cmd
This should be OK but will require some scaling...

net spindle-on <= motion.spindle-on => stepgen.4.enable
^^^^^^^^^^^^^^^
Good stepgen disabled when spindle off


stepgen.4.velocity-cmd
^^^^^^^^^^^^^^
leftover? not a valid hal statement

#setp stepgen.4.position-scale [AXIS_0]SCALE
^^^^^^^^^^^^^^^
you will need to set the scaling (unless scale of 1 is ok so Hz = RPM)
also this is not an axis so just use a number like
setp stepgen.4.position-scale 2.5
#2.5 Hz/RPM

setp stepgen.4.steplen 2500
setp stepgen.4.stepspace 2500
setp stepgen.4.dirhold 10000
setp stepgen.4.dirsetup 5000
setp stepgen.4.maxaccel [AXIS_4]STEPGEN_MAXACCEL
^^^^^
This is not an axis so just use a number like:
setp stepgen.4.maxaccel 200


net spindlestep <= stepgen.4.step
net spindledir <= stepgen.4.dir

net spindleenable axis.4.amp-enable-out => stepgen.4.enable
^^^^ delete this line

#spindle things
net spindle-cmd-rpm => stepgen.4.value
^^^^^^^^^^^^^
should be
net spindle-cmd-rpm => stepgen.4.velocity-cmd
This should be OK but will require some scaling...

Copy. I don't know what either one means, but I'll edit the change as directed and look into it

net spindle-on <= motion.spindle-on => stepgen.4.enable
^^^^^^^^^^^^^^^
Good stepgen disabled when spindle off

Total luck, but I see what you mean there. Copy

stepgen.4.velocity-cmd
^^^^^^^^^^^^^^
leftover? not a valid hal statement

Almost certainly just a leftover dingleberry. I'll delete it.

#setp stepgen.4.position-scale [AXIS_0]SCALE
^^^^^^^^^^^^^^^
you will need to set the scaling (unless scale of 1 is ok so Hz = RPM)
also this is not an axis so just use a number like
setp stepgen.4.position-scale 2.5
#2.5 Hz/RPM

setp stepgen.4.maxaccel [AXIS_4]STEPGEN_MAXACCEL
^^^^^
This is not an axis so just use a number like:
setp stepgen.4.maxaccel 200

haha. Well yeah, I doubt I'd be so lucky that the scale is 1.
But arent "[AXIS_0]SCALE" and "[AXIS_4]STEPGEN_MAXACCEL" variables stored in the .ini file or am I mistaken? Not that [AXIS0} will be correct (I just realized this) but I was under the impression that was a stored variable call. It would be easy enough to hard code the values in there once I figure out what they need to be though. I'll enter in some guessed values for those two variables to make things simpler for me.

net spindlestep <= stepgen.4.step
net spindledir <= stepgen.4.dir

net spindleenable axis.4.amp-enable-out => stepgen.4.enable
^^^^ delete this line

Copy. Deleted.

I'll attach the edited file for updated browsing. But I'm gonna go try it out now too and see what kind of new tragedy I can cause.
Thanks for the attention! I do really appreciate it.

Well it's definitely progress.
The file as-is does allow LinuxCNC to start now which I haven't had for a couple days.

So it also does now spin via either manual button in the GUI or MDI commands.
The only problem is it seems to max out at around 120rpm and that is with a commanded RPM of S 5000.
I'm thrilled that it will at least spin now.
And FYI, S values lower than 5000 do proportionally change the resultant RPM down to a crawl, so it is kind of partly functioning as expected.

Yesterday I was testing it on a positional axis configuration and my tachometer was registering a little over 1100rpm, so I do know that LinuxCNC is capable of sending appropriate step/dir signal for higher rpm than it's doing now, just FYI.

I tried changing the SCALE value but it didn't appear to affect the RPM per commanded S-value at all. Curious.

I also tried tweaking the steplen, stepspace, dirhold and dirsetup values and they didn't affect the RPM either, though I didn't really expect it to anyway. (The values I entered are lifted from a table I found in the LinuxCNC documentation. This driver was actually there! The positional axes values entered further down are just working guesses generated by stepconf wizard)

Since none of these values affected anything, I put them back to what it useta wuz.

One thing that did make an effect was max acceleration. Originally it would ramp up really slow, so I edited it from 30 up to 300 first and it was some better, then tried 3000 and it was about right. Also curious.

So anyway, something is throttling the pulses down by significant magnitude (~40x slower than commanded and 10x slower than yesterday) for some reason, and also clamping it at a commanded RPM of 5000.

BUT!!!... it's spinning, so woohoooo!

Any ideas on this RPM riddle?

I just got done trying something so I'm reporting back.
(I've attached the most recent .hal file)
I added a line for maxvel thinking there might be some default value that needed to be overridden. It didn't work but I have a new observation.
just FYI I also tidied it up a little and removed an unused stepgen channel, so the spindle is on 3 rather than 4 now.

So the new "thing" is that I now get an error which might illuminate something or point to something... or something.
The way it works is that after I start up LinuxCNC, then home the axes, whether I press a manual "spindle on" button or send an M3 or M4 command, it kicks the following alarm:
_{STEPGEN: Channel 3: The requested maximum velocity of 5006 steps/sec is too high.
STEPGEN: The maximum possible frequency is 5004 steps/sec.}

This alarm only triggers the first time after startup. And after closing them, it doesn't reappear on subsequent spindle commands, so it's apparently triggered from reading the list of stepgen setup information. If I close the GUI and restart, the alarm will trigger again just upon the first spindle command again. Curious.

It only kicks up an alarm text on the screen but the spindle starts anyway, i.e. it doesn't disable the control or anything.

The maximum requested velocity is a product of the <maxvel> * <position-scale> (I had values of 2503 and 2 respectively, if the product of the two numbers is slightly lower I get no alarm but the spindle behaves about the same). The maximum possible velocity is the same 5004 no matter what values I plug in, so that points to something but I don't know what.

Connecting my encoder to an oscilloscope and an using an optical tachometer for rpm resulted in: @1285rpm it was 74µs per pulse (rising edge to next rising edge). This comes out to ~631ppr as-measured so maybe it's closer to 625ppr which is close to dividing into 5004 plus a few pulses for something I don't know how to factor in?

Again, just yesterday I was able to drive the same motor with the same driver from the same computer and same pins from the same parallel port but configured as a positional axis and the same optical tach measured 1100 rpm, so I'm not sure what difference may exist between position and velocity modes that might cause the RPM to be 10X different.

Any ideas are appreciated.
Thanks.

Vinito wrote:

#spindle things
net spindle-cmd-rpm => stepgen.3.velocity-cmd
...
setp stepgen.3.position-scale 2

Encouraging to hear you got it moving! The rest should just be a matter of comprehending what these factors mean. Be careful you don't clobber your hand-edited .hal by running stepconf again.

The stepgen docs say position-scale is "steps per length unit". The doc seems defective in that "length unit" means "revolution" in velocity mode, the units are per second, and it shouldn't be overloading the name "position*" for velocity things (haven't seen so much overloading of variable names since 1975 when I was keypunching FORTRAN card decks). Shouldn't your position-scale be a larger number, like position-scale=600 if your motor encoder is 600 ppr? And "net spindle-cmd-rps ...", not -rpm? If I'm correct, your factor values are incorrect by both numerator and denominator items, and together this seems consistent with the incorrect speed you're getting of 1/20th too slow because you're missing the factors 60 / (600*2) = 1/20.

The excruciating docs ought to set forth a single summary mathematical formula stating how all the factors yield a final frequency, instead of just a prosaic description of what each factor represents with no summary formula. Of course the truth is available in the source code, but that is lengthy procedural logic and not a readable formulaic summary. The same might be said of machine coordinates in G-code; there's no summary formula stating all the possible factors (G54,G92,tool offsets,...) contributing to them.

How fast is your base thread?

How fast is your base thread?

Honestly I don't know yet. Can you point me to a spot (or just tell me the formula here) how I determine that?

"The excruciating docs ought to set forth a single summary mathematical formula stating how all the factors yield a final frequency, instead of just a prosaic description of what each factor represents with no summary formula."

I couldn't agree more, though I would argue that my impression of the documentation isn't as much prose as an exercise in connect the dots. Seems like I have to look things up on four pages minimum to find what a single line means, and even then I feel no more than 30% certain that I understand it in the end. Conversely, I don't mind doing basic math.

Similar vein - the section containing the lines you referred to was simply generated and I have no idea what any of that part means yet. Well maybe 5%. I did notice that two lines have rpm and two rps, and they are nets so I know they are connecting one side I have no understanding of with the other side which I understand even less. Then it ends with what looks like maybe a check that it's maintaining speed but there is no feedback from the drive or motor to evaluate anyway. But again, I don't know what it is so it's likely I'm incorrect there too.
But moving on to the scaling... I simply ended up with a value of 2 because that multiplied by the maxvel value determines the max requested velocity. I juggled those values to either trigger the error or not and the code I attached was just where I landed last, but the max possible value of 5004 pps remained fixed.

It seems to me that if I was able to accomplish 1200rpm in position mode yesterday then the dang system should indeed be capable of generating similar pulse speed in velocity mode, short of some synthetic programmer authoritarianism. This appears to be the root of my problem. What factor in velocity mode would limit the pps to such a low value as 5004 while that seems to be a cakewalk in position mode?