Gonna wait for the top-shelf version in a few days (5xC).
Gonna wait for the top-shelf version in a few days (5xC).
btw tested now fast-streamer from a regular linux box (some old Core2Duo E6850 running fedora), same file, same smoothieboard ...
[root@gedora ~]# time echo | python fast-stream.py -q milion.gcode /dev/ttyACM0 Streaming milion.gcode to /dev/ttyACM0 Waiting for complete... Press <Enter> to exit real 1m39.769s user 0m23.681s sys 0m8.914s [root@gedora ~]#
so 1:40 or 10,000 gcode lines per second ... more the twice the speed of orangepi one
yeah 5xC are avaialble for pre-order on robotseed ...
I think USA store has them on stock ( https://shop.uberclock.com/collections/smoothie ) you might want to check
I was hoping for v2 to come out but I kinda lost interest along the way .. and am actually holding myself to start testing klipper first chance I get to find some time
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
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.
@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).