Job file position reported by RRF is occasionally not valid

[T3P3]

Possibly related to: #794

Potentially only happens when two input channels are running at the same time, for example daemon.g

[T3P3]

May be the cause of: #899

[chrishamm]

https://forum.duet3d.com/topic/33399/daemon-g-logging-incorrect-file-position/6?_=1693409692066 may be related

[dc42]

When I run a job comprising a single G28 command followed by many G2 S1 commands, with daemon.g echoing job.filePosition every 800ms, usually see 1 or 2 instances of file position 4294967291 near the start, I presume while homedelta.g is running. I don't see any bad file positions after that.

If I put a M291 command requiring a user response in the file, then while the response is awaited the file position reported is zero.

I tried having the job use M98 to call a macro that delays 10 seconds, but the file position was reported correctly while that was executing.

So it appears to me that this issue is associated with running homing macros (and perhaps other system macros, but not user macros) and with using M291.

If I pause the job, the file position is reported correctly while the job is paused.

If I add a G4 delay command and an echo message to the end of the homing file, the file position is reported correctly until the echo message has been output, then I get a single bad position after that. So it appears that the bad position is associated with a system macro file ending.

[chrishamm]

Fixed by 5ea064e. Needs to be merged into v3.5 and backported to v3.4, [dc42 - now merged and back ported.]

[dc42]

I created a new issue #902 for the case of M291 being executed.