STMicro Drivers

[MLange]

I'm making a mock-up of a shield using the STMicro L6470. No guarantees, just thought I'd mention it, as it seems like a nice chip.

[bkgable]

I have been looking at this chip also. It could offload the high speed pulse generation from grbl and let the Ardunio do other things. I have some L6470 samples so would be interested in putting them on a prototype shield if you might happen to make any available. Significant effort to re-write grbl though.

[MLange]

I doubt that GRBL would need an entire rewrite, but depending on licensing, perhaps the .c file responsible for path plotting could be used in other projects

I also came across this, which seems to essentally be a module for the L6470 similar to the A4988 module, and would plug into a larger board to control a RepRap.

If you want, I could make a run of boards with Arduino shield pinouts, and one or two HTSSOP28s in the middle, broken out around it, and the rest just through-hole protoboard. Is that what you were thinking?

Edit: Added URL to "this" for reprap/L6470 module

[aldenhart]

Looks like you would have to integrate the grbl planner with the chip. The chip is capable of doing acceleration / cruise / deceleration trapezoids on it's own, but doesn't have any step / dir inputs, at least not directly. So everything comes in via SPI commands. The atmega328p has an SPI device on it, but running SPI at 5 Mhz is a lot of CPU resource even so. Perhaps the ST chip SPI can be slowed down - usually SPI data rates are controlled by the master (in this case the 328?). Also, I wonder what they mean by "7.0 amps peak, 3.0 amps RMS". Usually RMS is 0.707 * Peak. Interesting. I haven;'t read the whole data sheet - so perhaps some of these questions are answered.

Alden

[MLange]

Perhaps the ST chip SPI can be slowed down - usually SPI data rates are controlled by the master (in this case the 328?).

From the diagrams, the timings seem to all be based on the CK signal. These chips have an internal oscillator, or can accept clock in and clock out, or an external crystal or oscillator.

One of the nice things about these chips is that you basically tell it where to go, and it does so, and just raises the !BUSY line when it's done. A big feature that made me drool while reading the datasheet was the Full Step mode. If you try to move it too fast in a microstepping mode, it will kick itself into full step mode to get where you want it to go, then go back to microstepping mode, all while retaining its relative positioning. (Of course, you can limit its max speed, etc, especially while it's cutting)

These chips also have the option of being strung together in a daisy chain (the MOSI to the first one's SDI, its SDO to the next one's SDI, etc, etc, then the last one's SDO to MISO) (See pg. 37) In this case, they share one !CS line. That would certainly cut down on the CPU time, though it is not without its downsides. This would be one reason why a protoboard-type shield would be nice, to wire them up any which way and try it out first

[aldenhart]

You are correct, sir, regarding the SPI clock. I was just wondering if the ST chip needed to run at 5 Mhz, for some reason, or if it was just capable of doing so. This is my own lack of knowledge for not having read the data sheet carefully enough.

Of the various command modes the Motion commands seem the closest fit to the grbl code. Motion commands execute a user-defined number of microsteps within the velocity and acceleration profiles. This would basically execute a trapezoid that was built by the planner, and replace the step generation by the 328p (I don't call it the Arduino, because technically it's not an Arduino anymore once you have flashed it with grbl...). You would have to re-program the velocity limits to set the feed rate, or the max velocity value (seek rate) for G0 moves. Also, it's interesting to note that the acceleration and deceleration profiles can be different. In grbl they are the same. I don't know what would be required to implement the feedhold, but the stop commands are there for that. Also, it looks like can be run in step mode if you are willing to set the direction using SPI, but this negates the advantage of offloading the 328.

[MLange]

Indeed, hence why (under that type of setup) I would rather just leave the planning to the steppers and simply decode the GCode and send the movements to the respective drivers to be executed. This can be done however slow/fast the ATMega feels like, as the stepper drivers take time to do it.
In this case, it would also be very easy to stream off an SD card; simply open a file and interpret it line by line.

[aldenhart]

It can definitely work. A lot of the really complex robots and really expensive motion control systems work this way. For example, I saw a high throughput screening robot that can run thousands of chemical or biological assays per hour. They don't use Gcode at all but are programmed in Position-Velocity-Time (PVT) or Position-Time (PT) curves that get fed to dedicated control systems. These system (costing about $500 - $1000 per axis - for servo control) off-load the movement similarly to the ST chip motion commands.

That said, there's still a lot of things the grbl or other control program must do to properly decompose Gcode to the PVT or PT level, including setting feed rates / traverse rates, arc interpolation, cornering, and other types of interpolation. The look-ahead planning chain itself may still be required - I don't know, perhaps the ST is smart enough to plan-down the sequences of short lines most machine generated Gcode produces. Also, out-of-cycle commands such as homing, jogging, feedholds, probes, tool change (manual or automatic), Mcode, and other things must still be performed. So I'm not sure how much the grbl code actually simplifies, when it's all said and done. What this approach could get you is the ability to run much much faster machines - that would exceed the 30 Khz step rate grbl can sustain.

[alpha]

This looks like a nice driver chip... instead of creating another arduino shild I think a modular approce like seeed grove would be cool. For CNC some could just chain 3 modules together and if you need a second Y take 4 modules and if you need a 3d printer have 5 modules... as a controller I think a Raspberry PI would be mutch more powerfull then an Arduino and its only $5 more and has Ethernet. Use a USB WLAN dongle and it connects wireless. The PI has SPI as far as I know and it's small. You can send the GCODE over LAN to PI and start a job from an other room... so you don't need to put your good PC in the work shop. But you still have the option to add an old TV or modern screen and mouse keyboard for a human machine interface.

[MLange]

Interesting idea, though I doubt the Raspberry Pi will be available to the average Joe every-person (who hasn't pre-ordered) for a fair while yet. There is also the BeagleBone, Beagle Board, Pandaboard, etc. I'm not sure where the most benefit lies between a completely computer-controlled Arduino, a completely self-sustainable computer with monitor, keyboard, etc (Pi, Beagle, Panda, etc), or somewhere in between, with an Arduino or Pi/Beagle/Panda and a limited UI. The sweet spot will definitely vary from person to person.

With the majority of the processing offloaded to the drivers, even a 328 would have no problem driving an LCD-based UI with SD card slot for G-code files, or even Ethernet.

Modular would be interesting, though I'd imagine having controllers chained or wired to some form of base hub would introduce some interference; If possible, you'd want connections to be direct to the arent board, and barring a direct connection, you'd want the cables to be shielded. (Hmm. Cat6 Shielded? I digress...) That being said, I could see some kind of shield (an Arduino regular or Mega shield / Beagle Cape / Pi Shield / whatnot) with driver daughterboards attached vertically to allow for airflow/heatsinks on each, as well as a port for remote-mounting of the drivers, such that you could mount them directly and/or remotely. Thoughts?