Comments

• Windell Oskay

  March 2014

  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

  March 2014 edited March 2014

  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

  March 2014 edited March 2014

  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

  March 2014

  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

  March 2014 edited March 2014

  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

  March 2014

  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

  March 2014 edited March 2014

  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

  March 2014

  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

  March 2014 edited March 2014

  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

  March 2014 edited March 2014

  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

  March 2014 edited March 2014

  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

  March 2014

  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

  March 2014 edited March 2014

  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

  March 2014

  Ha!  You found the secret code!
• ragstian

  April 2014 edited April 2014

  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

  April 2014

  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

  April 2014

  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

  April 2014

  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

  April 2014 edited April 2014

  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

  April 2014

  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

  April 2014 edited April 2014

  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

  April 2014 edited April 2014

  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

  April 2014

  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

  April 2014 edited April 2014

  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

  April 2014

  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

  April 2014

  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

  April 2014

  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

  April 2014

  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

  April 2014 edited April 2014

  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
  
• EmbeddedMan

  April 2014

  Ragnar,

  
  

  Excellent. All of this feedback is good. I did nothing that should have broken all of that stuff that you found. So I'm going to have to dig into it and test some more this evening.

  
  

  I have never seen the 'pause' problem you've listed. I don't do a _ton_ of EggBot plotting, but I've done probably 50 or 100 eggs, and never seen it. The 'resume' problem is known and will take a Python expert to fix in the Inkscape Extension. I wonder if your pause problem may be due to a floating input pin or something. I'll look into it as well tonight.

  
  

  I'm so happy you're enjoying the long moves. Awesome.

  
  

  *Brian