[BUG] Repetier Host conflict with auto0.g

[theofficialgman]

Description

After enabling the autostart feature on my printer, when trying to connect to the printer view repetier-host, the printer fails to run the autostart and will not respond to any input whether that be the lcd or the repetier-host software until reset. Removing the sd card upon boot and connecting the printer to repetier-host without the autostart program works and the auto.gco can be run after the initial connection to the software is made. This is on the bugfix-1.1.x

Steps to Reproduce

1. Create any auto.gco file and place on the sd card
2. Attempt to connect the printer via usb to repetier-host
3. observe that the printer stops responding

Expected behavior: printer starts up and connects to repetier-host while performing the auto.gco

Actual behavior: the printer freezes and will not respond to any input

config and configadv.zip

[thinkyhead]

Has this now been solved in bugfix-2.0.x?

[theofficialgman]

Not sure. Running V1.1.9 commit f6ef58f right now. I'll have to check later

[boelle]

@theofficialgman did you check?

[theofficialgman]

Just checked. The problem is still there. Sorry for the unreasonably long reply time. I'm updated to the newest version now which took me a while.

[theofficialgman]

Interestingly enough. On bugfix-2.0.x I can navigate the menu on the printer lcd now as opposed to on V1.1.9 where even the lcd would freeze but I can't print anything and repetier host is unable to send or receive any commands.

[theofficialgman]

So enabling ping-pong connection is a workaround in repetier host but apparently that basically removes any cache of commands. It seems to me like the firmware is sending a ready signal right before loading the auto0.g and then repetier host wants to send its own commands which it ends up sending during or immediately before the auto0.g gets executed.

[thinkyhead]

It would be best if hosts didn’t send g-code on connect, but wait for the firmware to actually print out “ready.” If we are printing “ready” and then executing auto0.g that will have to be fixed. It means checking the “auto files not done” flag and only printing “ready” after the flag is cleared. I will add this to the TODO list.

[boelle]

@repetier can you maybe look at this?

[repetier]

The plain truth is that there is no generally visible clue when a host can send it's connection script. What we do is wait for "start" and if it doe snot come within a delay we send it anyway assuming printer does not reset on connect. This first script is essential for host. RH for example need it to see if communication behaviour is marlin like or repetier-like, as they are different.

I also think it is not a host problem at all. If firmware accept incoming communication it should also be able to handle it. If you are not ready let firmware buffer incoming data in serial in buffer but do not start parsing it until it is save. So if you must finish auto0.g first run it while blocking in and send a busy: response until auto script is finished and then start parsing serial in data. Haven't tested if busy on startup works but that is a way that hosts could handle it.

Also normal connect commands are more querying M115, setting multipliers, ... no moves. But you never know what users add to the connect script.

[InsanityAutomation]

Maybe executing auto.g needs to set busy state till done, then host may not see start but will see busy and will hold the command in the queue instead of sending right away.

[repetier]

"start" must be the first string and is for all firmwares. I would not change that. But it should be ok to block input and set busy afterwards till it is executed.

[InsanityAutomation]

"start" must be the first string and is for all firmwares. I would not change that. But it should be ok to block input and set busy afterwards till it is executed.

Exactly what I was thinking! I'll add poking around this to my task list and see when I get to it.

[boelle]

@theofficialgman problem solved?

[theofficialgman]

As of today the problem still exists and has not changed since my last post Feb 23. I just updated to the most recent commit as of writing 35b1149

[boelle]

any idea what commit that broke it?

[theofficialgman]

I originally tried using the auto0.g back in July of last year, when I made the first post in this thread (bugfix-1.1.x commit f6ef58f) . I hadn't used it before then so I can't say if it has ever worked properly. All I can say is that all of bugfix-2.0.x up to commit 35b1149 seems to have the problem. Repetier host initiates the connection which causes marlin to restart and upon restart the auto0.g never runs and Repetier Host is not able to send commands.

Though, I did find your @boelle recent posting on another issue about the "new" startup script which was implemented seemingly sometime between now and this past February. So far, this startup script option in configuration_adv.h runs my one gcode line fine without interfering with repetier host.

[boelle]

will close this one as "fixed"

So far, this startup script option in configuration_adv.h runs my one gcode line fine without interfering with repetier host.

we can always reopen

[github-actions]

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.