Communication error
Hi,
I've upgraded my Zonestar P802CR2 with repetier-firmware.
I've set all the pin and setting according to my printer and it print.
However, in order to make the printer communicate with repetier host, i have to set the transfer protocol to repetier-protocol. If I let it to "auto" or "ASCII", when the board is reset, the screen is blocked to the welcome screen, and the printer isn't responsive anymore.
The big problem is to use it with repetier-server. In this case, I can't force the communication protocol to repetier-protocol, and the printer never quit the welcome screen.
Why does the firmware act like that and how can I fix it?
I've upgraded my Zonestar P802CR2 with repetier-firmware.
I've set all the pin and setting according to my printer and it print.
However, in order to make the printer communicate with repetier host, i have to set the transfer protocol to repetier-protocol. If I let it to "auto" or "ASCII", when the board is reset, the screen is blocked to the welcome screen, and the printer isn't responsive anymore.
The big problem is to use it with repetier-server. In this case, I can't force the communication protocol to repetier-protocol, and the printer never quit the welcome screen.
Why does the firmware act like that and how can I fix it?
Comments
When you compile firmware you also say how long it should show start screen and not start communication. I think in your case that time is too long so server thinks it failed and retries. Solution is then to reduce the time it shows info screen (UI_START_SCREEN_DELAY). Just a guess but happened before.
I've tried to reduce this value (which was not very high, about 1000) to 100, and it doesn't change anything.
Here are the logs from repetier-host:
with all debug informations activated. It seems that it never send the "ok".
However, when I change the communication protocol from Autodetect to Repetier-Protocol, it works:
By the way, the firmware is set as repetier-firmware into repetier-server.
Also ascii communication with repetier-firmware should be no problem. That is the first thing I do not understand. Just looks like we get no response at all after firmware has send "start" and some other startup messages.
Are you running server also on windows or on linux?
Can you say what serial driver is used and which baud rate? Just found out that e.g. prolific driver on linux does not support 250000 baud, so just want to remove a simple com error problem.
Also note that no other software is connected to the printer if you try with the server, or it will also fail.
Both are running under linux (fedora for laptop and raspbian for server). baud rate is set to 115200. I also try to 256000 but nothing change.
The usb to serial chip is:
The response of dmesg is: I've checked and yes, the server is the only one who use the serial port. Actually, my raspberry is used only for this printer.
Might have to do with it or not. But since these can control how reset works it might be that server sets them on a value that always resets. Original the value did not matter and only the change caused a reset. Maybe this is not the case any more.
You could try with a serial terminal software that can toggle these lines and see how changing them causes the printer to behave. Not sure but I think coolterm can do this.
I think the key point is that it work well with repetier host when I set protocol to repetier-protocol, and it doesn't work anymore if i switch to automatic protocol detection, even without the server.
Maybe this can help, I attach the sourcecode I use (I downloaded it yesterday and make some modification to settings/pin according to my printer)
It seems that the function GCode::parseAscii never return. I don't know why but it stay blocked at the end of the function. However, if I put some check message, to know where is the code execution, it works well with Ascii and from the server.
Com::printFLN(PSTR("AfterLoop")); if(hasFormatError() || (params & 518) == 0) // Must contain G, M or T command and parameter need to have variables! { Com::printFLN(PSTR("Error Threatment")); formatErrors++; if(Printer::debugErrors()) { Com::printFLN(PSTR("PrinterError")); Com::printErrorFLN(Com::tFormatError); } if(formatErrors < 3) { Com::printFLN(PSTR("FormatError")); return false; } } else { Com::printFLN(PSTR("NoError")); formatErrors = 0; } Com::printFLN(PSTR("BeforeReturn")); return true;By the way, I get the sourcecode by the configuration webpage, and it seems that it is not the last version of the code (in the sourcecode in gitHub, the "(params & 518) == 0" is commented.
The function will always return if you reach AfterLoop - there is no loop that can block it.
Maybe you have not enough free ram? Especially if you have a delta you can lack free ram and that can cause different crashes at random places depending on timing. Make sure you have at least 900 byte free ram reported when compiling firmware.
I don't understand why it work right now, because I just added some tracking messages, not modified the interresting code...
I've got 4625 bytes of free memory, but maybe there is a problem with the microcontroller.
Your testing may be misleading if firmware hangs. If you need to be sure a line was passed you need to add a delay afterwards the print command
HAL::delayMilliseconds(20);
to make sure it gets send before firmware hangs somewhere and blocks everything. The free ram shoul din any case be enough here.