Topics created by HeidiH

@HeidiH assuming you are running without attached single board computer then one possible issue with removing power is that if the board is writing to the SD card at the time then the SD card may be corrupted. SD card writes can occur when uploading a file or doing a other DWC action that changes files, within 15 seconds following the last log message written if you have enabled logging, when a simulation completes, and any time you execute a command that writes to file e.g. an echo command with output redirection.

So as long as you don't do anything in daemon.g that writes to file or creates log message when the machine is idle, removing power is fine. It's what I do.

To avoid clogging the hot end you may need to wait until the hot end has cooled sufficiently before removing power to the hot end cooling fan.

@T3P3Tony Hi Tony, and thank you for your help. I got it now working well. I think I had an issue previously when I had configured my first sensor to have

M308 S1 P"spi.cs1" Y"rtd-max31865"

instead of having it

M308 S1 P"spi.cs0" Y"rtd-max31865"

based on the naming on the daughter board. But now I got all my three sensors working with two daighter boards.

BR; Heidi

@HeidiH said in Heaters turn ON when powering ON or restarting Duet 3:

I think these are the questions you want answering?

With the first case I got a heater fault warning and a comment on n/a as the temperature on the web interface

This was probably a configuration error, and the heater has been defined with no temperature sensor.

while with the latter case the firmware was not responsive. In both cases, both of my heaters turned on (even without setting-up any input for them), which is not desired.

I think the configuration with the output pins inverted, along with the wiring issue with the SSR, caused this.

Was these above events because I had my heaters wired and configured in a wrong manner, and does the above change avoid this risk?

Yes, I think so. The default state of the heater should now be off.

I had also my heater fault detection set with M143 as described below but it wasn't able to avoid this unwanted heating:
M143 H1 P0 S300 A0
M143 H2 P0 S180 A0

If the logic to turn on and off the heater is reversed, when the firmware tries to turn off the heater (either because it reaches temperature, or there is a fault) it will actually turn the heater on! It doesn't 'know' what is happening or why, just that the temperature is not what is expected.

By 'what is expected', the firmware has a model of how the heater responds, which is created by running M303 heater tuning, and configured by M307 in config.g.

Also, should I have my allowed lowest temperatures be configured with M143, and not only the maxima? Unfortunately I don't figure it out what does the monitor number mean (P in above commands)? Is it somewhat related to the H term?

Generally, you set basic maximum temperature limits with M143. It is possible to set minimum temperatures too, just it is usually not very useful. The H term is used to define which heater has this limit. You can set up to three M143 commands per heater using the P command, and use the A and C parameters to define different actions at different temperatures. For example:

M143 P0 H2 S180 C0 A0 ; Heater 2 temperature too high, generate heater fault M143 P1 H2 S200 C0 A3 ; Heater 2 temperature too high, shut down printer M143 P2 H2 P2 S10 C1 A0 ; Heater 2 temperature too low (below 10C), generate heater fault

Use M570 to configure how accurately you want to maintain the set temperature.

I also tried to read about these issues from: https://docs.duet3d.com/en/User_manual/Troubleshooting/Heater_faults, but based on that I assume the firmware should automatically detect at least bad wiring issues?

It can't automatically detect bad wiring issues, it just tells you when the input (ie turning the heater on and off) doesn't match the predicted output (temperature increase/decrease). This may be because of bad wiring, but it can't tell that is the issue, just that there is something unexpected.

Ian

@T3P3Tony Hi, and my apologies for the late reply. I repeated my measurements and got a bit more accurate values for the U and V based on those. I now added them in place and neither of the sensors was anymore showing any error, so I think that I might have mixed up with the U and V values. I ensured that the readings now also improved a lot, when using those correct U and V values. So thank you for these parameters for the developers :)!

@HeidiH I think this may be a problem of how you are calling the macros. If you start the beep macro from DWC, it will run, but if you start another macro from DWC, it will be queued behind the first macro, and only be run when the first macro is finished. This is similar to how when you set a heater temperature and wait for it to heat up from DWC, you can't do anything else from DWC, but you can from the PanelDue. If you call the beep macro from within a print job, then run that print job, then run the abort macro, I would think that would work. RRF maintains a number of separate input channels, and commands are executed sequentially within them.

Ian

@dc42 Yes, great. it is that. We solved the issue by using a semiconductor relay allowing to provide external trigger for our Duet 3 board input, in which we chose the active-to-inactive stage change. Thanks again!