Checking EBB motor voltage from Inkscape

[ragstian]

Hi.

Experimenting with the EBB board and “extending” my test program I discovered that the pulse output from the EBB is acting a “little strange”. When pulsing at a low rate the pulses stop briefly every 16th pulse causing the motor to “stop” briefly every 1.8 degree of rotation. Driving a camera pan head the stops can be easily seen in the video recorded. I reckon the “jitter” or stops also happens at higher motor speed.
Without access to a oscilloscope or logic analyzer it’s difficult to estimate the duration of the stops. For smooth operation I am assuming the spacing between the end of a “major step” and the beginning of next “major stap” has to be the same as a between micro-steps, Is my assumption correct?

When experimenting with different stepped drivers, motors and controllers it can often be difficult to figure out where the fault lies when the motor does not move as expected (sometimes it does not move at all!). Visiting different CNC forums over the years the need for a simple tester can be seen. Googling for a “stepper fault finding tool” came up with nothing so I set out with pencil and napkin and “designed” my own.
Result can be seen in this video snippet; Simple_Stepper_Driver_Tester.
The stepper tester is connected to the output of the stepper driver in parallel with the motor.
As can be seen in the video even the micro-stepping can be seen as varying intensity of the LED’s. (From approximately 0:30 when rotation changes to CCW) The micro-stepping can bee seen even better running the motor slower.
By removing power to the driver and rotating the motor (by hand) will cause the LED’s to light up if the motor is OK and wired correctly.
The (extremely complicated ;-) ) schematic for the tester will be uploaded as soon as I have translated “from napkin to PDF”.

Have fun.
RGDS
Ragnar

[EmbeddedMan]

Ragnar,

FYI, I just got back from a week of vacation. I love all of the digging and testing you are doing! I have answers to many of your questions, but I need some time to process everything and do my own experiments to make sure I’m getting back to you with accurate answers.

So this is just a note to let you know that sometime in the next couple days I’ll write up a post with as much info as I can in reply to the many great posts you’ve put here.

Many thanks!

*Brian

[ragstian]

Hi Brian.
Thanks for the feedback, I know there are too much info to digest in one go!
No rush on the answers.
My code for the “automatic check of the motor voltage before plot” is almost finished, it now works with all the firmware versions I could find on the net. For the hardware I have “simulated” the earlier and later versions.  Both my EBB board are ver 13.

RGDS
Ragnar

[EmbeddedMan]

Ragnar,

OK, I’m back at this after a long pause to clean up some other projects. I’ll answer your above questions in several steps.

1) I tested out the latest version of your updated Inkscape extension. It works quite well! As you say, the input voltage measurement is about 400mV or so less than the actual input voltage. But other than that it tracks quite nicely.

I got out my current probe, and measured the actual motor current going into the EggBot steppers and compared it (at various pot rotations) to the value reported by your extension. Here’s what I came up with:

Inkscape says 1087mA : Real is 1250mA

Inkscape says 1548mA : Real is 1900mA

Inkscape says 649mA : Real is 750mA

Now, I was running at about 15V of input voltage for this, and my current probe is not super accurate. But it’s clearly working – it’s just not dead on.

There is a potential problem though – just because the pot sets the current limit for the motors at some value x doesn’t mean that the motor will actually receive that current. There are other factors that could reduce the actual current going into the motor. For example, if the input voltage is too low, or the motor coil resistance is too high. Either of those could mean that your actual motor coil current is less (and possibly much less) than what the pot says. I still think your addition is a good one though!

2) I have confirmed that sending 0 in for a SM duration value will cause problems. I’ll fix that right away today if I can.

3) I have not been able to reproduce a problem with negative values for the duration. With 2.2.3, it seems that using negative durations simply generates an error (as it should) of “!5 Err: Need comma next, found ‘-‘”

4) About the reversed SP action in the new version – this is clearly a problem. I will update the documentation and the code to mimic the older EBB firmware. Having backward compatibility is the most important thing for all of these firmware versions.

5) Your problems with some microsteps having little to no movement (where you see ‘pauses’ in your video) is very likely because the combination of too-low of an input voltage, too-high of a motor coil resistance, and too-low of a max current limit set with the pot will create a situation where the motor driver isn’t able to properly create the correct current for some of the microsteps. This will normally appear as a ‘pause’ in the microstep cycle (when looking at actual motor position) and then a jump.

To fix this, try decreasing the max current setting via the pot and try again. If that doesn’t help, up your input voltage and then play with the pot again to see if you can make it go away. I’m pretty confident you’ll be able to solve the problem this way

---

More to follow later.

*Brian

[ragstian]

Hi Brian.

Thanks for the feedback, I will try the different suggestions to your ‘microstep’ fix – as a ‘hardware guy’ I just assumed the problem to be in the code!! – (As Jerry Pournelle (Byte Magazine – Chaos Manor – now Circuit Cellar) – once said “My favorite programming language is solder!” – ;-) ).
Will be able to have a closer look at the timing once I receive my Digilent Analog Discovery kit.

An interesting observation when checking the different datasheets from Allegro is that in later versions of the motor driver chip there are a mode to avoid loosing steps in slow micro-stepping, see page 8 of this data-sheet; A4988 datsheet. I don’t know if this is applicable in this case.

I am aware of the limitations in the current settings – without the proper voltage or too high coil resistance you will never achieve the set current.

For other use of the EBB board an acceleration / deceleration feature would be nice. The motor is capable of high RPM but will have to be ‘ramped up’ and ‘down’ to avoid stalling or loosing steps.

Again; Thanks for the feedback, it’s really appreciated!

RGDS
Ragnar

[EmbeddedMan]

Yes, absolutely. I’ve wanted to put accel/decel in for quite a while now. However, that is a big step because you must maintain coordination between the two axis. Also, the math (while not crazy hard) does get more complex, and I worry about not having enough CPU horsepower for it. Well, not at the max step rates that the EBB can current achieve.

*Brian

[EmbeddedMan]

I’ve just released a new version of the EBB firmware. Ragnar, you may want to update to it. You can see the list of changes on this page: http://www.schmalzhaus.com/EBB/EBBReleaseNotes.html

The big deal for this release is that, as far as I can tell (and I’ve done a  bunch of testing on it) it should operate identically to the ‘shipping’ 2.0.1 EBB firmware version as far as Inkscape and Water Color Bot is concerned.

You should not update to this version if you’re happy with your current version. But if you’d like to help us test out this new version to see if it has any problems or issues (compared to 2.0.1) please do so. We’d love to hear any feedback.

You can get the new version here : https://code.google.com/p/eggbotcode/source/browse/trunk/EBB_firmware/Releases/app/EBF_v224.zip

*Brian

[ragstian]

Hi Brian.

Testing of 2.2.4 started,
Operation of servo now back to ‘normal’. ;-)
Will try some of my plots.
Plots started OK.

(What’s the difference between EBF_v224.hex and EBF_v224.unified.hex?
(I have loaded EBF_v224.hex to my EBB board)

Edit; – Plotted Great!

RGDS
Ragnar

[EmbeddedMan]

Oh, wow. WOW. That plot is AMAZING! Nice job Ragnar. Where did you get the source material? Did you draw it?

The HEX file with “Unified” in its title is the application + bootloader all together, and would be used if you were programming a blank processor with a PICKit3 or other hardware programmer.

*Brian

[ragstian]

Hi.

The plot is  a copy of “Zentangle art” by Stoshi – see her blog page here: Stoshi’s Blog
( I got her permission to post the image as long as she got the credit she deserves.  )
She called the image “La Bella”, a great work of art! I traced the image by hand in Inkscape to get a SVG file.
Link to original image; “La Bella”

It is a nice test as the plot consists of a lot of small line segments causing a lot of pen-up/downs and moves. Takes about half an hour to plot. As you see I have ‘elongated’ the image somewhat to improve resolution. Will try to improve resolution further by smooting the egg surface. Right now the ‘rough’ surface causes the ‘jagged’ lines.

Are you posting the source code for 2.2.4?

RGDS
Ragnar

[EmbeddedMan]

It’s there in SVN right now. If just do an update, you’ll have the latest (2.2.4). And I’m on a mission to create 2.2.5 right now with 3-byte duration and step parameters for _really_ long moves.

*Brian

[ragstian]

Hi.

Great news Brian. I just made a plot in Inkscape of a one layer “Wave Winding” coil.
(See Wave Winding machine post.)
The image is 102400 pixels in width. This plots fine. For a 10 layer coil the width will be 1024000 pixels which does not work at the moment.

RGDS
Ragnar

[EmbeddedMan]

Ragnar, – it will work soon. If I can get this code beaten into shape, you’ll be able to do single moves that are up to 83886007 steps long. And/or take up to 4.7 hours.

Note that you can produce the exact same effect right now by simply sending several moves back to back in the same direction. Although this would probably be easier to do with a custom written application than trying to generate the paths in Inkscape.

*Brian

[EmbeddedMan]

Ragnar,

OK, new version is up now – v.2.2.5, with super long SM moves. Each parameter for SM can now be 3 bytes long. <move_duration> is unsigned 3 bytes, <Axis1> and <Axis2> are signed 3 bytes. It will also generate an error if you try to make a move that’s too slow for EBB (anything < about 0.76Hz).

You can get the HEX file here : https://eggbotcode.googlecode.com/svn/trunk/EBB_firmware/Releases/app/EBF_v225.zip

*Brian

[ragstian]

Hi.

A few observations on the 2.2.5 version.
 
Inkscape is unable to make any plots with this version.
Inkscape receives an incorrect return on Pen Up/Pen Down as it’s inserting a ‘Null Move” SM command according to the EBB Command manual recommendation. This can be seen by setting the pen height using the eggbot extension in Inkscape. Seems like the return value from the SM command is incorrect or not being accepted by Inkscape. When trying the SM command in my standalone program the response seems OK.

Response trying to plot: BadResponce.txt

Note that the ‘Pause’ button was never pressed, I have seen this behavior on the previous versions as well where the plot stops with inkscape reporting that the ‘pause’ button was pressed – when it was not, trying to ‘resume’ never returns to the correct place ruining the plot. I have tried to lower the baud rate as I thought it might be caused by ‘incorrect’ commands sent to the EBB, but this does not help. Maybe a bug?

The ‘QC’ command is ‘broken’ as well; the reported value for voltage is always ‘0001’ no matter if motor voltage is applied or not.

A last comment on the pen arm servo behavior; on resetting the board the servo is always returned to mid position, in my opinion this is bad as the eggbot will lower the pen onto the egg ‘ruining’ my plot! I would much rather have it to lift the pen using the last stored pen-up value.

On a more ‘positive’ note;

The ‘long move’ command is working like a charm! (Running from standalone python program.) Well done! This opens up a plethora of new possibilities for the eggbot and EBB board! (I can now draw a line from upper left to lower right corner filling in the egg in one move or – issue a ‘long move’ and ‘manually’ draw or fill in close to the end of the eggs. This is the closest thing to continuous rotation! I am doing the ‘happy dance’ right now!!

Happy Coding!

RGDS
Ragnar

[Author]

Posts