Report line number in error messages

[T3P3]

May already happen in 3.5 for this type of message.

https://forum.duet3d.com/topic/29335/how-to-find-which-line-throws-an-error

[T3P3]

requires a test to see if a job file with an error in it reports the line number of the error in RRF3.5beta4

[AndyEveritt]

Tested to see if line number in error messages for following messages in 3.5b4 standalone:

Error: G0/G1: target position outside machine limits

Error: G0: G0/G1: insufficient axes homed

No line numbers present for either error. Issue not fixed in 3.5b4

[AndyEveritt]

Using the latest commit it reports the command but not the line or column number

Setting the inFile bool in GcodeException.cpp to always be true adds the line number correctly which makes be suspect the issue is with the gb->IsDoingFile() function

const bool inFile = gb != nullptr && gb->IsDoingFile();

[dc42]

Thanks Andy, I'll take a look.

On Fri, 4 Aug 2023 at 08:56, Andy Everitt @.***> wrote:

Using the latest commit it reports the command but not the line or column number [image: image] https://user-images.githubusercontent.com/38423143/258357141-a7d89df7-499d-4806-8fdf-f1a5937ac5ed.png

Setting the inFile bool in GcodeException.cpp to always be true adds the line number correctly which makes be suspect the issue is with the gb->IsDoingFile() function

const bool inFile = gb != nullptr && gb->IsDoingFile();

[image: image] https://user-images.githubusercontent.com/38423143/258358504-5f0a5866-b1ab-4079-82ac-a84f1143ea32.png

— Reply to this email directly, view it on GitHub https://github.com/Duet3D/RepRapFirmware/issues/800#issuecomment-1665177324, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUYI3GILHKZOGE4OATKR3TXTSTJTANCNFSM6AAAAAA3BPP3V4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- David Crocker, Duet3D Ltd.

[dc42]

Andy, did you test in standalone or SBC mode?

[AndyEveritt]

Standalone on a Duet 3 Mini

[dc42]

I think the reason is that at GCodes2.cpp there is a try...catch block in the G0/G1 processing, which causes the job to be aborted. Eventually the exception gets retrieved in GCodeMachineState::RetrieveStateMachineResult but by then the file has been closed.

[dc42]

Fixed my merging AndyEveritt's changes into 3.5-dev.