qwerty8224 16
there is an error ....
The memory card checked all sector workers and a very good time reading
something in the firmware
Edited by Guestthere is an error ....
The memory card checked all sector workers and a very good time reading
something in the firmware
Edited by GuestMy understanding is the only way to get that error is if a gcode purposely moves outside of the print volume such as:
G0 X-10 (move X axis to position -10mm which isn't allowed)
or
G0 X300
or even
G0 X923489123987482374
Which cura should never generate but can happen if you have a read error. Most likely those 2 ribbon cables that connect the computer to the card reader.
Yes, but the marlin running smoothly
I have just bought a new sd card (EMTEC HC 8go) with a good read speed. The problem didn't happen during my last prints. "Gr5" said it might be because of the ribbon cables. Do you think if we put ferrit on this cables it can reduce the probability of read error ? It just a suggestion.
Edited by GuestI am still not convinced this is a sdcard issue. Just had a failure right now. Take a look at the print:
This is a very clean y-axis shift. I checked the pulleys, they are not loose.
And there is this weird movement again. It is not in gcode and incidentally on the same layer when the y-axis shift happens.
@tinkergnome: Do you have any idea what could cause this? Not even sure where to look. Hardware? (board damaged, memory corrupted) or firmware? Apparently the gcode is fine and i bet if I print this again, it won't fail at all...
Hi Nicolinux,
Would not this look like this if the Y-stepper slip (give way) due to high friction, so you'll have a new offset for the Y axis, cause there is no position feedback to give an error signal about this. The printer "happy" go on in order to finish, (and take the rest of the day off.. )
Torgeir.
As I said, I checked all pulleys and they are tight.
@tinkergnome: Do you have any idea what could cause this? Not even sure where to look. Hardware? (board damaged, memory corrupted) or firmware? Apparently the gcode is fine and i bet if I print this again, it won't fail at all...
I think, it's already proved, that it's not a problem with the gcode. Have you ever seen a similar problem while printing via USB / Octoprint?
My best bet at the moment: i saw the first reports about this after i switched to the sd-card stuff from a more recent compiler version. I think, it's a bit faster, but perhaps there's something in, that is not fully compatible with the used hardware? I never had an issue with it, so this is only a guess...
If i find some time for a new release, i'll switch back to the old version. Time will tell if that makes a difference...
As I said, I checked all pulleys and they are tight.
I'll think there was someone had some friction problem inside the stepper, when the stepper was hot. Well, just a shot..
I'll think there was someone had some friction problem inside the stepper, when the stepper was hot. Well, just a shot..
The symptom is similar, but the error message from the beginning of this topic can only appear during a print from sd-card and if a wrong x/y/z coordinate was read.
This restricts the possibilities...
I have this issue on my UM2 but not the UM2+ both use the same SD card manufacture, but i now have the UM2 rigged up to Octoprint and now i do not get the error at all....
Yes tinker but @Nicolinux did not imply that he got the error this time. I think his post is in the wrong thread. Nico you checked that belt pulleys are tight but did you check for friction? And did you check the pulley on the motor? It's usually the one on the motor.
I'll think there was someone had some friction problem inside the stepper, when the stepper was hot. Well, just a shot..
The symptom is similar, but the error message from the beginning of this topic can only appear during a print from sd-card and if a wrong x/y/z coordinate was read.
This restricts the possibilities...
Hi tinkergnome,
Thanks, just been readading through all the posting and sure agree. This is strange and interesting.
People are using different version of slicers, and firmware, correct?
I'm wondering if this happen at differen/random places on the same object, or same place every time tried to print this particular object?
Hmm.. Firmware is reading all information from the SD card the same way, but reporting “a wrong x/y/z coordinate was read”.
This could be a hardware failure as well, I.E. as a noisy power supply unit.
Thanks.
Torgeir.
@gr5: I did check all pulleys.
Even if the sdcard was bad, how big is the chance that it produces a weird move to the side (see second picture) and then returns exactly at the same spot but shifted into the y-direction. I find @tinkergnome's explanation more plausible
Hmm.. Firmware is reading all information from the SD card the same way, but reporting “a wrong x/y/z coordinate was read”.
This could be a hardware failure as well, I.E. as a noisy power supply unit.
May be, but it's suspicious that there is not such a problem with older versions or with the standard firmware. That's why i think it has something to do with things that were changed this year...
Hmm.. Firmware is reading all information from the SD card the same way, but reporting “a wrong x/y/z coordinate was read”.
This could be a hardware failure as well, I.E. as a noisy power supply unit.
May be, but it's suspicious that there is not such a problem with older versions or with the standard firmware. That's why i think it has something to do with things that were changed this year...
Great diagnostic.
Torgeir.
There were I believe some strange bugs in the planner where if you moved X,Y,Z axes all at the same time sometimes it screwed up and moved faster than it should be possible which causes some of the axes to lose steps. I don't know if all of these were fixed. It's not an obvious bug because usually the Z axis moves all by itself.
I suppose it's possible that the bug still exists and combine that with SD card read errors it could do a strange move suddenly and lose steps in one or more axes.
But it seems unlikely to me. It seems more likely that you lost steps due to a hardware problem in the Y axis and it was printing that arc where the red arrow points on the far arc behind the part right when it happened and so printed in thin air and then went to do the infill maybe or finished the arc onto existing layer below giving you a large loop behind the part but then the fan somehow blue the loop to the right.
The hardware problem could be loose pulley (I know - you tightened them all) or overheating driver or high friction in the Y axis.
Gr5 say
@Which cura should never generate but can happen if you have a read error. Most likely those 2 ribbon cables that connect the computer to the card reader.@
is needed to protect the cable ... (Screen)
What spoils signal. !!! I just moved the cable 2cm apart
20 hours of printing ОК.
Testing goes on
Edited by Guest>I just moved the cable 2cm apart
That might be it. It could be "crosstalk".
In the middle of printing pulled thread (((
Again, moving head ((((
Interference canceled)))
Edited by GuestHi guys,
I have moved the two cables who link the screen to the board away from each other. SInce I did this, I have printed 10h without any issue
The man wrote that laid the cable and 2 weeks prints no problems
Edited by GuestI ran into the same issues when installing tinkergnome's firmware V16.08.2
unexpected and unpredictable moves in X, Y and even small Z-hops.
I also had a "Remove Material" triggered randomly while printing a model.
So I rearranged the 2 ribbon cables from them mainboard to the SDcardReader and OLED that there is some distance between the cables.
Problems solved, printed many hours without any issues!
Recommended Posts
Top Posters In This Topic
9
7
6
6
Popular Days
Nov 17
13
Jan 1
4
Dec 20
3
Jan 2
3
Top Posters In This Topic
Nicolinux 9 posts
gr5 7 posts
keith-hobley 6 posts
tinkergnome 6 posts
Popular Days
Nov 17 2016
13 posts
Jan 1 2016
4 posts
Dec 20 2016
3 posts
Jan 2 2016
3 posts
Posted Images
Nicolinux 288
The funny thing is that I've had this error _only_ with this firmware. That's why I thought it might be related. I printed a lot since then and it didn't occur.
I am also using OctoPrint now. Let's see if it happens again.
Link to post
Share on other sites