Pulse Train Hat for the Raspberry Pi

Yep most of controllers out there accept raw Gcode commands and do all the calculations in firmware, including G01 Linear interpolation commands and G02 Circular interpolation commands.

So software like Gcode sender, simply send out these commands and have nice features like GUI windows plotting the course of each Axis for display purposes.

We have no plans to add this ourselves at the moment as a huge bit of work, but with the undocumented RAW buffer commands, already in the firmware it is possible to send many small commands.

Here is the screenshot of the Universal Application we have been testing with.

This takes each line of Gcode and converts it to RAW buffered commands. It looks ahead and knows when a command will change direction and hence injects ramping into the start command and finish command of that segment automatically.

Once the motors have started, all you are doing is sending commands with frequency and pulse count for each movement, that get buffered and executed one after the other.
The processor does not have to do much really apart from monitor pulse counts and change the frequency on the fly for each DDS generator.

We have a high speed baud setting as well of 806400 which helps a lot. But you can still run it at 115200 with a change of jumper on board.

Excuse the rough layout, it is only test at the moment.

Hello Peter, it is correct, in fact I wrote this:

At this point it is not needed to make a new firmware on the HAT to receive the G-Code commands and convert them in direct motion commands; this means to recreate the entire math and logic of the G-Code language. Fortunately the Universal G-Code sender manages the commands in GRBL, an open source standard for low-level motor control. The repository on GitHub can be found here: https://github.com/grbl/grbl/wiki

So what we need is "just" to port the GRBL standard on the HAT. This is not so difficult as it seems because of the advantage of the ASCII commands available on the standard firmware of the HAT. I see two phases porting:

 

1 - After forking the GRBL repository setup the low level calls using the way the HAT controls motors (ASCII commands)

2 - Optimise the GRBL math algorithms accordingly with the advanced features of the motor controller

The Universal GCode sender does not interpret the GCode into direction and steps, it simply manages a user interface and spools the cgode to the controller., there is a separate program for that

you may be thinking of something like this

https://github.com/grbl/grbl

now all the C source is available to port to the ST micro if needed.

To keep the price down, most of the dedicated boards use the processors on board peripherals like timers or hardware PWM's.

We went a different direction with the PTHAT and decided to use dedicated DDS pulse generators, to give us the resolution and the speed, but also to allow the PTHAT to be used as a square pulse generator for other applications.

With the PTHAT bundle it has 4 DDS Pulse Generators and these are the AD9833

http://uk.farnell.com/analog-devices/ad9833brmz/waveform-generator-9833-msop10/dp/1581966?st=ad9833&gs=true&ddkey=http%3Aen-GB%2FElement14_United_Kingdom%2Fw%2Fc%2Fsemiconductors-ics%2Fspecial-function

And the processor STM32F411
http://uk.farnell.com/stmicroelectronics/stm32f411ret6/mcu-32bit-cortex-m4-100mhz-lqfp/dp/2456967

As you can see if you wanted to build it yourself, the price does add up.

But we felt it was worth it when accurate interpolation was needed between motors and show an example on our website.

Motor1 that needs 1000 pulses and motor2 that needs 2222 pulses to reach the target travel distance.

You can see on the scope shot, by having the resolution of the DDS pulse generators, you can get a very accurate speed on both motors and both should stop and start at the same time, keeping interpolation.

Run motor2 at 2666.66Hz (100RPM)

Run motor1 at 1200.11Hz (45.45RPM)

We would love to see someone develop firmware for the PTHAT so it can run as a dedicated Gcode engine and by us supplying a JTAG  programmer with each PTHAT, makes it possible for people to develop their own firmware and upload it.

As I have said we are still working on the RAW buffer command set in the background, but it has to be done as time allows. We are only a small company and resource can be an issue when busy on other products we make.

Sean,

to be honest I was wondering how it was so difficult - until now - to find on the market a good hardware platform not strictly g-code oriented for the Pi. I should exclude Arduino from some of my motor controller projects for a lot of reasons and this sounds to be the better alternative.

By the way in the case there users need to interface the device with the G-Code feed from somewhere (e.g. laser cutters of 3D printers) I am following this option by a while and actively interact with a couple of development communities that I think maybe useful for who is interested:

The universal G-Code sender is a java tool adaptable on any platform as well as the PI (already tested) to solve the interfacing problems and can be found here: https://github.com/winder/Universal-G-Code-Sender

At this point it is not needed to make a new firmware on the HAT to receive the G-Code commands and convert them in direct motion commands; this means to recreate the entire math and logic of the G-Code language. Fortunately the Universal G-Code sender manages the commands in GRBL, an open source standard for low-level motor control. The repository on GitHub can be found here: https://github.com/grbl/grbl/wiki

So what we need is "just" to port the GRBL standard on the HAT. This is not so difficult as it seems because of the advantage of the ASCII commands available on the standard firmware of the HAT. I see two phases porting:

1 - After forking the GRBL repository setup the low level calls using the way the HAT controls motors (ASCII commands)

2 - Optimise the GRBL math algorithms accordingly with the advanced features of the motor controller