A way to test memory requirement?

[thinkyhead]

I noticed a post on Twitter complaining that the latest Marlin wouldn't fit on a 1280 board, but I don't know how accurate that is. So I'd like to be able to find out how much total Flash Memory and working RAM is required for a given build configuration. The Arduino software helpfully tells us how big the binary is, but as far as I know there's no code in the firmware to report usage (or free RAM) during a typical print process. Is this something that can be easily implemented, perhaps as part of the status GCode M27?

[hg42]

Just some ideas...

I also wondered recently, if Marlin can or could detect a memory overflow at runtime or even compile time.

I noticed, when I increase the buffer on a delta printer (just to try how this behaves), Marlin doesn't answer when connecting. So it seems to get an overflow.

I also get unresponsiveness somewhere in the middle of a print, when printing certain objects. I mainly print OpenSCAD models via Cura, so the conditions should be similar. Cura gets an error from Marlin (looking like a communication error) and recently Cura stopped after that, but latest Cura commits allow to continue in most error cases (repeating the command), but Marlin doesn't answer any more. Even reconnecting doesn't work. Marlin's behaviour in this situation is like connectiong with a too big buffer.

That's why I jumped in here.

My problem seems to depend on the object and the speed, and the position of the break seems to be equal or at least very similar for two runs (that is in the same layer, but I tried only a few times). Smaller objects print without a break. May be it's a complexity vs. time problem.

That's all not very well tested, so conclusions are speculative, but it looks like other influences (Hardware, Temperature) can be excluded.

Back to detecting memory requirements: From what I already saw in the code, I would assume the memory usage is mostly constant. E.g. the planning buffer is constant. I also didn't see recursive invocations of functions.

If the memory usage can be seen as constant (or say limited) then it could be checkable at compile time or may be at runtime, e.g. by comparing the memory address of the highest variable to a local variable plus some safety area (could be a check_memory function, which can be invoked at certain locations in the code).

At least one problem remains: which is the "highest" variable (the one nearest to the top (=lowest address) of the stack)? This should be compiler dependent (sequence of linked objects, different kinds of objects could be stored in different areas, etc.). But I think, gcc should be standard for Marlin?

With a given compiler, it could even be possible to use compiler defined values at compile time (err, but I think these values should not be known before end of the link phase...). At least we may be able to determine where to put the "highest" variable.

Last time I wrote a firmware for a microprocessor I didn't link the source files, but I used a main.cpp file, which #included all the parts. This way you have full control over the sequence of the source files and a memory test function could be implemented in there and also main() could reside here, delegating to another internal main function and invoking the memory check.

[thinkyhead]

Not sure how important this is, but qr_solve.cpp includes calls to malloc, apparently the only source that does.

As for your print failures, indeed Cura does have some tricks that help, and daid has suggested some hackish things for Marlin that you could try, but they won't be getting committed, as I understand it. Personally, I've had so many issues with communication breaking and killing a print that I just stopped using USB and only use SD printing now.

[hg42]

thanks for mentioning malloc, I didn't expect to see malloc in such a firmware, so I didn't search for it. Apart from that, I only had a quick look on the code, no time to investigate deeper.

USB failures: Usually, I can print the same complete object as a gcode file via Printrun, so Cura should do something differently.

I always wonder how Marlin can get something wrong when all lines are checked by crc and therefore every line that gets executed should be correct, right? Otherwise Cura should get an error an repeat the line. The log on Cura's side shows correct lines, but Marlin answers with an error. So I am currently looking for problems on Marlins side which could lead to such behavior.

Apart from a stop, I sometimes seem to get wrong values printed, e.g. my printer runs out of the print area in x-direction or suddenly retracts the filament until it jumps out of the bowden extruder on the top of the printer.

According to the straight x-move, I assume that the x value in a move gets modified. A delta printer moves in x-direction by moving all steppers together, so this cannot be caused by a modification in the planning buffer or something like that. It has to be the source value (kind of G(0|1) X).

If the value would be modified by the USB transfer it is unlikely that the crc check doesn't detect that. But memory overflows could indeed change a number on the stack after the check, so I'm looking in this direction now.

Also, I sometimes get an error message from Marlin logged in Cura with a modified character in one of the words, like "che*ksum error", which may also be caused by a memory conflict in Marlin. Note, in this case it could also be a transfer failure, because there are no crc checks in this direction.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.