Feature request: Better information for error codes

ericlmccormick

As a follow-up I get the following error "M98 P"0:/macros/Filament Change"
Warning: Obsolete use of S parameter on G1 command. Use H parameter instead."

This is the GCode for that macro, but I don't use the S or H on the G1 commands.
M104 S230 ; set extruder temp
G28 ; Home Bed
G1 X80 Y80 Z50 ;Move to Center
M109 S230 ; wait for extruder temp
G1 E10 F500
G1 E-100 F6000
G92 E0
M291 P"New Filament Loaded?" S2
G1 E150
G92 E0
G1 E-0.5 F500 ; Retract a little
M104 S0 ; turn off temperature
M84 ; disable motors

jay_s_uk

@ericlmccormick its probably coming from the G28 i.e. from your homing files

ericlmccormick

@jay_s_uk I don't have S in any of the G1 line of my homing files. I don't specifically call out H0 because H0 is supposed to be the default, but do I need H0 in each of the G1 lines?

jay_s_uk

@ericlmccormick can you post your homing files and we can take a look (include homeall.g as well as individual axis homing files)

fcwilt

@ericlmccormick

I agree.

It's sometimes quite hard to determine what file contains the error.

The expanded features, like conditional code and variables, have resulted in a increased number of files on my printers, with one file calling another which may, in turn, call another.

Having the filename appear in the error message would be a great help.

Frederick

dc42

@fcwilt reporting the filename will require additional memory to be allocated, so we may add it to Duet 3 firmware in future but probably not to Duet 2 firmware. We already report the line number and often the column number in the error message.

fcwilt

@dc42

Thank you for the reply.

I switched over to v3 hardware a while back. I only have two printers with v2 hardware. They will be upgraded as funds allow.

I am fairly certain that when you consider one .G file invoking several others and they in turn may invoke others, that knowing the line/column numbers still leaves are certain amount of "detective" work to figure what file generated the error.

Looking forward to the future.

Frederick

dc42

@fcwilt yes I am aware that when using nested macros, it can be tricky to determine which one provoked an error message. The use of nested macros also increases the amount of memory we will need to store the filenames, because we will need to store the full paths of all the macros in the call stack.

fcwilt

@dc42 said in Feature request: Better information for error codes:

The use of nested macros also increases the amount of memory we will need to store the filenames, because we will need to store the full paths of all the macros in the call stack.

Understood.

But even knowing the name of the file where the error occurred, regardless of the chain of calls, would be of great help.

Most of my errors are typos or syntax errors - few are of the "what the heck is going on" type.

Thanks.

Frederick

Chriss

@dc42 The filename would be already very helpful.

https://forum.duet3d.com/post/332495

I would not expect that there are tons of duplicate file names in real live. And it would be acceptable to go trough 5 files. But going trough more than 50 is a nightmare. And I had the problem that RRF was complaining about spaces and widespaces in one line. There is almost no way to grep for that. A "debug mode" maybe? You can free up some memory by dropping a lot of things, I guess that 90% of the problems appear before the actual g-code gets executed. So why not simulating the entire process with more debug info?

Or just store the filename in a variable and print it out with the error message. Just something which gives us a better hind. I add M118s to every file at the moment to trace down the location of the "typo".

Cheers, Chriss