Filament Runout: Filament change is triggered even if not printing (printers blocked)

TheThomasD

Hi,

I‘m using the Pro version 1.4.9. I have multiple printers connected, many of them with filament sensors configured. After an update from 1.4.6 (? maybe earlier, but definitely 1.4.x) the printers behave incorrectly. After startup, if there is no filament, the filament change is immediately triggered. While the nozzle heats up, no communication with the printer is possible. If I start up the printers without the usb connection, all is fine.

If I disable the filament sensor (M412 S0), the connection works. However, it seems that the behavior of Repetier Server has changed with one of the latest changes. I have been working with my setup for quite some time with different Marlin versions, but this didn’t happen before.

This behavior can be observed independently of whether M412 H is set to 0 or 1, also with Marlin versions 2.0.9.x and 2.1.x.

Can you please check what the issue is? Do you have an idea? I really like the host action to change the filament, but it should be only triggered when printing, not always.

Thanks! Thomas

TheThomasD

Update: old version was 1.4.4

Repetier

It is always changing to filament change when the message gets send, that hasn't changed. So my guess is that marlin is triggering this. Can you check in installdir/firmware.marlin.xml you have the startup code:

<connectionCommands>M110 N1
 M105
 M115 ; Get firmware capabilities and info
 M220 S100 ; Speed multiplier 100%
 M221 S100 ; Flow multiplier 100%
 G92 E0
 G90
 M82
 G21 ; Use mm as unit
 M114
 @echo Some printers don't implement timing, but can cause unexpected execution based on file name.
 @echo By triggering unknown command here we block it for real usage.
 @echo So please ignore unknown command if it appears now.
 M75
 M77
 @getIP
</connectionCommands>

My guess would be the M75/M77 is triggering this, also it just tells that marlin should start measuring print time.
Problem is we need these commands since some versions can not cope with M75 with filename so we need to test if it is supported on startup. So question is if this has the sideeffect you describe. Comment the 2 lines with semicolon and restart server and see if it still triggers this. Maybe I could add a delay on startup to ignore it directly at connect.

TheThomasD

Hi,

yes, commenting out those two lines did the trick. Can you explain why the test is needed? I would expect that most (all?) Marlin versions with a runout sensor will behave this way. Does it make sense to have a config where you can chooses whether this test is executed for Marlin-based printers? Or maybe let the user just „confirm“ whether the option is there or not. Or which type of M75 he wants to use.

One more reason why I think running the print timer in Marlin just as a test is not such a good idea: some procedures are coupled to the print timer, e.g. print statistics. They collect information on how many prints were made with the printer. „Running“ a print on every connection would basically make this information useless. For me, the print statistics are not relevant, but making Marlin think that a print is started „just for testing something“ seems to be not such a good idea to me. Please consider removing the check and introducing a configuration item for Marlin-based printers instead.

Thanks! Thomas

TheThomasD

Additional info: according to the latest Marlin source, the print statistics can also effect service intervals (if that feature is enabled in the printer) as they depend on the print statistics.

Repetier

The problem I try to solve is that there are a few hundred different marlin firmware versions. Same have no M75, some read filename and treat them as command causing ramdom errors, some know it just without filename and some use it with filenames. Of course other supported firmwares have other commands/solution/behaviour or it would get easy to handle all. And of course I could make for each firmware a dozen questions, but I can not expect users to know the answers. Some might but others are happy to just know the firmware name.

So this is a dilemma and I think I need to remove sending filenames on M75 like before. It has already caused so much troubles it is not worth knowing the file you print on printers with support. They can add a replacement if they like then. In that case I can also omit the test.

Thanks for testing and extra info with statistics. Never saw it on my printers.

TheThomasD

Thank you, I‘ll use the fix you suggested for now. Thank you for creating and maintaining such a great software!