Crazy behavior of Rostock Max V2 EEPROM reset etc

[kasper219]

As of late i can get about 3-5 prints out of it then the EEPROM resets to factory default.... After that if i upload "working" EEPROM settings the machine is no longer level. This is without touching anything else....The only upgrade/s that have been done to the stock part of this printer is going to the E3D V6 hotend and making a new extruder (cold end) which all happened about a month and a half before anything crazy happened. I also have only 1 peek cooling fan on the nozzle platform.

It will also leave Z artifacts and/or randomly shift objects in the front of the machine but not anywhere else on the build plate.... Causing layers to not propperly line up and shift from one another on the affected parts.

Basically if i have duplicates of the part on the build plate, the ones in front (closest to the LCD between the X & Y towers) will be miss aligned (stepping to the back of the plate but staying flat when printing) while the other parts that are being printed at the same time are just fine.

When i check the leveling of the nozzle to the plate I check the 3 towers then center, which all are as spot on as someone can get without a z-probe and i jog the nozzle to different areas of the plate to make sure it is still not dragging or sticking up from the print bed, which it is not....

All of the belts are tight and are in good condition, wiring is still clean and good, power is clean and good, tried changing usb cables to a more shielded one (didn't seem to help), always smooth motion on the towers... I have no clue what is going on with the printer and am in need of help. I have also tried running at slower and even faster speeds than my defaults and the outcome is the same either way.

[KAS]

What slicer are you using? and are you printing via USB when your EEPROM resets? starting to see a trend around the forums.

[kasper219]

@KAS
I use a couple of different slicers and have tried using just Slic3r and Slic3r through Repetier Host(I use it on linux and windows) I also use Cura through Repetier host and it all seems to have the same effect.... All my prints are through the usb port. I print some with an Odroid running Octoprint and via a Linux/Windows computer running Repetier Host and still have the same issues..... It mainly happens if i print the same thing back to back a few times. That is when it seems to happen the most often, but even printing different things it will still go nuts, just not as fast....

[kasper219]

Another thing that I forgot to post that has happened since all of this started happening, is that sometimes (maybe once every 15-25 prints) I will hit the home button in octoprint or Repetier-host and it will try to run the extruder rather than moving the effector back to home for about 10 seconds then it will send the effector home.... The extruder has run in both directions when it does this going forward or backwards when it runs the extruder after pressing the home button in the software (not the one on the front that does home/reset). If that happens it will definitely reset the EEPROM settings, but EEPROM can change without the above happening....

There is a ghost in the machine ...... Now to find the tricky ghost and get delete it so my machine runs normally.....

[Eaglezsoar]

Another thing that I forgot to post that has happened since all of this started happening, is that sometimes (maybe once every 15-25 prints) I will hit the home button in octoprint or Repetier-host and it will try to run the extruder rather than moving the effector back to home for about 10 seconds then it will send the effector home.... The extruder has run in both directions when it does this going forward or backwards when it runs the extruder after pressing the home button in the software (not the one on the front that does home/reset). If that happens it will definitely reset the EEPROM settings, but EEPROM can change without the above happening....

There is a ghost in the machine ...... Now to find the tricky ghost and get delete it so my machine runs normally.....

Perhaps Casper the friendly ghost?

[kasper219]

Perhaps Casper the friendly ghost?

I don't think i would say "friendly" in this case unless it decides it is done playing and comes up with a way to fix itself

[Eaglezsoar]

Perhaps Casper the friendly ghost?

I don't think i would say "friendly" in this case unless it decides it is done playing and comes up with a way to fix itself

I went for a play on words considering your user name, most on here know I have a warped sense of humor

[Polygonhell]

There really oughtn't be a way to reset the eeprom unless the GCODE is being corrupted while being sent to the machine. Several people seem to be having this problem lately though.

When you use repetier host, do you have it set for the binary protocol or the ASCII one?

You can turn on logging in repetier the only command that should cause a EEPOM reset is M502.
You could also check the log window after it happens.

[kasper219]

There really oughtn't be a way to reset the eeprom unless the GCODE is being corrupted while being sent to the machine. Several people seem to be having this problem lately though.

When you use repetier host, do you have it set for the binary protocol or the ASCII one?

You can turn on logging in repetier the only command that should cause a EEPOM reset is M502.
You could also check the log window after it happens.

I looked back though my terribly long log from Octoprint on the last time the printer went all possesed like and there was no showing M502 and there was only 2 times it reported an error and resent data through the 5 hours of transmitted gcode..... The protocol is just automatic which I believe goes to ASCII by default.

Since this last reset at my towers the spot checks are dead on for each tower and so is the middle but directly across from each tower the nozzle is almost 3 mm in the air...... So at each tower on the plate at Z0 they are spot on but directly across from each tower it is between 1 and 3 mm above the plate......

[KAS]

Your resets are a bit different from most others that are using MatterControl. We're seeing resets that are going back to the initial firmware EEPROM defaults which mostly effect the horizontal radius and the overall Z-height. This causes the printing in air issue upon the next print attempt and forces a re-calibration. From my own testing it's either from canceling within mattercontrol, canceling from the emergency button next to LCD while printing from USB, or printing from SD then opening up Mattercontrol with "auto connect" enabled which kills the current print.

Although none of those steps in any certain order produce the reset result 100% of the time..

[kasper219]

Your resets are a bit different from most others that are using MatterControl. We're seeing resets that are going back to the initial firmware EEPROM defaults which mostly effect the horizontal radius and the overall Z-height. This causes the printing in air issue upon the next print attempt and forces a re-calibration. From my own testing it's either from canceling within mattercontrol, canceling from the emergency button next to LCD while printing from USB, or printing from SD then opening up Mattercontrol with "auto connect" enabled which kills the current print.

Although none of those steps in any certain order produce the reset result 100% of the time..

I just messed with the length of the diagonal rods and put it back to default and it made the offset that is across from the tower less, but still not back to good..... I don't know if the atmel chip is having issues reading the EEPROM or just neglecting them sometimes... Or if there is an issue with the checksum (I think checksum was one of the added features to or just before .91)...

I am trying another print to see how it comes out. I may see about posting pictures to see if that can help show more of what i am talking about with the offset across from the towers.

[KAS]

You might want to checkout this page for more info on the issue between towers. It's a long read, but worth it.

http://forum.seemecnc.com/viewtopic.php?f=37&t=4868

[kasper219]

You might want to checkout this page for more info on the issue between towers. It's a long read, but worth it.

http://forum.seemecnc.com/viewtopic.php?f=37&t=4868

I did that and ran the script that was used to check each of the points and i have my machine dialed in to where only 1 of the points has just a little less of drag on the paper not much. I did a print on the machine but i am still having offset parts... It is weird.

The slicer wouldn't have anything to do with it if the max tower height and the radius is different in my program vs the EEPROM would it?

[Polygonhell]

You might want to checkout this page for more info on the issue between towers. It's a long read, but worth it.

http://forum.seemecnc.com/viewtopic.php?f=37&t=4868

I did that and ran the script that was used to check each of the points and i have my machine dialed in to where only 1 of the points has just a little less of drag on the paper not much. I did a print on the machine but i am still having offset parts... It is weird.

The slicer wouldn't have anything to do with it if the max tower height and the radius is different in my program vs the EEPROM would it?

The slicer doesn't care what machine it's generating code for. The GCode is all cartesian moves in mm, the Firmware does all the work to translate to the delta geometry.
The only things those values are used for is to draw the pretty picture of the build area and possibly warn you if the piece doesn't fit.

[kasper219]

The slicer doesn't care what machine it's generating code for. The GCode is all cartesian moves in mm, the Firmware does all the work to translate to the delta geometry.
The only things those values are used for is to draw the pretty picture of the build area and possibly warn you if the piece doesn't fit.

I'm just trying to go down the list for possibilities of what may be causing our issues with the rostock...

[kasper219]

I think i have figured out the wierd artifacting isssue with my prints I had 5 frozen U-joints..... I took them and the rods off gave them an Acetone & ethyl Acetate bath, washed them put them back on and used some lithium wheel bearing grease (plastic safe) and now that part seems to be working better.... It is also more level when checking the leveling. I didn't know that they were frozen in place until i marked the rods and saw if they were moving or stationary when the effector was being moved around.

As far as the reset issue I have not been able to track that down yet... Right now it seems to be behaving *knock on wood* (I have had half a dozen prints without it reseting so far in the past 2 days).

[KAS]

I haven't had any issues with the acetyl u-joints, but I did sand and smooth out the molding/cast marks inside the stock arms.

As for the resets , not one problem since installing the lastest firmware from the seemecnc GitHub(which I don't think changes anything) and I stopped using mattercontrol all together.

[kasper219]

I haven't had any issues with the acetyl u-joints, but I did sand and smooth out the molding/cast marks inside the stock arms.

As for the resets , not one problem since installing the lastest firmware from the seemecnc GitHub(which I don't think changes anything) and I stopped using mattercontrol all together.

I used a razor blade to shave off the mold/cast marks. I've had the latest fimware on mine since we got the Rostock I put it on when it came in. I haven't tried mattercontrol on this machine (I have on our Robo and i am not a fan....) I mainly use Repetier host or just straight Cura/Slic3r and then use Octoprint on an Odroid so it frees up my computer when printing and i can pause if needed.

The U-joints were frozen because tiny flakes of the plastic got in there and acted like glue over time.... Probably from the friction with printing over time. I just put the lithium grease on to help ease the movement and so far that seems to be doing the trick for me... Never even thought to see if they were freed up or frozen.