Makerbot Replicator 2 noHDB 'Serial communication error' and Error: Timeout: and Input/output error'

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 :slight_smile:
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?

starwars.gcode (1.0 MB) wars.gcode (214.1 KB)

2 different gcode I used

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 :slight_smile: 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

Thanks for that info :+1:

Thank you very much for your help. I wish I could reach the solution.

Is your slicer Ultimaker Cura 4.6.0? If so, I configured my Ultimaker Cura 4.8.0 with a Makerbot Replicator, changed the Build Plate Adhesion to Brim and sliced Test_Cube.stl (684 Bytes) into M_Test_Cube.gcode (38.3 KB).

This model (resliced for my printer) prints (including nozzle and bed heating plus calibration) in about 7 minutes on my LulzBot TAZ 6 through OctoPrint 1.5.0rc1 on OctoPi 18.0rc1 running on an RPi 3B.

Please slice it on your system (remember to change Build Plate Adhesion to a Brim), upload the gcode, delete your existing serial.log (but leave it enabled), and then print it on your printer. When it fails at 32%, upload the serial.log file.

I'm trying now

mr morgan

this time he stopped in different places

serial log 2 simplify program sliced ​​stopped at 33%

seriallog3 sliced ​​in ultimaker 4.6, stopped at 35%, previously stopped at 27% in another file

Do you think it is in the slicer? or is it from the GPX plugin ?

serial (2).log (121.4 KB)
serial (3).log (234.5 KB)

I looked at your logs and I still believe it is just a bad serial (over USB) connection. It is not the slicer, it is (probably) not the GPX plugin. There is just too much interference (noise) causing the serial communications to fail.

I (and others) have given you all the tricks we know to improve the reliability of the serial communications and it appears that none of them has worked. I'm afraid you are stuck with writing gcode files on an SD card and plugging that into your printer.

Sorry, I tried 3 usb cables, finally I will order 1 more ferrite core cable

Finally happened.
I put back the interface board of the printer, then put the shielding metal covering the motherboard, it successfully completed the test cube you gave.
Thank you very much for your help in finding the real problem.

Thank you very much for your help in finding the real problem.

1 Like