Acceleration Settings

[Caall99]

Without sounding argumentative, I am still not 100% convinced. Accelerated moves can be represented by gcode as much as non-accelerated moves. Ignoring the x3g limitations in accepting "varying acceleration", in my opinion the firmware should only read gcode line by line, and send the appropriate step pulses to the stepper motors. It should simply parse movement commands, not calculate acceleration for every move in the motion planner. Due to the large computational resources available to the slicing engine, it should calculate all acceleration in advance, and simply output an augmented gcode file with additional G1 or G1 moves that encompass accelerating and decelerating between movements.

I know that I can turn OFF firmware acceleration in Sailfish, and instead allow Cura to generate the acceleration enabled gcode. I can then convert the file from gcode to x3g with GPX, load it on my replicator, and during printing it will behave as though firmware acceleration was turned ON. This is pretty convincing that the gcode can contain accelerated moves that the firmware can simply read and execute, versus having the firmware read non-accelerated moves and then calculate acceleration on the fly.

[CompoundCarl]

I am still not 100% convinced.

How about the fact that every single firmware out there implements acceleration planning on the fly? Seriously. Every single one I know of. So I'm not sure why any convincing is needed...

I don't know why you keep saying it's too difficult for an 8bit microcontroller. I have 8 bit microcontrollers from almost a decade ago that cost $15 back then and were more than capable of doing acceleration planning. And again, the proof that this is easily possible should be that it's already being done by every firmware out there.

There's no way you could even achieve smooth acceleration using G1 commands without using thousands of tiny segments to represent one single line. The communication and parsing overhead would be far worse than doing acceleration on board.

[dorsai3d]

I know that I can turn OFF firmware acceleration in Sailfish, and instead allow Cura to generate the acceleration enabled gcode. I can then convert the file from gcode to x3g with GPX, load it on my replicator, and during printing it will behave as though firmware acceleration was turned ON.

It really doesn't. It executes the speed changes "instantaneously" which is typically worse for both the print and printer. I don't even know of a setting in Cura to create accelerated gcode, but I'm pretty sure even if there is a version that has an option for that, it's not doing what you think it's doing.

I am still not 100% convinced.

How about the fact that every single firmware out there implements acceleration planning on the fly? Seriously. Every single one I know of. So I'm not sure why any convincing is needed...

I don't know why you keep saying it's too difficult for an 8bit microcontroller. I have 8 bit microcontrollers from almost a decade ago that cost $15 back then and were more than capable of doing acceleration planning. And again, the proof that this is easily possible should be that it's already being done by every firmware out there.

I'll add on to this: accelerated motion planning was implemented with 7-track tape and relays/vacuum tubes in the early 1950s. Pretty much any modern microcontroller could do this, given enough IO ports and sufficiently well-written firmware.

[Caall99]

The fact that every firmware does it that way, doesn't mean it should be that way! All GRBL motion planning derived firmware that run on 8-bit controllers are exhibiting print slowing and other motion planning bugs when calculating acceleration for detailed models. 32 bit hardware does not suffer from the same problem, because of the processor overhead. I have been closely following the Sailfish firmware development and the creators of the firmware agree that they are limited by the hardware that the firmware operates on. The fact that it CAN work (although with limited capability and other issues) does not mean it SHOULD be done this way.

My proof is that Cura's accelerated gcode, results in much smoother printer behavior than letting the Sailfish firmware calculate and plan acceleration on the fly (all else being equal). Furthermore, allowing the slicer to do the job will provide additional advanced capability such as slowing down for small radii, more accurate accelerated pressure compensation for Bowden extruders etc... adding these to 8 bit controllers and expecting smooth operation at print speeds in excess of 60 mm/s is near impossible.

8 bit controllers are passé... to keep them relevant at higher printing speeds of detailed models, I believe motion planning should be computed on a multi-core processor, not an anemic 8 bit microcontroller.

[Caall99]

I know that I can turn OFF firmware acceleration in Sailfish, and instead allow Cura to generate the acceleration enabled gcode. I can then convert the file from gcode to x3g with GPX, load it on my replicator, and during printing it will behave as though firmware acceleration was turned ON.

It really doesn't. It executes the speed changes "instantaneously" which is typically worse for both the print and printer. I don't even know of a setting in Cura to create accelerated gcode, but I'm pretty sure even if there is a version that has an option for that, it's not doing what you think it's doing.

Then you don't know Cura 2.3 beta... even older versions had it...

Try it and tell me what you SEE, not what you THINK.

[dorsai3d]

Then you don't know Cura 2.3 beta... even older versions had it...

Try it and tell me what you SEE, not what you THINK.

Sure thing. Here's an excerpt of "accelerated" gcode from Cura 2.3:

G0 F3600.00000 X25.017 Y24.531
M204 S3000.000
M205 X20.000
G1 F1800.000 X25.612 Y24.043 E3.94555
G1 X26.254 Y23.620 E3.96001
G1 X26.937 Y23.265 E3.97449

Would you look at that... it does exactly what we've been describing to you. Issues a command to change firmware acceleration and then sets the next speed, allowing the firmware to do its job and plan the motion accordingly.

[dorsai3d]

8 bit controllers are passé... to keep them relevant at higher printing speeds of detailed models, I believe motion planning should be computed on a multi-core processor, not an anemic 8 bit microcontroller.

Also, now that we've established that you want to change how this is implemented to be different from every machine tool ever, explain how your anemic 8-bit controller is going to handle the communication required to receive accelerated motion commands at any reasonable print speed?

Even the slowest of 8-bit machine controllers is typically running at 16MHz, but can only receive communication bits at about 250kHz max. And that communication needs overhead for transmission time and reliability. I've seen printers choke on non-accelerated gcode simply because they don't have the communication throughput, and you want to add more overhead? I'm sorry, but perhaps you should try thinking through these things a bit more thoroughly before claiming to know better than everyone involved in machine control for the last 60 years.

[Caall99]

Thanks for looking at the gcode, since I haven't yet. I rest my case... but boy do you sound grumpy! SD card reads should be faster than 250kHz. I don't intend to print over USB...

The smoother behavior I noticed must have been due to another setting or condition. Originally I thought Cura would calculate a string of G1 moves to simulate acceleration, and not call out the M204 or M205 commands. My mistake for not checking.

Still doesn't change my belief that acceleration could be preplanned on a proper CPU for 8 bit controllers.

Let the 32 bit controllers do their own planning.

[dorsai3d]

Thanks for looking at the gcode, since I haven't yet. I rest my case... but boy do you sound grumpy!

You come in saying someone else should implement an idea that you had, but never bothered to look into whether it was practical/possible or not. Then when Carl & I tell you that that's not really how that works, you doubled down. I may have gone a little overboard, but you didn't seem to be getting the concept.

SD card reads should be faster than 250kHz. I don't intend to print over USB...

The smoother behavior I noticed must have been due to another setting or condition. Originally I thought Cura would calculate a string of G1 moves to simulate acceleration, and not call out the M204 or M205 commands. My mistake for not checking.

Still doesn't change my belief that acceleration could be preplanned on a proper CPU for 8 bit controllers.

Actually, most of these controllers implement SD over SPI, which is limited to 128kHz max, so it's actually slower in many cases, but doesn't have the extra overhead/headache of USB, so it can be smoother in some cases.

Regardless, firmware calculated acceleration is still way smoother than a string of G1 commands that would emulate acceleration. If anything, you would want to look at offloading some of the other overhead out of the firmware if you wanted to go faster with limited hardware.

[Caall99]

dorsai3d,

Lets see if i caught you on a less grumpy day... This might interest you:

A snippet from accelerated code generated by Craftware 1.14:

; ------------------------------------
; Layer #0
; ------------------------------------
G21 ; mm
G90 ; abs
G92 E0 ; reset extr
M106 S0
;segType:Skirt
G0 F2400 E-4.5000
G0 Z0.160 F300
G0 X72.674 Y62.156 F6000
G0 F2400 E0.0000
G1 X72.814 E0.0041 F840
G1 X73.054 E0.0112 F1440
G1 X73.394 E0.0212 F1500
G1 X92.254 E0.5763
G1 X92.595 E0.5864 F1447
G1 X92.836 E0.5935 F847
G1 X92.978 E0.5976 F247
G1 X93.051 Y62.035 E0.6018 F847
G1 X93.185 Y61.811 E0.6095 F842
G1 Y61.571 E0.6165 F1442
G1 Y61.230 E0.6266 F1500
G1 Y42.357 E1.1820
G1 Y42.089 E1.1899 F1009
G1 Y41.921 E1.1949 F409
G1 X93.066 Y41.802 E1.1998 F1009
G1 X92.909 Y41.645 E1.2064 F599
G1 X92.711 Y41.617 E1.2123 F1199
G1 X92.426 Y41.576 E1.2207 F1500
G1 X73.248 E1.7852
G1 X72.979 E1.7931 F1009
G1 X72.812 E1.7980 F409
G1 X72.693 Y41.695 E1.8030 F1009
G1 X72.536 Y41.852 E1.8095 F599
G1 X72.508 Y42.050 E1.8154 F1199
G1 X72.467 Y42.336 E1.8239 F1500
G1 Y61.514 E2.3883
G1 Y61.782 E2.3962 F1009
G1 Y61.949 E2.4012 F409
G1 X72.586 Y62.068 E2.4061 F1009
G1 X72.674 Y62.156 E2.4098 F409
G1 Y62.325 E2.4147 F1009
G1 Y62.431 E2.4179 F840
G1 Y62.571 E2.4220 F240
G1 X72.814 E2.4261 F840
G1 X73.054 E2.4332 F1440
G1 X73.394 E2.4432 F1500
G1 X92.541 E3.0067
G1 X92.809 E3.0146 F1009
G1 X92.978 E3.0196 F409
G1 X93.097 Y62.452 E3.0245 F1009
G1 X93.287 Y62.262 E3.0324 F1500
G1 X93.389 Y62.159 E3.0367 F1199
G1 X93.531 Y62.018 E3.0426 F599
G1 X93.559 Y61.820 E3.0485 F1199
G1 X93.600 Y61.535 E3.0570 F1500
G1 Y42.357 E3.6214
G1 Y42.088 E3.6293 F1009
G1 Y41.921 E3.6342 F409
G1 X93.481 Y41.802 E3.6392 F1009
G1 X93.291 Y41.612 E3.6471 F1500
G1 X93.047 Y41.369 E3.6572
G1 X92.908 Y41.285 E3.6620 F1442
G1 X92.702 Y41.162 E3.6691 F842
G1 X92.462 E3.6762 F1442
G1 X92.121 E3.6862 F1500
G1 X73.248 E4.2416
G1 X72.980 E4.2495 F1009
G1 X72.812 E4.2545 F409
G1 X72.693 Y41.281 E4.2594 F1009
G1 X72.503 Y41.470 E4.2673 F1500
G1 X72.260 Y41.714 E4.2775
G1 X72.176 Y41.853 E4.2823 F1442
G1 X72.053 Y42.059 E4.2893 F842
G1 Y42.300 E4.2964 F1442
G1 Y42.640 E4.3064 F1500
G1 Y61.513 E4.8619
G1 Y61.781 E4.8698 F1009
G1 Y61.949 E4.8748 F409

Appears pretty accelerated to me. And now that I am seeing it, it was Craftware and not Cura that implemented it this way. Craftware also allows you to set the resolution (or time step) for feed rate changes in miliseconds. That code above was done at 10ms.

There are also the following settings under acceleration:
Max Accel: 1000mm/s^2
Corner Coefficient: 4
Min Speed: 4mm/s