Nevermind, looks like the reason F0 did not work was due to some connector issue.
And the wrong indication for F4 & F5 was probably due to Duet Web Control still being on 3.4.0 and not 3.5.0.
Everything works fine now. Issue not related to 3.5.0-rc.1.
Please disregard.
I have the Duet 3 6HC with 3 Expansions Boards 3HC and just updated all boards from RRF 3.4.0 to 3.5.0-rc.1.
Before 3.5.0-rc.1, all fans worked fine but now I encountered some issues. Some fans are working, others are not. Here's the heater & fan part of my config.g:
Removed
Some observations I made:
Blower F0 does not work but Blower F1, F2 and F3 work and can be set manually via Duet Web Interface.
Heat sink fan F4 works if triggered by the temperature threshold but I cannot turn it on manually via Duet Web Interface.
Heat sink fan F4 and F5 were showing in Duet Web Interface that they are set to100% but were not actually turning. Once the temperature threshold was reached, they were still showing 100% and started to turn as well.
Did 3.5.0-rc.1 change anything with regards to fans? I am aware it added some parameters for LED's but that's about it?
@dc42 excellent news, thank you!
If the documentation about Input Shaping is up-to-date, it is currently only possible to apply IS to axis motors driven directly from the Duet 3 6HC.
This basically limits IS to any printer with up to 6 axis motors which is probably good enough for many people but not for me. 
Are there any plans to enable IS on axes connected to CAN-connected (3HC) expansion boards or is this a hardware limitation of CAN FD?
Hey guys,
Unfortunately this is not an issue where I simply configured the motor direction wrongly (printer been working fine for years, I just recently switched my Z probe). Instead I have the following:
When I start my printer and home all the axes except for Z, then use G30 to home Z, it works perfectly fine.
But when instead of G30 I first do a fast homing of the Z-axis by executing the following code:
G91
G1 H1 Z-600 F300 ; fast homing
G1 Z2 ; move away a bit
G30 ; final slow homing
... the bed moves in the wrong direction when G30 is executed. Instead of moving up towards the nozzle, it slowly moves down 10-20mm and then rapidly further down and reports probe was not triggered. Immediately after that it executes a second probing where the directions are then correct (up slowly, down quickly), however due to the distance between probe and bed by then, it also reports that probe was not triggered.
My Z-Probe, which is an Euclid type probe with a MSW (hence a relatively high trigger height), is configured as follows:
M574 Z1 S2
M558 A5 S0.03 P5 C"^io2.in" H1.5 F80 T10000 ; set Z probe type to unmodulated and the dive height + speeds
G31 P500 X-15 Y5 Z17.0
Interestingly when I change the trigger height from Z17.0 to Z1, everything works fine.
I would say that this is a bug in the firmware (I have 3.4 installed) as the trigger height value might be unusually high but let me know your opinion.
Any workaround if this is a bug?
I am designing a customized PCB with a NC microswitch (limit switch) which will be connected later to the IO Pin of the Duet 3 and used as axis endstop. Hence, a few questions:
As per the documentation, a simple 2-wire microswitch should be connected to the IN and GND pins of the IO connector. Is this 3.3V or 5.0V? Because I wish to connect an LED in series for switch feedback and need to pick an adequate resistor.
In addition to the microswitch and the LED mentioned above, the PCB has another brighter LED which should illuminate the scene a little bit. Is it somehow possible to turn this LED on/off using the IO connector? I know this would work with a fan connector but with an IO?
Thanks in advance.
Greetings!
I just measured my 320x400mm aluminium bed and although the height map could be worse, I wonder if anything can be done to correct the imperfections shown below:
As you can see the mean error is kinda low but the corners are a bit too high with deviations up to 0.254mm at Corner 2. You can find a sketch of my printer layout below:
The gantry moves on two linear rails (MGN9) in X-direction and the print head moves on the gantry on a linear rail as well in Y-direction whereas the bed moves in Z-direction.
I wonder if any adjustments can be done mechanics-wise to get rid of the high corners or is this as good as it gets? Maybe raise/lower one of the rail (1-2-3-4) or gantry ends (5-6)? The bed is made of aluminium with a magnetic sheet and removable spring steel installed on top of it.
(Note: I currently use an IR probe on bare spring steel and although the steel is quite shiny, I got pretty good repetitiveness for the measurements.)
@roiki11 Too complex if you ask me. Imagine having to troubleshoot and maintain 16 heaters and thermistors. It's also 16 potential fire sources. They should have gone with max 4.
@t3p3tony Is there a fix for this in beta 6?
I didn't have a delay in my config.g but I added one at the beginning for testing purposes and it does not make any difference (well except that it takes longer ofc).
Sending M98 P"config.g" does not generate any errors.
When I send M112, there are actually no errors and the homing works fine, just like pre 3.4-b5 (even the thing with the different motor speed, might have been a one-time thing)
When I send M999, I get the errors. Also when I change the config.g and reset the board (which probably is also M999?).
After upgrading from 3.4-b2 to 3.4-b5 on my mainboard and from 3.3 to 3.4-b5 on my expansion boards, the drivers on my expansion boards don't seem to work anymore correctly. During the very first boot, there is no error message but even then I notice something's wrong during homing (e.g. wrong motor speed). When I reboot with M999, I then get the following error message:
After that error message, the motors in question don't turn anymore. I have a Duet 3 attached to an SBC and 3 expansion boards.
Is there any easy way to downgrade to 3.4b2 for the mainboard and 3.3 for the expansion boards? Or should I wait for beta 6?
Thanks, I edited the script a little bit and now it works
T0 P0
M106 S1
T1 P0
G4 S1
M106 P0 S0
T0 P0
G4 S1
M106 R2 ; This should turn the fan back on, no?
Note that replacing the last line with "M106 P0 R2" does not work. This is probably the reason why my printer did not restore the fan speed after toolchange. Not sure if this is intentionally or not.
I've noticed that my printer does not restore the cooling fan speed after a toolchange despite being told to do so. Usually when a tool is freed, the PC fan is turned off and turned on again when the tool is selected.
So I created a little test script where I simply turn on & off the fan (no toolchange involved) and it indeed does not seem to work
T0 P0
M106 S1
G4 S1
M106 P0 S0
G4 S1
M106 P0 R2 ; This should turn the fan back on, no?
Can anyone test the script and post their firmware version in case it works or post an adjusted script where it works?
@hackinistrator said in How do I get rid of plastic dropping out of the nozzle?:
purge - retract - wipe - print
Well that's my current procedure. The problem is the step "wipe - print" where the head moves from the wiper to the print object. On the way there, plastic oozes out of the nozzle. I already tried changing the retraction in 0.5mm steps from 1 to 6mm (direct drive) with zero effect.
@pcr Copperhead from Slice Engineering
@deckingman Thanks for the tips, I have only tried PLA so far at 185°C which imo is already quite low.
I've got an IDEX printer which works great but multicolor prints are usually a mess. I even have a purge bucket + wiper and after the purge & wipe process, the nozzle is clean but on the way from the bucket to the print object, about 5mm of plastic drop out of the nozzle which then protrude from the outer wall of the print object.
I already tried adjusting the retraction settings but they don't seem to change anything (which makes sense since retraction only pulls back the solid part of the filament and does not affect the already molten part in the nozzle very much).
The only solution I can think of is a prime tower (which I wanted to avoid, hence the purge bucket). Increasing the travel speed will probably minimize the leaking part too but not get rid of it 100%.
Has anyone solved this issue with his/her multi extruder printer?
@dc42 said in Toolhead preheat prior to a tool change.:
We plan to implement this on Duet 3, by having 2 readers reading the same GCode file. Reader #1 will do the printing, while reader #2 will run in simulation mode and stay ahead, so that it can tell #1 in advance that a tool heater should be switched to active temperature, or (for a mixing extruder) that the mix should be changed.
On Duet 2 there probably isn't enough RAM to do this easily, because of the additional DDAs needed to run a simulation in parallel with a real print.
Cura has a facility to advance tool heating and I believe some users have it working with Duets
@dc42 Sorry for necroing this thread but was this ever implemented? This would actually be useful since some slicers (like PrusaSlicer) don't pre-heat tools before a toolchange happens.
@dc42 @dc42 I finally managed to update the main board to RRF 3.4b2 and the issue seems to be fixed. Thanks! I will do some further tests just to be sure.