non step/direction interfaces

More
10 Jun 2017 01:55 #94380 by dlang
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?

Please Log in or Create an account to join the conversation.

More
10 Jun 2017 14:13 #94391 by PCW
Replied by PCW on topic non step/direction interfaces
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

Please Log in or Create an account to join the conversation.

More
10 Jun 2017 20:24 #94398 by dlang
Replied by dlang on topic non step/direction interfaces
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.

Please Log in or Create an account to join the conversation.

More
10 Jun 2017 22:36 #94399 by PCW
Replied by PCW on topic non step/direction interfaces
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

Please Log in or Create an account to join the conversation.

More
13 Jun 2017 23:07 #94485 by andypugh

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 other supported interfaces than step/dir (but step/dir works very well for stepper motors). Lots of servos use analogue voltage control for torque or velocity command, for example. Some drives take PWM, either a velocity command, or in some cases as individual winding currents.

And there are some purely-digitally controlled drives. The Mesa 8i20 servo driver takes a digital angle and current command, and the STMBL servo drive takes a digital position command. (in motor radians). These both use the Mesa Smart-Serial protocol.

Then there is a vast array of EtherCAT hardware, and General Mechatronics support CAN-bus controlled drives.

Please Log in or Create an account to join the conversation.

More
13 Jun 2017 23:37 #94491 by dlang
Replied by dlang on topic non step/direction interfaces
@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.

Please Log in or Create an account to join the conversation.

More
14 Jun 2017 00:09 #94494 by dlang
Replied by dlang on topic non step/direction interfaces
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.

Please Log in or Create an account to join the conversation.

More
14 Jun 2017 00:58 #94496 by jmelson

@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

Please Log in or Create an account to join the conversation.

More
14 Jun 2017 08:48 #94500 by andypugh

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


I already mentioned the Mesa 8i20 , the STMBL and General Mechatronics.

Have you looked at: wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_Supported_Hardware

Please Log in or Create an account to join the conversation.

Moderators: PCWjmelson
Time to create page: 0.160 seconds
Powered by Kunena Forum