@CR3D did you take the M122 reports one right after the other? The M122 report for the master board says it was reset 38 minutes ago, but the board 1 report says it reset 17 minutes ago. So perhaps board 1 had an unexpected reset. Unfortunately the M122 report for board 1 doesn't give the reset reason. However, next time it happens, if the M122 B1 report shows that board 1 has reset, you could connect to board 1 via USB so that you can send M122 directly to it and get the complete report.

OOH if the 3.5beta3 firmware is working well for you, then you can continue using it. We hope to release 3.5beta4 next week.

@DuetWiz1122

would you happen to know how many Duet 3 HCs are sold / manufactured each year?
(this is all in the name of trying to show "maturity" to a suspicious graduate school advisor)

A million flies can’t be wrong? Following this argument path you’ll end up with a PC box from the Stone Age running WIN98. Not ideal for a 3D printer, but with "proven" commercial success 🤡.

Your "suspicious advisor" is well advised to check the requirements of your project: Is it for open hard- and software, for an all-gCodes approach, extensibility, broad support for printer components, a large and dedicated community … - or is it merely to print some benchys? Educate him to make a qualified decision, don't count the flies.

@oliof said in David's IR Sensor: Questions:

Also, how would one update the firmware in existing sensors at home?

You would need a programming tool for AVR microcontrollers, such as a USBASP or AVRISP or an Arduino running the ISP program, plus a 6-pin pogo pin adapter such as https://www.sparkfun.com/products/11591.

@casperen I'm glad it's fixed. One possibility is that your router installed an automatic update that introduced an incompatibility with the older firmware for the Duet WiFi module.

@OwenD, while interesting to see what all can be done with conditional code, I do not have the confidence to start a print all by it's own at a particular time. I will always check on print progress on multiple occasions and especially at the beginning of a print. While I let my printer print overnight, I always end up waking up 2 or three times during the night so I can check the print progress on a web cam.
I am currently still on RRF 3.4x but I will study the code to see how I can take advantage of the upgraded message system in 3.5.

@deckingman Thanks for the update

Thanks all figured it out

@RogerPodacter said in Problem with Fan Settings Across 3HC and Mini 5+:

my original intention was to use the daughterboard thermocouples and have TC0 control a fan on the mainboard, and TC1 control a fan on the 3HC.

That should work, provided all boards are running firmware 3.4.2 or later.

@dc42 That was the problem. I have already changed the pin and it seems that everything is fine and that the measurements are correct.
Thank you very much for your help.😊

@dvmourik thanks. The filament length in those files is already recognised in the 3.5.0-beta.3 build of RRF. I have back-ported the change so that it will be included in the forthcoming 3.4.6 release too.

@WarriorMe to suppress the duplicate labels in RRF we would need to try to work out whether a M486 refers to the same object that has just been labelled by a comment; and vice versa. Alternatively we could provide a special version of M486 that instructs RRF to ignore all remaining M486 command sin the file.

Regarding which form of labelling we prefer, either comments or M486 commands that include the object names provide all the information that RRF needs. If the M486 commands generated by SuperSlicer do not include the object names, then comments would be preferred.

PrusaSlicer appears to generate comments but not M486 commands when the Label Objects box is checked, at least when there is just a single object in the print.

@Wehaywire please share your homex.g, homey.g and homeall.g files too. It's possible that you have set them up in a way that leaves X and/or Y outside the normal reachable range, in which case the first movement after homing will try to bring them into range.

@Th0mpy said in Anybody wants a stepper motor analyzer?:

You can update your code to point to these two repositories:

That's got it working, thank you!

@dc42
OK thanks, I was using 70'C, that may be the problem!

I'll try it at 80'C

@chrishamm update: today this SD card died permanently. so it was in fact beginning to fail.

the SD card is the one which came with the Duet 3 Mini 5+ which i purchased in Sep 2022.

@chrishamm yes, I understand, thank you. You can mark it as solved.

@SANJR you can configure X2, Y2 and Z2 endstops as triggers in config.g. See https://docs.duet3d.com/en/User_manual/Tuning/Triggers

For X1, Y1 and Z1 you can also configure them as triggers in config.g. Then reconfigure them as endstops at the beginning of each homing macro, home axes, the redefine as triggers at the end of the homing macros.

The triggers should probably be set as emergency stop, as if the machine has gone beyond the limits, something has gone very wrong!

Ian

@Saschka you may be able to use a G1 H4 move in that case. Just make sure you setup the correct sensorless parameters

Great, now everything works as I wanted. The indications received were perfect. You can mark it as solved, thanks!