Error Tried printing out of printing area

[gr5 2,192]

I got this for the first time.  I was in production mode (what I mean is I was printing many identical parts) and it was the 3rd time printing the same gcode file.  I just printed it again and it was fine.  I'm guessing it means a read error from the SD card which is very worrying.  Maybe re-rout the parallel cables?  I've had this printer since the UM2 came out (3 years?) and this is the first time.

[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.

[qwerty8224 16]

there is an error ....

The memory card checked all sector workers and a very good time reading

something in the firmware

Edited November 5, 2016 by Guest

[gr5 2,192]

My 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.

[qwerty8224 16]

Yes, but the marlin running smoothly

[Jerbear 1]

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 November 15, 2016 by Guest

[Nicolinux 288]

I 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...

[Torgeir 248]

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.

[Nicolinux 288]

As I said, I checked all pulleys and they are tight.

[tinkergnome 927]

@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...

[Torgeir 248]

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..

[tinkergnome 927]

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...

[cor3ys 28]

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....

[gr5 2,192]

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.

[Torgeir 248]

 

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.

[Nicolinux 288]

@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

[tinkergnome 927]

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...

[Torgeir 248]

 

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.

[gr5 2,192]

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.

[qwerty8224 16]

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 November 18, 2016 by Guest

[gr5 2,192]

>I just moved the cable 2cm apart

That might be it. It could be "crosstalk".

[qwerty8224 16]

In the middle of printing pulled thread (((

Again, moving head ((((

Interference canceled)))

Edited November 19, 2016 by Guest

[Jerbear 1]

Hi 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

[qwerty8224 16]

The man wrote that laid the cable and 2 weeks prints no problems

Edited December 5, 2016 by Guest

[uit 14]

I 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!