There is a paper here:

http://www.ambots.net/user/pages/03.technology/_publications/chunk-based-slicer.pdf

That describes, amongst other things, a slicing strategy for "cooperative" printing.

May be of interest.

adavidm

That's right. Apologies, I had intended to copy and paste the whole line, not just the number!

You should get somewhere in the right region with 96. I'd still recommend you fine-tune the extruder after doing that though. There are loads of tutorials on how to do that, including Thomas Sanladerer's here:

https://toms3d.org/2014/04/06/3d-printing-guides-calibrating-your-extruder/

On the Duet, you can send an M92 command while the printer is running. e.g.

M92 E96

and you can see the results straight away. Use a guide like Tom's to get the figure as accurate as possible, then modify your config.g with the new value.

adavidm

Mean is a simple average of the deviation from a theoretical perfectly flat, level bed at each probe point.

RMS is Root Mean Squared. As I understand it (I am not a statistician), you square each of the deviations, take the mean of those squared numbers and then square root that mean. The most important effect, in our case, is that it eliminates negative values which might otherwise give a misleading impression of how level the bed is.

Here is a better explanation:
http://www.analytictech.com/mb313/rootmean.htm

The square/root process also exaggerates higher deviations, so it's not quite the same as just stripping the negative sign off and taking the mean.

As to which is more important, I'm not sure there is a simple answer to that as there are so many other considerations ( where the deviations are on the bed, if the errors are randomly distributed or in a clear pattern, etc).

If you have min and max deviations that are a long way away from the RMS then I'd suggest looking for the causes of that. Your Max deviation is 0.176, which is on the same order as the layer heights commonly used in 3D printing. That might not cause issues, especially if you don't print in that area of the bed and/or use mesh compensation, but it's something to look into, IMHO, as the plastic flow will be impeded to some degree at that point.

Your bed looks like it's reasonably level but it's noticeably higher at the four corners. What is the bed made out of and how is it attached, out of interest? It's fairly large, around 300mm per side, so quite likely sagging in the middle under it's own weight to some degree. I don't have a heated bed on my printer but I believe this makes a big difference too.

hope this helps

adavidm

Might be worth backing up the contents of your SD card and use the SD Association tool to format the card before replacing the contents and trying again:

https://www.sdcard.org/downloads/formatter_4/index.html

adavidm

There are some great external tools for the Duet ecosystem and I wonder if its a good idea to integrate them into the base platform and have them interact with the 'live' system.

I think the tools go a long way to addressing the "GCode everywhere" steep learning curve and make the system much more beginner friendly. I'd hazard a guess that even experienced users would sometimes benefit from a more visual approach, as well. I've mentioned before I used to do a lot of work with Cisco network devices. 99% of the time the command line interface was the best way to work but, occasionally, there was a place for the GUI tools (In my case, when building complex firewall rules).

What I'm advocating here is to keep RRF itself 'pure' in it's gcode only approach, and use an extended version of DWC to provide a richer interface into the configuration in addition to it's current operational role.

Example 1: http://www.escher3d.com/pages/wizards/wizardbed.php

@dc42's bed generator for delta printers. A version of this hosted on the Duet that could automagically update bed.g would be great. Especially with a visualisation that shows the points probed and the opportunity to 'nudge' individual points (e.g. for fan/ bed mount clearance)

Example 2: https://configurator.reprapfirmware.org/

The RRF configuration tool. Again, a version of this self-hosted that a) generates the base files in-place and b) allows for configuration updates to be made live by directly manipulating the sys/*.g files and console would be awesome. Bits of this are already in DWC, but by replacing that with the configurator you get access to a lot more parameters in a fairly friendly interface.

With both of the above, there will be a fair amount of effort to do the initial port but I'd have thought the longer-term maintenance would be similar to today. It makes printers more self sufficient without relying on external sites for configuration tools.

I think this has been mentioned before but having a vendor-ratified, built-in, method for basic tuning of certain parameters might be worth pursuing too, using a wizard system. e.g.

• Pressure Advance Tuning
• Non-Linear extrusion Tuning
• Retraction Tuning
• Stall detection homing
• PID Tuning
• Steps / mm Tuning

KissSlicer has interesting wizards for some of these but I can't help thinking they should be controller-side and not baked into the gcode.

There are loads of third-party tools/scripts that would also be cool to have on-board but I can see that supporting them out-of-the-box could be problematic for Duet3D.

Bang Bang mode could definitely be the culprit. Quickest way to test is to print PLA with the bed-heating disabled.

adavidm

@roth

Here is a good place to start:

https://duet3d.dozuki.com/Wiki/Calibrating_a_delta_printer#Section_Auto_calibration

It will take you step-by-step through learning to calibrate your machine. Between that and the Tevo-specific information in the video, you will be up-and-running in no time.

RepRapFirmware's use of "GCode everywhere", although daunting at first, is one of it's key features and makes for some amazing capabilities. @deckingman's recent thread showing off his CoreXYUV behemoth is testament to that!

Thinking about the request for help thread here:

https://forum.duet3d.com/topic/5909/guide-for-posting-requests-for-help/11

It occurred to me that a lot of the information gathering could be done using a macro, IF there was a way to A) Echo the contents of a file to the console with a g-code, and B) use M28 to capture output from commands.

You could do something like:

(Note, M930 does not exist, just using it as a placeholder for a function that echos file contents).

M28 tech_support.txt ; Open tech_support.txt for writing
M118 S"------------ BEGIN Technical Support Readout -----------------"

M118 S"---- Main System Files Output -----"

M118 S" -- /sys folder contents ---"
M20 P"/sys"
M118 S"--------------"

M118 S"----- config.g -----"
M930 P"/sys/config.g"
M118 S"--------------"

M118 S"----- config-override.g -----"
M930 P"/sys/config-override.g"
M118 S"--------------"

M118 S"----- homex.g -----"
M930 P"/sys/homex.g"
M118 S"--------------"

M118 S"----- homey.g -----"
M930 P"/sys/homey.g"
M118 S"--------------"

M118 S"----- homez.g -----"
M930 P"/sys/homez.g"
M118 S"--------------"

M118 S"----- homeall.g -----"
M930 P"/sys/homeall.g"
M118 S"--------------"

M118 S"---- Diagnostics Information -----"
M122 ; output diagnostics for platform, move, heat, gCodes. network and webserver modules

M118 S"------------ END Technical Support Readout -----------------"
M29 ; Finish SD card writing

M118 S"A file called tech_support.txt has been created on the root of your SD card "
M118 S"Please attach the file to your support request"

Obviously there are ways to improve this - pretty-printing, adding extra files/diagnostics, verbose/concise mode, etc. There are also far more sophisticated ways of packaging the data using DWC rather than a console. The upside of this approach is that DWC doesn't have to be up-and-running, you just need an operational console connection and the ability to put a file on an SD card.

When/If branching in gcode becomes available, a more sophisticated approach will be possible as the macro could detect kinematics/drive strategy, etc and finesse the output accordingly.

Thoughts?

Can you post your config.g, config-override.g and your bed.g ? It might be your printable radius is too small to be probed when taking the probe offset into account.

Is your windows client defaulting to ssh?

There is a paper here:

http://www.ambots.net/user/pages/03.technology/_publications/chunk-based-slicer.pdf

That describes, amongst other things, a slicing strategy for "cooperative" printing.

May be of interest.

adavidm

M605 is not supported according to the documentation.

I think what you are looking for is here:

https://duet3d.dozuki.com/Wiki/ConfiguringMultipleIndependentXcarriagesCartesian#Section_Creating_a_tool_that_uses_more_than_one_carriage_to_print_multiple_copies_of_an_object

adavidm

@sean said in Closed Loop Control of Stepper Motors with Rotary Encoder:

What does "PanelDue has a hardware option to add a rotary encoder, but it's not yet supported in the firmware." mean from: https://forum.duet3d.com/topic/2613/external-rotary-encoder-with-duet-wi-fi/8

That encoder is usually combined with an LCD and is used for driving a GUI on most printers. Nothing to do with closed-loop control.

What is the complete M915 line you are trying to use?

You probably just need to tweak the z value in your g31 command.

Try making it -0.2. There are better ways than just guessing but that should be enough of a change to notice if things are going in the right direction.

What temperature are you trying to print at? What kind of extruder is it?

@trout-thug said in So close to printing getting Error: G1/G2/G3::

G

Your M208 line in config.g is telling Reprapfirmware that the minimum z position is 320. Calibration ignores this setting but when you go to print z is well below 320, so the move fails.

I'd change that line to something like

M208 Z-0.1 S1

The gcode file is the one that cura produces. Open it in notepad and copy the first 20 lines or so.

There is nothing stopping you using 12v. I think 24v is advantageous for 0.9degree steppers but it's by no means necessary. Is there something in particular you think you need 24v for?

Can you post a small section of the gcode you are trying to print, up to and including the first few G1 lines?

I'm wondering if your slicer has its origin misaligned with the forward or similar.