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)
4 Likes
SCNRIt'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".
1 Like
Perhaps you could go into detail here to help anyone following along.
1 Like
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.
1 Like
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.
1 Like
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 
2 Likes
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
1 Like
Some control boards can be mounted as a USB mass storage device. One way around the problem with performance of Upload to SD is to use the file system rather than a serial transfer to the printer. This should be easy to achieve my Re-ARM board running Marlin 2.0. Send G22 to release the SD card, mount the USB mass storage device, transfer the file, then send a G21 to initialize the SD card within Marlin.
1 Like
@dmulligan That's awfully hacky when you could just do what I do for the same effect, with higher speeds and far fewer steps:
I run them on all my printers, using a microSD <-> SD adapter for boards that can only use microSD (CR-10S, for a modern example). I have a static DHCP assignment for their MACs (and another for the Pis that run their associated OctoPrint instances), set them up a single time and plug them in, and then that's it...I can simply mount them via WebDAV on boot, slice directly to the SD card over WiFi, and kick off and monitor an SD card print via OctoPrint.
The only real issues are with machines running firmware that doesn't give good status updates to OctoPrint during the print or that can't be interrupted by OctoPrint, both of which can be addressed by other methods (often suboptimally, but come on...people have been making machines that can burn your house down while leaving out basic safety features like watchdog timers, thermal runaway protection, and stall detection for years).
@supertaz It is not hacky at all. Only one OS can access a block device, such as a SD card, at a time. M21 and M22 can be thought as unmount and mount device commands from the point of view of Octoprint.
I have experienced this issue. Here is the same print over USB(top) and direct from SD card(bottom).
The USB print was frozen/non-functional and shows blobbing/zitting. It also took almost two hours longer than the estimated print time. The second print from the SD Card yielded a noticeably better/functional result which completed at the estimated time. Furthermore the print head movement was much smoother.
- Creality3D CR-10 V2
- OctoPrint 1.3.12
- Raspberry Pi Model B Rev 2
- Print: Roller bearing from 100% printable filament spool holder
- HATCHBOX PLA
- bed: 50° C
- end: 200° C
I'm not positive that the Raspberry Pi is not also contributing to the issue. At the time of the printing, MJP-stream was also running. It's possible that the Pi was just swamped. I intend re-test with OctoPrint running on better hardware but, given what I have seen online so far, my results seem to support the USB data transfer limitation.
2 Likes