In 0.92 of luc-github (or my github fork), I have not had any issues like this.

But in repetier I have Ping-Pong communication enabled and receive cache size set to 202.

This was with an earlier .91 build and Luc has already addressed the issue for me as there was a confirmed typo in that build. I am not going to bother to switch to .92 as I am about to swap out the board to a Ramps 1.4 and run Marlin on it. The Azteeg X5 mini I was going to use has now been allocated to the Kossel/Delta I am building.

But in repetier I have Ping-Pong communication enabled and receive cache size set to 202.

It very well could be your computer... I have had very similar issues when I was attempting to run RH on an old laptop that I had. I run it on my gaming machine and I have yep to have the issue again. I am on .91, the bin file specifically

I used the BIN at first and did not see this issue. It was not till I switched to the package that you have to compile in Adruino and then upload that I found this issue. As you can see Luc addressed what it might be. I think I will update .92 at least until I can get my carriage finished and get my alternate controller installed.

for 0.91, binaries : github.com/luc-github/Repetier-Firmware/wiki, for 1.0 and 2.0
if you use sources (github.com/luc-github/Repetier-Firmware) it is better to patch the arduino files to avoid the usb connection lost especially when using window, also be noted variants.cpp file is different than bgm one
This one is in RC (December) and it is final one actually - no more update planned

for 0.92, sources only for now : github.com/luc-github/Repetier-Firmware-0.92 for 1.0, 2.0 and 1.0A
but has watchdog support and 1.0A support, also need to patch arduino files for usb issue and variants.cpp file is different than 0.91
This one is the active one

If you do not know where your sources come from, I guess you took from bgm repository : github.com/bgm370/Repetier-Firmware/tree/davinci/src/ArduinoDUE/Repetier, it is very old and not maintained anymore
It contains an error for the "wait" identifier in configuration.h
it is typo issue W is upper case when it should be lower case
#define WAITING_IDENTIFIER "wait"
I think this is the root cause of what you observed

Thanks I'll check that out and see if it the case. Where can I find the most recent release of Rep firmware?

Hi, may I know which 0.91 sources your are refering to ?
Have several repositories

Thanks,

Not sure, I got it off what was said to be the official github and the latest at the time. The version according to the changelog file inside the folder is 0.91.7 with the date of 15-03-2014.  If it also helps my current Rep Host is version 1.0.6.

Thanks,

If you are running Repetier Firmware and host I would not advise running live over USB unless the newest version has fixed the issue I found. With the last version which was not in BIN form, I found there is a problem with the communication protocols. The software/host will send the gcode data real time to the printer. The printer is supposed to send back commands to the software to not send anymore data as my buffer is full and to wait for me to request more. It however doe not do this. Instead the software just keeps streaming the data to the printer filling the buffer with some code which is first in first out until it is done. But being limited to 32K it cannot hold that much, only a few layers of medium sized object. Then the printer will continue to print until what ever was loaded into the buffer at first is used up. It will then stop leaving the head at that position with heaters on. You can test this or at least I could by changing the port speed. At higher speeds the issue would happen sooner. At lower speeds it would happen later.

What would happen is once the buffer is empty the end gcode is never sent since it was never loaded into the buffer but instead was streamed into oblivion. The head will stop with the heater on and the bed heater on and the head will just sit there melting a hole into the spot it stopped at.

Another issue I had when trying to print real time over USB is that the same comm issue would make the host lock up. Since the temp is monitored and controlled by the host during live prints, this is a serious issue. If it locks up it no longer monitors the temp and so no longer adjust it. Both the bed and hot end will go into thermal runaway and reach whatever temp is possible until you smell ABS that is way too hot like I did or something starts burning. This also made the bed hot enough that the nuts on the adjusting screws inside the bed rounded out their holes and I had to glue them in so I could adjust my bed.

So please if you run Rep Firmware and host and try to print live over USB do not leave the printer alone. Also with this combination I have not been able to transfer files to the card.

I put my card inside the print area using an extension cable. I just remove it, put in my laptops card reader and put the files on it then put back in the printer. Restart the printer and print from the LCD. This was my work around for this issue. When I print from the card using the LCD I never have any issues with crashing, stalling, locking up, and so on.