Hi all,
I have a batch 1 gen6 board that always produces serial errors, and after fumbling around for a month or so without luck I am thinking about the possibilty of a hardware problem.

Symptoms: While firmware uploading and running manual commands work fine, running GCode files in e.g. repsnapper produces serial errors after a few seconds. The actual error changes with firmware and software used, it's always along the lines of "Error: No Line Number with checksum, Last Line:13" or "checksum mismatch". With DEBUG_ECHO activated one can observe that sometimes apparently the last few bytes (including line end) get lost, so the firmware sees 2 GCode lines as one. Sometimes the problem already occurs when homing Z.

Things I tried so far:

• On the host end (linux):
  
  • different kernels, computers, usb cables
  • repsnapper and reprap host (and repg I think)
• On the mendel:
  
  • Mendel parts firmware stock and 20110107
  • reprap firmware from august 2010
  • Tonokip firmware from this forum
  • Sprinter firmware

So far, the results did not change much. I'm out of ideas. Do you have some? Is there some kind of debugging firmware to test the different pins? Something else I can test?

Have you looked to your electronic noise environment?... (make sure your USB doesn't run along your heater or motor cables)

Also is your power supply adequate to the job? (you could check this by removing the filament from the printer and printing with the nozzle temperature at ambient.... thus saving power on the heater)

Al...

Hi,


Yes, I already did that. I hung it straight above and away from all other cables. I also tried a short cable with a ferrit core, alas to no avail.


Well, the power supply is the one from the set from mendel-parts. I also tried different voltages (the power supply has a switch for 12-12V).
The problem occurs before the heater is used, so I doubt it's a power issue. As mentioned, depending on the firmware used it already happens when homing the z axis.

One additional thing: When printing from a GCode file, Repsnapper keeps pushing GCode lines to the mendel at a speed that does not seem to be in line with the configured 4 instructions cache. Repsnapper mostly is at line 600 or higher when the first serial errors for line 13 or so get returned from the mendel. Is that normal?

Hi,


Yes, I already did that. I hung it straight above and away from all other cables. I also tried a short cable with a ferrit core, alas to no avail.


Well, the power supply is the one from the set from mendel-parts. I also tried different voltages (the power supply has a switch for 12-12V).
The problem occurs before the heater is used, so I doubt it's a power issue. As mentioned, depending on the firmware used it already happens when homing the z axis.

One additional thing: When printing from a GCode file, Repsnapper keeps pushing GCode lines to the mendel at a speed that does not seem to be in line with the configured 4 instructions cache. Repsnapper mostly is at line 600 or higher when the first serial errors for line 13 or so get returned from the mendel. Is that normal?

Hi,
am I right to assume the lack of responses mean that you guys also have no other explantion than a hardware problem of the board?

Hardware problem vs software problem. I guess both

One question: does repsnapper resend info in a good manner and will the print continue? Or does your print job fail when this happens?

If it fails: repsnapper does not understand the code when a failure occurs. You could use an older version of repsnapper. The resend command in firmware and software should match.

If it does not fail and software recovers than your problem is also solved.


Ok, one guess of what the problem is: USB uses a CDC class driver with data verification. However on the gen6 board (and on almost all other boards) this data is converted to normal RS232 protocol on TTL levels. This data is not yet verified. When the firmware on the board has a checksum mismatch it requests the line again. However your software on your PC should handle this and wait for OK from or resend from the Gen6. This is where it goes worng.

Hi, thanks for the answer. Can you give me combinations of versions of repsnapper (or reprap host or whatever) and a version of the firmware known working together? I have tried dozens of combinations and none worked so far.

Currently, repsnapper seems to just continue sending. Repsnapper usually already is at line 600 or higher when an error for line 10 or 13 or so gets reported from the board, so it seems to be like you described. But I have no clue how to enforce proper communication between the two. Repsnapper has a cache of 4 instructions set, but seems to ignore it/ seems not to wait for an ok from the board. But as I said, it also happens with other host software.

It might be that this is a problem only under linux or macos, I myself use windows (xp) and have not experienced these problems. Neither Camiel himself does.

I cannot find the versionnumber of the repsnapper I am using. I suggest you call mendel-parts for their sw version. At this very moment they are open.

This is I am getting the same kind of behaviour with repsnapper just chucking the whole gcode file out. I am using a gen6 board and windows vista.
Did you find a solution for this ?

Maybe you can try to use an older version of repsnapper? Or you might have some settings wrong?