Not sure about that 10%

Try sending M106 P0 L0 and then check if it's still 10% min.

I also notice that you have the PWM freq at Q150. Can you try returning that to the default 500?

Does the hotend heatsink fan behave correctly?

@dc42 @deckingman Thanks for your feedback
Concerning the analysis, with my Raspberry, I get a pretty accurate analysis (a few millimeters)...

In this case, if I understand correctly, the simplest thing would be to analyze the distance with the Raspberry, and to send the displacement via my python program in Gcode...

This is a possibility.

Otherwise, for my need of height analysis (outdoors for a max distance of about 90 cm) without need of accuracy higher than a millimeter, would you have a tip for a probe more adapted to the Duet3?

Francis

The code I suggested is based on using the sensor you have as a filament monitor.
If that is not the case and you simply have it connected to an input then you will need to replace any reference to sensors.filmentMonitors[var.whichSensor]status with something like sensors.gpIn[var.whichSensor].value ,where whichSensor is your gpIn value for the switch
You would also not need anything referring to M591

@phaedrux Thanks for the fast reply fellows.

I replaced the files on the SD and flashed the 3.4 firmware via the PanelDue.
After that the Wifi adaptor no longer turned on, connected the Duet to my pc and turned on wifi adaptor by a command.
Connected through the COMM port and did the Wifi turn on command, all good now.

I can't find the 'Issue resolved button" here, but this topic can be marked as solved.
Cheers

Can I use the Echo command (https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands) in one of the files of the filaments section, in order to have it automatically create/overwrite a macro, according to the currently used filament? (the macro should have same name for all filaments, but then only contains the temperature for the currently selected filament).

So that i can call this macro with M98 custom gcode in the slicer and it would always set the other layer temperature to the one i define in the filaments section of dwc? Would config.g or load.g make the most sense to have it create that macro?

Also, is calling for M703 in start.g enough, or does it have to be included into the slicer start code too, in order so noting overrides it?

Edit: echo >"test.g" "M104 S210" does not seem to work

@arnold_r_clark said in Spurious heater faults:

never reach the same conclusion twice

How much variation are you seeing?

@dc42 @dc42 Hello,
yes the connections are well on IN and GND and I have good feedback but not very precise.

I tested with the following options:
m308 s0 y "thermistor" p"^io6.in"
m308 s0 y "linear-analog" p"^io6.in"
m308 s0 y "linear-analog" p"!io6.in"
m308 s0 y "pt1000" p"!io6.in"
m308 s0 y "pt1000" p"^io6.in" T100000 B4725

I have some reactions but they seem strange, because for example I go from "Sensor 0 type PT1000 using pin !io6.in, reading 58.6 , last error : success, R:2200.0 L:0 H:0" to Sensor 0 type PT1000 using pin !io6.in, reading 2000.00 , last error : success, R:2200.0 L:0 H:0.

Which type should be used?
Is there any way to calibrate more or less the reading?

Thank you very much

@jrcl

Always glad to be of help when I can. I remember starting out with my first 3D printer and having to climb the learning curve. Pretty soon it will all be second nature to you.

Frederick

@mejituu no you can't. RRF will use the UART if it detects that it is present. This means that for the two add-on drivers that you can connect via the stepper driver expansion header of the Duet 3 Mini, you can choose to use drivers with or without UART.

@marioys97 you can connect the two thermistors in series or in parallel to a single TEMP input and adjust the M307 T parameter to suit. Series connection biases the reading towards the cooler thermistor, while parallel connection biases it towards the hotter temperature. Series connection has the advantage that you will get an open-circuit reading if the wiring breaks anywhere.

@phaedrux and Stephen6309, thank you both very much. This is very helpful with so little time to work on it currently.

@dc42 said in Makro with variables:

Use the R0 parameter in the M290 command to set absolute instead of relative babystepping.

I already printed with half the value, but this is much better and makes it perfect, thanks! 😎

Thanks for the help @everyone, this is exactly what I have been looking for!

Could someone maybe post the code of a well filled filament config.g so i can look at it? I am specifically wondering how to set first layer and other layers temperature in a way that all slicers understand, as they seem to utilize differently named variables. That's already more than I aimed for, but I like the idea of having all my filament configuration in one place on the printer, a lot.

@fcwilt

https://www.amazon.com/Youleke-Torque-Digital-Servo，Waterproof-Horn（270°）/dp/B08739MGPL/ref=sr_1_4?crid=HHSQAXOVWT74&keywords=BETU+2Pack+25KG+High+Torque+RC+Servo&qid=1650928661&s=toys-and-games&sprefix=betu+2pack+25kg+high+torque+rc+servo%2Ctoys-and-games%2C73&sr=1-4

@highfreq said in Axis temperature compensation:

if i can change it continuosly or just once at beginning of the print

If you compute axis compensation in start.g, this is for the whole print - which makes sense. If you want, however, monitor the chamber's temperature all the time (and adjust the compensation accordingly), put your code in daemon.g where it will be called every 10 seconds. Personally, I think the latter approach is questionable, as you counter one "global" variable (the axis elongation) which affects the whole print with a measure which affects single layers - that's difficult to balance properly. Better you keep the conditions stable during a print.

@dc42 said in Filament sensor triggers for the wrong extruder:

@adammhaile I confirm there is a bug. When the filament-error event is constructed, the CAN address and device number parameters are swapped.
I have fixed this in the source code. The fix will be in RRF 3.5.0beta1 and also in 3.4.1 if we do that release.

Awesome. Thanks for the update!

This fixed my issue, thank you for your help @Stephen6309!

@dc42 said in Object cancellation: cancel global features:

Would it really make sense to cancel all non-object items at once?

No of course not all at once, this is why I thought it was maybe possible to count and list non-object items the same way as object items so there would for example the following list

Object 0: "cube"
Object 1: "cylinder"
(non) object -1: purge towers, etc. Everything that the slicer gemerates and does not label as object
(non) object -2 to -99: e.g. custom gcode sequences that are explicitly labeled via M486 S(-2 to - 99) that the user may want to leave out at some point, and that are not printing moves. The negative numbers only make sure that these custom features can be used regardless of the number of printing objects (for which the slicer/firmware would automatically generate only positive numbers).

You could of course also label these custom features with M486 S999999 or so because you are realistically not printing a million objects but I am not sure if there would be some implications for that (like the requirement for continuous numbers so the firmware would create "null" placeholders for everything between the last object number that is actually in the gcode and 999999) EDIT: this seems to be the case but only up to 40 objects

Post your config.g and your homing files. Perhaps you have the homing move shorter than the axis length.

@fbg said in Duet3 problem sensor homing, not happen in Duet2:

Remember @Phaedrux IF I test with a duet2Ethernet ALL works properly.

This makes me think you've wired it incorrectly. Photo?

Ok, looks like a wiring issue on the PWM wire between the Duet and the fan.

Thanks for the support!