Porting to faster hardware

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)

http://linuxcnc.org/docs/2.7/html/motion/kinematics.html

As a trivail test, I can first test slowly where I can easily count revs, then
fast with a drill and see if a pointer keeps pointing the same place after many
revs. And if needed, I can rig something up that uses a stepper to drive the
encoder (200 steps on the stepper = 4096 steps on the encoder) and go wild with
that (I should be able to spin the steppers fast enough to exceed the maslow
requirements), and if all else fails, I can finally get around to setting up the
odrive controller to spin things faster.

and yes, we do need to test with I/O and network traffic (and other workloads
like graphics, etc) on the pi.

There is sample pigpio code that has a C daemon spawned by a python front-end
that has the C code handle encoders and make it available via shared memory for
the python code to read as needed

1 Like

Sorry for multiple posts, but they better reach the email reading crowd than edits.

Found a really interesting statement in the supported hardware page about servos:

any Stepper-motor or servo-motor drive that accepts step/direction signals could be used with LinuxCNC.

OK, time to stop now

1 Like

We would still need a motor controller board, but it could be a simple set of
MOSFETs like the current board rather than something that has to have other
smarts on it as well.

Yep, exactly, and more filler to reach 25 characters

Here you go - a step-direction controller for a gearmotor for $55 per motor. That does add to the Maslow cost, though…

1 Like

This is just a link to the top level of the documentation, and while there is a
section in there about servo specific info, it’s all about tuning PID loops,
nothing about how to actually configure it.

The kinematics section referenced above has a discussion of how to implement what they call bipod (and we call Maslow) devices.

Either I need to go back to school or get more tylenol, all this math is like Rincewind’s 8th spell (just watched the color of magic on Amazon prime) and has fled my brain.

Squekie woke up and is fussing, time’s up. How can one 13 pound person take so much time and effort?

1 Like

the good news is that there are clear indications now that it is possible, it’s
just a matter of the acceptable speed.

There is talk about parallel ports being limited to ~50KHz of updates, at full
speed, we need 320-500KHz of updates.

I don’t know if the Pi with it’s GPIOs is better than that. There are posts
indicating that the BBB may be able to reach those speeds (thanks to the PRC)

While I would like to use the PI, if we can use the LinuxCNC on the BBB, that
will be FAR better for us in the long run.

David Lang

1 Like

Quite a while ago, I backed this on kickstarter. it’s meant to drive a ramps 1.4 board, and runs smoothie firmware.
I wonder if it might be usable to drive our motor board instead?

http://www.panucatt.com/Re_ARM_for_RAMPS_p/ra1768.htm

Unfortunately, like grbl, smoothie lacks support for encoder based motors so it would involve flashing entirely new firmware, so probably not going to happen without a ton of development work, but i thought i’d throw it out there as a inexpensive cnc-capable 32 bit board.

1 Like

The I/O connectors seem to be layer out in the same pattern as a Mega. Is there a way to look at the schematic without having to install the Diptrace application they used? They say it’s a plug-in replacement for the Mega for RAMPS, so that makes it seem possible that a Maslow board might work.

Porting the firmware might be an exercise. I’m not familiar enough with Marlin or Smoothieware to know the scale of that adventure.

Here’s a RaspberryPi/CANbus approach with nodes that seem powerful enough to control a pair of motors for a straight segment of movement (with an appropriate driver chip). The firmware presently breaks all movements down into straight segments and passes those to a routine that makes the movement. Moving those routines onto a node would help insulate the real-time motor control from the rest of the things a pi and it’s operating system might be called on to do.

Further information here.

1 Like

With the Maslow, there is virtually nothing that’s a straight segment as far as
motor positioning goes, motor speed is always changing as you move around

Arcs are sent to the axis PID loops as straight steps with the destination chain lengths - see Motion.cpp arc(), lines 317-318.

2 Likes

Thank you for this! That little clue greatly helped me to understand what the code is doing. Is there any section of the Maslow firmware code, even historical code, that demonstrates an arbitrary point to point straight line move at an arbitrary speed, end to end all in one file? If it returned the actual measured velocity over the final segment of the move, that would be an added bonus.

If the Pi precalculates everything as a series of straight line moves, the controller can simply be a ‘player’. It just needs to keep its buffer fed and compensate when the machine sticks or overshoots.

I have 6 CAN controllers that can do this and an original Pi B+ on hand. http://www.ctr-electronics.com/talon-srx.html Am willing to put some hardware together and test if there is software to load.

1 Like

The CAM software can send a series of stright lines or arc to the g-code (some
CAM software sends arcs as a series of short straight lines), if the firmware
gets an arc, it changes it to a series of straight lines.

But then when the firmware is trying to follow a straight line, things become
very different.

On a ‘traditional’ stepper based system, the controller says ‘to follow this
line, set speed of motor 1 to A and speed of motor to to B, execute’

On the maslow, we instead do something more like:

  1. calculate where we should be
  2. Are we there?
    Yes: good
    No: “do we need to speed up or slow down motor A, do we need to speed up or
    slow down motor B”
  3. wait a few ms (during which time the sled moves in a semi-predictable way)
  4. goto 1

note that the movement in step 3 is only semi-predictable because the same
amount of power to the motor results in different speeds depending on friction
(which can vary based on what cuts have already taken place), and on the tension
on the chain to that motor (which varies as you move around the sled)

So the maslow firmware never moves at a given speed for a given distance. The
most you can do is to apply a given amount of power to a motor for a given
amount of time (I think this is done via ‘b codes’ to find it in the firmware)

There isn’t software you can pick up and move, the Maslow is a tightly coupled system, but I think that a node could provide much of the function in the Motor and Encoder sections of the present firmware, perhaps more. Here’s what came to mind when I saw the Pi+nodes mentioned above.
I would start by setting up a node to provide two independent PWM outputs and two more gpio outputs - eventually these would be two separate motor driver controls providing speed and direction for each motor. In addition, the node should handle four interrupt-driven inputs to manage the encoders that will be attached to the two motors. Take a look at Encoder.h from Paul Stoffregen for how he handles encoders, the Maslow firmware uses his library. As you study that note that in addition to reading and writing counts there are times that are recorded as well, and the main firmware PID loops make use of them.
That would be the I/O framework that a node might provide. There might be a way to move the position PID onto the node, but that could wait until the node is shown to handle the above tasks reliably with plenty of time and resource to spare.

2 Likes

I have installed diptrace and have “printed” the schematic to a pdf for you to look at:

rearm schematic full.pdf (834.6 KB)

3 Likes

Thanks for the schematic. There are some signals they’ve routed that would prevent the stock Maslow boards from working without cutting some traces on the Maslow boards. The TLE5206 board might work, as it doesn’t use some of the conflicting pins.
It looks like a big job to convert the software, more than I’m able to commit to. Sorry :neutral_face: for the discouraging word.

3 Likes

just a quick question. would the Arduino Due be a good alternative for a quick upgrade? With Maslow already being Arduino based would the code still run on the 32 bit atmel? is the Due any faster in our application?