For the lazy person who doesn't want to open the base for powering the Octoprint server when converting to DuetWifi+Duex: 1.) Cut open the leftmost cable tie of the line that holds the Raspberry USB cable and the 2-pin cable that used to be connected to the Rumba 2.) Connect the 2-pin cable to a Fan/LED connector on the Duex (or Duet if you run single extruders) 3.) Power on the Raspberry with M106 P8 S255 (P8 is FAN/LED port 8 on Duex in this example) 4.) If power works again, put the command in config.g for automatic startup of the RPi each time 5.) Execute tutorial: https://betrue3d.dk/rpi-zero-wireless-video-for-duet-using-motioneye-os/ (Kickstarter BigBoxes came with a RPi 2B) 6.) Profit! You can reboot the RPi now via the Duet.Bonus points for macro G-code that reboots the Raspberry, might be a good way to play around with M291 and M292 commands to do it elegantly via touchscreen.
Have you noticed whether the DUET actually processes the gcode faster? I think the RUMBA board with two extruders and bed leveling enabled pauses at times - Simplify3d completion time predictions and what I actually get are often off by 2x. Thanks!
The time prediction being off still happens with the Duet in my case, S3D doesn't specify which prediction method it actually uses. I also encountered the times being off in OctoPrint when I was using the Rumba. Duet Web Control shows different predictions how long a print will take to finish, based on average layer time, filament consumption over time vs predicted filament amount for the finished print and also progress through the file. Since I often use honeycomb infills the file progress prediction is all over the place because each comb has several commands compared to just rectlinear infill which is much ligher on file size. So I think both platforms are capable enough to process the gcode, Duet just runs a lot smoother - whether this is due to the higher CPU horsepower or the vastly superior stepper drivers I can't say. Probably both.
S3D assumes that moving any weight of print head from zero to full speed takes zero time and also that all changes in speed take zero time. That's why it's mostly off. They would need to ask for the print head weight and model that to have any chance of getting closer to the truth. You'll quickly learn what factor to multiply the estimate by in order to get closer to the actual time for you machine but you're still likely to be off from time to time. A round cylinder printed in spiral mode should give a fairly accurate estimate, but other geometries will be off.
How about just setting the accelerations you use in your firmware config also in your S3D printer profile so it can do the math? Shouldn't be too hard given today's CPU horsepower and how fast it slices anyway.
If you want an accurate print time and you are using a Duet, then right click on the filename in Duet Web Control, or touch the filename on a Panel Due running the current beta firmware, and select Simulate. That will give you a very accurate print time. Otherwise, the print time estimate based on filament consumption is generally the most accurate of the three. It over estimates the print time during the first couple of layers because of the slower first layer speed that most people use.
Thanks for all of the information! Does anyone have a practical way of recycling all of the plastic that goes into test parts, misprints, etc? Also, I think I have a great idea - a small machine that splices your end-of-reel filament left over that might be too short for your next print together with the next roll (of the same stuff)... any thoughts?
I too need a way to splice filament, there are one or two commercial products and a failed Kickstarter project on the same subject.
If you keep an eye on your print, you don't really need a splicer; you just need to be nearby prior to running out, then pause and switch over. The really cool use of splicing is in the creation of the multi-colour print splicer. Not sure if you've seen this ... https://www.mosaicmanufacturing.com/? That thing can create some seriously awesome prints with many colours. There are some 6 colour examples on Thingiverse (https://www.thingiverse.com/thing:2446453)
I have seen this and I agree that it is very neat! How do you set up the new filament such that there are no gaps between the old and new filament? Are you pausing between layers with the hotend parked away from the print?
The answer really depends on your control system. On the Duet, for example, I can hit the pause button whenever I like. The result of this is to execute the pause.g set of commands, which for me cause a restraction, lift, and move to 5,5, followed by a filament eject and a disabling of the extruder motor. I then swap filament. The next thing is to hit resume, which executes resume.g, which repositions the head back to the last X,Y and moves back to begin printing where it left off. I also use that in a more planned fashion between layers by inserting an M226 into the gcode before uploading to the printer. Previously, with RUMBA and Marlin, similar options were available. The firmware could be configured with a filament change spot and a swap filament command could be entered via the panel to initiate. Alternative it could be planned via gcode with M600 (iirc).
Since I haven't gotten around to fit a BLTouch to my machine, is there probably a way to make the manual bed levelling adjustment increments in the web interface more granular? Doing it with 0.1mm is a tad too large then levelling with a sheet of paper and a warped bed.
I am but I want to go for a BLTouch as I have already prepared most of the IDEX parts for it. Also I want to be able to switch beds and have the printer compensate automatically. Sometimes I will use the glass and I have a second glass that will be covered with PrintBite+.
Ok, so my Duet is running like clockwork and I couldn't be happier with it, however since I upgraded to the 1.21 firmware, I always get the red colored message "Error: G1/G2/G3: intermediate position outside machine limits" twice during my startup script. Checked the script, it is the part where the extruder would move to the dock and dump some filament in there, it just goes to the pre-dock position and skips the steps and then prints as if nothing happened. Weirdly enough, the position it tries to move to is perfectly within the movement limitations specified with the M208 command in config.g Any clues on how to solve that?
Weirdly enough, the docking works perfectly fine after the print when the end script runs. @dc42 probably knows what's going on here?
The clue is the word intermediate. RRF has for many years checked that the endpoint of the move is within the bed limits, but recent versions check that intermediate positions are within limits too. On any printer, it is possible to specify a G2 or G3 arc move so that the start and end points are within the bed limits but the arc goes outside the limits of the bed. On some SCARA printers it is also possible to specify a straight-line G1 move that takes the print head through a position that is not reachable. If you are getting this message on a Cartesian printer, then I think either you have specified an invalid G2 or G3 move, or else you ghave nesh bed compensation enabled and the initial position is outside the M208 bed limits. That could happen if you use G92 to set the current position.
I have checked my GCode files and have yet to find any problem where the move should be outside the bed. The printhead just stops at the position before it moves into the dock and skips the steps of moving in there, purging, moving out etc. Mesh bed compensation could be the culprit at my bed is pretty uneven but I dialled it in manually so it doesn't bite me. In the rear portions of the bed, the heightmap displays negative Z values which is where the dock is located. However, the printer does not skip any printing moves in that area and also prints the first layer onto the bed in these areas flawlessly. Everything works just as nicely as it did up to 1.20 firmware, since the update it has this weird issue. It gives the message twice in succession every time but the move commands for docking are not outside the M208 movement limits. It is really odd.
Can you send the commands manually from the command line one at a time, to see which one is causing the error message? You could also try the 2.01beta1 firmware.
