Nice. He just changed the status on that page. (There was a complaint that he's on a backlog but maybe he's done a few of them by now.)
i read some days ago that smoothieware need more powerful hardware.
A board with only 100MHz and that less ram will not be supported in a few versions.
The recommendation for the LPC1768 boards is to use Marlin 2.0.
they are working on v2 board for quite some time .. but its a very slow progress .. the original smoothieware works on original smoothieboard (100 or 120mhz board - I usually go with 120mhz on the ones I make myself) but yes not everythig can be added to the v1 as the way that team organize software is professional and they don't allow dirty/ugly hacks in the code (like you have in marlin) and 'cause the board is used a lot with cnc machines so they need to keep compatibility with both systems.. v1 is still awesome .. I would restrain myself from commenting on marlin
There are no dirty hacks in Marlin.
Marlin is a dirty hack.
(ducks for cover)
@fieldOfView let me throw some
ifndefs in your general direction for emphasis SCNR
It's clearly a myth ! I've been successfully printing at 80 mm/s or more for years with a Mega 2560+Ramps 1.4 hooked to a RPi 1 Model B and an old version of Octoprint, without visible artifacts. The baud-rate was set to 250 000. I just had to increase the timeouts to avoid random crashes.
The limiting factor was never data transfer. It was non sharp corners or missed steps when the moves were too "violent".
Perhaps you could go into detail here to help anyone following along.
The bottom line here is that it isn't the print speed that is the problem, is it the number of gcode instructions needed to direct the nozzle on the necessary path. A straight line or a sharp corner is short because its basically 1 line of gcode, but a complex path requires a lot more instructions, which is what causes problems.
I'm new to the world of 3d printing, but have been a computer nerd for a while. The gcode issue is really an amazing anachronism for 2019. Even without changing the language, it seems that gcode would respond well to standard compression algorithms. If backwards compatibility is a hard requirement, has anyone tried using some of the unused gcode namespace as a way to "tunnel" a base64 encoded asynchronous protocol within the standard gcode protocol?
The serial connection speed is not the only issue. "The other end" of the connection is - for many printers - an 8 bit atmega chip that's having trouble keeping up controlling the steppers and calculating checksums and handling a serial buffer at the same time. Decrompressing gcode lines, even base64, would not help that.
One of the current paths appears to be to offload some of the logistical work from the controller back to the Raspberry Pi in this case: Klipper.
There are times when I like the Klipper approach and then there are times when I realize that people should just replace the stock 8-bit controllers in their printers with something beefier. The baby Arduino boards are okay if you print from the SD card locally but if you're looking for a more holistic approach with a nice web interface, timelapse, streaming video and all the bells and whistles then it's really not.
klipper approach works for decades for linuxcnc on machines handling way more code then our 3d printers do (lazors) moving heavy dangerous equipment so it definitely works .. there are other professional systems that also control the "stepper generator" trough modbus or other similar remote system, so controlling a stepper generator trough usb/rs232/modbus/i2c/spi/rs485/ethernet ... definetely works... now can't say how good klipper is and if that amount of power is needed or not, but it is for sure proven way to do powerful things
e.g. I'm now working on mesa like stepper generator with virtex5 fpga and there are just no bad sides here from what I see (price & complexity of design excluded )
I've got a Smoothieboard 5xC coming in a few weeks so we'll see what it's like to be on a real board.
I was running Octoprint 0.9 for about 3 years with these settings:
Communication timeout: 15 s
Connection timeout: 8 s
Autodetection timeout: 4 s
(It wasn't much documented so I increased all of them)
I recently changed to the latest version. It already has higher values than these by default (except for autodetection timeout). I still doubled them for good measure
But these linuxcnc machines are not running marlin on atmega chips, right?
neither is klipper. linuxcnc machine will send data trough isa/pci/usb/ethernet/serial to external stepper generator (e.g. mesa card) so all the calculation is done on a linux box by linuxcnc and step generator is done by external card. mach3/4 for e.g. also can talk to external step generators via modbus or rs485 or usb so you have calculation done by windows box and steps being generated by external devices... klipper is doing same thing, it runs calculation on any linux box (e.g. rpi or opi or something stronger if you like) and it uses external stepper generator via usb, what's interesting about klipper is that they have firmware (not marlin, not even close to marlin) for external stepper generator for your regular atmega boards... so you can convert your ramps, melzi... 8bit atmega board into simple step generator (you put the firmware designed by klipper crew) and you use klipper on the rpi to do the calculation and send step generator instructions...
8bit atmega is more than capable of being a step generator for speeds we use in 3d printing so no worries there
you'll love it .. just make sure about 2 things
- make sure you config lines are shorted then 130 lines
- edit config on a computer and then copy it to the card, sync, then unmount the card