Communication error

Liptibilly

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?

Repetier

In server it will always select repetier protocol if you select the firmware to be repetier-firmware.

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.

Liptibilly

Hi,

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:

11:13:01.149 : Printer reset detected - initalizing
11:13:01.149 : start
11:13:01.165 : Transformation matrix: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000
11:13:01.292 : N1 M11034
11:13:01.527 : Free RAM:4640
11:13:01.529 : SelectExtruder:0
11:13:01.532 : FlowMultiply:100
11:14:41.309 : Communication timeout - reset send buffer block
11:14:41.309 : N2 M11536
11:16:21.323 : Communication timeout - reset send buffer block

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:

11:17:37.955 : Printer reset detected - initalizing
11:17:37.955 : start
11:17:37.969 : Transformation matrix: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000
11:17:38.135 : N1 M11034
11:17:38.333 : Free RAM:4640
11:17:38.335 : SelectExtruder:0
11:17:38.336 : FlowMultiply:100
11:17:38.338 : ok
11:17:38.338 : N2 M11536
11:17:38.343 : ok 2
11:17:38.357 : FIRMWARE_NAME:Repetier_0.92.9 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:2 REPETIER_PROTOCOL:3
11:17:38.361 : Printed filament:688.17m Printing time:6 days 3 hours 1 min
11:17:38.361 : PrinterMode:FFF
11:17:38.364 : ok 3
11:17:38.364 : N4 M11435
11:17:38.371 : ok 4
11:17:38.371 : N5 M111 S698
11:17:38.373 : X:0.00 Y:0.00 Z:0.000 E:0.0000
11:17:38.375 : ok 5
11:17:38.376 : DebugLevel:6
11:17:38.376 : N6 T060
11:17:38.378 : ok 6
11:17:38.378 : N7 M2022
11:17:38.381 : SelectExtruder:0
11:17:38.383 : FlowMultiply:100
11:17:38.383 : ok 7
11:17:38.384 : N8 M8019
11:17:38.386 : Unknown command:N7 M20
11:17:38.388 : ok 8
11:17:38.388 : N9 M220 S100104
11:17:38.392 : ok 9
11:17:38.393 : N10 M221 S10081
11:17:38.393 : SpeedMultiply:100
11:17:38.395 : ok 10
11:17:38.395 : N11 M111 S687
11:17:38.398 : FlowMultiply:100
11:17:38.400 : ok 11
11:17:38.400 : DebugLevel:6
11:17:38.401 : N12 T0*9
11:17:38.405 : ok 12
11:17:38.405 : SelectExtruder:0
11:17:38.408 : FlowMultiply:100

By the way, the firmware is set as repetier-firmware into repetier-server.

Repetier

No, the delay was short enough and can not be the problem.
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.

Liptibilly

Hi,

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:

Bus 001 Device 009: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light

The response of dmesg is:

[ 4585.360997] usb 1-5: new full-speed USB device number 10 using xhci_hcd
[ 4585.560635] usb 1-5: New USB device found, idVendor=10c4, idProduct=ea60
[ 4585.560644] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4585.560649] usb 1-5: Product: CP2102 USB to UART Bridge Controller
[ 4585.560653] usb 1-5: Manufacturer: Silicon Labs
[ 4585.560657] usb 1-5: SerialNumber: 0001
[ 4585.570942] cp210x 1-5:1.0: cp210x converter detected
[ 4585.573214] usb 1-5: cp210x converter now attached to ttyUSB1

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.

Repetier

One thing I want to add in server is more option for RTS/DTS handling. Currently server toggles these signals to reset printers. I'm not 100% sure but have the feeling that the handling on some new printers might be different so it might be needed to say do not touch or let it high/low all the time. Not that I like the idea as it makes it uncomfortable and hard to find a working solution if you never know what is working with which 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.

Liptibilly

In fact, I don't think the problem come from this, but more likely from the firmware, because it has worked (with the server and repetier-host in auto protocol detection) before with an old version of the firmware, but I've upgraded it because the auto-levelling have some trouble and to install out-of-filament switch.

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)

Liptibilly

Ok,
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.

Repetier

What firmware version are you using? Haven't changed gcode.cpp for quite a while, so should be the same if you use 1.0.0 or dev version.

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.

Liptibilly

I'm using the 0.92.9 version, since i've seen that it is the stable version.

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.

Repetier

1.0l.0 is now also declared stable which is why you see now such a difference between github. 1.0.0 is now in master branch.

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.

Liptibilly

Ok, I'll try with the 1.0.0. In the configurator webpage, when I click to v1.0.0, it says it is still dev. version.

Repetier

Thanks, have fixed the message. Just forgotten to delete it.