Checking EBB motor voltage from Inkscape

[ragstian]

Hi.

I have added a few lines to the eggbot extension to be able to “read” the motor voltage.
See this link; (See updated link in post below)

Anyone brave enough to test my code?

Is it OK to post a link to “unofficial” code or does it have to go through “Evil Mad Scientist” for check first?

The EBB also reports motor current as a reference voltage, does anyone know the “factor” for this number?
In the EBB command manual it is only described as a 10 bit number from 0 to 1023.
The schematics for the V2.1 Board have some info:
REF_RA0 Current:
0.0V = 46mA
2.58V = 1.35A
Can we assume a linear range?
What “raw” value does the EBB report for 1.35A?
My EBB shows a “raw” reading of 513 for a (idle or holding) current of 0.56A,
(1.917V across a 3.4Ω winding).

The table for the motor voltage given in the EBB command manual seems quite accurate with a max error of around 0.1V on my EBB using a Fluke 89IV for actual measurement.

My code interpolates from the table given in the manual.

RGDS
Ragnar

[Windell Oskay]

Hi Ragnar,

You certainly do not need any review to post code.  

We have not implemented this in the main trunk of the code because the command query was added in one of the newer firmware versions– not every EBB supports it with the firmware that it came with originally.  (Our plan had been to check the system voltage, to detect if the power supply were unplugged.)

[ragstian]

Ho.

Ok, here’s a link to a zip file containing the eggbot.py and eggbot.inx.
http://bit.ly/1juocaa
Code will work on EBB hardware v1.3 and above. (The white boards from EMSL are
v2.0, and all boards from SparkFun are v2.0 and above)

Another small change I made a while ago, on reporting the EBB version the com port settings will be listed as well, you will have to make the window larger to see it. Handy to know which com port to use when sending commands directly to the eggbot.

When making a table for the current measurement I discovered the reported motor voltage is dependent on the setting of the current potmeter, my input voltage was 12.22V and the lowest reported motor voltage was 6.97V!
This with the pot meter set fully counter-clockwice for 0 current. (The silkscreen on the board is incorrect! Counter-clockwice rotation will decrease the current.)
Max reported motor voltage was 14.46V at a motor current of 1.04A.
Any idea on why the reported motor voltage is dependent on the current potmeter setting? The two readings (A & V) uses their own AD input on the microcontroller.
I am not sure of the board revision on my eggbot as there are no version info on the board. Board layout date is 10/27/2010. Maybe my board version is too old?
Update: from the schmalhaus web page; “As of hardware version 1.4, the name changed to EiBotBoard”. My board has the “EiBotBoard” printed, board must be at least V1.4.

RGDS
Ragnar

[ragstian]

Hi.

The extension is now updated to include current setting as well.
Link to new version; http://bit.ly/1dvSQO7

My spare board which had firmware 2.0.1 reported too low voltage, works ok after upgrading to 2.1.5.
The reported voltage is still dependent on the current-potmeter setting, is this due to a bug in the firmware – using the incorrect reference voltage for the DA converter? Would be nice if the source code for the EBB board was open-source. ;-)
( Edit; the source IS open – YIPPIE !!, found it here; http://bit.ly/1l7M0OG :-) )

The EBB reports current setting = 0 for the first 10-15 degrees of rotation of the pot from fully counter-clockwise (min current) position, the extension will now “catch” this.

Please report errors and bugs.

RGDS
Ragnar

[EmbeddedMan]

Ragnar,

Wow! Your changes are so cool. Nice work. Yes the EBB firmware is open source, and I’m glad you found it. Prior to the most recent EBB firmware versions (2.2.3), there were bugs in the analog to digital code. It would sometimes work and sometimes not work quite right in prior versions. This would have affected the QC command. This has been re-written in version 2.2.3 and should work much better now.

As far as some of the other things you’ve seen – the QC command returns two values separated by a comma. The first is the analog voltage going into the REF_RA0 net. This value is directly controlled by the current adjustment pot. Looking at this first value allows the PC to read the maximum coil current that the user has set via the current adjustment pot. This is the voltage that you can measure with a DMM on TP3. With 0V on TP3, you should see 0 counts, and with 3.3V on TP3, you should see 1023 counts. Note that 0V on TP3 = about 46mA max coil current, and 2.58V on TP3 (about 800 counts) = about 1.35A of coil current.

The second value – after the comma – is a scaled version of the voltage on the M+ net (i.e. power input to the board via the barrel jack – after the diode D1 so there will be a diode drop in there.). This is so that the PC can see what voltage is being applied to the motor driver chips. The scaling factor is such that 0V on M+ should read 0 counts, and 31.4V on M+ should read about 870 counts. It should be linear.

I believe that both of these values are correctly measured in version 2.2.3 but I have not done very much testing since I didn’t think anyone was ever using this command! I’m so glad you are. Can you try out firmware 2.2.3 and let me know if the values seem to make more sense? If they don’t I need to do more work on the analog to digital converter code.

Note that EMSL correctly recommends NOT updating to any version beyond 2.0.1 (which is what EBBs are currently shipping with) because of issues with the pen arm not responding the same in newer versions as it does in the ‘official’ 2.0.1 version. I am working on figuring out why there is a difference right now, and will be releasing newer versions that attempt to perfectly mimic the 2.0.1 behavior. Once we test these fixes out and people agree that the newer version works just as well as the older, then we give folks the green light to use the newer versions if they have need for some of the newer commands or bug fixes.

*Brian

[ragstian]

Hi Brian.

Thanks for the nice words and the long answer with a very nice explanation on how your code works.
I figured most of the details as you have explained from your very well commented code!

I would love to test the 2.2.3 code but I have one “small” problem, I can’t find it!
The highest version I can find is 2.2.1, here; http://bit.ly/1peWqOi. Where do I find the 2.2.3 version?

I understand the implications of testing the new “cutting edge” versions but as long as I can revert back to a “proven” version I find it exciting.

One question on the current measurement, when measuring the current vs counts I measured the coil having the highest current (for simplicity I measured the voltage across the coil and calculated the current). My values came out lower than stated in the EBB command reference documentation. See here for a plot; http://bit.ly/QlA0iq. Looking at the values I realized they are “off” by a constant. The difference might be close to √2 = 1.41 less which to me implies the current setting is for peak current through the coil and my measured values are the RMS values. Is this correct? I have not had time to study the data sheet for the Allegro 4983 motor driver chips yet but will do in order to get a better understanding of the “inner” workings of the EBB board.

Keep up the good work!
RGDS
Ragnar
 

[EmbeddedMan]

Ragnar,

Sorry about that. I’m not doing a very good job of posting all of the intermediate development versions. This file (https://code.google.com/p/eggbotcode/source/browse/trunk/EBB_firmware/app.X/dist/EBBv13_with_bootloader/production/app.X.production.hex) is version 2.2.3 (until I check in a newer version). Once we get a version that is stable and has better pen servo behavior, I’ll make a ‘real’ version and post it.

So, actually measuring peak current on a stepper motor driver like the EBB is actually harder than it sounds. Because these driver chips are ‘chopper’ drivers, they are constantly turning the voltage to the coils on and off – even when the motor is standing still. This is happening at about a 20Khz rate, so your meter won’t see it. And measuring the voltage across the coil isn’t going to give an accurate value either. You have to either measure the voltage across the sense resistor (which is quite hard, because it’s such a low value), or you have to use a real current probe around the motor coil wires. (Which is what I do to verify these things.) And the current probe must be connected to a scope, as it’s a very ‘AC’ type waveform, and you have to look for the peak at each microstep. Just because the current limit pot is set to – say – 1A, you’ll only get the 1A peak through the coils if several things are true: the sequencer has to be on microstep 1 for that coil and you have to have a low enough resistance motor and a high enough input voltage that, taking into account the voltage drop across the FETs in the driver chip and the sense resistor, the driver chip can actually deliver that much current into the coil.

So, yeah. It’s not super simple, unfortunately. I don’t even completely understand it all the way yet. 

Hopefully this will help – you can read more on chopper drivers if you want to learn more of the theory.

*Brian

[ragstian]

Hi Brian.

Thanks once more! Using firmware v2.2.3 I am happy to say that the reported motor voltage is no longer varying with different pot meter settings. I am very impressed with your code! I am curious about what was the “bug” in previous versions?
(I am currently participating in the edx – Course; “Embedded systems – Shape the world”, programming a TI Launchpad (ARM chip), see http://bit.ly/1jBkc80. Challenging as I never dipped my toe in the ‘C’ before! )

I had to edit the v_points in my code to get the correct voltage reported. I set the 0 count voltage to 0.0V and the 1023 count voltage to 36.3V ((3.3V/4700Ω)*51700Ω). The measurement is almost spot on with a count value of 333 reporting a voltage of 11.99V. Actual voltage applied is 12.21 which would account for the voltage drop over the diode. With the motors enabled the reported voltage falls to 11.88V due to a slightly larger drop over the diode.

To get “my” code to report correct replace the v_points with this; v_points = [(0,1),(36.3,1023)]
(As the slope is now linear I am re-writing the code, the table interpolate is no longer needed, stay tuned for update.)

A am also curious about the pen arm “failing” code, I have plotted several “hours” of eggs without noticing any problems using version 2.2.1.

Thanks for the explanation on the motor current, will study it closer when time permits.

I am impressed with your coding skills and learn a lot by reading your code!

RGDS
Ragnar

[EmbeddedMan]

Ragnar,

The problem with the pre-2.2.3 analog code was that each time any command needed an ADC conversion, it would set up the ADC, start the necessary conversion, wait for it to be done, then print out the result.

The problem with this method is that it fundamentally conflicted with the existing interrupt based analog conversion code brought over from the UBW codebase when I started the EBB. For the UBW, I keep a list of all active analog channels, and convert them all (one every 5ms) and store them in a FIFO. Then, when any command needs to read an ADC, it simply uses the latest value(s) from the FIFO, as the ISR is taking care of doing all of the conversions.

So the change I made was that a adopted the QC command to use the existing UBW interrupt based analog conversion functions. You can see the changes yourself if you compare SVN 289 with SVN 290.

As for the problems with the pen arm code – I’m very happy to hear that you are having good success with it! Other testers have reported problems, although we have not yet really worked on understanding exactly what those problems are – they may have been phantoms. Right now, there are some remaining bugs with the functions I’m working on at present – getting ‘long moves’ to work. This is where the SM command will be able to take times and step values much larger than it currently can. Several folks have requested this, and it’s taken me longer to get everything working than I thought it would. 

Once I have all of the new features in, I’ll publish a call for people to test out the new version. Then we’ll really see exactly what the pen arm problems are.

Thanks again for your great work on this!

*Brian

[ragstian]

Hi Brian.

Once again thanks for the detailed explanations, it’s appreciated!
I am “sucking up” the info like a dry sponge!!

For the pen arm code failing doing long moves using the SM command, most of my latest plots have been very fine detailed with a lot of short moves and very few long moves. ( Example ) I also make sure to use the “optimize” feature of the eggbot extension to limit long “air-moves”. To test Iong moves I can make some designs with a lot of long moves. What’s the reported “failure mode”? Loosing steps, failing to move, crashes? Due to the mechanical constraints of the eggbot the pen arm movement is limited to about 900 pixels, by removing the pen arm and using a circular disk (graduated in degrees) much larger pen movements can be simulated. I remember running into problems with large sheet sizes trying to plot a 128000 pixel long line from upper left to lower right corner of the sheet (canvas in Inkscape lingo), this was to make a line spiralling 40 times around the egg. At the time I attributed the problem to inkscape/eggbot/EBB_board using 16 bit numbers (max 65536 or 32768 if signed). Have not tried this experiment lately with latest versions of inkscape/eggbot/EBB_board.

I have one question regarding the motor current setting calculations, where does the 46mA at 0 counts come from? I have studied the A4983 motor driver data sheet but could not find any relevant info. (Reading datasheets is difficult (for me at least), try the TI Tiva™ TM4C123GH6PZ Microcontroller datasheet – 1452 pages!)

Quote: “You can see the changes yourself if you compare SVN 289 with SVN 290.”
Again, where to find? ;-)

Here are my new eggbot.py and eggbot.inx files eggbot.zip

Please be aware that this only works on EBB firmware version 2.2.3 and higher.
EMS does not recommend to upgrade past version 2.0.1 d.t. a possible
pen arm movement bug in the newer versions.

RGDS
Ragnar

[ragstian]

Hi Brian.

I have now done two tests, one EBB pen move command turning the motor one complete revolution in one second.
This was done for over 12500 moves without error. The second test was random length moves – in random direction – restricted to the range available on the eggbot. This test ran for over 21500 moves (Six hours) without errors. Video snippet of test.

The EBB board seems to “behave” OK but is very unforgiving on incorrect parameters. The EBB board will hang after a while if the duration for a move is 0 (zero). A negative number causes the EBB board to crash.

RGDS
Ragnar

[ragstian]

Hi Brian.

After testing the pen move using the 2.2.3 version I reckoned – why not try “the real thing” – running the eggbot from Inkscape.

When setting up the eggbot after flashing the EBB on the Eggbot ( I used my spare EBB board for testing on the bench) I found the pen-up pen-down to be reversed in v2.2.3.
When I perform – “Raise pen – turn off motors’ the pen is lowered. By reversing the upper and lower values in the setup I can still use version 2.2.3 but it might confuse users having a lower number in the Up position than in the Down position.
Flashing the EBB back to V2.1.5 changes to “Normal’ behavior.

From looking at the commands sent to the EBB from Inkscape using a USB device Monitor (software) when performing a “Raise the Pen” manual command Inkscape sends;

“SC,4,18240”
“SC,5,20540”
“SC,11,250”
“SC,12,100”
“SP,0”
“SP,1”
“SM,500,0,0”

– According to the EBB bot board command manual it is supposed to be the other way around “SP,0” to raise the pen and “SP,1” to lower. From manual;

Format: “SP,<value>,<duration>,<portBpin><CR>”
<value> is 0 (for up) or 1 (for down)

Looking at the eggbot.py confirms this error to be in the eggbot.py extension code. The EBB code works according to the manual. I have verified this using my standalone python test program.

By the way the “Command manual” is missing a section on the “QB” (QueryButton) command.

RGDS
Ragnar

[ragstian]

Hi

Another fruitful run without errors.
Dump of last four lines from program;

Moving pen   279 steps=  31.39°, egg   279 steps=  31.39° in  697mS.
Moving pen  -558 steps= -62.77°, egg  -535 steps= -60.19° in 1394mS.
Moving pen   279 steps=  31.39°, egg   279 steps=  31.39° in  697mS.
Performed 25037 move commands in 5:51:20.

I am pretty confident in the pen arm code being bug-free.
RGDS
Ragnar

[ragstian]

Hi

Reverse engineering of Brian’s file ebb_demo.c  in python. Plotted with standalone python test program used for above tests.

Front and Back

RGDS
Ragnar

[Windell Oskay]

Ha!  You found the secret code!

[Author]

Posts