The filament and layers are calculated in hours. This is part of the progress estimations done by the Duet, along with the file progress. Since different print jobs can give different results, the Duet calculates these 3 to allow you to make an estimate on how long it will take to complete:

• File Progress: at the current rate of working through the file, it is estimating that it will take X hours to complete. This one is typically for me the most accurate.
• Filament progress: your slicer adds information on the total length of filament to be used during the print. Using that information, along with the length of filament that have been extruded (and how long it took to extrude that filament), it calculates how long it might take. As long as your print use a very constant amount of filament, this can be accurate (also only accurate if you do not adjust the Extruder percentage / flow rate on the Print screen). In DWC the progressbar also displays the length that was printed vs what the slicer said.
• Layers: The slicer also have layer numbers (and in some cases specifically say the number of layers), and using that information along with the time it took to print the last N number of layers, to determine how long it may take. This is typically accurate only when layers are similarly sized and shaped. If you for example print a pyramid, it will over estimate.

The DWC can also display 2 extra estimations:

• Slicer: The slicer can estimate how long it may take, and this vs how long it already took is used here.
• Simulation: If you simulated the print, it will use that estimation vs how long it already took.

Using these different estimations, and knowing the rough geometry of your part, you can make more accurate predictions on how long it will take. Examples:

• If you have a very flat print, with a few small features (only walls/perimeters) on top, the Layer estimations will be far off; Here the filament might be more accurate; and the file progress may also be way off.
• If you have a pyramid shape (big bottom, going smaller etc): Layer estimations will be off (since each layer takes less time); Filament may also be off, filament usage at the base might be high, while lower near the top; file progress may be most accurate (same number of commands per layer, after the initial layers).
• If you have a simple 2D extruded shape: Layer estimations may be most accurate (since each layer takes the same time).
• If you have a bridge shape (arch bridge, so 2 towers and then gradually into the arch): Layer estimations are way off; filament usage may also be way off, and the File progress will also be off (when completing the arch, the number of commands may reduce, but each command takes longer to complete).

Thus using these estimations, it can provide an idea of how long based on past data (actual printing the job), and coupled with your knowledge of the print, you have an idea of when to expect it to be done.

The number of layers is counted by the firmware, however the PanelDue does not display this right now (it is shown in the DWC). For this I typical take the height (Z) and divide it by the layer height (though this only works when using a fixed layer height).

As to the picture you have added, that is a bed leveling button. Do not press it while printing. There was a discussion a while back to disable a few buttons when a print is ongoing (for example Home, this bed leveling, de-selecting a tool when there are no other active tools etc). This is expected a bit later, but no eta currently available.

This button runs the macro /sys/bed.g in your system files. This can allow automatic bed leveling (actually adjusting the bed), automatic bed level compensation (simply compensates from an uneven bed), assisted bed leveling (it calculates the bed unevenness and provides instructions to fix it). You can also have it move to predetermined locations, allowing for a full manual bed leveling (does not require a probe) or if you do not want it to do anything, you can simply clear the file (or comment everything out - add a semi-colon before each line ';').

For many of the values, I looked at the known values from the Repetier Firmware or Marlin Firmware available for my printer.

Things like the axis steps/mm values, endstop configuration etc can easily be checked manually:

Endstops (2-wire micro-switches): If possible, using a multi-meter check the continuity of the 2 wires and trigger it. If the multi-meter get continuity prior to the trigger, it is Normally Closed (which is better than Normally Open). Connect the endstops between Ground and the Signal and ensure the Endstop is configured for Active HIGH (this way, if the endstop is disconnected, it is read as triggered since the Duet will use a Pull-up Resistor to keep it high; unless it is actively pulled Low by a direct connection to ground, it is triggered). If yours is Normally Open, the same 2 pins is used (Ground and Endstop), but you configure it to be Active LOW - since only when triggered, will the endstop be pulled LOW (to ground). More details at https://duet3d.dozuki.com/Wiki/Connecting_endstop_switches

Steps/mm: For a Belt System, you need the number of teeth on the pulley, the belt pitch (so far I have came across GT2 [2mm] and MXL [0.08" / 2.03mm]; but others also exist and are used). You also need to know the number of full-steps/rotation from your stepper motor (usually found by a Google search for the stepper model number; also possible to use the number of microsteps/mm at a specific microstepping level [usually 16x]). The configuration tool can calculate what you need from this information.

Motor Currents: If you get the motor information, this will be in the datasheet (though it is a good idea to calculate an 80-90% of the rated and use that).

Motor Going Backwards? This is one of the things one should test and then change if needed: 1 got my head in the center of the build volume (around 50% in all axis), then command a single move at a time for a short distance (use the S2 option on these moves, for example "G1 X10 S2" to ensure it will move even though it is not homed). If it moves in the correct direction, it is correctly configured; if it moves in the wrong direction, invert its direction (Drive 0 is X; then Y and Z; finally P3 is E0, and if used, P4 is E1 - on standard Cartesian) by changing the Sn value between 0 and 1 for the M569 (for example "M569 P1 S0" makes the Y motor move inverted). It is also possible to invert the motor by changing the order of the 4 wires leading to it.

Acceleration rates: If you can find them in previous firmware, that is a good starting point; if not, start conservative and build up from there. The heavier the head (like a Direct Extruder), the lower your acceleration needs to be, otherwise it may skip steps on starting and stopping.

Maximum speed, once again a heavier head will need lower speeds, otherwise ringing may be caused. If found in firmware use that as a basis. Your head type also have a limit (MK10 heads, for example can only do about 60mm/s sustained; so limiting the printer a bit higher, like 100mm/s is good). Your voltage plays a role (due to Back EMF) - more information on https://duet3d.dozuki.com/Wiki/Choosing_and_connecting_stepper_motors (How to work out the power supply voltage you need; they have a spreadsheet to calculate an absolute maximum).

Look for "3d printer k8400 firmware" I found a few places that posted firmware, and from there (https://github.com/birkett/Vertex-K8400-Firmware/blob/velleman-official/Marlin/Configuration.h)

• Maximum Speed (called XY_TRAVEL_SPEED): 6000 mm/min (or 100mm/s)
• Acceleration (called DEFAULT_ACCELERATION): 6000 mm/s^2
• Jerks (XY, Z): 10, 0.5
• Motor Directions: X and Z is inverted (note that how you connect them to the connectors will also affect this).
• Endstops: X and Y is at MAX, and Z is at MIN (unless you changed its locations). I could not find if endstops are Normally Open or Normally Closed.
• Steps/mm (possibly 32x due to DRV8825; X, Y, Z, E0): 134.74, 134.74, 4266.66, 200

Minimum layer heights:

• The Duet will attempt to give you the layer height as found in the print files from your slicer. If you set your slicer to do 0.05mm layer heights, it will get to as close as it can to that.
• I have read that going below 0.08mm on PLA can cause issues or print more difficult, but have not tried it.
• Nozzle diameters are also important when trying to print low layer heights. Typically a nozzle can do 1/4 to 3/4 of the nozzle diameter as layer height (allows enough squeeze to lay it down), which means if you want to attempt going below 0.1mm layer heights, you need a 0.2mm nozzle.
• Hardware may also be a limiting factor. Microsteps are not always very accurate and the actual layer height might be a rounded value close to what you set, but not exactly what you wanted (difference should be quite small, but at low layer heights, it can be enough to affect the print).

Maximum speeds:
This is very much printer dependent, but usually the limiting factors:

• Quality of the final print. The faster you print, the lower the quality will be. Artifacts like ringing are more pronounced at higher speeds.
• Printer's melting chamber in the nozzle. Each extruder have a limit for how fast new filament can be molten. Depending on the molten chamber size, this limit can temporarily be exceeded without issue. When it is exceeded for too long, you get underextrusion (typically this happens on large areas where the printer achieves maximum speed for a long time before slowing down). As an example a Chinese MK10 extruder can melt 4.8mm^3 of filament per second. At 0.2mm layer height and a standard 0.4mm nozzle, this gives us a maximum sustained speed of 60mm/s as a theoretical maximum. Doing lower layer heights, can give you faster sustained speeds.
• Printer head: Direct Drive extruders are typically quite heavy. Bowden extruders are typically light. With a light head, you can easier get to a greater maximum speed since it takes less power to accelerate and deceleration can happen slightly later.
• Printer construction. If you want the head to move at massive speeds, the printer needs to handle the forces applied to it - requiring a very ridged structure.

Now, as you mentioned, DWC have the option to increase both Extrusion Speed (this is how much filament is pushed into the extruder) and Printing Speed (how much X Y and Z as well as E is increased). It should be noted that Printing Speed also adjust the rate of Extrusion to match the speed of movement for the lines being printed. By increasing the Printing Speed, DWC can show you what speeds are achieved and you can enter it into your slicer - newly sliced files will then use the new speeds (they either take a value in mm/s or mm/min - simply multiply or divide by 60 to change between the 2).

Using extruders like the MoarStruder or E3D Volcano (which features massive molten chambers), one can achieve quite fast printing speeds at large layer heights.

I have looked for a Duet compatible CNC Postprocessor for a while now, and I am not happy with the ones I found. The grbl version was not good and the reprap version's gcode does not look very standard.

I have taken the reprap version and modified it to produce output that is more like I want it:

• Each line does exactly 1 thing. The reprap version sometimes combined a few commands into a single line (for example: "G28 G91 Z0" as a single line).
• Not using G28 so much. The reprap version sometimes produced 3x G28 commands in a few lines, which is simply not needed.
• Use ";" for Comment starts instead of brackets. I know brackets are acceptable, but in the other gcode I have read, a semi-colon is the start of a comment, so to make it easier on myself.
• Changed the Tool Change part. It started by using the tool number as defined in the tool library, for example it would have "T210" to change to tool number 210 in the library. I use a numbering scheme for my tools (allowing me to label each tool's storage location), but the machine does not need to know that. I force it to use T0, and instead adds a little bit more complicated script: It starts by stopping the spindle (at the current working coordinate origin), then using command M291, asks for the new tool to be inserted (press OK to continue), now it asks you to prepare for probing (again using M291, OK to continue), performs the probe (G30) and finally requests you to remove the probing gear (again M291, OK to continue) before continuing with the next section.

Currently it does not yet support arcs, though that is on my todo list. This is also not yet tested on my machine.

For some reason it does not always produce a G0 or G1 before the position. For example, the following is output from it:

G0 X131.51 Y-5.767
Z25.5
Z10.5
G1 Z2.54 F1000
X131.502 Z2.341
X131.479 Z2.143
X131.44 Z1.947

As you can see, the lines simply continue, specifying new X, Y or Z positions for the previous command (either G0 or G1). Does the RepRapFirmware understand this? I just want to know it is safe before trying it.

I was not yet able to post the cps file on a more permanent location (the cps file format is not supported here).

@LB The space issue I mention is space on the display and not storage -> since PanelDue is a touch screen, each button and action needs enough space to ensure you don't touch the wrong button. It also feature only a 800x480 pixel display (5i and 7i versions).

With the current layout PanelDue only have space to display 3 estimations

A print job that was simulated, have its estimated time saved to the gcode file itself specifically to prevent having to simulate them again.

It can be done (with the Duet supporting both a Laser and CNC mode). You will just have to write both configurations (with the new firmware in Beta, it is possible to easily load different configurations). Also have a way to accurately position the laser/cnc bit is a must.

For a setup like this, I would recommend using a laser module (not the Co2 laser tubes), the ones that can more easily be attached to a head. I have actually looked at them and found that some places have them in 15W modules (greater than that was no where to be found when I looked). These modules simply laser out their bottom, and have a cooling fan at the top (so no mirrors to arrange) - attach them to your machine head and you are mostly good to go.

As with any dangerous operation (like both CNC and Lasers), care should be taken as it can easily become deadly. It is a good idea to make sure that the laser can't accidentally turn on (there is a module that one will need to make that will correct this - details are on the Duet Wiki). The reflection of a laser is very dangerous to eyes, ensure you either have a safety cover or filtering glasses (for the exact frequency of the laser).

Note that CNC creates dust and chips, lasers want a very clean environment (with gas extraction to get rid of the vaporized material - you should not breath in that vaporized material).

Typically Laser machines need less strong motors, while a CNC needs strong motors - if the motors are not strong enough it can get dangerous (cutting too slow can cause the dust to start catching fire - I have personal experience on this, it only started to create embers when I stopped it). Lasers don't mind strong motors.

This thread is also for anyone interested in doing this.

The issue: Duet Web Control is not using encrypted communication (HTTPS) and browsers are complaining when entering passwords into sites that are not encrypting communication. At some point, browsers might even refuse to allow entering passwords in any website that is not encrypting their communication.

The Duet board's main controller is based on the Arduino Due, which are a 32-bit processor with a bunch of memory and processing power, but still it is an Arduino and does not (based on what I could find), support hardware floating point operations and similar functions that would speed up encryption; in addition encryption simply takes a lot of extra memory and processor cycles all of which reduces the processor's ability to handle 3D Printing and all of the timings related to it. Therefore I agree with the Duet developers that it simply does not make sense to try to embed encryption into the Duet boards.

So that is where this idea and somewhat tutorial comes in. We can offload the encryption to a Raspberry Pi, which can easily handle it (especially if the Raspberry Pi don't have to do a bunch of extra stuff). I have decided to also run a Pi Cam from mine, to embed into DWC, but that is completely optional.

To make things easy and small, I have decided to use the Raspberry Pi Zero W (small board, with builtin wireless and a camera connector).

How I got to here:

• Downloaded the Lite version of the latest Raspbian (Stretch), and flashed it to a microSD card using Etcher (platform independent flash utility, makes things very easy). Just note that this will format the card, so backup any important files. You can also download the full Raspbian image, but that is only useful if you plan to have a display connected to the Pi (it uses a lot more of your card simply to run a GUI)
• Now, you will see a "boot" drive in your My Computer (Windows) or similar for other OSs. Create 2 files inside this drive: "ssh.txt" (this file will enable SSH connection to your Pi, which is how we will connect to it) and "wpa_supplicant.conf" (this file will contain your Wifi SSID and password, so that the Pi knows what to connect to).

Edit the "wpa_supplicant.conf" file to be more like this:

country=US
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
	ssid="xxxxxxxxx"
	scan_ssid=1
	psk=yyyyyyyyyy
}

The "xxxxx" and "yyyyyy" are your SSID and password respectively, change the US to whatever is your country's 2 character code.

You can now eject the card and insert it into your Raspberry Pi and connect it to power. The lights should start flashing, and if everything was correct, it should appear on your network, note the IP address when you find it.

Now we should connect to it using SSH, which allows us to execute commands on the Pi. Granted SSH is not the most beautiful interface to work with, but it is universal. You can download the Adafruit Pi Finder (https://github.com/adafruit/Adafruit-Pi-Finder/releases - yes, it is old, but it works) to help you locate and connect to the Pi (default username is "pi" with password "raspberry" it is highly recommended to change this asap).

Next we need to enter a few command for the pi, to set it up:

• passwd - run the set new password utility; this asks for the current password, and then the new password twice (the password entered is not displayed at all, so be sure to type it correctly).
• sudo apt-get update - this will perform a set of updates, simply wait for it to complete and respond to prompts if there are any.
• sudo apt-get upgrade - upgrades to the latest version, wait for it and respond to prompts as it happens.
• sudo raspi-config - this loads a very basic configuration interface, where you can expand the file system, enable the camera (if you will use it) and more. Go through it and set it as you need it.

Finally we are ready to install Nginx as our proxy server:

• apt install nginx - this will install the nginx package and start it.
• sudo systemctl stop nginx - this will stop the nginx server, so that we can edit it.
• cd /etc/nginx/sites-available - this will simply go to the nginx site configuration directory, where we will make an edit.
• sudo nano default - open the basic (nano) file editor, as an administrator (sudo) and edit the file in the current directory named "default"; this will load the file with the default settings and information, modify it to be:

server{
	listen 80 default_server;
        listen [::]:80 default_server;
        server_name <rpiname>.local localhost;

	root /var/www;
	index index.php index.html index.htm;

       	error_log /var/log/nginx/<rpiname>.local.log;

	location / {
                proxy_pass http://<duetname>.local/;
                proxy_set_header Host $host;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
	location ~/\.ht{
		deny all;
	}
}

Replace <rpiname> with the name you want to use to connect to your Pi; and replace <duetname> with the name of your duet board (to which the traffic should be forwarded).

Now we can run sudo systemctl start nginx to start the proxy server, and if all is well it will not give any error and you should be able to visit http://<rpiname>.local in your browser and have it display exactly what the direct link to the Duet display.

One known issue, is that uploading files does not work yet - this will take some more debugging and digging into logs (or if someone knows why it fails, you can chip in).

The next post will be about getting a self-signed certificate and implementing it in nginx to allow https connections between your browser and the Pi.

I use a PT100, 2 wire sensor.

The different sensors available in a little bit more detail:

• Thermistor: They are a simple resistor (usually high resistance, like 10k or 100k), with the added property to change its resistance based on the temperature it is exposed to (actually all resistors will change, Thermistors simply follow a predictable curve). Since thermistors are resistors they can be connected using stranded wire, which allows bending (compared to solid core; useful if mounted on a head of a printer). Generally a maximum temperature of 285C.
• Thermocouples: they are special solid core wires (2 different alloys, specified by the Type, most commonly used is the K-Type) that are fused together at a single point - this is the sensing point. When exposed to different temperatures, it creates a voltage (K-types have a 0.1V/*C graph). The thermocouple wires can't be soldered, as this would create additional sensing points, they can be crimped to different wires. Since the voltage it creates is extremely small, you need an amplifier close by to read it and provide a more useful signal to the controller. Since it is solid core, that part of the sensor may not flex or it will break off. Since it creates a voltage, polarity is very important. Generally for temperatures up to about 290C.
• PT100: These contain a very small piece of actual Platinum inside. That piece is calibrated to be 100 Ohms at 0C and follows a predictable graph (though this resistance increases with the temperature, compared to decreasing with Thermistors). Since they are resistors, flexible wires can be used without issue. More accurate than Thermocouples. They can be used for temperatures over 300C without issue (though each manufacturer specify a maximum which should not be exceeded).
• PT1000: Like the PT100 it is Platinum that is specially calibrated. Since it is in the 1k resistance range, the standard Thermistor inputs can be used for this (PT100 would allow too much current through, and actually affect the temperature by heating up). These can also handle the high temperatures. These are not readily available.

Thermistors and PT1000 can be connected directly to a Duet mainboard using the same 2-pin connectors. For PT100 or Thermocouples, you will need a daughter board, sold separately.

2-wire, 3-wire and 4-wire PT100 sensors:

• 2-wire: Most commonly used and most readily available (though not in my country, I had to import mine). This provides better accuracy than Thermistors, but usually not more than a good thermocouple. The same wires that bring electricity to the sensor, also performs the measurement - this results in the wire resistance (very small, but it exists and makes a slight difference) also being taken into account.
• 3-wire: This is the 1/2 way between 2-wire and 4-wire. Provides better accuracy since one of the wire's resistance is taken out of the equation. Since virtually no current flows through the 3rd wire, its resistance does not matter and the wire running next to it, which have all of the current running through is no longer used (the voltage drop over this wire is simply thrown out).
• 4-wire: In this setup you have 1 for Power +, Power -, Sensor + and Sensor -; since no current flows through each of the Sensor wires, they don't add resistance (we get a full Before Sensor voltage and a After Sensor voltage on these 2 wires); the before and after sensor voltages might only differ with a few mV from the power and ground, but this provides more accurate results.

Personally the 2-wire PT100 is good enough for me and allows me to use high temp filament without worrying (note that your hot-end should also be able to handle the high temperatures, if you need it). My other printer is happy with its Thermistor. I would avoid the Thermocouples - my big printer (with the PT100 sensor) came with one, and the amplifier board broke after 1.5 years (it broke due to flexing; requiring me to make massive changes, configure own firmware, since original firmware was not open source and it required changes inside firmware code etc - took a few months to get it back into service; now it is running a Duet and I no longer have to worry about it).

The way the Duet electronics is setup, any PWM switching (on the controllable fans) is handled on the Ground side of the fan. This allows you to supply the power of your choosing (granted that it shares the same ground) to the fan. For non-controlled fans, you can do the same or even have a separate board (like strip board with headers), to which you supply the different voltage.

On my setup, I have 24V Vin, but I only have 1 fan that uses 24V (extruder heatsink fan, so since it is an always on, it gets its 24V more directly from the power supply) - the rest are 12V fans as well as a 12V LED strip, these are run from a DC-DC Buck converter (input directly from the PSU), set to 12V and have this power fed into the Fan Voltage pin near the fan outputs - this ensures all 12V fans get their 12V and I have full control over them all.

A Buck converter is much more efficient at reducing voltage, compared to a regular regulator IC and cost only a few bucks (on Amazon I have seen a 8x converter kit for ~$12).

As to your suggestion of the resistor: it does not work like that. A fan is an inductive load, and not a resitive load: for a resistive load the Ohm's Law is perfect, but the inductive load works a lot different. Very basic: while the fan is spinning up, or below its ideal speed, it draws a lot of current (usually the rated amps), and as it is reaching its ideal speed, this current drops. This is where you will run into issues: the current is no longer enough to keep the voltage over the fan within its limits, and it blows. Also, don't add 2x fans in series, same issue will happen.

Running a single fan from an LM7812 (12V IC voltage regulator) is fine (though give it a heatsink),

I have previously tried a few other methods, including a reverse bias Zener diode (of sufficiently rated amps and voltage) - while it worked initially, the diode got extremely hot. Another option, not ideal, would be to build a simple voltage regulator (similar idea to what you have, except that you need a 12V zener diode reverse biased parallel to your fan):
Basically it will "short" the excess voltage to ground, through your resistor; this will keep the current through the resistor enough to create a large enough voltage drop to have stable volts.

Just an extra note, on newer boards there is a 1A fuse on the fan outputs, so just remain below that. Older boards does not have this protection, so remain well below that.

My recommendation is simply the DC-DC Buck converter.

The Gcode commands take a while to get used to, and is not very user friendly for most people. What helped me the most, was the Configuration Tool (https://configurator.reprapfirmware.org/ - just note its SSL certificate expired very recently [admins, can you perhaps go take a look]). By simply answering the questions, most of the setup is being generated for you.

After the basic configuration is done, I worked through the Gcode page (https://duet3d.dozuki.com/Wiki/Gcode to custom code the things I wanted). While not required to get a working printer it helps with fine tuning your settings and getting things the way you want it.

The other side of the Gcode is that it is extremely powerful: I have converted a Wanhao D5S Mini with the DuetWifi (E3D Head, Bondtech QR etc). I am waiting for a few additional heads, which will allow me to switch heads (not nozzles, since changing nozzles takes time and requires heat) very easily; very useful when I want to switch between 1.75mm and 3mm filament and even between 0.4mm nozzles and the other sizes (like 0.2mm and 0.8mm); change between PT100 and standard thermistors. Yes, I need to shut the printer down before doing a change like this, but after the change simply run a macro and the printer knows exactly everything it needs to know for the extruder/head/temperature sensor combination, and ready to print.

If you have not lost all hope yet, why not post your config and explain the issues you are having - a lot of users in this forum may be able to help.

@LB The space issue I mention is space on the display and not storage -> since PanelDue is a touch screen, each button and action needs enough space to ensure you don't touch the wrong button. It also feature only a 800x480 pixel display (5i and 7i versions).

With the current layout PanelDue only have space to display 3 estimations

A print job that was simulated, have its estimated time saved to the gcode file itself specifically to prevent having to simulate them again.

@User3D Only the Simulation time gets saved; the other estimates (filament, layer, file progress) are calculated while printing and is not saved as these are constantly recalculated and change often. Rerunning the print, can yield different estimations (especially when a change in flow/feed rate was commanded).

@medicusdkfz As mentioned in the quote, "DWC can also display 2 extra estimations" -> DWC is Duet Web Control (the interface you run in your browser when connected over the network - ethernet or wifi). PanelDue is unable to currently show these estimations due to a lack of space. While the 7i is larger than the 5i, they have the same number of pixels.

Perhaps take a look at https://github.com/frank26080115/PanelDueSplashMaker

While it is old, and not updated recently, it is still working even with the latest firmware versions. Simply go to its folder "release_binary" and download the file.

Place the file in an easy to access location and run it (I think it will download the Bossa and bmp2c-escher3d binaries automatically, on first run). It provides a simple to use interface:

• Click on the Load Image and select your image (a preview will be shown).
• Choose the "Local Files" tab (default is From Web, which gets the latest version, but may not work reliably).
• In the Firmware Binary (nologo) File Path, browse to your firmware that you want to use.

The last step is what to do with the resulting firmware. If you want to save it, (for example to upload it with DWC in latest version firmwares, to flash it from ReprapFirmware), click the Save Resulting Firmware and choose your location. If you have the PanelDue directly connected to your (you might still have to save it), you can use the "Final Firmware Binary File Path" and its buttons to flash it (have not used this direct flashing).

This is what I use to create the splash screens for all my various printers.

For the Unload command (similar to the M600), you can set that in your PrusaSlicer's Tool Change gcode, the command for that would be: M702 (I guess you would want this prior to M600).

Another option is to insert the M702 in your M600 macro (filament-change.g in /sys). This will automatically do the Unload for you.

Regarding the the automatic cooldown, I have not seen any way to do this yet. For me, I am typically close to the printer while printing, and especially if there is a need to change filament, I am on standby for it (so the filament don't cook in the nozzle).

Ok my problem was solved, and I further improved my script (I called it duet-tool-change-strip.py)

#! /usr/bin/python3-64
# duet_toolchange-strip.py
import fileinput
import re
import sys

#first we define our regular expressions for a match
extruder_0_pattern = re.compile('^T0') #the first of this is kept
extruders_other_pattern = re.compile('^T([0-9])+') # match any extruder number (if you define 100, in PS, you can use all 100 or even more)
empty_line = re.compile('^$') #we are stipping empty lines
temp_set = re.compile('^M109 S([0-9]+)') #match the deprecated way to set a temperature
temp_set_2 = re.compile('^M104 S([0-9]+)') #match second deprecated way to set temperature
acceleration = re.compile('^M204 S([0-9]+)') #convert to Duet acceleration set

#this variable to is to ensure it still work for single extruder prints
print_have_started = 0
for line in fileinput.input(inplace=True):
    if extruders_other_pattern.match(line):
        if (extruder_0_pattern.match(line) and print_have_started == 0):
            print(line.rstrip("\n")) #we keep the Tool as is.
            continue
        else:
            print_have_started = 1
            m = extruders_other_pattern.match(line)
            extruder_nr = m.group(1)
            print('M291 R"Tool Change" P"Tool #%s " S1 T30\nM600' % extruder_nr)
            continue
    else:
        if not empty_line.match(line):
            if temp_set.match(line):
                m = temp_set.match(line)
                print("G10 P0 S%s" % m.group(1))
                continue
            if temp_set_2.match(line):
                #void we don't want or need this line.
                m = temp_set_2.match(line)
                print("G10 P0 S%s" % m.group(1))
                continue
            if acceleration.match(line):
                m = acceleration.match(line)
                print("M204 P%s" % m.group(1))
                continue
            print(line.rstrip("\n")) #this is the default - we keep the line as is, if it is not empty

So this script works as explained in a previous post, and now also correct the temperatures and acceleration for RRF. Note that PS adds its heatup command after your own starting Gcode, so if extruding in your starting, it is best to ensure the printer is heated before it.

The acceleration, while PS generates the M204 commands, RRF does not know the S-parameter, here I convert the S to a P for print acceleration..

Both 104 and 109 commands are converted to G10 commands, only setting the S (active temperature), so if you have set the standby, it is kept.

The issue I had, was simply not calling Python directly before the script in the Print Settings > Post Processing scripts. I have used Python 3.8.5, which I placed at: C:\Python38\python.exe (if yours is installed in the default place, instead of wrapping the path in quotes, you should place a "!" before any space - https://manual.slic3r.org/advanced/post-processing). this gave me the entry in my Post-processing scripts as <path to python.exe>\python.exe <path to the script>\duet-toolchange-strip.py;

Some people place the script in a subfolder in their PrusaSlicer installation, that can be overwritten on a new version. Place it in a safe location.

As to a license for the above code: Public Domain. Modify, adapt, distribute as needed.
There may be more efficient ways to do the same.

@T3P3Tony Thank you for your reply.

I am trying to go with option 1: creating a post process. I have a post-process that works directly in my command line, but having trouble getting it to work directly from PS (I have both a Perl and Python version). I have create support post in their support forum, as well as a issue in PS's github.

When I get it working, I plan to post it here. My current code actually waits for a T1 (or higher tool number), before actually starting to work (this assumes the correct first filament is inserted, as I always do) which have the by-product of not doing anything unless a second tool is required.

I also plan to use it to process a few other commands Duet have issue with (like PS's temperature setting, acceleration and other I might find later).

Option 2 might have worked easier if the virtual tools could be hidden from DWC and PanelDue.

So all my printers have single extruder/hotend setups. With S3D I previously made a few print files (very manual process), to use different filament on the same layers, using simple M600 command to change the filament (from the video by Make Anything on YouTube).

Most modern slicers now allow a form to create the gcode files for this (including PrusaSlicer, with its "Single extruder multi material").

However with that setting on, it is still generating T commands (for tools that don't exist). While I can easily go through and remove them one by one (a lot less work than what I did for S3D), it is still a manual process of editing the gcode.

I have now attempted to create a few virtual tools in RRF, but it is showing all of them on the PanelDue and DWC, which is not ideal.

Ideally I want a message prior to any filament change specifying the tool, from the slicer, prior to me having to change the filament (using M291). So basically anytime there is a T command where it is higher than -1 (is used to deselect), simply show a message for a few seconds (non blocking, so that M600 can cause the pause, displaying the new tool number) and then run the M600, without actually going to the new tool (still use T0). How would I go about configuring this?

According to your description for home limit locations, mine is setup very similar (X min, Y min, Z max - stall detected). Z is also allowed to go below 0.

When I set the origin of the stock, I have a macro that simply runs G10 L20 P2 X0 Y0. I run this when I am happy with the current XY as being on top where the cutting should be, and it will show as XY 0 after running (also a good idea to set G54 so that you switch to the first work offset - mine is set in my config, so I am always in it).

Right after the probe, to determine the top of the stock, I run G10 L20 P1 Z24.25 - The Z24.25 is my measured height of the probe block.

The idea of the Work coordinates is that while the machine knows exactly where the spindle is, it can run relative commands related to an origin. As long as the stock does not cross to the outside of the limit switches, it should work as expected.

I have done this upgrade: in short I wanted a bigger nozzle, for improved flow (since the plus is quite big, and using a 0.4mm nozzle will simply take days to print anything bigger than I already could), and have a unified interface across all my machines.

I opted for the Duet Maestro for a few reasons: 1) it have ethernet (I used an ethernet extension, to bring it to the outside; wifi is going to struggle to get in through the chassis); 2) it have sufficient ports and connectors for everything on the Ender 5 Plus; 3) it is not as expensive as a Duet Wifi; 4) improved BL Touch capabilities compares to the Wifi (installing and setting up the BL Touch was simple easy and straight forward - on posts in this forum, I noticed it is harder to do on a Wifi or Ethernet).

I designed a mounting plate, that fits the Ethernet port, and is used as a mounting point for the PanelDue case.

I mounted an E3Dv6 Volcano; using the Petsfang/Bullseye as a mount (extended with a different blower fan mount). This part caused me to lose about 5cm in X direction, and actually gains a few cm in Y, but it works nicely.

I also upgraded the extruder to a BMG, and it is working great.

When upgrading, it is important to have all mounts and parts printed before you start (unless you have an extra printer, but to save time).

The heatbed is the thing that draws the most current, the stock E5+ use a big mosfet board to handle this - I decided to keep using it (technically the Duets can handle the current, but it is near the limits). Note that the Z axis have a shallow angle in the threads (it keeps the bed where it is left), but increases the z steps per mm.

I have been running this configuration since early in the year, and working great.

Which Post Processor are you using?

The purpose of the Post Processor is to convert Fusion's native toolpaths, into gcode which your machine can understand. Since Duet is more meant for 3D printing, and does not support all cnc related codes, you should use a Duet compatible version of a Post Processor - this ensures the right commands and parameters are in the output (and nothing which will cause "Bad command" errors).