Slow Z movement returns!

[Jimustanguitar]

OK.... I reported a few months ago that when running a print over USB from Repteier that once in a while the axes would home at normal speeds and then super slooooooooowly move down as the first move of the print. Like multiple minutes to get down to Z0 slow. I had some scatter brained observations based on random chance and hurried troubleshooting, but eventually found out that it didn't really matter which slicer I used or anything else like that, it just randomly would happen. (happens printing from SD too, if you're curious) Rebooting the printer and clicking "run job" again or printing the SD file on the LCD almost always works the second time.

The consensus from that thread was that I probably needed ferrite cores on my LCD ribbon cables to sort out the EMI sorts of flukes and anomalies that are possible in unshielded ribbon cables. I believe the cores have been prescribed for the "it just stopped printing" phantom as well. Anyway, I haven't done that yet and have just come to accept that it happens once in a while, and it's probably a very specific "me only" kind of thing like cable routing.



The plot thickens.

A good friend of mine bought a Rostock kit last week and put it together by himself over the holiday weekend. I showed up to help him for the last few steps, and his printer did the exact same thing. We had a dead LCD which John helped us with in his own personal time over the holiday weekend (extra props to John!), so we had the LCD cables completely out of the machine when we were observing the "slowness glitch".

His machine is also considerably different than mine. He has the newest Rambo, one version newer firmware, used his own laptop, had a virgin install of everything from the download.seemecnc.com website that day, and is running Windows 7-32 instead of 8-64 like me... We also live in different parts of town on different utilities... I can't think of something common between our two scenarios except the printer itself and the software we're using.



Any idea what the common denominator might be? I'm stumped because it really doesn't seem to be an environment specific thing, you know?

[Eaglezsoar]

The common denominator is that you touched both machines.

Seriously, I would like to know what the 12v looks like when it is moving like that.
I know that it is a random occurrence but is it possible to put a voltmeter on the 12v
and keep it on until the event occurs then observe what the voltage is? Just a hunch.
A small dedicated voltmeter can be had inexpensively and you can leave it in place
long enough to catch the voltage when it is needed.

[Jimustanguitar]

The common denominator is that you touched both machines.

True. And I am kind of slow

Seriously, I would like to know what the 12v looks like when it is moving like that.

This reminds me of another good point. The two machines have different power supplies. Felix's new Rostock has the one that ships with the kit, and mine died twice so I've got a different ATX with more current on the +12v rail.

As far as taking a measurement, since it takes so long to move I can just wait until it does it again and get the meter on it then. What's your train of thought, do you think I'm hunting for a consistent voltage difference, or should I have a meter on it constantly to watch for a blip?

[Eaglezsoar]

As far as taking a measurement, since it takes so long to move I can just wait until it does it again and get the meter on it then. What's your train of thought, do you think I'm hunting for a consistent voltage difference, or should I have a meter on it constantly to watch for a blip?

I would just like to know what the voltage is when the problem is present. I have a hunch is not going to be 12 volts but let's wait and see.

[Lochemage]

I don't know if this is the answer to your problem, but if you issue a G1 move command but don't supply the speed value (e.g. G1 Fxxxxx) before or on that move command, the default is to move extremely slowly. It's possible that your gcode slicer doesn't set the speed at the start of the print, so it is using whatever speed it was set to last. This doesn't quite explain all the problems you are getting, but it may give you better results if you add something like "G1 F2000" at the start of your gcode.

[johnoly99]

Lochemage BAM! you guessed it, I'll bet.


Jim, check your startup Gcode, and see if there's any Fxxxxxx after anything there? If not, put an F12000 line at the top. Also, check your Repetier Host printer settings, the printer tab, Z axis speed might be set really low. So, if you 'jog' the machine, it stores that feedrate, then when you start a print, it prob. does the z move at that speed since it hasn't seen another F command since. Many G/M codes are "modal", or they are persistent until the next is seen, so if you typed F12000 once, and never issued another F command, it would execute all G1 moves at that feedrate


Lemme know what ya find out, curious as well