Error wrong checksum repetier

Format Error, Wrong Checksum, Missing Linenumber

Hello everyone, I am having communication problem between Server ( Raspberry Pi) and my printer (Kossel Mini).
This is what I have tried to troubleshoot:
-Run direct from Usb to PC = No error
-Debug with M111 s24 = No error

Anyone can help ?

Here is what happened on the log , long pause made stepper disabled and result layer shift or hitting print.

So as soon as you enable steppers you get communication errors printing from pi but printing same prom a pc would work? If you have try putting a active(powered) hub between printer and pi. Then the hub reduces power load on the pi and also filters usb signals. Alternatively a lower baud rate like 115200 could work.

Yes exactly printing from pc using same usb cable give no communication error. I have tried other baudrate with pc but with the PI it keep connect/disconnect and I am not able to use the printer with rate lower than 250000. The Pi is powered by a 5A 12v to 5v regulator connected on the GPIO. I will install a voltmeter on the output of the regulator to record a voltage drop.

I have read things about buffer size who can give error on Arduino Due. Can you give me help about that ?

I will try with a usb hub when as soon as I receive a male to male usb.

Thanks a lot for your support .

If you compiled with recent Arduino IDE buffer size is 127 byte. Older had 63 bytes. In general same buffer size as in host should work, but you are right. This kind of problems can happen also with wrong buffer size.

Regarding power connector make sure usb cable is also with good wires so pi gets >5V at the receiving side.

Aren’t all usb hubs male to male?

I have done a couple of test and here is what I have found. By accident one time I have disconnected the PI from the supply on the GPIO but the PI was still connected to usb and didnt turned OFF. But if a do this now the PI will not stay ON. Maybe the converter who supply voltage to the usb on the Arduino is dead ? I have tried to put an active usb hub but it didnt solve the error.

Next, I have 4 extruders and I have found if I only keep one mapped without any hardware change the problem disapear.

Only one mapped means configured firmware for 1 extruder?

Having all 4 and only ever activating same extruder should behave the same. Switching active extruder might then activate the problem. If that is the case check where the motor/heater wires go. But on the other side printing in dry run does not use any extruder and you said that failed as well right?

By only one mapped I mean 4 in firmware but only one in Host.

I am a hundred percent sure the problem is software now. Value in the eeprom were set at -1 and this is what seems to produce the error. I have added extruder one by one and each time after adding one I have run a 6 hour print in dry mode. I think the error are generated by a conflict between different value from Host ,Eeprom and Server.

Host doe snot really matter as it just sends gcode and the error is communication. Only baudrate influences communication on host side. But you also mention server so same rules here. eeprom contains baud rate and some parts influencing how hardware is controlled. So that would be part of firmware configuration.

I think it depends on which extruders get power, so if you are using extruder 1, 2, 3 or 4 or even heat several at once. That would be a slicer setting if they got used. More active extruders make more problems with power unit as all extruders are turned on the same time, so the current rise per pulse increases. That could mean more induction or a bigger voltage drop.

Maybe I am on a wrong track but error appears with only one extruder powered. To my eyes it look like when I have 4 extruders configured communication are more loaded. When the extruder are off , firmware continue to monitor the temperature. I have tried to keep all the hardware unchanged and only keep one extruder in the firmware with no errors.

Since my last post I have buy an other usb cable and I have added a 5A usb supply to the PI and I am still having communication issuse.

If I run print same print in dry mode I get errors. I have a multimeter who can record voltage drop. I have run the print in dry mode and look at what the meter have logged and there is no significant voltage drop.

I have a lcd screen connected on the radds and you can see the buffer usage. It is always between 15 and 19 but when communication drop it came empty.

Do you suggest me to remplace the PI ?

You could also try the other usb port of the due, not sure which you are now using. Just remember to change configuration accordingly or configure it to use both ports so you can switch any time.

Strange thing is that it works on pc, so that makes you of course think pi could be the reason. But since it works for a while I do not think it would solve the problem. With an active usb in front you have already replaced the communicating part and decoupled printer from pi. Or didn’t you do that test?

Sorry for the delay. Job take all my time.

I have tried the solution with the active USB hub with no success. The first one I have tried was cheap so I have to tried a better one before saying it was not working for me. I am still getting the same error I was having with the Arduino plugged directly in the PI.

I will try with the second usb port on the Arduino this week. Thanks

Источник

Printing from SD card #10

Sorry to be a nuisance, but I’m now finding that I can’t print from SD card anymore — I can load files to the card, but when I try to print, I get an error message — wrong binary checksum. The SD card did work OK with version 0.43, and now doesn’t. Is this a problem with my hardware or has something changed in firmware?

The text was updated successfully, but these errors were encountered:

The changes had nothing to do with the SD command and didn’t change anything of the related code. I even rechecked the sd card on my board and it is still working flawless.

The first question is when do you get the error.

1. The start print command issues it — just restart
2. You get it during print — hardware problem
   The data is stored including checksum. Could be a write or read error on that file. Try uploading a small file and recheck. Try also with fan disabled (I remeber you having added a fan). SD cards are quite sensitive on voltage fluctuations.
   That you succeded uploading a file shows that your card is more or less working. The only questions is what triggers your error.
   You could also upload a file on your pc eliminating possible upload errors.

Thanks Repetier, I’ll try that. BTW with the latest release the extruder hotend (pin 13) no longer works. Adding the simulate pwm for the fan/heater seems to have stopped it working? The previous release works OK with the simulate_pwm_fan defined.

Источник

Error:Binary cmd wrong checksum. #7

Hi, I just upgraded to the latest firmware (5b925be) and I’m having some problems. The print starts out ok, but after a short while, repetier host get’s disconnected. I’m running the latest 0.34b version.

When I updated the firmware, I moved over my working settings, didn’t change anything and it was working great before.

I have uploaded the log to http://pastebin.com/ZbCb40eL if someone would like to take a look.

Let me know if there’s anything else I can submit.

The text was updated successfully, but these errors were encountered:

I just tried to print the same STL from pronterface, and it worked fine. So I guess the issue I’m having is with Repetier Host?

Shall I close this issue?

it should work Repetier-Host, too. Are you using Arduino 1.0 since your upgrade?
Since Arduino 1.0 the directly supported boards have a reduced receiving queue. It went from 128 to 64 bytes. In the printer settings you can set the queue length, which is used for faster communication. Default is 120 so with the 64 bytes this would mean an overflow creating the com errors. Try reducing the number to 63. Alternatively you can also try the slower Ping-Pong mode, which is what pronterface does.

Hi, sorry for the late reply. Work got in the way. I just fired it all up again, and now repetier-host is not working at all. It says it connects, but there are no commands sent to the firmware. I closed it, and opened up pronterface, and it worked as expected.
I also just did a reinstall of repetier-host, but same thing, think I need to delete the settings files tho, as it came up with my old settings. will dig around for them.

Oh I did try the 120 to 63, and ping-pong, but since the host wont even talk to the printer, I doubt it will have any effect until I get the current problem sorted.

well, it all started working magically again 😉 I replaced 120 with 63, didn’t activate ping-pong though, but it all seems to work fine again. Thank you!

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Checksum Errors & Thermal Overrun/Overheat / Overall crashing/freezing/ruining of prints

Without changing ANYTHING in software, firmware, hardware, etc around the end of January I suddenly started seeing hundreds of checksum errors in my error reporting window in RepeteirHost. These were accompanied by some wicked crashes/freezes, and then later by horrible thermal overrun a few weeks after. We are now almost a month into these horrible issues and I fear something to do with RepHost is at fault.

Related: This is a completely new error from 2-19-17 and I have never seen it before or since! Not even sure if relevant. Only happened once.

-Tested 2 new/functional RAMBo boards. Same issues. Same checksums. Ugh. This was before runaway even was an issue. -Tested PSU night of the 17th. Good voltage. No problems there. Very ordinary. -Tested 4 different USB cables and all my USB ports, 2.0 and 3.0, front and back of desktop chassis

-Tested another computer. (Mac) SAME checksums and crashes. Didn’t see any thermal overrun but only tested 3-4 hours.

-Tested another host program. Didn’t see any checksum or crashing, or overrun. but print quality was awful and workflow was confusing. didn’t test this enough. I LOVE REPETIER so I don’t want to change.

Issues in short:

Not long after this all started, prints started randomly freezing. Sometimes they would restart, sometimes now. Often, the XYZ motors would lock and the E motor would furious spin, inducing a massive retract or extrude command which inevitably led to the usual ruining of the print.

Sometimes, the crashes would put all four motors offline and NO errors would actually be reported at the time. The entire machine would just there, fans running, hotend hot, bed hot, totally 100% frozen. Pressing emergency stop returned all functioning to normal. until the next print of course. Throughout this, the host has never become unresponsive!

Suddenly, on the 17th-ish, the nozzle started having thermal runaway (heating up WAYYY beyond normal and leaking molten filament) when idling/heating before a print. Actually starting the print caused the runaway to stop and printing could proceed normally (with plenty of checksum errors of course!) NOTE: nothing is reported in host or on LCD screen of my romax when this happens! The reporting is 100% normal. the thing just smokes badly and leaks molten filament, clearly getting wayyy too hot. I even installed an auxiliary LED to check and see if the circuit was staying on too long. Nope. LED flickered to indicate heat variance, off and on as it should once temp is reached.

The printer FREQUENTLY ALSO forgets all of its EEPROM settings, resulting in failure to maintain PID, horizontal radius, accel values, extruder steps, etc, etc. I have locked my settings into firmware, but it still forgets horizontal radius — which is impossible to set in repeteir firmware directly. Why in the WORLD does this happen? I can’t even find anything while googling this. It has not done this since the 17th, however.

SeeMeCNC support has totally give up, stating they have never heard of anyone encountering these problems before. Reprap IRC is helpful as always, but nobody knows why any of this is happening.

They suggested I try:

_ A: A new RAMBO board

_ B: A new USB cable going to my desktop

_ C: Printing from SD card.

_ A: I tried a new board and exact same thing happened. Tons of checksums and freezing.

_ B: I tried FOUR BRAND NEW USB cables, some even with ferrite chokes to prevent EMI.

_ C: I tried printing from SD cards and successfully got the checksum errors to stop, BUT this is horrible for my workflow AND the hotend runaway / EEPROM forgetting STILL happen.

Before the end of January, none of this happened. I want to reiterate: NONE of this happened. It remembered its settings for years, never froze, and only spat out some non-critical checksum errors every few dozen prints! And never hundreds in a single print.

I did not change the room, the table, the machinery. NOTHING. Nothing has changed. Early in the month of January I did upgrade to the newest version of Repeteir firmware DIRECTLY from SeeMeCNC. No errors occurred and things ran smoothly until the end of the month when things started going nuts.

What in the world is going on? I swore trying a new clean working board, SD printing, or new USB cables would be the solution. SeeMeCNC says out of the thousands of customers they have nobody has ever reported these issues, especially in combination.

Please. if anyone can help. I’d sincerely appreciate it.

I’m located in San Francisco if anyone is local to come take a look. I will pay you for your time/expertise.

I upgraded my desktop’s RAM from 32GB to 64GB (1600mhz to 2133mhz) on January 7th. I printed from the 7th until the 29th of January and NEVER had any issues! The 29th was the first crash. (or thereabouts within one or two days if memory serves)

The alternate host I tried was Mattercontrol.

I have tried with hundreds of different 3D models. Both mine and public models. Doesn’t make a bit of difference.

I have tried reseating my RAM, reseating my GPU, checking my CPU’s temps. all NORMAL and properly done. [I’ve built 30 computers and 10 printers so I’m pretty good at hardware troubleshooting]

I have tried using MANY different versions of RepHost, from 0.95 all the way up to the current 1.6 something. STILL checksums and crashing and thermal overrun.

Things I have not done yet but may:
-Switch back to OLD RAM that I know worked perfectly.
-Switch out for a NEW power supply. but I already have an amazing one and the voltage was stable so I’d rather not!
-Continue to do long/difficult prints from SD even though the workflow for that sucks and rephost actually crashes if I don’t save the gcode externally.

Источник

Advanced

Hi Robin, so, jetzt also hier.

wenn du während dem Druck dem Drucker Befehle «unterjubeln» möchtest, musst du diese in den Gcode-Stream (printer.code) einbauen. Das ist nicht ganz einfach.

1. Dazu musst du zunächst den Druck pausieren, sonst schickst du bereits neue Zeilen an den Drucker, während du noch ausrechnest, wo du die Zeile einfügen musst und wie die Prüfsumme dafür aussieht.

2. Den Gcode kann man über die Funktion loadgcode (Zeile 95) laden. Dieser Funktion wird aber bereits der geparste Gcode (Gcode mit Zeilennummer und Prüfsumme, ohne Kommentare) übergeben. Du musst also an passender Stelle in der Liste deinen Gcode mit Prüfsumme und Zeilennummer einfügen. Die letzte gesendete Zeile ist printer.currentln (Zeile 170). Du musst deine Zeile also bei currentln +1 einbauen.

3. Jetzt kommt aber der Haken: Fügst du eine Zeile ein, musst du auch alle Zeilennummern aller nachfolgenden Befehle ändern. Es kann ja nicht z.B. Zeile 42 zwei mal an den Drucker gesendet werden. Mit den Zeilennummern muss auch die Prüfsumme (das hinter dem Stern) neu berechnet werden. Am einfachsten bekommst du das realisiert, indem du das mit dem Parser erledigst.

4. Du musst alle Zeilen, welche noch nicht an den Drucker gesendet sind, holen. Du kannst nicht einfach den Eingangs-Gcode verwenden, da dieser eventuell Kommentare enthält und damit deine Zeilennummern verschieben würde. Von diesen Zeilen musst du jetzt die Zeilennummern und Prüfsummen entfernen, da du diese ja neu erzeugen möchtest. Danach hängst du den Gcode, den du gleich senden willst vorne an das Ergebnis ran. Das sollte so funktionieren:

your_codeline = "" # Die Gcode Zeile, die du senden möchtest
unsent_lines = printer.gcode[printer.currentln +1:] # Nicht gesendete Zeilen holen
re_linenumber = re.compile('^Nd+s+')
re_checksum = re.compile('*d+$')
new_lines = [your_codeline]
for line in unsent_lines:
    line = re_linenumber.sub("",line)
    line = re_checksum.sub("",line)
    new_lines.append(line)

1. Das ganze gibst du jetzt dem Parser wie folgt:

parser = gparser()
parser.fcontent = new_lines
parser.parsed = [''] * printer.currentln # Parser Zeilennummer richtig setzen
for line in parser.fcontent:
    parser.parse(line)

1. Danach lädst du den neu erzeugten Gcode in den Drucker:

printer.loadgcode(parser.get_parsed())

1. Die Pause aufheben.

Da du ja noch eine GUI an mein Programm rangebastelt hast, hast du vermutlich 2 Threads am laufen. Das könnte auch das Problem sein, warum das Programm nach ‘programm stopped.’ noch weiterläuft. Hier musst du darauf achten, dass der andere Thread auch beendet wird.

Es ist wichtig, dass der Thread, welcher die Daten an den Drucker sendet pausiert wird, während du den neuen Gcode berechnest.

Erstelle doch auch ein Github Repository und lade da deinen Code rein, oder forke meines.

Grüße,
Florian

PS: Die Prüfsumme wird in der Funktion checksum() in Zeile 37 ausgerechnet. Die Funktion csline() in Zeile 44 nimmt eine Zeile an und gibt sie mit Prüfsumme zurück.

В Melzi стоят драйвера шаговых двигателей A4982, они могут работать с ШД до 35В 2А.
42BYGHW609 — 1.7A 4000g.cm(56oz-in) 1.8 degree
42BYGHW811 — 2.5A 4800g-cm(70oz-in) 1.8 degree

Вывод, второй двигатель мощнее, но и жрет больше, даже больше чем выдает A4982, на таких токах, понятное дело, не работают 3Д принтеры, для регулировки тока на плате Melzi есть регуляторы, обычно их выкручивают на 25-30%, так что подойдет любой, выбирайте из соотношения цена, вторичное использование, качество.

neverdie писал(а):Доброго времени суток
возник вопрос
использую программу Repetier-Host
также Sanguinololu Rev 1.3a,

почему-то не удается печатать модели выше 100 мм
даже в ручном режиме не могу поднять выше данного значение
что не так ?
есть гдето ограничение но немогу найти

Ограничение на самом деле в прошивке, обычно в Marlin стоит по умолчанию 100 по высоте:

Код: Выделить всё • Развернуть

// Travel limits after homing
#define X_MAX_POS 205
#define X_MIN_POS 0
#define Y_MAX_POS 205
#define Y_MIN_POS 0
#define Z_MAX_POS 100
#define Z_MIN_POS 0

Искать в Configuration.h

Добавлено спустя 13 минут 35 секунд:

lamer20071 писал(а):Добрый день! Помогите разобраться! Купил себе Solidoodle 4. К стандартному столу не липнет пластик, стол грел до 110 С, не помогло. Положил стекло, тоже самое, использовал и лак для волос, и пиво с сахаром(как советовали). Даже купил с дуру 3М голубой скотч. Результат «печалька». Подскажите, пожалуйста!

На самом деле это отдельная большая головная боль каждого владельца 3D, у нее целая ветка —

forum107/topic11993.html

Я тоже когда печатал первые образцы думал, что можно на чем угодно. Пробовал и на стекле, и стекло шкурил, и разные температуры пробовал, и синий скотч 3М, и моментом, и АБС плавил в ацетоне и еще пиво, в общем перепробовал много.
Теперь у меня алюминиевый стол по клеенный каптоновой лентой, 1 раз промазанный ацетоном с растворенным АБС, печатать приятно, никакой деламинации, накаких скрепок стекол, зеркал и т.д.
А лучших результатов удалось достичь со стеклом при нанесении раствора ацетон+АБС, а так-же местного безалкогольного пива, но стекло я менял 3 раза, да и как то раз клеил суперклеем основание чтобы допечатать.