Network time sometimes missing. How to force it to try again.

[mikeabuilder]

I have a MB6HC with wired ethernet. I'm running RRF 3.5.1 in SCB mode, using PanelDu as the interface

I have a recurring problem where occasionally, my boards boots, connects to the network, but does not get it's clock set to the correct time. This causes me problems because I have macros that turn the heaters off 10 minutes after a print finishes, but when I don't get the date/time started properly, state.time is null

This happened to me today and here's a clip from my event log. You can see on line 8 that the board got an IP address, but no client login is recorded. In this case, the client login succeeded over 6 hours later. What happened when it succeeded is that I echoed state.time from the PanelDu console and got a null returned. Then I walked into the house, connected from my laptop and used DWC to look at the object model and saw IP was connected. By then (about 5 minutes later) the system had logged in and gotten a time.

So my question are:

1. Is this maybe a bug? I assume not because it would have been flagged by loads of people.
2. Is there a way for me to force the system to attempt a login? I can see putting something in daemon.g that would look for a null state.time, verify there's an IP address, then force a login. I don't want to do anything that might impact a running job.

2024-11-02 16:49:33 [warn] Warning: 12V under-voltage event (9.4V)
power up + 00:00:00 [info] Event logging started at level info
power up + 00:00:00 [info] Running: Duet 3 MB6HC v1.01: 3.5.1 (2024-04-19 14:30:55)
power up + 00:00:00 [info] G10 P0 X0 Y0
power up + 00:00:00 [info] G10 P0 Z-0.335
power up + 00:00:00 [info] G10 P0 R0 S0
power up + 00:00:00 [info] starting 0:/macros/prep_printer.g
power up + 00:00:00 [info] M291: - [no title] - Run prep_printer macro? Heats bed, homes axes, levels bed, creates comp mesh.
power up + 00:00:04 [warn] Ethernet running, IP address = 192.168.0.172
power up + 00:00:06 [info] M292: cancelled=false
power up + 00:00:06 [info] M291: - [no title] - Prep Step 1 of 3 - Heat the bed? May take 10-15 minutes
power up + 00:01:45 [info] M292: cancelled=false
power up + 00:01:45 [info] M291: - [no title] - Heating bed to 65C prior to next steps. This may take up to 15 minutes.
power up + 00:09:09 [info] M291: - [no title] - Bed heating completed.
power up + 00:09:09 [info] M291: - [no title] - Prep Step 2 of 3  - HOME ALL AXES?
power up + 00:18:50 [info] M292: cancelled=false
power up + 00:18:50 [info] M291: - [no title] - Homing all axes.
power up + 00:19:19 [info] M291: - [no title] - Homing completed.
power up + 00:19:19 [info] M291: - [no title] - Prep Step 3 of 3 - CREATE COMPENSATION MESH?
power up + 00:19:22 [info] M292: cancelled=false
power up + 00:19:22 [info] M291: - [no title] - Compensation mesh creation skipped per user request. 
power up + 00:19:24 [info] M292: cancelled=false
power up + 00:19:24 [info] Compensation mesh skipped per user request. 
power up + 00:19:24 [info] M291: - [no title] - Printer prep process exiting.
power up + 00:19:26 [info] M292: cancelled=false
power up + 00:19:40 [info] G10 P0 S210
power up + 00:21:34 [warn] Started printing file 0:/gcodes/Shell 1 - new.gcode
power up + 00:21:34 [info] G10 S210 P0
power up + 00:21:45 [info] G10 S210 P0
power up + 02:27:37 [warn] Finished printing file 0:/gcodes/Shell 1 - new.gcode, print time was 2h 6m
power up + 02:27:37 [warn] Error: in file macro line 15 column 53: meta command: expected numeric or enumeration value after '+'
power up + 03:07:37 [warn] Started printing file 0:/gcodes/Shell 1 - new.gcode
power up + 03:07:47 [info] G10 S210 P0
power up + 03:07:58 [info] G10 S210 P0
power up + 05:13:01 [warn] Finished printing file 0:/gcodes/Shell 1 - new.gcode, print time was 2h 5m
power up + 05:13:02 [warn] Error: in file macro line 15 column 53: meta command: expected numeric or enumeration value after '+'
power up + 05:15:31 [warn] Started printing file 0:/gcodes/Shell 1 - new.gcode
power up + 05:15:41 [info] G10 S210 P0
power up + 05:15:52 [info] G10 S210 P0
power up + 06:38:24 [warn] HTTP client 192.168.0.100 login succeeded (session key 3399339837)
2024-11-03 15:35:27 [info] time check
2024-11-03 15:35:34 [info] time check
2024-11-03 15:35:50 [info] 2024-11-03T15:35:50

[dc42]

@mikeabuilder one for @chrishamm .

[chrishamm]

@mikeabuilder In SBC mode, the Pi should automatically update its datetime unless it was previously overridden. You can check out timedatectl further details about the clock setup on your Linux board. DSF 3.5.3 allows you to enable/disable NTP using M905 as well. In SBC mode, the Duet controller is automatically notified about datetime changes whenever they occur and it's set just before config.g is executed. By default, that automatic check should happen every 4 seconds.

On a side note, RepRapFirmware has never supported NTP, so the datetime is only set by the web interface when a client connects. If you were using standalone mode and faced this problem, you'd have two options I could think of:

1. Add a permanent 5V supply to your printer so the board processor remains powered, which then keeps track of the current datetime
2. If you have another device at home that can do HTTP requests, you could write a little script that auto-connects whenever the Duet goes online again. See rr_connect and the optional time request.

[mikeabuilder]

Thanks @chrishamm. Reading your response made me realize that I not only mistyped "SBC" but also that I was backwards about it. My system is NOT running in SBC mode, it's stand-alone. So thanks for answering that version of the question.

I'm restating your "never supported NPT" comment to see if I understand the implications for a machine running in stand-alone mode:

• The stand-along RRF will not "know" the time until a client connects. This means all log entries will have a timestamp based on the machine's uptime (time since boot).

• If/When a client connects, if that client is DWC, then DWC will set RRF's date-time.

• If a client other than DWC connects, and it connects using rr_connect with the time option, then RRF will update with the time from the client.

This explains a lot of unexplained macro errors I've observed over the past three years. And I can see now that I'll need to rewrite all the macros to not use state.time for measuring duration. I'll convert them all over to using state.upTime rather than state.time.

I think I'll also look into making an Rpi pico that powers up with my system and that does the rr_conenct function.