non step/direction interfaces

reading the various driver boards, it looks like they are all variations of step/direction (just using different hardware to dive the pins)

There are a number of controller boards out there that are designed for very high speeds (pthat and odrive are a couple examples). Talking to these boards via a step-direction interface would be extremely inefficient.if it's at all possible at all.

These boards take commands over a serial port that go something like "move 2000 steps in X, 500 steps in Y, at speed Z with acceleration W; start"

Is it possible to create a driver for linuxcnc that can use this sort of interface? or would that require drastic changes to linuxcnc to support something like this?

Those boards are independent motion controllers. LinuxCNC has its own motion controller with features tailored for CNC applications. Typically "smart" motion controllers of the type you mentioned are not a good match for use with LinuxCNC or particularly good for CNC applications that use any advanced features that require real time reaction to external inputs. Some of these features that LinuxCNC supports include probing, threading, rigid tapping, and adaptive feed.

Most CNC systems work in a similar matter to LinuxCNC at the motion control level, A set of position waypoints
is generated by the trajectory planner and these position waypoints command the motion. Given that the motion can be completely arbitrary, and can change in real time, this ends up being simpler to implement with motor controllers that take very simple real time position/velocity commands (possibly with acceleration or jerk), rather than have to convert an arbitrary real time motion profile into a specific motion command language, that is the "smart" features just get in the way.

If the smart controller had the ability to handle say a 500 commands a second and supported simple position/velocity commands (set XYZ position to ABC and velocity till next waypoint to DEF) then a LinuxCNC interface would be relatively straight forward

These boards do have communications fast enough to be able to deal with that sort of command rate.

These boards don't currently have any g-code support, so it's not just a matter of feeding them the g-code. I'd like to avoid seeing these projects reinventing the wheel and each creating a poor g-code implementation when LinuxCNC has such a complete implementation available.

There's also the problem that these boards only control a limited number of axis (mechaduino=1 odrive=2 pthat=4) and have limited inputs and outputs available, so being able to combine these controllers with each other or with 'normal' I/O is valuable.

The advantage of these boards over normal step/direction interfaces is their speed, pthat can do 125KHz step rates for example, so if the machine is light enough (or the motors powerful enough), you can have machines move very quickly. Several of these are also closed-loop so you don't have the problem of skipped steps.

Would it be possible for someone who knows the codebase to throw together a quick 'hello world' driver that simply printed the desired movements to a file? from that it would be much easier for someone like me who's not that familiar with the linuxcnc codebase to then make a driver that would send commands to these boards.

For LinuxCNC, Its not just that the motion controller interface needs to be fast, it needs to be realtime
(and the host interface requires this as well)
So if run from a RPI serial port, at some high baud rate (probably a couple MBaud minimum),
the RPI would need a real time driver for the serial port (this may exist, I don't know off hand)

Note that many existing LinuxCNC hardware stepgens run _much_ faster than 125 KHz

@andypugh, is there a good example of a driver that uses one of these alternate methods for positioning?

you mention servos, I've got one machine that uses servos and encoders for positioning instead of steppers and would like to replace it's controller logic.

for what it's worth, I've never been expecting that communications with these smarter boards would have to be in real-time, you can't send messages to multiple devices truly simultaneously. My thought was to send messages to boards queuing up movements, and then having them start the movements on a single pin GPIO start signal. That way the high-level communications (serial, USB, CAN bus, ethernet, bluetooth, whatever) don't need to be real-time.

By doing something similar to what i2c and USB do, you could have each device on the bus pull the pin active-low until they are ready to start the movement, and then when all devices on the bus are ready, a pull-up resistor will pull it high and they all start at once.

This does require that all actions that are queued be planned to take the same amount of time across all axis/outputs, but that doesn't seem like an unreasonable requirement.

dlang wrote:

@andypugh, is there a good example of a driver that uses one of these alternate methods for positioning?

you mention servos, I've got one machine that uses servos and encoders for positioning instead of steppers and would like to replace it's controller logic.

Yes, the Pico Systems PWM controller communicates with the PC over the parallel port, and produces PWM pulses for up to 4 axes. It also has encoder counters and digital I/O.

Our PPMC is a set of boards with encoder counters, analog output and digital I/O. You plug in as many boards for each function that you need.

You can see these products at pico-systems.com

Jon