gaudat / eggbotcode Goto Github PK

Goal: allow concurrent use of multiple Eggbot devices connected to the same 
computer.

This works already on Windows.  On Windows, device handles by default are 
exclusive.  If one process has opened a device handle to an Eggbot, then as 
long as that handle is opened, no other process can open a device handle to the 
same Eggbot.  Other processes will skip that device in their search for an 
available Eggbot device.

On POSIX platforms, file descriptors are not exclusive.  Two processes can 
concurrently open a file descriptor to the same device and send commands to 
that device.  That's not desirable.

The proposal is to use POSIX advisory locks and have eggbot.py honor these 
locks.  This will then give the same behavior as on Windows.

Originally Reported by westfw, May 25 (4 days ago)
To find the serial port occupied by the eggbot, the extension code sends a
"v\r" (version) command to each port it sees, looking for an appropriate
response.  This may have unintended consequences depending on what other
serial devices are connected to the system, so there should be an easier
way to have the user specify a specific serial port to try.  I suggest an
environment variable ?

Inkscape extension .zip file should not contain the top-level directory 
"eggbot_2010_10_04". Instead it should contain the contents of that directory.

What steps will reproduce the problem?
1. Follow linux software instructions from 
"http://wiki.evilmadscience.com/Installing_software"
2. Start Inkscape for second time
3. Check "Extensions" menu

What is the expected output? What do you see instead?
Expected to see "EggBot" menu, but it was not present.
Fixed it by:
cd ~/.config/inkscape/extensions/eggbot_2010_10_04; mv * ..; cd ..; rmdir 
eggbot_2010_10_04
# then restart Inkscape

What version of the product are you using? On what operating system?
Inkscape 0.47 w/eggbot_2010_10_04.zip on Ubuntu 10.04


Please provide any additional information below.

WIf you use Inkscape's File > Document Metadata facility to add a title or 
related information to a drawing, then a SVG <title> element is added to the 
document.  eggbot.py doesn't recognize the <title> tag and thus issues a benign 
"unable to draw object" warning.

The STOP button in the plotter panel doesn't seem to actually do anything
on my Mac.  I'm not sure whether this is Mac-specific or general.  (the
CANCEL button in the old driver didn't work either.)

The Eggbot can be used to print a single long spiral path around an egg.  You 
can do this by drawing a single line that extends from (0,0) to (32000,800), or 
much further.  

You can make a line like this by making a diagonal line from (0,0) to 
(3200,800), and then stretching it horizontally.  

The line draws correctly, wrapping around with 10 full revolutions of the egg 
motor while it draws the single line.   However, when it finishes and tries to 
return the pen home, it *unwinds* 10 full revolutions.  If the egg-axis is set 
to wrap, then we need to detect that we've wrapped around, and go the short way 
home.

EBB v 1.1 has 1/8 microstepping motor driver chips; newer boards have 1/16 
microstepping driver boards, giving 3200 steps/revolution. 

In normal use, the driver document is 3200 pixels wide; this should correspond 
to one full egg revolution.

Driver should auto-detect board type and scale appropriately.

What steps will reproduce the problem?
1. Any time I try to plot.

It would be super helpful to be able to have an ability to pause and/or cancel 
the plotter.  Otherwise, during testing, you waste a lot of time setting 
everything up.

Currently, when I try to cancel, the program just hangs and prints anyways.

Reported by Brian today.

* Issue appears to be windows only (no trouble reported on mac or linux), and 
not consistent. 

* Problem only appears on certain windows machines.  

We plan to migrate the (working) serial-connect code for windows from the wx 
development fork.

There is an "Engraving mode" option in the Eggbot Control GUI that is not yet 
implemented.

The plan is as follows: When the pen is down, we will turn on a digital output 
at location B3 on the EBB.  The 3-pin header on the EBB provides power, ground, 
and the signal output.  The signal output will be used to control a transistor 
that powers a small pager motor that vibrates a diamond tip against the object 
to be engraved.

I am able to roughly center a golf ball in my Egg-bot by moving the pen arm 
back and forth and watching the clearance between the pen tip and the ball 
surface.

It would be helpful to command the pen to move back and forth between the edges 
of the print field. The pen then would stop exactly in the center.

We have seen observed on more than one computer that using extremely long 
paths, such as the computational output from TSP art programs, can crash 
Inkscape, resulting in potential loss of data.  

The crash typically occurs when the Eggbot Control extension window is closed 
after performing complex plots.  As the operation of that dialog box is handled 
fully by Inkscape (not by the extension), it would indicate that the actual 
error is internal to Inkscape, or perhaps its handling of extensions. Using the 
same paths, we were able to cause separate crashes with some of the standard 
(built-in) extensions, which confirms that this issue is not eggbot specific. 

The fact that the crashes are not caused by the Eggbot extension is a mixed 
blessing. While it's nice to find that the fatal flaw is elsewhere, it is also 
the case that it's less easy for us to debug and fix.  If you see an error like 
this, please report it here, so that we can compile useful information towards 
a bug report for the Inkscape team.

First data point:  We have observed this problem on more than one 
recent-vintage Windows computer. Both had reasonably fast processors and 
seemingly ample RAM.

Originally Reported by westfw, May 25 (4 days ago)

None of the "extra" command or configuration windows seem to work using the
mouse to select; the buttons don't click.  (the "start" and "stop" buttons
in the main driver panel work correctly.)  However, you can change the
configuration by tabbing to the appropriate fields, entering new numbers,
and then tabbing to the "apply" button and using the space key to select it
instead of the mouse.  The same keyboard shortcuts work in the manual
control window as well.  (The mouse works for the Start/Stop buttons in the
Plotter window, and it works for selecting the window.  Odd; not the sort
of problem I'd expect it to have...)

Originally Reported by westfw, May 25 (4 days ago)
the windows version of inkscape currently includes its own copy of Python,
since it is somewhat unlikely that the average windows inkscape user will
already have installed python.  the windows pyserial installer looks for
python already installed, but cannot/doesn't find the version "under"
inkscape, so you have to install a separate version of python under
windows, install pyserial there, and then copy it to the inkscape python
directories...  (Ouch!)

Do you think it would be possible to include pyserial source in the eggbot
extension directory, and then have the GUI install it as appropriate in
Inkscape's copy of python?  Apparently the inkscape-included python isn't
quite complete enough to run stand-alone and I guess the pyserial installer
is actually written in python as well (at least, that was the case on the Mac.)

To prevent possible file export issues and to ensure future compatibility, 
there should be an option (or perhaps separate inkscape extension) to strip all 
eggbot-specific data from the inkscape SVG file.

While the Eggbot is plotting from within Inkscape, it will show you a window 
with a "cancel" button.  That button, unfortunately, doesn't actually do 
anything.  

This is a bug that has been reported to the Inkscape developers.  
Unfortunately, it does not appear that a fix is forthcoming in the near future.

https://bugs.launchpad.net/inkscape/+bug/591435

What steps will reproduce the problem?

1. Open the attached test.svg in Inkscape, looks like a nice big numeral "2"
2. Plot it on the Eggbot
3. Doesn't plot as large as you might expect, eh?

At issue is that the SVG document uses the "viewbox" attribute which is 
basically stating that the entire document needs a transform applied to 
transform from a width of 35.56 and height 8.89 to whatever the display 
dimensions are.

Not too sure how we will want to handle this.  In the short term, perhaps a 
warning about the "viewbox" is in order.  I do suspect that setting the initial 
transform to correspond to a scaling

scale(page_width/viewbox_width, page_height/viewbox_height)

is probably the correct solution.  The second test file, test2.svg, does this.

Widget is nonfunctional, should be replaced by a simple text entry box.

Software should be able to reverse either or both motor directions to 
accommodate different builds. 

Originally Reported by westfw, May 25 (4 days ago)
The "eggbot Manual Control" panel of the new GUI plot2eggbot extension
seems to have "pen motor" and "egg motor" buttons reversed.  that is, if I
select the "jog pen motor" button, the motor with the egg mounted on it turns.
I guess this could be a terminology difference too...
The actual plotting seems to get it correct; pen motor ranges from about
0 to 1000, egg motor varies from 0 to 3200...

As reported by dnewman, the Mac installer uses the wrong permissions for the 
pyserial folder.

Short-term fix: change the permissions on the folder

/Applications/Inkscape.app/Contents/Resources/extensions/serial/

so as to allow world access.


Long-term fix: create new version of installer.

Currently (in all known versions) it returns values 1 or larger if the pin is 
high.

Reported by user; lib hid-dev  not installed by default

If you do a 
SM,2,5000
bad things will happen from that point on.

Add code to trap for the max stepper speed allowed, and only go that high.

When I first tried the eggbot software I got invalid syntax errors on lines 705 
and 754.  I broke out the one-liner into what I think is equivalent code.  See 
attached diff.

My bot seems to work fine with these mods.

Wrong sign with respect to plotting coordinate system.

Reported today on the mailing list by BillW

Originally Reported by westfw, May 25 (4 days ago)
getSerialPort fails to work on MacOS (and probably not on linux), resulting
in an "eggbot not found" message.

You might think that "open the Nth serial port" would be a OS-independent
sort of action, but apparently this never does anything except on windows.
Mac and Linux will require looking for /dev/tty.usb* or similar, as per the
earlier version of the extension in the eggbot forums.

Excellent design, but instead of the pulldown menu & spinner box for moving 
motors, it would be helpful if there were dedicated buttons for each axis. 

The Makerbot ReplicatorG software has an excellent interface for jogging:
http://www.flickr.com/photos/makerbot/4562941397/

The arrow keys allow you to jog in any direction, and the selectable step size 
is handy too. Perhaps a custom step option would also be useful.

Right now, the manual jog feature makes several discrete steps at a fixed 
speed.  Instead, it should 
work at the speed defined by the user.

If the pen-up or pen-down sequence is slow enough, either through the actual 
servo command or through the following delay, it is possible to generate a 
serial timeout.

Proposed solution: split long delays and travels into shorter segments that are 
under 0.75 seconds in length, as we do with long motor movements.

The Inkscape extension plots paths in the order of objects that it encounters 
in the file.

It would be nice to have an option to optimize the order of plotting.   

Some things to consider:
* Optimization should only be performed manually as a separate option from 
plotting-- plot order should normally be under full user control.
* Optimization can only be layer by layer.  If the user wants to optimize the 
full drawing, then it should be converted to single-layer first.
* Reversing paths should be considered as an option
* A good figure of merit would be the total pen-up distance travelled. 
* The problem is computationally hard (TSP equivalent).  Approximate solutions 
should be considered acceptable.
* User should be informed of degree of optimization performed.

Or make them all ground. Either or, but not the way it is now, with one of them 
a copper polygon that's not ground (power even).

Reported by multiple users:
On complex files with multiple layers, it takes too long (minutes, sometimes) 
to begin plotting. 

The Eggbot Plot extension reads through the whole Inkscape file and starts 
plotting when it gets to the right layer.    And, once it finishes the correct 
layer, it scans through the rest of the layers until it reaches the end of the 
file.    This process can take a while, particularly if the file is very 
complex. 

The Eggbot Control extension silently ignores some unsupported SVG elements 
while providing warnings about other unsupported elements.

To the list of silently ignored elements a few additional elements should be 
added.  At the same time, a more helpful warning about embedded bitmaps might 
be provided.  Finally, the generic warning about unsupported elements 
encountered might include the element's tag name so as to aid in any diagnosis.

What steps will reproduce the problem?

1. Create an object
2. Select the object; reproduce it with Edit > Clone > Create Tiled Clones....
3. Plot the drawing with Eggbot Control; each clone of the object will be drawn 
atop the original

eggbot.py has support for the SVG "use" element.  This support has previously 
been tested by plotting some of the "use" examples from the SVG specification.  
However, it seems that this support in eggbot.py does not work correctly with 
the use of "use" generated by Inkscape when Inkscape generates clones.

(Minor architecture problem.)

The graphics generated by the Eggmazing contributed extension are not very 
friendly for new Eggbot users.  To get decent plotting results, there needs to 
be very minimal slippage while plotting.  That is, high plotting precision is 
required.

If the extension were to generate graphics which require much less precision, 
then it would be much more user friendly.

The present behavior of the "Start with pen centered" option is to take the 
pen's position at the start of the plot to be the point (x, y) = (x0, 500) in 
the Inkscape drawing where x0 is the x-coordinate of the first point of the 
first line segment in the drawing.  The fixed value of 500 derives from the 
historical usage of a 1000 pixel high drawing template.

Given the option's name, "Start with pen centered", this behavior is not what 
users might expect: the point (x0, 500) is seldom the center of the drawing.  
Nor is the Eggbot itself centering the pen.  Thus the existing behavior is 
somewhat at odds with common interpretations of the option's name.

This enhancement request is a request to make the behavior of the option more 
in agreement with a behavior suggested by the option's name: namely to take the 
pen's starting position to be at the center of the document containing the 
Inkscape drawing.  Namely to take the pen's starting position to be at the 
point (w/2, h/2) in the drawing where w is the drawing page's width and h is 
the drawing page's height.  These values are typically w=3200 and h=800.  And 
users may adjust them as they see fit with the "Document Properties..." item of 
Inkscape's "File" menu.

From a user request: for any command that take a number of steps, use 4-byte 
signed values rather than 2-byte signed values to give the ability for very 
long moves. The move time would also have to be extended as well.

Feature request from user:

Add command to EBB firmware to make it 'go forever at a constant speed' where 
the speed can be specified.

Originally Reported by westfw, May 25 (4 days ago)
If you "disable motors" in the manual control panel, and then "Start" a
plot in the plotter panel, the motors will of course be enabled, but the
Manual Control panel will continue to lave the button label "Enable motors."

Since the "pen up"/"pen down" buttons are not "smart", I don't think the
motor enable needs to be either.  Just have two buttons...

What steps will reproduce the problem?
1. I put the eggbot_hatch.py and eggbot_hatch.inx files at 
/usr/share/inkscape/extensions/ directory
2. I open Inkscape
3. The hatch extension is not there

What is the expected output? What do you see instead?

The extension is not loaded

What version of the product are you using? On what operating system?

r221

Please provide any additional information below.

Inkscape claims when parsing the .inx file, the output goes attached. But the 
.inx seams to be ok. BTW I am using Sozi Inkscape extension, but I don't 
believe there is any conflict between extensions.

If there is an XML comment (or processing instruction) buried in the SVG 
document, this can cause recursivelyTraverseSvg() to issue a warning while 
plotting about an element which needs to be converted to a path.  This, because 
the XML comment node shows up as an SVG "element" we don't recognize.  (It's 
not actually an XML "element" per se.)

Detecting this is easy enough in eggbot.py, albeit not immediately obvious.  We 
need to use an instanceof() check t see if the node's "tag" in the lxml.etree 
we're traversing is of type "basestring" or not.  If it is, then it's some sort 
of XML element.  If it isn't, then it's a processing direction or comment which 
we can ignore.

>>> a=lxml.etree.XML("<a><!-- comment --><b/></a>")
>>> a[0].tag
<built-in function Comment>
>>> a[1].tag
'b'
>>> isinstance(a[0].tag, basestring)
False
>>> isinstance(a[1].tag, basestring)
True
>>> 

OriginallyReported by westfw, May 25 (4 days ago)
Trying to run the inkscape extension on MacOS results in a traceback:

 Traceback (most recent call last):
  File "Contents/Resources/extensions/plot2eggbot.py", line 2, in <module>
    import wx
  File
"/BinaryCache/wxWidgets/wxWidgets-
11~88/Root/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/py
thon/wx
-2.8-mac-unicode/wx/__init__.py",
line 45, in <module>
  File
"/BinaryCache/wxWidgets/wxWidgets-
11~88/Root/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/py
thon/wx
-2.8-mac-unicode/wx/_core.py",
line 14007, in <module>
  File
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/locale.p
y",
line 512, in getpreferredencoding
    setlocale(LC_CTYPE, "")
  File
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/locale.p
y",
line 476, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

A hint was found here:
  http://fatvegan.com/2007/03/14/localeerror-unsupported-locale-setting/
And I was able to make that change and write the modified locale.py (from
/usr/lib/...) to the
Inkscape.app/Contents/Resources/python/site-packages/i386/2.5/locale.py
where it was apparently picked up by the inkscape-specified path, but
Windell says there was no locale.py found on a snow-leopard mac.

I'm using the EBB to drive a laser cutter, with good success.  However, with 
this platform, the ability to use limit switches to find a "home" position 
would be particularly useful.  The laser cutter already has
the limit switches (actually optical sensors) that provide a signal
when the gantry has reached the minimum X and Y positions.  This is
also one of the possible "hacks" discussed on the EggBot wiki: 
http://wiki.evilmadscience.com/Hacks

There
would be several ways to attack this with the EBB, depending on how
automatic and configurable it's worth being.  The fanciest approach
would have a command to specify the X and Y limit switch I/O pins, logic levels,
and motor directions, and have a "home" command to run the steppers
until the limits were reached.  The most trivial one would have a
command to read a known I/O pin or two, and the host code could
alternate between small moves and running that command to find the
home position.

A logical compromise might be to have a command to run a single axis
until an I/O pin changed to a particular logic state.  The direction,
distance, speed, I/O pin, and logic state could be fixed or configurable.

Originally Reported by brian.schmalz, May 26 (4 days ago)
Right now it's still listed as v1.0, and has been for several 'versions' now.

In some instances, when plotting SVG output from Adobe Illustrator, the pen arm 
will try to go past its drawing limits on the Eggbot (i.e., run up to the head 
or tail stock before drawing).  This can occur when Illustrator produces a SVG 
document which uses the min-x and min-y parameters o the SVG viewBox attribute.

The Eggbot Control extension needs to take this information into account when 
plotting.

Originally Reported by westfw, May 25 (4 days ago)

If you make changes and "apply" them in the Configuration menu (servo
up/down position, step speed, etc), those changes will be sent to the
eggbot board the next time "Start" is clicked to begin the plot, but the
changes are NOT picked up when you move to the "Manual Control" window in
an attempt to try them out...

The latest hardware versions of the EBB (1.5 and 2.0) with the latest firmware 
(2.0.1) have the ability to monitor the power input from the wall. Because the 
boards are also powered from USB, you can't easily tell (from the LEDs, for 
example) if you've got good wall power on your EggBot.

This is a request to add a feature to the Inkscape extension that would query 
the EBB for the current voltage level at the power input jack, and warn the 
user if they try to run their EB without power (or with power less than, say 
8V).

The EBB command to use is the QC command.

Trying to plot a multi-layer image in Ubuntu (Lucid), with the "pause between 
layers" option turned 
on causes the extension to crash and exit back to inkscape.  

Best guess: something is wrong with the dialog box code.

No error is encountered if "pause between layers" is turned off.