Doesn’t Klipper, like Sailfish, just move some firmware functions from the avr to the host making it a hybrid? The article is suspect, claiming grossly exaggerated step rates; my modded plywood Printrbot was limited by Marlin’s 15K (not 175K or 500K) rates and I don’t recall Klipper being that much better. Didn’t read the other link, saving it for later
We haven’t discussed smoothieboards (Hi, Arthur!) yet, and there’s @blurfl 's Teensy board sitting on my to-do stack
LinuxCNC does not support DC motors/encoders, only steppers (and even then, not
particularly well due to the timing issues due to having a full OS)
I would love to get support for DC motors/encoders added to grbl and LinuxCNC,
but I have not had the time (or money to hire someone with the time) to write
the code.
anything running on a full blown OS has problems with precise timing because the
OS may jump in at any time and take controlofthe CPU for housekeeping stuff (or
other programs running)
programming to the bare metal gives you FAR more control over the timing of
things, and much better response to interrupts.
This is why programming to the bare metal on an 8MHz Arduino is better for a
stepper based CNC than using a 1GHz RPi.
A BBB is sort of a hibrid, it includes a couple cores on it that are not managed
by Linux, that you have to write to the bare metal to use (the PRC). So if you
are using steppers or anything else that requires extremely precise timing, a
BBB is a good choice.
But a BBB does not have video available, and while it’s got a fairly broad
community, it’s nowhere the size of the RPi community.
However, the Maslow is not driving steppers, so it doesn’t have the precise
timing requirements that steppers would require.
The Maslow does have to keep up with reading the encoders, and I’ve seen a few
different libraries to do that (the pigpio library seems to be showing up a lot,
and from what I’m seeing is able to keep up with the performance we need)
So if you are ALWAYS going to remote in to the device, the BBB would be a little
better than the RPi, but will be more complex to program (as you need to program
the PRCs separately from the main program), but if you want the ability to hook
a keyboard/screen/touchscreen to the device and be entirely self contained (and
have wifi), the RPi is attractive.
The good news is that if you target the Pi, you can easily have alternate
functions that interact with the PRC and have the result work there as well.
David Lang
Can you amplify on this? I think of servos as wanting step/direction control
and the Maslow as closed loop control of a brush motor+encoder. I’ve seen a
board that accepts step/direction commands and does brush motor+encoder
control from that.
servos are closed loop, steppers are open loop.
There are controllers out there that emulate a stepper controller by presenting
a step/direction interface and then using the motor/encoder to hold that
posistion. They aren’t particularly expensive, until you look at the maslow
costs and realize that they are as expensive as the motors we are using
The key difference to remember is that open loop step/direction gives you zero
feedback as to if the motor actually was able to move to the new position, or
how close to maxed out it is. [1]
the maslow is able to track not only what it wants the motor to be doing, but if
it is doing it, and if not, raise an alert.
Could LinuxCNC directly control the Maslow motor+encoders?
not without writing a new driver. I have looked into this.
David Lang
[1] the new trinamic stepper motor drivers that are hitting the 3D printer world
bend this barrier, there is a SPI interface to the chip in addition to the
step/direction interface, and the chip can sometimes notice when the stepper
didn’t move.
We have talked about them in the past, and they would be far better than the
arduino, but would still be a matter of programming to the bare metal.
Going to a Pi/BBB based system would be a very different thing.
The best way would be to write a driver and new kinematics model for LinuxCNC so
that we could leverage everything it provides, but it should not be that hard to
port what we have to a Pi
I respectfully suggest you giggle LinuxCNC servo control and look at quadrature drive servo systems. These are motors, AC or DC, with encoders, sounds a lot like maslow style motors. On a quick look they even mention L298 controllers.
LinuxCNC requires a preemptive real-time linux kernel, and with the proper hardware can be as deterministic as you’d like, or good enough if you go cheaper and can live with some jitter.
It runs some seriously big iron along with the low end stuff guys like me use
FYI - If your into it it looks like you can run LunixCNC on the Pi.
Thank you
I know it was tried but not very successfully. I should go poke around in the forums again, been a while
I respectfully suggest you giggle LinuxCNC servo control and look at
quadrature drive servo systems. These are motors, AC or DC, with encoders,
sounds a lot like maslow style motors. On a quick look they even mention L298
controllers.
I specifically asked, and was told that they did not support these sorts of
things directly, only when there was some other motor controler between LinuxCNC
and the motors.
I could go dig up the forum posts if needed (but I don’t see the value in it)
If it is possible to drive them directly, please show me the config to do so, I
would love to do so.
LinuxCNC requires a preemptive real-time linux kernel, and with the proper
hardware can be as deterministic as you’d like, or good enough if you go
cheaper and can live with some jitter.It runs some seriously big iron along with the low end stuff guys like me use
getting just the right hardware can be harder than you think. I have a machine
setup and running a machine with LinuxCNC, and it can’t operate the graphics
card or wireless network and remain operational, I have to use a remote machine
and connect over a wired network
just floating this idea, but why not use the arduino everyone already has to convert steps/direction into DC motor and encoder language? The atmel will do that without problem, faster than you could possibly want it to move… And then interface that with the rPi or BBB… and then you can create a new custom shield that has the motor drivers and a little atmel chip (like a 328) that JUST drives the motors and leaves all the computing up to either a rPi or BBB or whatever you want?
Then you just ned to code the kinematics into the rpi, and leave the timing critical stuff up to the atmel processor?
for existing maslows, the existing firmware will keep working, they can manage
it from a Pi today.
What we are speculating on is a future version that simplifies things by
eliminating a board/chip.
Now, we may find that the Pi cannot keep up, in which case we will need to look
at a BBB instead, but let’s start off being optimistic and test it.
I’ve seen posts that indicate that the pigpio library should be able to handle
encoders well beyond what we are needing. We just need to confirm it.
Does this take into account the effort of porting the firmware to the pi? Volunteers?
There are encoder reading chips out there that might handle the timing critical functions well. Not recommending this one in particular having no experience with it, but here’s an example:
http://hades.mech.northwestern.edu/index.php/Using_the_LS7166_Quadrature_Counter
Unfortunately, the LS7166 seems pretty much sunsetted not widely available, though available for ~$10 qty100. It needs an 8-bit data bus to read the values.
To replace the encoder duties provided by Encoder.h by amassing the values the firmware routines use, it looks like the best candidate would need to keep a 32-bit up/down count of encoder position, be able to accept a position value written to it, and would keep track of the elapsedTime and lastStepTime. This is not something an off-the-shelf part will do. One or more sub-processors might be made to do it, but would be custom parts.
Another approach might be a chip to convert the A and B pulses for each motor to step and direction signals (LS7184,~ $2.50 qty100). The up side of this approach is that the interrupt service doesn’t need to calculate direction or check for missed pulses, just increment or decrement the counter as indicated by the direction. The down side is that the interrupt must be serviced before the next step occurs. It’s reasonable to think that a pi or bbb could respond in time to keep up though.
What about something like the LFLS7366R with a serial interface?
https://www.usdigital.com/products/interfaces/ics/LFLS7366R-S
Nice find!
The LS7366 is very interesting, it handles the 32-bit counting we need. The SPI interface on the pi or bbb are easy to use. I guess the encoder functions could be written to keep the time themselves and get the counts from the LS7366.
Could you tell whether the crystal is required? It seems to be. $4 qty100 for the parts is pretty reasonable.
I should be able to at least do the performance testing to find out how well
pigpio is able to keep up with encoders. I’ve got a couple of 1024 PPR (4k
steps/rev) encoders rated to spin up to 5k rpm.
we need to support 2 8k step/rev encoders running at 20 rpm (plus Z axis)
I’ve seen people post that they were doing multiple counters @ 600+ PPR * 13k
rpm (not quad encoders, just simple pulse counters on the theory that they know
what direction things are turning) without a problem, which would seem to say
that a Pi should be able to keep up with our needs
I saw another post that indicated that they were handling 4 encoders operating
at decent speeds at once.
So I think there’s a real chance that the pigpio library on a Pi2/3 will be able
to keep up.
David Lang
Will you be able to count revolutions as well as pulses to verify that none are missed? It would be interesting to test while disk IO and/or a VNC session were active.
The documentation includes a section on servo specific configuration[ (for the casual reader these aren’t RC servos, a different beast), which would require supporting servos. I’ve never tried using servos, other than the Maslow they’re typically out of my class, so all I know is what I’ve read. I’ve also run across several LCNC and Mach discussions about servos vs steppers (steppers are cheap and lower power, before Bar 
servos are mo power and more bucks) although I’m not familiar with how Mach does much of anything.
If somebody has done RPi development to drive something like a Maslow directly, including PWM controlled DC motors with encoders, and pluggable kinematics then the hardest part has a good start but even the 3DP crowd doesn’t seem to have any significant success doing so (or I’ve managed to miss it, not only don’t I claim omniscience my kids make a claim for the opposite)
Isn’t there always a motor controller between most motion control software and the motors? I understand you mean something like a Mesa controller but I did find a reference to an L298 driver board.
Interestingly, Pololu has motor driver boards that will accept a quadrature encoder input, although it took some digging to find them. I only have casual knowledge of the robotics people (First Robotics shares the high school shop at the same time as adult woodshop, and Squeakie’s mom was in FR back when I was working 80 hour weeks running the dial-up ISP) but I’d think they’d be a possible source of info on RPis and brushed DC encoded motors. Smashing other robots with robotically controlled hammers could be a source of rapid development.
My biggest gripe about BBBs is the cost of the motor controller capes. Even the CRAMPS board is way more expensive than it’s Arduino RAMPS equivalent, when you can actually find one. Maybe somebody here with more recent and better exercised design skills than my 1970s night school can make a new board with a TI Sitara and those amazing PRUs
I had google-fu’d into somebody’s copy of the LCNC docs; here’s a section from the recent one on implementing advanced kinematics. Hoping squeakie keeps sleeping so I can delve deeper into servo support with this Lenovo 500e chromebook (multitasking checking out new EMS charting computers with more important stuff. OT: it would be great if this $300 touchscreen widget would run GC somehow)