Printer off, RepetierServer remains "connected to the printer"

ARCH_T

Hi. I found that when I turn off the printer, the Repetier Server continues as if it were "connected to the printer". As you can see in the images I send. I would appreciate that you could solve this problem. Thank you

Repetier

The prusa port never vanishes. You can enable the flag "Port is visible even if firmware is not running". That will at least prevent you seeing all the connection tries. Not 100% sure if it then gets handles as offline.

Also worth a try is taping the 5v line of usb connector as describe here: https://www.repetier-server.com/knowledgebase/undervoltage-and-throtteling-of-pi/

That should make it offline in any case. Only question is if the chip then gets powered over the prusa once prusa has power on. Never tried that solution on it.

ARCH_T

In other versions of RepetierServer it always worked correctly. I don't know why it doesn't work equally well on this one. It should. 

ARCH_T

The printer is the same (MK3s with MMU2s) , only the Repetier version has changed. The printer only disconnects making an emergency stop or removing the cable. In version 0.93 it worked perfectly.

Repetier

Will test this myself today a bit more. You might need to disable "Continue print after fast reconnect". My current guess is that this feature does not play well with the prusa problem that the port stays visible when power is off. That way server can not say if it is disabled or just in the usb reconnect mode.

ARCH_T

No, unfortunately it doesn't work that way (disabling "Continue print after fast reconnect")  
This does not seem to be the cause of the problem

Repetier

Funny fact - if I hit reset a second time it connects correctly. Searching that issue. Already found the not disconnect problem. So that is the last special prusa problem.
On the other side I also want to test the tape method for 5v since it is annoying for the server to see the printer also it does not work. That causes constant tests that would not be necessary otherwise.

ARCH_T

Thanks. As soon as you have a solution to this problem, I would ask you to tell me how to solve it. Or If there is a new beta version that fixes it. Thank you!

ARCH_T

Another thing I noticed is that sometimes the symbol of thunder appears, but there was no Undervoltage. It's normal? Because if I refresh the page, the thunder symbol disappears.

Another question: In the previous version of RepetierServer, only one ethernet network appeared to me. In this new version appears 4, is it normal? 
I send images to try to explain. Thank you

Repetier

The data in flash menu is updated once per minute, so it appears after max. 60 seconds of a reload. So that is normal. White arrow means no power problems. If it gets orange or red you have power problems. As it also contains other os info it will always show up.

Reason you get more network components is that ipv6 is now also enabled. If one of them is reachable depends on your router and os running browser which also need them enabled. But normally you will stick to ipv4 as that is much easier to remember and shorter.

Disable detection now works in beta, just reset requires me to hit it twice. So continue to search why this is the case.

ARCH_T

Ok, Thanks for your explanation

ARCH_T

I see that the new version (0.94.1) came out but this problem has not been completely resolved. After turning off the printer, the Repetier Server takes about 40 seconds to detect that the printer has been turned off. It's normal? In the previous version it was an immediate action.

Repetier

The solution is correct and mainly depends on timeout. The problem is that the port does not disappear if you disable power. The usb chip gets fed via usb. So first we assume a communication problem and only if we see no advance and the flag for always visible port is on we decide that it must be disconnected. So that is why there is a delay.

Regarding the reset I tested a whole day and see no solution. When reset fails what happens is that we don't receive anything. On next reset we receive all the start code and it succeeds. Don't even know why we should be able to block the firmware start up. Don't know marlin good enough for this but in repetier-firmware there is nothing host side that can stop the restart from being finished. None the less I have seen it happens. Seems like sending gcode due to timeout/running communication can cause this. When it is blocked and I hit pause on debugger the reset continues. Will keep an eye on this any maybe I get an idea how to solve it better.