Just an idea. Don 't know if this is new or useful.
Instead of sending G-code to the printer why not send pure binary.
For now the computer is doing nothing except sending an ASCII sign once in a while and the printer-controller is doing all the calculation to move the steppers.
Why not let the computer do this calculation? If it knows the printer set-up (style, axes-sizes, steps/mm, interrupt resolution, ...) it can produce a file with a sequence of bytes representing the output ports of the printer controller. For the whole print! it will do this very fast and be able to optimize. You can call it a printer-driver.
This file can then be send to the printer.
All the printer controller has to do is:
- at the beginning: send its configuration
- home all axes
- take care of any temperatures
- watch the end stops if present
- fill a buffer with the bytes coming from the computer
- supply an interrupt that will get the bytes from the buffer and transfer them to the output registers.
- report its status
Some numbers as an example.
file size: 32 output pins = 4 byte, interrupt frequency 20 kHz, printing time 1 hour ==> 4 x 20000 x 60 x 60 = 288 MB
transfer speed: 4 x 20000 Hz = 80 kbit/s
I don't know the interrupt frequency that is used in usual firmware but I guess it is close to 20 kHz. Please correct me if that is wrong. But even if it is 10 times faster. 800 kbit/s looks possible to me.
What would be the advantage?
The printer controller can be very simple = cheap.
The SW on the computer can look ahead as much as possible.
Total printing time is known from the start. (except for temperature changes)
G-code errors can be recognized before the printing starts.
As I said. Just an idea.

I've thought along these lines as well. I think there's a couple more benefits available by moving more of the work onto a more powerful computer (desktop, Raspberry Pi, phone):

• More accurate curved paths
• Faster prints... the printer doesn't need to do the 3D rotation for bed-levelling, nor G-code interpretation
• Synchronized control of multiple extruders.

The downsides:

• You're going to need the "big" computer running throughout the print, unless you can download all the data to the printer's SD card, and your printer can retrieve data fast enough from there.
• Pausing the print would need to be controlled by the "big" computer

This does require that the computer know the details of step size in each of the axes, and for each extruder. And also the bed levelling parameters if bed levelling is being use. But that's not a big deal.

At a typical 150mm/sec and 80 steps/mm, that's12000 steps per second, so your interrupt rate would need to be 12KHz. The steps/mm would be double if using 1/32 microsteps, or 0.9 degree steps, so your 20KHz guesstimate is about right. Maximum speed from the PC to the printer (assuming comms similar to existing Arduino boards) is 250Kbps (maybe 115Kbps on some systems?). Assuming it really is converted to serial at some point, rather than emulated via USB, your max data bandwidth is 8/10 of that = 200Kbps. You really should do error-handling (e.g. CRC or checksum, plus some kind of resend protocol), which (based on a wild assumption that these comms will be fairly clean) will take another 10%. So you have 180Kbps to play with, which is plenty.

All that's needed is a big enough buffer to prevent running out, particularly if there are comms errors.

A 64KB buffer would hold 16K samples and take about a second to print. Trouble is, the ATMEGA2560 only has 8KB of RAM. (256KB of Flash, but that's no use for a cache that will be rewritten often). Maybe 6-7KB of RAM might be available for the cache?

OTOH, each stepper actually only needs 2 bits (step and direction) at each interrupt, so if you send 8 bits/sample you can support 4 steppers (a bit limited) or 16 bits/sample allows 8 steppers. And LZW or similar compression might give you a 10:1 factor. Based on those assumptions, you'll be able to cache a second's worth of data. Whilst the chances of a 1-second comms loss are small, if it did happen I don't think the printer would be able to pause and resume.

Personally, I think I prefer the idea of downloading the entire file to the printer's SD card (8GB = 7 days @ 12KHz, 1 byte/sample, uncompressed), then printing from there. But the downside of this is that interactive pausing is practically impossible, and there would probably be a long delay (about a third of the whole print time) while the data was downloaded to the card.

hi frankvdh,
it 's good to see my mailing is comprehensible.
I am not a controller specialist but there should be many micros that can do pure USB without simulating a seriel com connection. Transferspeed would not be a problem with those.
Does anyone known how many people use the SD-card for printing? I gues most of us have an other computer running anyway while printing.

Quote

downside of this is that interactive pausing is practically impossible

Why do you need pausing and why should it be practically impossible?
Just for information: I 'm using a Raspberry Pi for printing and I 'm working on a software that will first do the step calculation and then transfer that data to the output port. Layer by layer. No need for seriel comm there. It just came to me the same idea could be used for "normal" printers.

Quote
vlorijer
Why do you need pausing and why should it be practically impossible?
Just for information: I 'm using a Raspberry Pi for printing and I 'm working on a software that will first do the step calculation and then transfer that data to the output port. Layer by layer. No need for seriel comm there. It just came to me the same idea could be used for "normal" printers.

I must admit I rarely pause a print... only if something is going wrong (maybe broken filament, or something like that).

The problem is that the steppers need to be accelerated and decelerated. You can't just instantly stop a stepper that's running at full speed -- you have to slow it down gradually with an appropriate series of pulses gradually slowing down. And, conversely, you can't just resume the stream of pulses at high speed without losing a bunch of steps... you have to gradually accelerate it back up to the speed.

Unless you're using Linux CNC you're likely to have the same kind of issue. Linux (including most of the variants used on the RPi) is not a real-time OS, so you cannot generate precisely accurate pulse streams with it. When the pulse stream speed varies too much from the actual speed of the motor, you will skip some steps. I guess that so long as you keep the pulse rate slow, below some arbitrary rate, everything will be fine. But then you'll have a slow printer.

I am not using Linux CNC and I know Linux is not a real-time OS but I did some tests.
On Raspberry Pi 1 the SW slowed down when I moved the mouse. On modell 2 that 's no problem anymore. There are 4 cores.
I get a step time of 100 µs (10 kHz) with only a litle jitter without overclocking or changing priority. Even having grafics showing me the movement of the printhead.
That leaves room for optimisation for speed.
Acceleration is already on my to do list. It worked fine without this far but I got some stepper with higher resolution now.

What instruction will you give your printer after something went wrong?
Do you know the exact point in your G-code file to resume printing?

I use Octoprint on a RPi (recently updated to a RPi3 ) as my printer user interface, but I think Cura and Repetier Host probably also offer the ability to pause & resume interactively.

If something goes wrong (and I'm there to see it) I'll press 'Pause'. Octoprint stops sending instructions to the printer and fairly soon it stops. I can then take my time to fix whatever is wrong (change filament, remove a blob from the bed, or whatever). That might involve moving the print head with the UI. When I'm ready, I move the print head back to where it was when paused (it would be nice if the software did this for me automatically), then "unPause" Octoprint (click the 'Pause' button again) and it resumes sending Gcode instructions to the printer at the point where it was paused. Because the printer calculates the speed of each movement, typically things will start off slow, but it quickly gets back to full speed.

So, if your program is going to offer a pause (or stop) function, it will need to decelerate all the steppers to a stop before handing control over to the user. When the user tells the print to resume, your program would need to accelerate the steppers from stopped, rather than resume from the point where it left off.

[Edit]: A variant on your idea that I've been thinking about is sending the pulse sequence to the printer, but NOT the timing. I believe that the sequence of steps fully determines the object being printed (unless you get so slow that indivdual extruder pulses come out as blobs of plastic rather than a line). So a sequence of xxeyxexyexxey would designate moving at 30 degrees whilst extruding at some constant rate. The timing of each stepper pulse (and therefore any acceleration/deceleration) would be calculated by the printer firmware. This would reduce the data transfer needed, since a pulse that was a millisecond long would be represented by 1 token (4 bits... 3 bits for stepper motor number plus 1 bit for direction), rather than the 20 2-bit tokens used if your interrupt rate is 20kHz.

Edited 1 time(s). Last edit at 04/06/2016 05:59PM by frankvdh.

I can't see any advantages to using a PC to do the step calculations, but I can see disadvantages. PCs don't run real time operating systems, which is why they already struggle to consistently feed the data fast enough to the printer sometimes - even a few Octoprint users have reported this. You would be sending a far greater volume of data if the PC did the calculations. Step pulse rates already exceed 100 kHz in some configurations, and the new generation of stepper driver chips with higher microstepping will cause this to increase further. Meanwhile, embedded processor power has become very cheap, so the printer electronics does not need to be expensive.

IMO the best way to print is from local storage on the printer, and use a web interface or LCD (or USB if you must) to monitor it and make any adjustments needed. That way the printer is not dependent on the continuing functionimg of a comms link and another piece of electronics.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Several minds have spent a lot of time puzzling about this.
There is a project folder here, but it is stagnant: [forums.reprap.org]

I think there are versions of this that have some merit.

You could of course use LinuxCNC to send steps directly to the printer - but the communications would need to be altered, probably not worth it.
I personally do not like having my computer chained to the printer, and printing from SD is far more reliable, plus a dedicated PC costs much more.

Also with 32-bit electronics becoming mainstream (sooner the better) the power of the controller is no longer an issue. Cost is the only downside, but that is declining, and the value is well worth it all the way around.

In my opinion far too much time has been wasted on 8-bit. 95% of the reason for the lag in embracing 32-bit (and their currently slightly higher cost) is because the firmware needed to be re-written - a complex and time consuming process - and there are few willing to do it for little or nothing - the cost of development must be born by someone. After all the difference in cost for the micro-controllers is minor. I think that moving the step generation from the micro-controller to a dedicated PC hit the same roadblock - its a very complex undertaking, plus the fact that there were good alternatives.

I am thinking of an alternate scenario for a robotics project with a great number of motors.
Instead of interpreting gcode and sending step pulses, a multi-core master controller (like a Pi 3) could send "motion frames" to slave controllers (like 1GHZ Pi Zeros running bare metal, $5 each).
Think of a Pi-3 plugged into a daughter board that has a row of Pi-Zeros socketed into it, each controlling multiple socketed or on-board stepper drivers...
The motion frames would contain pre-computed speed, # of steps, and acceleration profiles. Running without interrupts the bare metal Pi Zeros could supply the step pulses without jitter.

Of course the same thing could be done for Reprap printers. You would need to change the gcode motion planner module to run on a PI, and output motion frames, and program the Pi Zeros to communicate with it and process the motion frames into pulses...
And that could cost more than the existing boards that are already working well. It would however allow very high performance, graphical interfaces, a real operating system (Linux), fast communications, and a continual upgrade path with new Pi models.
Just sayin...

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!

There is an functional project for this: [forums.reprap.org]
I am quite impressed with it.

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!