Printing off the job

[Reverse_Engineer 0]

Hi everyone

 

I'm new to all this, so sorry if I'm posting in the wrong place or asking about something that's been answered ad nauseum.

 

I'm using a newly acquired Tevo tornado and slicing my stl's with Cura 3.4.1 (appimage) on a linux host.

 

Some of my jobs print fine but sometimes the nozzle will shoot off to the side or front of the job and keep extruding while it's off the print job. This is leaving unwanted strings all over the place. Sometimes it gets so bad the extraneous strings get caught up in a bundle which wraps around the the nozzle and ruins the print. Sometimes it wants to head towards X home and other times it heads towards Y home while it's off the job and extruding.

 

I read somewhere that minimum layer time can cause a similar problem , so I reduced that to 3 and it didn't help. Besides including a purge/wipe routine in the Cura machine settings, I've never had the need to even look at G-code until now, so I must admit I don't really know for sure what I'm looking at but I can't see any X or Y coordinates in the G-code to account for the extra off job trips the printer does. The X and Y coordinates in the G-code seem to stay within dimensions of the job being printed.

 

I first noticed the printer going off job at 0.6 layer height of the print in the pic and examining the first few layers of the G-code shows no off print coordinates I can see. It kept doing it during the rest of the print and ended up ruining the print (a ball of crap wrapped around the nozzle and snapped the top off the print).

 

I don't know if it helps but I'll include my profile settings and my G-code after slicing if anyone wants a look. The strings were a lot worse than what you see here, I've started snipping them off with scissors and trying to get rid of them whenever I notice them.

 

Any advice would be greatly appreciated.

 

CCR10_My new Z nut bracket (narrow).gcode.zip

Bracket profile (random strings).curaprofile

 

 

 

 

 

[gr5 2,191]

So I have had printers with this problem.  First let's go over the symptoms.

 

The X or Y axis (never the Z) will suddenly move very far - sometimes 100mm from the normal position.

Also sometimes the print will stop and the E axis will move very far - maybe 100mm.  And then it will move back and continue printing.  It will be paused for maybe 5 seconds while the E axis retracts 100mm and then goes back like nothing happened.

Oh and the other symptom is occasionaly "print out of area" errors.

 

The cause:

Very bad communication.  One time the problem was that I was using an SD card and there was a hair in the connectors.  I took that part of the printer apart and cleaned it out with a toothpick and compressed air and vacuum.  After that it worked much batter.

 

Also it's possible the USB cable can cause the problem if you are printing through USB or the ribbon cables that connect to the arduino board or even the arduino itself can be a bit defective.  Once the problem was fixed by simply repositioning the ribbon cables.

 

What happens is there is a checksum.  If one random bit is changed then the checksum fails and it resends that line of gcode. Most of the time.  But if the checksum is also changed and passes by random chance then the line of gcode is assumed to be okay (even though it isn't).  If a G1 X150 is changed to G1 X250 or G1 X050 then the X axis will move very far away from the print and then return and continue.  If it is changed to G1 X950 you get the out of bounds error.  Random failures of the checksum will pass 1 out of every 256 times (on average).

 

 

[Reverse_Engineer 0]

That makes perfect sense, it's an intermittent thing that only happens sometimes.

 

Thanks for taking the time to answer and help me out, I really appreciate it.

 

I'm printing from an SD card that has an adaptor to fit a mini SD card, so there's a few possible bad connections in the chain. I'll change that and see how it goes.

 

Thanks again, I never would have considered that to be the cause.

[obewan 37]

This could also be a problem with spurious interference from the stepper motors being picked up on the endstop wires,

what firmware are you using?

did you upload it to the controller or was it already installed ?

[Reverse_Engineer 0]

19 minutes ago, obewan said:

This could also be a problem with spurious interference from the stepper motors being picked up on the endstop wires,

what firmware are you using?

did you upload it to the controller or was it already installed ?

The firmware was already installed, it's  Marlin 1.1 I believe. It's mid print right now & don't have a computer hooked up to it so I'm not sure if I can query the version right now.

 

& I changed the SD card and played around re-seating it but it's still intermittently printing a mess off the job. I'll hook the the laptop up to it after the kids go to bed and query the Marlin version and run a print from USB to see if that proves or disproves the faulty contact on the SD card/slot.

 

Thanks for the input obewan.

[obewan 37]

If it is Marlin, you can disable endstop detection by sending a M121,.after you have homed the printer.

re-enable detection with M120

These can be added to cura's start/end gcode.

 

[gr5 2,191]

If it was endstops then the part would have sudden permanent (for a few layers anyway) shifts in position.

 

@Reverse_Engineer - you really need to take apart things and clean out the SD card reader with a needle and compressed air and re-position the cables that go between the board with the SD card reader and the main circuit board.  Maybe swap the 2 ribbon cables (I assume your printer has 2 ribbon cables - maybe it has one cable).

[Reverse_Engineer 0]

Sorry for the slow reply, don't you hate it when life gets in the way of your hobbies.

 

I must admit I couldn't really get my head around the end-stop issue. I would have thought that would cause a layer shift or drift of some sort too.

 

Anyway I ran a print through Cura over a USB connection to isolate the SD connection and remove that from the control loop. It worked perfectly and there's no more random stringing or unexpected movements off the print job.

 

It seems that gr5 was on the right track, thanks mate!

 

I was considering an octoprint setup, if I can't get the SD connector 100% reliable this might be the nudge I needed to commit to that decision.

 

Thanks guys.

[Reverse_Engineer 0]

Sorry to drag this up again.

 

I thought I had this solved, printing from Cura with a USB cable connected to my laptop resulted in three perfect prints last night. Then today I did a print of a Unicorn my daughter found on Thingiverse and it displayed repetitive layer shifts along the Y axis.

 

I can't say for sure but this seems to be a different issue to what I had before, there's no extra paths being printed off the job just (roughly) 0.5 - 1mm layer shifts with the rest of the printing as normal. I'm still not discounting your advice obewan, your suggestion could be a good diagnostic tool for this current issue.

 

I was getting layer shift issues (also along the Y axis) when I first got the printer but I adjusted the output voltage of the Y stepper driver and that issue seemed to be cured. Those shifts were intermittent and very random, these shifts are almost what I'd class as in being a regular pattern.

 

Now for a bit of speculation

The only real difference I can think of between the last few successful prints and the one that just shifted layers was that my mrs was running the washing machine when it printed. Could it be possible that the washing machine motor could be spiking the voltage of my house wiring through counter EMF when the field collapses each time the motor switches off and is causing my problems?

 

I'm not certain but I think it's on the same circuit as the outlet the printer and laptop is plugged into. I'll investigate that when the current load of washing has finished. Even if it is a different circuit both circuits share a common rail n the meter box before they connect to the breakers.

 

Is a dirty supply voltage known to cause this type of problem ?

 

Edit : To save dragging this up again I'll just edit this with an update.

I just ran another print sans the washing machine running on the same circuit (I did determine that it's running on the same circuit) and it turned out perfect, so it seems the noise from the washing machine motor was having a deleterious effect on the printing performance in regards to axis shift. I'll mark this as solved now and put it to bed.

 

Edited July 28, 2018 by Reverse_Engineer
To update my findings