X "Walking" .3mm with each layer?

I just finished my new dedicated machine (I had been printing via my CNC which was incredibly slow (and hard on the machine)). I am super happy with the results, a super-solid, welded steel frame with plenty of cnc-milled Lexan parts. Some of my better work if I do say so myself.

Here is a video show and tell and my first test print.
http://www.youtube.com/watch?v=Bb4icBq6Ay8

Everything seems to be in order, I have my steps figured out and a MM is actually a MM. Ultipanel is dialed in and and works great. In fact, everything seems to be 100% --With the exception of the fact that my X seems to be walking its way to the left a little each layer.

I did some measuring, and it looks as if the print is walking .3mm to the left each layer. The final print is slanted exactly the same amount as its height. I don't feel as if I am loosing steps --unless of course, I am loosing a perfectly-equal number of steps each layer. I mean, the "walking" is so even, and so consistant, that I would be surprised if it were mechanical or a "lost steps" sorta issue.

At first, I thought this was an issue with the Ebay-cheapie drivers I am using. They are a little "buzzy" when at rest so I changed in the firmware to disable the steppers when at rest --My assumption was that the drivers were being "reset" when enabled/ disabled and thus, were gaining or loosing a step during each "start-up". I have changed this, and it seems this is not the problem. At this point, I am out of ideas.

Oh, I am using Marlin, Pronterface and Slicer.

It really does look like lost steps.

Check to see if the drivers are getting hot and going into protection mode for a split second. This would give you the same loss every time as it turns off for almost the exact same period of time each time it turns off.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

The drivers are cool as can be. They are rated at over 3 amps and I am only drawing 1.2A or so. Beyond that, I am using NEMA 23's that are probably in the range of 150-200 oz/in --I mean, we got plenty of driver, and plenty of motor.

If indeed it is lost steps --would you have any thoughts on why it is so even and better yet, how to fix it? --Heck, I would settle for simply a way to test it. I have thought about putting an O-scope on it, to monitor steps going in, and steps going out to the motors, but I only have a 2-channel scope --I could only watch one of the signals going to the motor --dunno if it would tell me what I want to know.

It's either the driver overheating, or there is enough mechanical resistance/inertia in the X direction to cause the stepper to stall.
This could be because the driver is set too low and putting out marginal torque.
It could be that your X-Table is over constrained and the asymmetric pull causes it to skew very slightly as motion on a layer starts causing it to momentarily have much higher resistance.
If it's the latter try turning down acceleration if your firmware supports it.
You can usually hear a stepper miss, it sounds like a clunk or a loud tick, but if it's at the start of a layer you might not hear it because of the noise from the Z motion.

Can I just say, that is a beautiful looking printer!

Here's a few troubleshooting tips:

Try switching your x and y axis stepper controllers to narrow down the problem. If you still get the error on X, it's mechanical, if it moves to y it's electrical or software.

Make sure you have marling set to not check endstops while you're printing, as noise can make false triggers.

Move the print to a different part of the table.

Print bigger/smaller/pyramid shaped and see how the error looks.

---

--
-Nudel
Blog with RepRap Comic

Hey thanks, Nudel

Yup, I swapped the drivers and I can replicate the same effect. Also, the affect does not move to the other axis when swapped. I will try the endstops thing as well as trying to start with a different origin.

Also, @Poly --I slowed everything down to a crawl, accel to 100, and overall printing speed at 50% (via the ultipanel). I am printing very, very slow. Again, same results.

I am getting a feeling like I am missing something very, very simple here...

Swapping the axis with no change implies it's mechanical, or I guess possibly a weak stepper, or I guess possibly noise.
Can you hear or feel the stepper miss? It would be useful to know where in the layer is misses, start end middle, corner etc.
I'm assuming when moving things by hand there is no obvious binding?

You have 4 what I assume are either LM8UU or LM10UU bearings rigidly coupled to the X axis, that makes it very sensitive to bearing alignment, I had problems with a design when the drive belt pulled asymmetrically. While it all appeared to move smoothly when pushing it around by hand, when motion started from a dead stop, the initial impetus caused the carriage to skew very very slightly which caused the bearings to bind and the steppers to stall. In my case it was the Y axis, and there was enough flex in the design that it was only apparent at relatively high speeds and accelerations, but it might be what's happening here. You can simulate it with the belt off by giving the X Carriage a relatively sharp push at the point where the belt mounts and see if you can feel increased resistance.
You might try temporarily removing one of the bearings on the none driven side this might alleviate the affect if it is related.

I'd like to reiterate Nudel's suggestion of printing on different parts of the table, to see if you see the same effect, if not it could be something binding in a particular location.

More info:

Well, we did a different part of the print table with the same results. Here is a video:

http://www.youtube.com/watch?v=eSytf1cMvnc&feature=youtu.be

I think the next thing is to swap X and Y signal wires, but not motors. I will simply swap my X and Y --The table will become X and the gantry will become Y. If I can cause the same slant, but on the Y axis, I can then eliminate mechanical, I think. Beyond that, I guess that would prove it is pre-driver and thus, in the Arduino, wiring, slicer or host software.

On the other hand, you guys are all correct --this is screaming "lost steps" in terms of the problem, but I am just not seeing it. --Take a look at the video.

And still some more...

I just swapped my X and Y axis and I can cause exactly the same problem using the mechanics of the Y axis. It is identical whether I use the sliding table as my X or if I use the gantry as my X. So far, I have swapped/tested each driver, each stepper and mechanics of each axis.

Looks like it is not mechanical. It also seems like the problem is not wiring either (a loose connection etc. would not be this consistant)

I suppose it has to be in the firmware, host software and or slicer.

Again, I am open to any thoughts

I think unless you're using something really esoteric I really doubt if the issue is in the firmware/slicer/host software.
If you use something like repetier host you can preview the sliced file, and rule that out.

If the error didn't change directions when you swapped drivers etc, I would say the one thing you haven't ruled out is it being mechanical, or am I misunderstanding your description?

I would agree, it would be amazing if this were an issue with slicer, pronter or marlin. However, in terms of mechanical...

The issue started on the X axis (gantry axis) and slowly stepped to the "-" side each layer. When I swapped out the driver, the issue was identical (thus, not the driver). When I tried to print on a different portion of table (thus, different part of the rods and belt) the issue was identical. Then, when I swapped the axis, and made the table into X and the gantry into Y, the issue was identical, but now slanting allong the axis of the sliding table. If this were a mechanical issue, then that mechanical issue exists on both the mechanics of the gantry and the mechanics of the table. I should mention that the issue is IDENTICAL whether using the table as my X or the gantry as my X --Thus, unless the mechanical problem exists (in exactly the same way) on both systems of glides. That would be a pretty big co-inky-dink.

Ok then I misunderstood the description and it's likely not mechanical.
I assume you've tried slicing/printing something else?
Assuming you swapped the wiring bewtween the microcontroller and the drivers to swap the axis, it could still be a noise problem or an electrical problem before the drivers.
Without a scope or replacement hardware that's hard to test.

It's probably easier to try a different firmware and rule that out.

Yup, I was afraid of that...

I remember fighting through different firmwares when I was printing with my CNC. Ugg

At any rate, I appreciate everyone's help on thinking this one through, I think I just have some good ol' fashoned tinkering time ahead of me.

Thanks, guys.

Try printing the part twice the size. If it displaces twice the amount on each layer, the error accumulates as it's printing the layer. Bigger layer = more errors. Then it's likely a noise issue. You could also try out the default sprinter firmware to weed out that issue.

If the walking errors are the same and each of the layers come out fine, the issue appears as you move from one layer to the next. This implies noise from when the z motors activate. Are they always on, even when idle? How's the z acceleration? Either way, I'd double check every connection and soldering point on the offending stepper controller. You could try beefing up the grounding cables, but it's a shot in the dark.

You can also try to switch the z stepper controller for the x. I don't know the drivers you're using, but a faulty driver is not uncommon.

Good luck!

---

--
-Nudel
Blog with RepRap Comic

Other thoughts.
You could try changing the I/O pins on the arduino that you're using to drive the bad axis.
Personally I'd re run the wiring for that axis as well.

If you are using normal CNC drivers it is quite likely the step pulse width is too small or the setup and hold time of the direction signal is too short.

I got a similar effect when I had my step signal the wrong polarity so it changed too close to setting the dir signal.

Reprap firmware is designed to drive stepper motor chips directly. Often CNC drives have opto couplers which slow everything down.

Edited 1 time(s). Last edit at 05/12/2012 03:33PM by nophead.

---

[www.hydraraptor.blogspot.com]

Thanks guys,

I had a moment of clarity last night when I noticed that we seem to be walking exactly the same distance as we are moving up on the Z. --Z is moving up .3mm (approx) each layer and what do you know, we are also walking about .3mm on each layer.

Seems to me that I have some Z "bleeding" into my X. I mean, the math would be there for that theory.

Ok, for today, I am going to do the "print twice as big" thing, going to try swapping pins on the Arduino and finally, I will probably re-wire the X axis.

I think we might be running out of things "it could be".

Fixed. I guess...

It was firmware. I am running Sprinter now and all seems right in the world. Of course, this means I have lost my fancy-schmancy LCD and encoder wheel, but I am getting prints going straight up now.

Now I have to figure out if I want to go back to Marlin and see if I can find the problem (I am thinking more now about float rounding problems) or if I want to just suck it up and stick with Sprinter. Ugg.

I cannot tell you guys how much I appreciate your help on this one.

Chris

It probably is the pulse timing then. Sprinter gives shorter pulses on the X axis that it does for Y, which is shorter than Z and so on.. Marlin may well be shorter still.

---

[www.hydraraptor.blogspot.com]

Do you think this would be as easy as just adding say, a 1 or 2 uS delay in the code after the high/low step? The Mach3 software I use for my mill has this "elongated pulse" option standard, I wonder if I can replicate this lengthened pulse by doing the above.

Don't get me wrong, I am very happy to be printing again, and I am stoked to start work on the proper build table and to start getting things dialed in for good prints --that said, I sure do want my LCD back.

Glad you've got it working.
Interesting info about Sprinter/Marlin and I assume the other derivatives, I wouldn't have guessed that and I've never put a scope of the signal pins because I've never had an issue.

Sprinter looks like this:

void do_step(int axis) {
  switch(axis){
  case 0:
    WRITE(X_STEP_PIN, HIGH);
    break;
  case 1:
    WRITE(Y_STEP_PIN, HIGH);
    break;
  case 2:
    WRITE(Z_STEP_PIN, HIGH);
    break;
  case 3:
    WRITE(E_STEP_PIN, HIGH);
    break;
  }
  steps_taken[axis]+=1;
  WRITE(X_STEP_PIN, LOW);
  WRITE(Y_STEP_PIN, LOW);
  WRITE(Z_STEP_PIN, LOW);
  WRITE(E_STEP_PIN, LOW);
}

So X gets a shorter pulse than the others.

Marlin looks like this:

      if (counter_x > 0) {
        WRITE(X_STEP_PIN, HIGH);
        counter_x -= current_block->step_event_count;
        WRITE(X_STEP_PIN, LOW);
        count_position[X_AXIS]+=count_direction[X_AXIS];   
      }

      counter_y += current_block->steps_y;
      if (counter_y > 0) {
        WRITE(Y_STEP_PIN, HIGH);
        counter_y -= current_block->step_event_count;
        WRITE(Y_STEP_PIN, LOW);
        count_position[Y_AXIS]+=count_direction[Y_AXIS];
      }

      counter_z += current_block->steps_z;
      if (counter_z > 0) {
        WRITE(Z_STEP_PIN, HIGH);
        counter_z -= current_block->step_event_count;
        WRITE(Z_STEP_PIN, LOW);
        count_position[Z_AXIS]+=count_direction[Z_AXIS];
      }

      #ifndef ADVANCE
        counter_e += current_block->steps_e;
        if (counter_e > 0) {
          WRITE_E_STEP(HIGH);
          counter_e -= current_block->step_event_count;
          WRITE_E_STEP(LOW);
          count_position[E_AXIS]+=count_direction[E_AXIS];
        }
      #endif //!ADVANCE

So all pulses are the same and a bit shorter than Sprinter. Simply moving the low write to after the update of count_position might be enough to make it the same as Sprinter.

Edited 1 time(s). Last edit at 05/13/2012 06:33AM by nophead.

---

[www.hydraraptor.blogspot.com]

Interesting, the counter change in marlin is going to be of the order of 1-3 clocks, so you'd end up with pulses in the low 100s of ns range assuming WRITE_E_STEP is just writing to a memory mapped location, which is really short compared to what something like Mach3/EMC would put out for a mill.
I just looked and the drivers on my mill are specced with a minimum pulse width of 2.5us or 2500ns.

Since Sprinter appears to work I think your suggested change to Marlin would actually provide a longer pulse than sprinter so it's worth a shot.

I wonder what the spec for Chris' drivers is?

Interesting indeed.

I will put a O-scope on the output for both Marlin and Sprinter and I will tell you my friend, exactly how long those gosh-darn pulses are. Well, I mean I will get to it... At this point, I simply have a working machine and I just want to use the darn thing! I have been doing a bunch of test prints and trying to get things dialed in, so far with fantastic success. To put it simply, I am currently distracted by a shiny thing --forget the problems of the past.

Here is your update, guys --Its a good one.

http://www.youtube.com/watch?v=UYBbkfThmOM&feature=youtu.be

Oh, and specs for the driver? Um, yeah --I think there is one, single, EE in Shenzhen who designed the board and thus knows the specs of these drivers. For the other 99.99999% of the world, we just shell out our 17 bucks to ebay and hope for the best. --Joking aside, I am sure I could unbolt the heat sink and find out what chip is in it but again... ...distracted by a shiny thing.

Solved and solved. AND I GOT MY MARLIN BACK!

Once again, I can not tell you guys how much I appreciate your help on thinking this one through. It is a real blessing to be part of so many open source communities. Sharing and helping are good things.

Alrighty -- Yes, I was loosing steps. However, I was not loosing steps via the motors actually "slipping" or "skipping". Instead, it was a simple matter of the pulse width coming from the Arduino (and Marlin firmware). We had arrived at this earlier in this forum thread, but I can now confirm this with data. I finally got around to getting a scope/ logic analyzer on one of my drivers. I was able to monitor the pulse going into the driver (via the O-scope) and also the 4 outputs going to the stepper (via the logic analyzer). I could see each step being sent clearly, but I did not always see a corresponding change in the 4 bits that were showing me the state of the motor coils. Put simply, the pulses were just too quick for the drivers to catch.

You wanna know what I did? --I made them longer (and it could not be more KISS than this...)

delayMicroseconds(2);

That's it. I simply added a 2/1,000,000 second delay and all is right in the world. The walking is simply non-existent. I can see no noticable change what-so-ever in the function of the firmware with this tiny delay added. I have also repeated my original test (scope/logic probe) and, I can confirm the fix. Oh! It is SOOOO nice to have my LCD, encoder wheel and on-the-fly adjusting back.


On a side note, I should mention that I also got around to finishing my heated bed. I milled my own PCB(s) and (because God loves me) I got pretty darn close to the resistance I wanted. I now have (2) 6x9 PCB's for a total heater size of 9x12 (230x300). The machine is actually capable of 14x14x16 (350,350,400) but for now, I think 9x12 should do me just fine. The final specs for the heater come out to 1.8 ohm @ 24v = 13.5 A and 320 watts. Not too shabby.

Thanks again guys.

It would be nice if the pulse width time could be set in the configuration.h file. I have an extra CNC controller that I am thinking about using for a 3D printer I'm building right now. I had a similar problem with a board I bought on Ebay that came from China. The problem with that board was that the opto couplers were too slow and made the square wave look like a triangle wave so at faster speeds it lost a lot of steps.

http://www.kwartzlab.ca/2011/06/taig-milling-machine-stepper-motor-and-controller-upgrade/

Could you please indicate where in the Marlin code you inserted the delayMicroseconds(2) ?
Thanks!

i would be tempted to say you timing pulley is slipping i would rough up the surface of the shaft and put the timing pulley back on and tighten it right up, also i'd get those belts nice and tight (springy), i'd also be tempted to print some abd timing pulleys anf press fit those on instead, how much current are you putting into those steppers?

I am having the same issue, (although I was printing fine and it just suddenly came up out of the blue), but I'd like to try adding a small delay too. +1 for finding out where in the code you added it.

Thanks,

Steve

Hey guys, sorry for the delay.

I have been a bit swamped with orders --I gotta do stuff that feeds me before I get to go play with printers.

Okey dokey, the delay itself was added to the actual HIGH/LOW step command. This can be found under the "Marlin" tab in some versions and under the "stepper" tab in some other versions. In either case, you can usually find what you need by doing a "find" search for "HIGH". Eventually, you will find something that looks like this:

if (counter_x > 0) {
WRITE(X_STEP_PIN, HIGH);
counter_x -= current_block->step_event_count;
WRITE(X_STEP_PIN, LOW);
count_position[X_AXIS]+=count_direction[X_AXIS];
}

There will be similar routines for each axis. My delay-added version looks like this:

if (counter_x > 0) {
WRITE(X_STEP_PIN, HIGH); <-- this is the actual step
counter_x -= current_block->step_event_count; <-- this is the code "counting" steps
delayMicroseconds(2); <-- this is the added delay to make the step pulse longer
WRITE(X_STEP_PIN, LOW); <-- end of the step, back to low
count_position[X_AXIS]+=count_direction[X_AXIS]; <--more counting stuff
}

I should also add that this whole problem stems from the fact that I have a habit of reinventing the wheel. Reprap and all of its cousins, has been pretty much figured out. In hind sight, I would have been better served by simply replacing the "standard" reprap frame with my beefy welded-steel assembly and called it good. Instead, I felt the need to upgrade to really over-sized motors and thus, really big drivers. These drivers, unlike any "standard" reprap driver you could use, includes opto-isolators. These opto-isolators are basically a LED and a photo sensor (facing each other) inside of a little chip. These are handy in that the thing that is sending the signal and the driver itself are completely isolated from each other. There is no chance for noise to backfeed and no problems with any kind of "surge". The problem is that the LED's and sensor take a little bit to physically turn on. Sure, we are talking millionths of a second here, but still much longer than what marlin and the arduino are spitting out.

Although, adding this delay solved my problem, I have now found that when I print, there is a "sweet spot" in terms of the final printing speed. (I use a ultipanel and thus, can speed up or down while printing). Even with the "fix" in the code, the walking effect can return if I simply print too fast or even if I print really slowly. Put simply, although this does indeed "fix" the problem, a FAR better fix would be to use the proper drivers in the first place. And on those lines, I am doing just that. I am in the process now of converting to more "standard" drivers.