Stepper motor issues?

Shop › Forum › Makelangelo Polargraph Art Robot › Stepper motor issues?

Tagged: , , ,

Viewing 25 posts - 1 through 25 (of 26 total)
1 2
  • Author
    Posts
  • 2015-12-26 at 10:33 #8822
    Anonymous
    Inactive

    I purchased a M2.5 about a year ago and drew some cool pictures for my wall that came out great (https://drive.google.com/file/d/0B8pvUsBJ13P6cGF2ejBaSEczVEZ5X1Jjc2Z5ZW5GSUVTOVdZ/view?usp=sharing). Then I put it away for several months and recently got it out to do some more drawings. I had to reinstall the software on a new laptop, and am using V5 (V7 installed and connected, but the dialogue for editing the machine size wouldn’t pop us so I couldn’t use it). I’m using Windows 7, and have Java 1.8 installed.

    Anyway I’m having a problem – it appears that the steppers aren’t moving the pen holder accurately in the Y direction (see part of a drawing I started with big zig-zag that should make the issue clear: https://drive.google.com/file/d/0B8pvUsBJ13P6Rzd6Mzd2Nm93YVZMWi05aldQaUxTSG53emdv/view?usp=sharing). I also think I hear the steppers skipping (clickity-clackity sounds intermittently coming from the stepper motor when it’s drawing). Are the motors shot? I’ve tried slowing down the steps/min but it hasn’t helped. Any other troubleshooting ideas I can try? I’ve checked (and re-checked) all connections to the motor shield.

    One last mystery that might or might not be related to this, when I load an image (or even generate the hilbert curve, it shows up misaligned relative to the center of the paper (see: https://drive.google.com/file/d/0B8pvUsBJ13P6cVNpeGNJcmZaYnpGd3pMLWllTUU1V3N2ODBN/view?usp=sharing).

    Sorry for the multi-part question, typing it out made me wonder if I have a couple different issues interacting here. And thanks in advance for any help!

    2015-12-26 at 13:55 #8824
    Anonymous
    Inactive

    Sorry I don’t know what your problem is but those old pictures are fantastic

    2015-12-26 at 14:10 #8826
    Dan
    Keymaster

    I audibly “wow”ed at those pics.

    Did you update the makelangelo-firmware? Often it’s best to pair the firmware and software.

    Picture showing up in the wrong place sounds like a configuration error.

    Do “jog motors” work OK? It should make short movements in both directions.

    I’ve had stepper motors sit without being used for years and work fine when I turn them on. The only reason they’ve ever failed is a broken wire. I’m not convinced yet that this is the problem here.

    2015-12-27 at 05:37 #8828
    Anonymous
    Inactive

    Thanks Dan!

    Jog motors appears to work well, in/out go in the correct directions. The X, Y +100, -100, buttons are hit and miss – I’ve moved the pen around with those a lot and sometimes they have appear to work appropriately, and other times the pen moves diagonally when it should move horizontally or vertically, suggesting that one of the steppers isn’t turning correctly.

    Thanks for the idea about the firmware. Now that I think about it I have the firmware that came with V7 installed, as I was playing with that before downloading V5 because of the machine size setup dialogue issue. What do you mean about configuration error? Would that be caused by the firmware?

    I’m at work today, but will test the firmware that came with V5 this evening when I get home. Thanks again!
    -Lex

    2015-12-27 at 18:24 #8835
    Anonymous
    Inactive

    Hi again,
    Still no luck, I downloaded the software and firmware that’s linked here:
    http://learn.marginallyclever.com/index.php/Makelangelo_2.5
    The firmware compiles and uploads, but the software still does the misaligned thing with photos, as in my previous image. I’m not sure if is related to the drawing problems it’s having, but it seems like a good starting point to get that back in alignment.

    I also tried the firmware here, which also compiled and uploaded, but acts the same with respect to that misalignment in the software:
    https://github.com/MarginallyClever/Makelangelo-firmware/releases/tag/1.0.2

    And I downloaded V7.1 from here:
    https://github.com/MarginallyClever/Makelangelo/releases/tag/v7.1.0

    Also was able to install compile and install the firmware but still have that same misalignment issue with V7.1 (see: https://drive.google.com/file/d/0B8pvUsBJ13P6cUg0Y2ZvUmZNTTlibV9ULTFoRlczLXo0SjlZ/view?usp=sharing). Any clue what might cause this?

    I also have weirdnesses in manually driving the X and Y around. Such as, when I click Y -100 several times it sometimes starts in one direction (moving vertically up), only to then turn around and go the other way if I keep clicking the same button. I have Adafruit Motorshield V1 BTW. Any other troubleshooting ideas?

    Thanks again for your help! -Lex

    2016-02-01 at 06:04 #8870
    Anonymous
    Inactive

    I am having a similar issue. All my drawings shift ~1cm on Y axis mid drawing. This is very frustrating when you waste 2 hours, just to have the entire drawing shift and ruin it.

    I am running over-sized NEMA23 steppers, so I seriously doubt I’m losing steps due to binding, etc. I have tried tweaking acceleration speed ect. But all that does is make drawings take longer before it shifts.

    Also this seems to happen the most on DXF drawings. Pulse and scan line rarely do this. I have also tried also raising the current and/or voltage to steppers which only caused more heat.

    I have tried different microstep values, but nothing has helped.

    Anyone have any ideas?

    I am running newest firmware(rumba) and 7.3.0-alpha.

    Thanks

    William

    2016-02-01 at 07:24 #8872
    Anonymous
    Inactive

    Here is an example of the issues I am having with DXF. This 10 min drawing resulted in a 3cm Y, and 1cm X error. However I can do a 3 hour pulse line without a single error.

    Example PIC

    Doing a go home after the drawing finished showed a 3cm Y, and 1cm X slip. But I do not think this is mechanical, as this error does not happen when I do scan line or pulse line. Only DXF.

    Regards,

    William

    2016-02-01 at 08:17 #8873
    Anonymous
    Inactive

    One other note, I just reran this exact image 3 more times. Each with a different speed. Each time I closed the software and reconverted the DXF. All three drawings came out EXACTLY the same. The errors were in the exact same places. This must be an error in the software, as mechanical stepper slipping would be random. This is not random.

    Hope that helps.

    Regards,

    William

    2016-02-01 at 12:23 #8874
    Anonymous
    Inactive

    I took the gcode from this drawing and simulated it a gcode simulator. There is no issue with the gcode, so the issue is in the machine itself. I am at a lose as to how I get the exact errors every print. Just for fun I printed a 1 hour scanline drawing with zero errors, than tried to reprint the DXF drawing. Once again the errors are in the exact locations as the previous 3 attempts.

    It appears to be a gradual error in the Y axis. Its almost like some calculation is dropping a decimal point causing calculation errors to get worse over time.

    I think this error exist in all drawings, but scan/pulse line drawing it doesn’t show up. Maybe this is because every gcode line is gradually increasing Y axis, where as DXF jumps around the drawing drawing lines. This math error could explain why its the exact same every time.

    Hope any of the above helps.

    Regards,

    2016-02-02 at 09:15 #8876
    Anonymous
    Inactive

    I did a new test. I created a incremental positioning gcode (using G91). Running this gcode 10 times produces zero error.

    G91;
    G00 X100 Y100;
    G00 X-100 Y-100;
    G00 X100 Y100;
    G00 X-100 Y-100;
    G00 X100 Y100;
    G00 X-100 Y-100;
    G00 X100 Y100;
    G00 X-100 Y-100;
    G00 X100 Y100;
    G00 X-100 Y-100;
    G00 X100 Y100;
    G00 X-100 Y-100;

    Running the same gcode with absolute positioning (using G90) 10 times, each results in the same amount of error each time.

    G90;
    G00 X100 Y100;
    G00 X0 Y0;
    G00 X100 Y100;
    G00 G00 X0 Y0;
    G00 X100 Y100;
    G00 G00 X0 Y0;
    G00 X100 Y100;
    G00 G00 X0 Y0;
    G00 X100 Y100;
    G00 G00 X0 Y0;
    G00 X100 Y100;
    G00 G00 X0 Y0;

    So this shows the steppers are not losing any steps. The error in the G90 example must be in the calculations.

    Any ideas? Thanks

    2016-02-02 at 14:54 #8881
    Dan
    Keymaster

    The most relevant code would be in these two places:

    The bit that turns pulley diameter into ammount-of-belt-move-per-step:
    https://github.com/MarginallyClever/Makelangelo-firmware/blob/master/firmware_ams/firmware_ams.ino#L227

    The bit that turns (x,y) into (belt lengths left, belt length right):
    https://github.com/MarginallyClever/Makelangelo-firmware/blob/master/firmware_ams/firmware_ams.ino#L309

    They are identical in both the AMS firmware and the RUMBA firmware. Nothing obvious jumps out at me (like a nasty rounding error). Those blocks of code have not changed in a loooong time.

    My guess is that the newer compiler that comes with Arduino GENUINO is doing something funny.

    2016-02-04 at 11:33 #8887
    Dan
    Keymaster

    Please try this gcode and send me a picture of the results. It should draw a series of dots that demonstrate the drift. Does it happen if you go to the top left instead of the top right?

    G90;
    G0 Z50;
    G4 P50;
    G0 Z90;
    G4 P50;
    G00 X100 Y100;
    G00 X0 Y0;
    G0 Z50;
    G4 P50;
    G0 Z90;
    G4 P50;
    G00 X100 Y100;
    G00 X0 Y0;
    G0 Z50;
    G4 P50;
    G0 Z90;
    G4 P50;
    G00 X100 Y100;
    G00 X0 Y0;
    G0 Z50;
    G4 P50;
    G0 Z90;
    G4 P50;
    G00 X100 Y100;
    G00 X0 Y0;
    G0 Z50;
    G4 P50;
    G0 Z90;
    G4 P50;
    G00 X100 Y100;
    G00 X0 Y0;
    G0 Z50;
    G4 P50;
    G0 Z90;
    G4 P50;

    Edit: changed P1 to P50 because it’s milliseconds, not seconds.

    2016-02-05 at 10:02 #8888
    Dan
    Keymaster

    I ran this test repeatedly and did not get any deviation.

    After 10 back and forth’s I still had only one dot on the board. If there was drift it would have been anything but.

    2016-02-06 at 13:59 #8895
    Anonymous
    Inactive

    Dan,

    I ran your gcode ~ 100 times (Just replicated the gcode 100 times and let it run) and all I have is a 1cm sharpie dot bleeding at x0y0. But from what I can tell there is no drift.

    I changed home location and tried from a few different spots, the same results. No noticeable error.

    All the built in routines, produce great results (spiral/pulseline/scanline(have not tried crosshatch)). But DXF is where I run into issues.

    Thinking it might be my equipment I tried running on a RAMPS board vs my current setup. I even swapped the steppers for different models. The results were the exact same. All errors in the same exact places! This happens for every DXF I try (except easy ones).

    I would love it if you could try my DXF at A2 and let me know how it works for you.

    Here is the dxf https://www.dropbox.com/s/6zq8e2syp8ucmb2/r2d2.dxf?dl=0

    Please note I am running 1.8 degree 16 microsteps, so any error I get, will be double that of the .9 degree motors. Running at 8 microsteps caused my error to double. So keep that in mind.

    I have ruled out losing steps, as I get error with no load (belts off) and different drivers and motors.

    I’m at a loss, as I can print a 2 hour pulse line , but a 15 min DXF is all messed up.

    Regards,

    PS I got the reprapdiscount full graphics controller to work with the Ramps board. Its only showing xyz values now, but its a total rewrite, as its a graphic LCD, Not Character. I’ll post about that later.

    William

    2016-02-06 at 14:35 #8896
    Anonymous
    Inactive

    Here is the video after ~ 50 iterations. As you can see, no error I can see!

    Please try the DXF above and let me know.

    Thanks

    2016-02-11 at 16:57 #8930
    Anonymous
    Inactive

    Dan,

    Did you ever get a chance to try the DXF?

    William

    2016-02-16 at 12:09 #8950
    Dan
    Keymaster

    I finally tried the DXF. The code is fine afaik.

    Belt is skipping off the pulleys here, but I’m using an older model motor mount at the moment.
    Tomorrow I’ll assemble some of the newer mounts and try again.

    2016-02-16 at 13:07 #8951
    Dan
    Keymaster

    Oh, wow. Now I have to recount every tooth on every pulley in stock. Time to make a one-off robot to count them for me?

    2016-02-16 at 15:34 #8959
    Dan
    Keymaster

    I think I put too much water in the bottles, it’s pulling the pen up a little bit over time.

    2016-02-16 at 17:50 #8961
    Anonymous
    Inactive

    Yours is doing the same as mine, however your error is less due to 400 step motors. I initially thought it was the weights also, but I adjusted the weight many times and it did not affect final print at all.

    My guess is you could print it 5 times, and they all would have that pen pulling up the same amount.

    I have ruled out any belt slip issue.

    Like I said, I unmounted the motors, marked the pulleys, and ran the print. After the print was done I went to home position, and the pulley was not in the same position.

    I have ran several pulse line and scan line prints since without a single issue. But if I run this same DFX, the image always shifts up exactly the same is yours(a bit more I run 200 step motors).

    Willaim

    2016-02-17 at 10:20 #8964
    Dan
    Keymaster

    Hrm. I believe you.

    I don’t believe it’s DXF related. the DXF loader turns the DXF file into Gcode, and from then on it’s treated like all other drawings. The problem should be happening to all drawings.

    I need a simplified test case that demonstrates the problem. A 20 minute drawing is too long, and it’s hard to see where the error begins. Would you have some Gcode that does that?

    2016-02-17 at 10:45 #8965
    Anonymous
    Inactive

    No its not DXF relate I don’t think. I think it just shows up on the DXF. I think its related to the large gondola moves up and done the drawing. Its not optimized moves like a pulseline.

    I will work on creating a simple gcode to reproduce the problem when I get a chance.

    I too am baffled. I have tore through the firmware and debug logging, but have found nothing. Changed motors, stepper drivers, boards. All no luck.

    One thing I did find that may help. The error increased as steps per rev was reduced in firmware.

    ~Y error in R2D2.dxf ( as defined by home location after drawing finished)
    200×4 = ~50mm
    200×8 = ~25mm
    200×16 = ~13mm

    As you can see, the error goes down as you increase microsteps. If I went to 400 step motors with 32 microsteps the error should only be a ~3mm. Unfortunately I don’t have .9 degrees steppers, nor drivers that do 32 microsteps to test.

    I will run some test, and try to come up with some code to reproduce and let you know.

    Regards,

    William

    2016-02-17 at 10:55 #8966
    Dan
    Keymaster

    Very strange. I would think the increasing number of steps would increase the errors. that means it’s not error/step, it’s very likely the rounding error you suggested.

    DXF files make more pen-up moves than the other drawings. Maybe related? I don’t know why, moving with pen up is exactly the same as moving with pen down.

    2016-02-17 at 11:57 #8967
    Dan
    Keymaster

    https://github.com/MarginallyClever/Makelangelo/issues/165

    I’ve created a bug report, and I’m looking into it. I tried the only rounding method I know of in the code, but it didn’t make a difference. I can confirm the bug is repeatable and consistent.

    2016-02-17 at 12:06 #8968
    Anonymous
    Inactive

    Thanks, If you need me to test anything let me know.

  • Author
    Posts
Viewing 25 posts - 1 through 25 (of 26 total)
1 2
  • You must be logged in to reply to this topic.