So, wierd thing happening...

I have a threeup printer from QU .... had to jump through some hoops to get it working! ... but now it works! Had it for about two weeks, it's been working well! ... but, anything I try to print over about two inches tall (25mm) 'shifts' on both the x and y planes... and never on the same Z... if I reprint the same thing, it happens again, on a different location.

No, it's not slippage, cuz, when I hit home, it goes home correctly, so it knows exactly where it is at all times! And anything less than about 10mm (25mm, etc, haven't tested this extensively, it's getting expensive!) anything below 10(20)mm works flawlessly!

Should I upload new firmware? maybe install a cardreader? (I do not think it's a sourcecode problem as both Blender and Repetier are showing it as valid, and I am using Slic3r and it is also showing it correctly

You should first do some reading on how a printer actually works as you seem to struggle understanding what part of the hardware is responsible to the print results.
Sure you can get a card reader, falsh a new firmware, but would it solve your porblem? No...

Quote
Malendryn
No, it's not slippage, cuz, when I hit home, it goes home correctly, so it knows exactly where it is at all times!

There is no real work done when it homes and it actually goes home on startup because it does not know where it is

Do a proper hardware calibration followed by calibrating the Esteps.
Only once that is done properly continue to tweak your print settings.
After that you not only know better how your printer works but you will also get usable prints.

Layer shifting is caused by mechanical problems such as loose pulleys or belts, intermittent wiring, and by having acceleration, jerk, and speed settings too high. You have to rule out mechanical and wiring issues first by carefully inspecting everything and making any necessary adjustments. If the problem persists, try turning down acceleration and jerk in the firmware, or printing speed in the slicer.

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

The fact that "it goes home correctly" does NOT necessarily mean that it always knows the head position correctly.

I don't know the printer you have, but, generally speaking, printers have microswitches that trigger when they are in the home position. Telling the printer to 'home' typically means it moves in the X & Y axes until the switches trigger.


So I agree with TDD.

Try moving the head around under manual control, up above the 10-25mm height where you see errors... does it clunk or skip or does it move smoothly? Are there any wires or whatever that could get hung up at that height? Perhaps get hung up on the object that's being printed?

How sure are you that it's height related? Could it be that the errors are time-related? It's typical for heating/cooling issues to show up some time after the print is started.

Edited 1 time(s). Last edit at 12/20/2015 03:38AM by frankvdh.

The printer I have is the threeup from QU-BD, and it has no endstops so when I said it goes home correctly, I mean it moves to XY zero on its own, no skipping, no slippage, and that's what has me puzzled. I've calibrated it numerous times, and it prints very nicely as long as I don't try to print anything too high. ... If it wasn't for the fact that it moves back to home correctly (without endstops, strongly suggesting the belts didnt slip or the motor got hung on anything) then I'd be looking for a completely different kind of problem.

Whether it is height or time related is still a thing to test, and you're right, it could be time related. (I'll be setting up a recording camera on it on my next print so I can keep track of everything down to the second...)

The head and bed both move by hand, no jerking or wobbling or 'stuck' points anywhere.

As for my experience, as someone earlier commented, This is my first 3d printer, but I have been a machinist for over seven years, and am a computer programmer for over thirty. I'd put myself slightly above 'clueless' here ;>

Which slicer are you using? Sometimes Slic3r does bizarre things. Try Cura...

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

I guess you get what you pay for.
There is a good reason printers use endstops and I would not have a clue how this printer should get it all right without.
That means it must use a modified firmware as well.
The board supports endstops as far as I could see in the manuals....
In the end to get it to normal standards the added parts and labour make it as expensive as a better model

Start the next test really low speeds and if in doubt let it run over night.
If that turns out much better check / increase the current for the motors that cause the shifting.
Check that your threaded rods are straight and don't wobble, also that all bearings move freely over the entire length of the axis.

I'm running another print right now, and this time I have 3 movie cameras on it so I can capture at the moment something goes wrong (if it does, with my luck it'll print fine this time! )

The board supports endstops but the printer didn't come with them (since this is a project-type printer they don't include things like that!) But I have some switches on hand to add them later on (and recompile the firmware to enable them at that time too) ...

The firmware is Marlin, the board is a RAMPS 1.4, and yes I'm using Slic3r (and repetier host)

The current print has been going for nearly half an hour and is flawless for the moment, we'll see what happens! If it screws up I'll be trying other options such as slower print, more distance (I print at 0.2 per layer) so fewer G-code commands on the wire might help too...

Maybe you're having a USB communications problem. Does the printer have an SD card reader? If so, try it and see if that solves the problem.

Shortly after I started 3D printing a couple years ago I was taught a hard lesson about the reliability of computers sending gcode to printers for hours at a time. Since then I have been using SD cards exclusively and I don't have that sort of problem any more. Yes, sneaker netting SD cards from the slicing computer to the printer is a little bit of a PITA, but not as big a PITA as failed prints due to computer issues.

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

That was precisely why I mentioned in my earlier posts, to get the CardReader on line, to eliminate that as one of the issues .... (my board doesn't presently have one, but the pinouts are there, simple purchase, can-do!) I have heard a lot of issues with the usb linkup. I tried to resolve this best I could with what I have on hand (dedicated laptop) ... but USB over 5 hours of printing? definite chance for failure!

ANyway, current news, the print this time around worked! There was a very minor shift on the Y plane (unlike before where X was off by 25mm! -AND- Y was off by about 10MM in a deadpan instant) ... so I am now strongly thinking this is a usb problem

It makes me wonder why everyone jumps to "use an SD card" as soon as there are any print issues.
If your car has starting problems in the cold, do you replace the engine right away?
Back in the day we had no USB, WiFi or other fancy things, if you wanted to communicate with another device you had to make sure everything is set right.
For startes there is a status window or log file that could and would show problems.
Usually brings something up like "unable to communicate... force continue".
In severe cases the printer becomes totally unresponsive.

If stuff like that happens only when using a USB connection there are really only two possible reasons for it:
a) There is a power problem.
If the power supply is faulty, like loose connections, cold solder joints and so on, the printer will try to get the power it needs over the USB connection.
As the PC can not supply enough the driver for the USB port shuts it down to prevent damage.
b) The serial port for the printer is not configured correctly.
Although people tend to think USB means all is automatic, the properties for the serial communication still can and in many cases should be adjusted.
For example the default baud rate - most computer porst won't support 25000 baud as it is a very unusal value but the default for most printers.
Or take the buffer size - too low and you get overflows, too low and the communication can struggle.
Even worse for the flow control - most printer boards don't support the buffering of data or only have a tiny cache for this data.
That means the settings in Windows must match what the board supports and what is configured in Marlin / Repetier.
Only if all is a match the USB communication will work without hickups.
I do 24h+ prints over USB while surfing the net, downloading files and or streaming videos to the TV, so why exactly would I need a SD for this?

I didnt jump to using an SD card as one of the immediate answers, I've just heard it's a good thing to do when there are potential problems. THere's a lot of good reasons for going that route. USB means a line to a remote computer, house wiring, clitches, all of which are potential points of failure. The best way to solve a problem is to eliminate points of failure, and USB is a significant point of failure! Especially when you're talking about four hours of uptime!

So, now to get to where I was ... the print, this time, worked! There was a very slight problem on the Y-table, about 1/2mm ... ... so, now I'm of the mindset to get the SD reader, this was a 6 hour print, and that's the best course of action right now to reduce future problems.

Getting back on the USB thing, I have a laptop running the software, so the laptop is self-powered, ... The printer doesn't have a battery backup, and the entire house is 'potentially subject to glitches' on a scale I don't have the abilit to measure. I'm a process kinda guy who works on the simplest solutions, if at first you dont succeed, try try again, and eliminate all potential problems along the way. ... Today's print worked! What that TELLS me is the software is fine! 'the exact same problem' did not repeat itself, therefore, eliminate other problems!

Whilst I agree with you about removing possible causes of failure, I disagree that USB is a significant issue. Continuous connections of 4+ hours are no more difficult than 4+ minutes, so long as no-one is jiggling the cables. I haven't yet used the SDCard reader on my printer.

And, whilst I think you're right that the software is fine, that's not 100% guaranteed. In real-time systems, the software runs in different ways, depending on external factors. So 'faulty' software may run OK one day, but not the next.

Glad to hear that this print worked OK. The obvious question is "What was different this time (apart from the cameras)?" NB: The answer "Nothing" is incorrect... something must have changed. It may just be that you don't (yet) know what. Maybe you moved the printer to make room for the cameras? Which maybe jiggled a loose wire or USB connector?

The printer is clamped down to a tabletop via a pair of vicegrips, so it has not moved. (I plan to rectify that soon and have it bolted down to the tabletop properly, but for now, that does keep it steady!) The laptop that controls it all is a dedicated system running nothing that it doesn't strictly have to, -but- it's windows 10, so who knows what goes on in that ugly little brainchild!

I have it set to never turn off, never go black, never sleep, never even wind the hard drives down ... But I do monitor it through teamviewer (hence one possible point of failure... I also discovered the other day that I have to have 'show filament' turned off, or things really went sour after about 30 minutes in to a print!


... and now after a few hours of sitting there doing nothing, repetier has decided to lock up! (Oh and another point of interest, this isn't the first PC that was attached to the printer, the original print failure occurred when a completely different computer was in control!)

I am liking the approach of slowing the print down most of all right now. I don't care if it takes an extra hour to print, and watching it deal with infill and the way it tries to shake itself apart handling support structures scares me!

Oh and another point of interest, somewhere down the road I plan to be rebuilding this from the ground up. Already working out the designs for it. (All the primary parts of it are made of melamine, of all things!) I bought the threeup cuz it has two steppers handling Z, and the heated bed as well, (Basalt) cuz right off the bat I knew a melamine bed was not gonna last longer than a few days at best!

What are your com port settings in Windows, including the extended ones?

It defaulted to Com3 ... and I have experienced a few red flags in the communication where it had to resend a line once or twice, but during those occasional resends the print never had a problem.

The port is defined as Arduino Mega 2560 (Com3) Port_#0001.Hub_#0006 9600:8:N:1, no flow control, using both xmit and rcv fifo buffers (16550 compatible)

The installed driver is from Arduino LLC, version 1.2.2.0

I was talking about things like baud rate - both in marlin and Windows.
And of course what is hiding in the advanded section of the com port settings - they should be identical.
I don't have the english settings but it is for the plug and play and RTS - both should be ticked, you can also adjust the buffer size for the USB communication there, I used 4096 here...

Well, things get a little confusing here, since the driver says 9600:8:N:1 but the software says 250,000 baud. I could drop it to 115,200 but first experimenting with slowing the printrate down a bit. ... I don't often make big prints, at least not yet, so I won't really be able to give good test results until I do!

So, I'd like to thank everyone for all their help and input! It's been informative and instructive, and useful!

Well if there is a mismatch already in the standard settings than I am almost certain the extended ones won't be much better.
You should check what speeds are supported in your Windows, match the highest speed there in the firmware and last but not least set this speed in the print program as well.
If you also check the extended settings and make sure they match the needs of your board all should work just fine.
The last connection problem I had was about 4 rolls back and caused by some idiot installing new drivers without checking LOL

Another thing to look for in higher-height shifts, is warping which caused the top to hit the nozzle.

If the printer is shaking itself apart, try lowering your acceleration and jerk values. It should be able to print anything at ANY speed without being violent. The higher speeds will only be noticed when it can reach it without violating the acceleration or jerk parameters (long, straight lines are always the fastest).

---

Master Tinkerer