- This topic has 17 replies, 4 voices, and was last updated 10 years, 7 months ago by .
-
Posts
-
Hi,
I builded an Egg-Bot myself. Now I’ve mounted stepper motors with 400 fullsteps per revolution to be able to draw at a higher resolution.I made some speedtests. As the new motors are 56mm 1,7A 0,89Nm I guess I can drive them pretty fast.But when I tried more than 1000 steps per second the thing goes crazy. The pen-motor jumps very quickly thanthe stepper is stalling. this happends even at 1100. While 1000 steps per second is moving the pen quite easy.Is this a problem of the firmware? If speeds higher than 1000 steps / sec where used the firmware gets out of snyc?does anybody now how to manage that?best regardsStefanHi Stefan. The EBB uses some very simple math to determine the time between steps, based on the number of steps in the SM command, and the amount of time that you ask the move to take. There are some higher steps speeds (like you’ve found) that cause this math to ‘break’ and give incorrect results (i.e. motors go crazy). Because the EBB never needs speeds this high, the existing firmware is just fine for normal EggBot use. But you’re in a special situation!
I am currently working on an updated EBB firmware that will solve some other long-standing problems (none that affect EggBot usage) and add some new features (like being able to handle very long moves). I will also now add to my list of things to do your request – to be able to handle faster step speeds. If the EBB is not able to produce smooth steps, it should report back an error (i.e. not say “OK”) rather than making the motors act crazy.Now, this same type of problem may be happening because your input voltage is not high enough for the motors you are using and your current adjustment pot is set too high. So, can you try this for me? Run your motors over and over at the higher step speeds, and very carefully adjust the current adjustment pot slowly in both directions and see if you can get smoother movement than you’re getting now. You can also try using higher input voltages to the EBB which will help produce more torque at higher speeds.Let us know what you find, and I’ll get to work on improving the firmware.*BrianStefan,
I just did some testing with EBB v2.0.1 firmware. I have no problem running my motors at step rates up to 32,000 steps/s.I have some 400s/rev steppers that I’m using for testing (like your setup). Since we have 16x microstepping, this should provide me with 1 full revolution at 6400 steps. So I executed the command:SM,1000,0,6400I saw my motor move exactly 1 revolution in exactly 1 second (timed with a logic analyzer on the step signal to the motor driver chip). This proved that we are able to handle step speeds up to 6400 steps/second no problem. The motor moved very smoothly.Since the largest step value you can use with SM (in this version of firmware) is 32,767, I decided to pick a nice round number of 32,000 steps. I then didSM,1000,0,32000And saw exactly 5 rotations (as expected). However, the timing is off – the total move took around 1.4 seconds, and the pulses to the motor driver were not equi-spaced in time. The way that the EBB generates pulses, each pulse has to line up on a 25KHz ISR boundary, so the fastest step rate we’ll ever see is 25,000 steps/second out of the EBB. Since I’m asking it to do 32,000 steps/second, it still took the exact right number of steps, but it had to spread them out a bit and thus take longer than 1 second.Again, my motors smoothly moved the 5 revolutions. Even thought the pulses sent to the motor driver were not perfectly smooth, the mechanical system of the motor smooths them out and we get smooth motion.So, in answer to your question: can the EBB support step speeds above 1000 steps/second? Yes, absolutely it can, as these experiments show. Up to about 25,000 steps/second, things should work as you expect.My guess, at this point, as the the cause of your issues is a mis-adjusted current adjustment pot on the EBB. It appears that the firmware is doing what we expect of it.*BrianHi.
Have you selected the “Egg (x) axis wraps around” in the options tab?
RGDS
RagnarHi
I plot designs 6400 wide on my 3200 pixel eggbot (1.8° motor) without problems
( with the “Wrap around” option enabled )The largest canvas size I have used was 32000 pixels (to get a 10 turn spiral of text on the egg – the text go between diagonal corners).
What happens if you plot a continuos line?
I might get a 0.9° motor for some experimentation, reckon the added resolution won’t be of much use since the arch length for a 48mm diameter egg will be 0.047mm/microstep for the eggmotor and 0.069mm/microstep for the pen (70mm dia circle). What’s your experience plotting with this motor (apart from the above problems).
RGDS
RagnarHi StefanL38.
Good catch on the coding.
Using “hard-coded” values in (any) code is a ‘pain in the neck”.
It’ is used “all over” in the inkscape extensions,
I have changed most of my extensions where I need higher default values – like in the
“Render – Parametric curves” the max value for the independent variable “t” is 1000,
if I use the “degrees” option this will plot less than three “revs:” I have set it
to 100000 in the “param_curves.inx” – I then store the extension files in my %appdata%
folder (“C:UsersRagnarAppDataRoaminginkscapeextensions”on my win7 system)
– the files here will not be deleted by uninstall / install of Inkscape.
You can do the same to increase the too low step/second value in the eggbot.inx file.
Having experimented with higher step values in my standalone driver program my motor fails to move fast as it is not accelerated or ramped up/down.
How do you overcome this?For the pen arm play you will have to ‘design out” the play.
I agree that the original design is “clever” and very simple doing a very good job.
Two changes to the original design would be beneficial.
In the original design the pen tip moves along an arc when the pen is lifted, when changing pens the getting the “new” pen height just a tiny fraction different from the previous pen height will introduce a “large” offset along the X-axis. I am working on a design where the pen moves straight up/down when lifted/lowered to remedy this. (there are already one in thingiverse).
Another “problem” in original design is that it’s possible to “twist” the pen along the x-axis as the hinge part is not stiff enough. (using the optional “stiff” hinge almost eliminates this problem though).
I use extra force (provided by a rubber-band) to keep the pen down as some of my pens require this “extra” force to work.
The RC-Servo does not “like” the constant force provided by the rubber band in the up position.I try to come up with something “simple” that can be mass-produced using the existing technology (laser cutter) of EMS.
Currently I have a design on my napkin using a wedge (moved by the servo) lifting the pen.
Another change I would like is to move the pen arm servo off the pen arm to reduce the “moment of inertia”.
By having the servo link operating in the center of the pen arm motor axis the servo can be attached to the eggbot frame.Good luck “pimping” your eggbot ;-)
Thanks to the EMS team for providing me hours and hours of fun!
RGDS
RagnarThere is a lot of stuff in this thread, and I do not immediately have all of the answers. Some things that I can add, though:
1. The Eggbot Control extension does have a facility for adapting to the 1600 step/revolution resolution: Add a new, empty file in the directory called “motor1600”, and it will make that switch. Look in the code for how that works, and it should be straightforward to use that code to instead adapt it to work at 6400 step/revolution resolution. This one scaling factor should (hopefully) take care of most of the “hard coding” problems that you are describing.2. The 1000 speed limit has never been a problem before, since the Eggbot does not generally work nearly that fast. An actual bug is that you should not be able to set the input value to 10,000, but instead to 1000 max.3. The WaterColorBot extensions for Inkscape use much of the same code, but with a little more flexibility and fewer hard-coded values. It uses an external configuration file “wcb_conf.py” where you can set some of those numbers like DPI and relative speed scale. You may want to look at it for additional examples.4. We did come up against the 1000 speed limit in the WaterColorBot code, and fixed it as follows:Eggbot code:nTime = int( math.ceil( 1000 / self.fSpeed * distance( self.nDeltaX, self.nDeltaY )))WaterColorBot code:nTime = 10000.00 / self.fSpeed * distance( nDeltaX, nDeltaY )
nTime = int( math.ceil(nTime / 10.0))>How about a pen-adapter for exact repositioning made by a 3D-printer?
There are a few different ways that we could go about making an adapter for high-precision multi-pen positioning, but we wouldn’t make any of them on a 3D printer. In practice, we’ve always been able to reposition the pen to a degree that it hasn’t been a significant concern.What we really need is a way to reposition the egg exactly once you take it out and put it back in. That’s one that I do not have a good solution for.
- You must be logged in to reply to this topic.
