Amin

Forum Replies Created

Viewing 25 posts - 1 through 25 (of 25 total)
  • Author
    Posts
  • in reply to: the drawing is offbeat #20989
    Amin
    Participant

    Well, I’m using spools, so there’s no pulley nor teeth. And I should say there’s no winding problem in my setup either.

    I started out using the the spool circumference for “PULLEY PITCH” – I’m assuming this is the right way to go? But then when it wasnt accurate, I re-did it with your formula in the link above. Now X works flawlessly, but Y is off. Probably if I re-do it, calibrating on the Y axis, the X axis would be off.

    With this in mind, you think it’s the drawing area measuements that are inaccurate? I’m using a ~1.5×1.5 area so there might be some minor measurement errors when I set it up. But I mean, it can’t be off by more than 1cm, and I am getting movement accuracy errors of 2-4cm. It seems a bit much off for such a small measument inaccuracy no?

    in reply to: the drawing is offbeat #20978
    Amin
    Participant

    Hi,

    I’m also having offbeat drawing/movement. Granted I have a custom made version with spools and all.

    After following your tips here:

    How to fix 9 common Polargraph drawing problems

    I told the machine to move 10cm to the right and adjusted pulley pitch accordingly. Now having perfect X axis precision. However, Y axis is always off by 1-2 cm’s.

    What could it be?

    in reply to: Faster speeds #20332
    Amin
    Participant

    Regarding commanding within the code: thanks, lineSafe() worked just fine! I am trying to find an equivalent for jogging the motors. I see that the variable “amount” is responsible, but amount = parseNumber(MotorNames[i], 0), and afaik “MotorNames” is not a step amount but only the letter assigned to the motors (L,R,U,V..)? How do I command jogging from within the code?

    Regarding speeds: so you think the serial transmit is what is preventing even faster speeds? So using lineSafe() within the code should help?
    Also, have you tried raising the Acceleration? For me it works smoother when I raise it to the same as feedrate, and sometimes even higher. On the other hand, changing MAX_JERK didnt do much for me.

    As promised, here are some videos of my setup (it’s still being improved):
    1) OVERVIEW https://www.instagram.com/p/BiXJD3JDhXA/?taken-by=shazman.visuals
    2) CLOSE-UP https://photos.app.goo.gl/oeRVC11LmRRM3fQB8
    3) THE NEW PROJECT THAT NEEDS FASTER SPEEDS (Strechable canvas, soon audio-reactive) https://photos.app.goo.gl/3VD1xdVvXYtWGUBy7

    in reply to: Faster speeds #20300
    Amin
    Participant

    Some progress: now with enough current given to the motors, I see that also lower levels of microstepping and full stepping work better. Things do now go faster, but you also need to lower the F-speed in order not to go too fast and skip steps. At the end of the day, there is only a slight increase in speed, and unfortunatly not enough to satisfy me.

    **CONCLUSIONS** for anyone reading this in the future with motors that skip steps when trying to go faster: make sure you are providing enough current by setting the current limit on your driver (e.g. A4988) to the rated current of your motor. And don’t worry about your power supply not delivering enough current; it (usually) supplies 12V which is higher than your motor’s voltages (~2-3V), so it don’t need to output as much current as they are rated to. A 12V supply with 5A is enough in most cases.

    Regarding spools, I found that they, when tensioned, actually automatically let the cord place itself uniformely on the spool. And if the cord is thin enough and spool diameter is big enough, even if there’s a layer of winding on top of another, the accuracy does not get measurably worse. I’ll place a pic or video of my setup here during the weekend.

    >>>New question: can I somehow send Gcode commands within the Firmware, or must I use the serial input? I’m writing new code that will generate position commands and I want to feed that to your Makelangelo firmware to react upon.

    in reply to: Faster speeds #20290
    Amin
    Participant

    Thanks, but my problem was not skipping of belt, because I am not using pulleys and timing belts (I use spools – there are pros and cons but I’m happy with it for now). My problem was that the motor shaft itself was jerking/skipping when commanded >F5000.

    I increased the current limit on my A4988’s up to the max rating of my steppers (1.3A/phase). This helped a lot, so insufficient current was probably the main reason for my motors jerking/skipping. I can now run F8000 smoothley, almost F10000 with some steps being skipped.

    Another current-related thing that might hinder me going even faster is that my power supply only outputs 6A @12V. With my 4 steppers @ 1.3A/phase, won’t I need 4 x 1.3 x2 = 10.4A power supply?

    I also read somewhere that increasing the input voltage from 12V (to max 18V?) “generally allows for higher step rates and stepping torque”.

    in reply to: Faster speeds #20275
    Amin
    Participant

    Ok so I tried changing microstepping (in both HW and SW) to 1/4 and 1/1 without any significant speed increase. The “jerking” keeps starting around >F5000. In fact it the jerking seem to change even earlier with 1/1 than 1/16. Interesting.
    Now I’m wondering if it could be the current limit setting of my A4988 drivers. I have not changed them at all, maybe they are set too low or something and wont give enough current required at higher speeds? I haven’t really understood what changing the current limit *actually means* lol.

    Regarding the code, you mean one can only adjust the ISR speed by changing the FEEDRATE value?
    These things in configure.h shouldn’t be tampered with I presume? 🙂
    #define CLOCK_FREQ (16000000L)
    #define MAX_COUNTER (65536L)
    #define MAX_SEGMENTS (32) // number of line segments to buffer ahead. must be a power of two.

    One more thing, say you’ve pushed to F8000 – did you also notice if the motors themselves seem to “jerk”/jump at these speeds? (irrespective of belt skipping)

    in reply to: Faster speeds #20261
    Amin
    Participant

    Thanks for clarifying. I think I’ll start with trying to remove microstepping, as I might accept some accuracy loss. Another thing might be using bigger spools?

    But when it comes to the code, you mean there is *nothing* I can change other than MAX_FEEDRATE etc to get faster speeds? There is no added delay/pause anywhere, like the Jogging feature has?

    Increasing MAX_FEEDRATE won’t help I’m afraid, since the “jerking” starts way before I reach the levels already in there. What can this jerking be btw? The motors can run much faster under the same load manually with my own code. Could it be my Arduino Mega or Ramps board that are slower than your Rumba? You seem to be able to go much faster than me.

    in reply to: Faster speeds #20259
    Amin
    Participant

    With “jerking” I mean the motors seem to jump and struggle as they move. Almost as if they take one step back for every two steps forward.

    I’m looking to move ~0.5m/s.

    MAX_FEEDRATE & MAX_ACCELERATION: you change this with Gcode right? G0 F5000 A4000? That’s what I’ve done and the “jerking” hinders me to go above F5000 & A4000.

    What is MAX_JERK?

    My project is to use the 4 motors to stretch a piece of stretchable cloth into different geometrical shapes (using the jog feature on each motor, which btw can be sped up just fine by altering pause() in Makelangelo-firmware.ino), and then moving that shape around the 2D space (here is where I need much faster speeds). Happy to post pics when I start to get somewhere.

    What do you think I can do?

    in reply to: Makelangelo – tuning it in #19857
    Amin
    Participant

    Hmm don’t they need to move the same amount, but just that mine does it in less steps than yours? Does that really mean mine need to go faster?
    And woudn’t the motor setting in configure.h compensate for that nonetheless?

    Sorry for keep bothering on this minor issue! 🙂

    in reply to: Makelangelo – tuning it in #19849
    Amin
    Participant

    A5000 F9000 is super jerky for me – wierd that your motors can run smooth on that and mine can’t. Could it be that I’m using 200steps/rev motors and you 400?
    Everything else should be the same (1/16th microstepping, same RAMPS board set to 1/16th, same firmware). Only other difference is I’m using larger pulley diameter than you but that cant be it.

    in reply to: Makelangelo – tuning it in #19830
    Amin
    Participant

    I can share the following data I gathered with my machine, when moving from X0 Y0 to X600 Y60.

    F A Duration
    1000 1000 13.5s (super smooth movement)
    3000 3000 6.2s (smooth movement)
    3000 6500 5.9s (smooth movement)
    5000 500 6.4s (some noise/jerk)
    5000 5000 4.6s (some noise/jerk)
    5000 10000 4.6s (some noise/jerk)
    6000 6000 3.8s (kinda jerky)
    6000 12000 3.7s (kinda jerky)
    8000 8000 3.8s (jerking so much that losing accuracy)

    Conclusions:
    – The Acceleration value seems to benefit being over a certain treshold not too much less than the Speed value. But once it surpasses the Speed value, not much difference is made.
    – I need to stay under F5000 A5000 to avoid jerking. I have a feeling that’s lower than it ought to be.

    I can’t remember what the default settings were, since I’ve changed them so many times since. Can you do me a favour and have a quick look, and maybe even try running at higher speeds to see when it starts jerking for you?

    in reply to: Makelangelo – tuning it in #19814
    Amin
    Participant

    I’ve tried to increase the movement speed (not for drawing reasons), but found that the motors start jerking oddly when I go over speeds/accelerations of 5000 (running GCODE: “G0 F5000 A5000”). Am I doing something wrong or is there a upper limit for how fast the system goes?

    Could it be the commands for movement I’m sending? I’m running “G0 Xnnn Ynnn”.
    I haven’t noticed any difference between using G0, G1 or even simply G. And Makelangelo SW seems to be using G00. Is there any difference between these?

    in reply to: Zarplotter 4-motor drawing machine #19771
    Amin
    Participant

    I think you have to do this with GCODE. The term to use is:

    M101 A0 Tnnnn B-nnnn – where n is Top and Bottom values of X axis
    M101 A1 Tnnnn B-nnnn – same for Y axis

    See this pic:
    https://i2.wp.com/preview.ibb.co/eYTLQS/Setup.png?zoom=1.25&resize=500%2C500&ssl=1

    in reply to: Harware #19770
    Amin
    Participant

    Simon, happy to help – what is your Arduino knowledge currently? If you are starting from zero, it may be better to do some basic tutorials you can find on youtube etc. Uploading a sketch is usually a first step. Don’t forget to change the setting to Arduino MEGA before uploading.

    in reply to: Pen holder design factors #19755
    Amin
    Participant

    Ok so you’ve found that the most impactful thing to do is having long arms that balance the pen over it’s entire length. Do you think the arm-to-pen bearing (or what it is you use) is necessary too? Thing is, I find super simple designs out there that seem to be very stable, I’m perplexed haha!

    The other stuff, like having 3 points touching the drawing surface, or long string lengths don’t matter that much in your experience?

    I can’t remember the default settings, but wasn’t it like 6500 something? Crazy! I can barely get stable over 500! 🙂

    in reply to: Pen holder design factors #19750
    Amin
    Participant

    Hmm you mean the Makelangelo 5 pen holder? The arms do look like (extremely thin) triangles, but I can’t see how they support both ends of the pen – both arms seem to meet at roughly same place at middle of pen length.

    What speed and acceleration settings are you running your stuff on?

    in reply to: Harware #19739
    Amin
    Participant

    As is written in configure.h just above the line where you should add the motor board you have, the following boards are supported:
    RUMBA, RAMPS, SANGUINOLULU 3 and TEENSYLU.

    Regarding software, I found it easiest to just download everything from this website. Then you don’t need to deal with github.

    Firmware: https://www.marginallyclever.com/product/makelangelo-firmware/
    Software: https://www.marginallyclever.com/product/makelangelo-software/

    in reply to: Makelangelo – tuning it in #19622
    Amin
    Participant

    And about the “Home” function…

    – When using Makelangelo SW:
    What exactly does “Home” mean, is it the starting position? And why does it seem to be fixed at a certain distance from the top border of the machine, even when pressing “Set home” and being somewhere else in the machine area? (the GIU shows the pen go back to the original home point)

    – When using Gcode, e.g. with your GcodeSender tool:
    Is setting/using the Home position relevant for someone using only Gcode to run the machine? I can’t find any use for it, since only the boot-up position seem to define coordinates X0 Y0.

    in reply to: Makelangelo – tuning it in #19621
    Amin
    Participant

    Ok I finally got around to build a larger iteration with the forementioned spool and external cord guides.

    In Configure.h, PULLEY_PITCH is the spool circumference right? Is this the main parameter to change if the movements are larger than expected? I get (69,2) cm when commanding (60,0) cm. I have the measured spool circumference and no winding on the spools.

    in reply to: Makelangelo – tuning it in #19513
    Amin
    Participant

    No, those are two different belt configurations shown at the same time. The right one (marked Makelangelo) is yours, and the left one (marked “mine”) is the one I have in mind. I should have clarified I’m using a cord and not a belt, kind of like this:
    http://4.bp.blogspot.com/-22X2YVoGvbE/UlX3xNDssdI/AAAAAAAAvDk/CWg34sYm-mY/s1600/IMG_20130428_204618.jpg

    So should I just define machine dimensions as where the outer pulley/pins are located? Or add a couple of mm X and Y to take into account the yellow-marked distance drawed in my first post from yesterday?

    in reply to: Makelangelo – tuning it in #19511
    Amin
    Participant

    You are most welcome, happy to help!

    All I know is that the Kritzler code uses pythagoras formula to calculate the belt length, based on input dimensions going all the way to where the belt leaves the pulley. But not sure if that extra accuracy is visibly detectable in the drawings. As I read this and other forums, sometimes it seems a input dimension error of a few mm will mess up the entire image, and other times I get the impression it’s not that sensitive.

    Maybe I’m overthinking this, but can you take a look at the below drawing and confirm my assumptions? I want to use a second pulley to move the belt away from the motor, before it bends and turns towards the drawing surface. Is my new imaginary measurement point correctly assumed?

    in reply to: Makelangelo – tuning it in #19505
    Amin
    Participant

    I was a little confused about the input tuning dimensions, so I did this visual guide that might come in handy for others too. Dan, can you please confirm if the assumptions are correct?

    I’m particularly interested in how the motor edge is mapped to where the belt leaves the pulley (i.e. the point where the belt’s length is calculated, I presume). For those of us making custom setups with multiple pulleys/spacers diverting the belt, the (yellow-marked) distances won’t be the same as in Makelangelo machines.

    in reply to: Custom Polargraph misc questions #19426
    Amin
    Participant

    Thanks for the reply!

    QUESTION 3:
    That’s a great list, but I was more referring to “how” one should send the commands. I guess serial is the most common way?

    I saw that you have made this tool back in 2014, is this what you’d still recommend?

    GCodeSender v1, the Better Arduino Serial Window

    Do I just make a *.txt file with a bunch of command lines, then open it in the above tool and press send once? Or is there more hacking involved?

    QUESTION 4:
    With “origin” you mean the starting point of the gondola/pen – it could be in the center of the drawing area or anywhere else within right?

    According to another forum post, these measurements are from origin to “bottom right corner of the left motor” and “bottom left corner of the right motor, in millimeters”. So I’m assuming that somewhere in the code you are working out the distance from the motor corner to where the belt actually leaves the pulley? (to get the belt length math right)
    However, for me using a custom setup and different diameter spool, won’t this distance need to be altered? If so, where?

    in reply to: Zarplotter 4-motor drawing machine #15719
    Amin
    Participant

    I read you loud and clear – ordering Arduino Mega + RAMPS right away. 😉

    Is RAMPS fully supported now btw, I read above that there has been some issues?

    in reply to: Zarplotter 4-motor drawing machine #15708
    Amin
    Participant

    Hi folks, here’s another guy just getting ready to try out the Zarplotter. Dan, hope you had a nice vacation.

    First question: In configure.h, I see the list of supported boards, but what I have is unfortunately not listed; the “CNC v3 shield” for Arduino Uno (4 motor outputs).

    Picture: https://872c4715dbe9f10b83d1-0b39dab3ba460c18aad59cf32aacf5c8.ssl.cf5.rackcdn.com/TE623-E-10-9.jpg
    On Aliexpress: https://aliexpress.com/store/product/CNC-Shield-Expansion-Board-V3-0-UNO-R3-Board-for-for-Arduino-4pcs-Stepper-Motor-Driver/217987_32817440363.html

    Where/how can I add this shield in the code? Is it only a matter of changing pin numbers or will this be a major operation? If so, I guess it’s just easiest to just buy a Arduino Mega + RAMPS shield – if RAMPS is now confirmed to fully work.

    Thanks!

Viewing 25 posts - 1 through 25 (of 25 total)