I get the same error when the gcode is sent via usb cable via the makerbot desktop without raspberry pi, it stops at 32%. What could be the problem?
Makerbot Replicator 2 noHDB 'Serial communication error' and Error: Timeout: and Input/output error'
Either there is a flaw in the gcode or the printer firmware
I don't think the problem is with gcode. If I downgrade the firmware, will it fix?
According to my research, could there be a problem with the baud rate of the makerbot replicator 2? (115200)
So from SD card in the printer it runs well?
I like to exclude the baudrate error.
Before you downgrade the firmware, you may consult the Makerbot forums.
yes it works when I check it from its interface interface, but since my interface card is broken, I want to check it with raspberry instead of buying a new one, so I encountered such errors.
Maybe if I enable octo printed sd it can be fixed, do you know how to activate it?
You probably don't want to do that as OctoPrint's Upload to SD is very slow as it uses the serial connection established through the USB port. If you are having problems with the serial connection, then it will probably fail uploading to SD from OctoPrint just like it fails printing from OctoPrint.
1 Like
I just looked at your serial.log and this looks like a plain old communications error. These are usually caused by a bad or improperly shielded USB cable, Electro Magnetic Interference (EMI), and/or grounding problems.
You say you have ferrite cores on your USB cable. Can you check with an ohm meter that the outside metal part of both ends of the cable are connected together (i.e. is this a shielded cable)? How long is the USB cable? How much shorter could it be (i.e. what is the shortest cable that would work)? Try moving the RPi to the opposite side of the printer (and does this require a longer or shorter cable)?
Mr morgan thank you for your suggestions and advice.
My ferrite core cable is 1.5 meters in length with a shielded cable, should it be shorter?
And why does it stop printing at only 32% even if it's from this cable?
I didn't understand your sentence "Try moving the RPi to the opposite side of the printer".
So you appear to have a good USB cable. In most cases, shorter is better but 1.5 meters isn't "too long", IMO. When I connect my LulzBot TAZ to my desktop, I use a 10 meter "active" extension cable. The RPi is connected with the USB cable that came with the printer (1.5-2 meters). My RPi is on the opposite side of the printer's electronics.
Is the failure at 32% in multiple attempts at the same gcode file, or does any gcode file regardless of length always fail at 32% of its length? There are line numbers generated by OctoPrint as it sends the gcode to the printer. Examine the serial.log file for multiple failures and see if it is always the same line number that failed.
If it is multiple attempts of the same file always failing at (approximately) the same spot, then perhaps this is EMI with the printer's moving parts shielding (or creating) the EMI when they reach a certain position.
One of the techniques for solving EMI issues is to move things around. Move two objects that are interfering farther apart or putting something in between can change the symptoms. If your RPi is to the left of your printer, move it to the right of your printer. This will either make things worse, make things better, or will have no effect. Worse or better are actually both good outcomes because now we know for sure it is EMI and can proceed to find a solution.
Yes, regardless of the length, I always get an error at 32%. I tried RP in all directions, always the same error. It stops at 32%.
I don't understand what is EMI?
As I said above:
or if you prefer a longer explaination, https://en.wikipedia.org/wiki/Electromagnetic_interference
mr morgan,
I tried the printer in the living room in the kitchen, on the wireless and wired broadcast on the right and left of the printer 
Could it be from you baud rate?
OctoPrint communicates with the printer only over USB. OctoPi's (or the printer's) network connection shouldn't matter.
I don't believe you can change the baud rate on the printer. If you can, trying a different rate may give us some additional information.
You didn't answer the 32% question... Always the same file at the same spot?
Have you tried other (shorter) gcode files?
Always 32% error in the same file and different files (even if it is shorter and longer)
Sorry, but I'm stumped. Maybe someone else has a better answer than "gremlins".
Can you share a shorter gcode file?
Still curious about this. So it may be a firmware issue. Have yo asked at a Makerbot forum already?
Also found negative layernumbers in the gcode files. They start with -7:
;LAYER_COUNT:12
;LAYER:-7
Those are as remarks, but plugins analyze this data. Maybe they cause issues.
Yes, I asked many times, they couldn't find any problems, I am confused too Why is it not solved? I guess they will buy me 400 $ interface card.
A negative layer count in some slicers means its part of a raft.
1 Like