Code Monkey home page Code Monkey logo

eggbot's People

Contributors

berleant avatar cabalist avatar embeddedman avatar jbaehr avatar jrheard avatar mutoo avatar oskay avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

eggbot's Issues

Add new "XM" command for mixed-axis stepper moves

Feature request: Add a new command, that simplifies use of the EBB in machines that have mixed-axis geometry, such as H-Bot and CoreXY.

In machines with these and similar geometries, the rotation of a single stepper motor causes a translation of the machine's end effector in a direction diagonal to the machine's cartesian axes — i.e., in the ± (X + Y) or ± (X - Y) directions. This is a well-understood type system, and is usable as-is with the EBB. However there are certain circumstances, such as during initial setup and test, where it is convenient to be able to issue an EBB command to move the machine directly alone its cartesian axes.

I would propose to add the following command to the EBB command set:
"XM,<move_duration>,<axisA>,<axisB><CR>"

Executing this command would be equivalent to executing:
"SM,<move_duration>,<axis1>,<axis2><CR>",
where <axis1> = <axisA> + <axisB> and <axis2> = <axisA> - <axisB>

@EmbeddedMan, I have assumed that this is straightforward, and could be done by (insert hand-waving here) having the XM command internally call the SM command. If it is not straightforward — for any reason — please say so. :)

Add formal support for multiple motor resolutions

All "stock" EggBot kits use a total of 3200 steps per revolution. Current versions have 200 step/revolution motors and 16X microstepping drivers. Some beta models had 400 step/rev motors and 8X microstepping drivers. However, it is also possible to construct versions with

  • 1600 steps/rev (e.g., with 8X drivers and the 200 step/rev motors), or
  • 6400 steps/rev (e.g., with 16X drivers and the 400 step/rev motors).

The software needs to know the number of steps per revolution in order to properly scale the motor motion to the standard template, as well as to know when it is safe to "wrap around" an object to save pen-up travel distance.

Ideally, we would like to natively support these configurations:
1600 step/rev
3200 step/rev (default)
6400 step/rev

Tiresome extraneous warnings during single-layer plots

In the following situation the user gets multiple extraneous error warnings:

  • Using the "Layers" tab
  • There is a non-numbered layer with a non-plottable item on it, perhaps an image or some text

Each time user plots a numbered layer, a warning dialog is presented to inform user that the non-plottable item is non-plottable. This occurs for each and every numbered layer user plots, despite the fact that user has not numbered the non-plottable layer and therefore is not requesting it be plotted. This gets rather "old" rather quickly, at least when user has more than a handful of pen changes.

A proposed fix is attached.

In addition, this fix also attempts to clarify proper warnings of numbered non-plots, by identifying the name of the offending layer. An example of a possibly-cryptic warning is: " unable to draw flowRoot object, please convert it to a path first." At any rate, it is cryptic to those such as I who do not immediately recognize the term "flowRoot".

eggbot.zip

Plotting fails if layer names contain unicode characters

Plotting a single layer fails if layer name contains unicode characters.
For example, try plotting layer 3 from this file: http://www.thingiverse.com/download:1219530

Traceback (most recent call last):
  File "eggbot.py", line 1154, in <module>
    e.affect()
  File "C:\Program Files (x86)\Inkscape\share\extensions\inkex.py", line 268, in affect
    self.effect()
  File "eggbot.py", line 220, in effect
    self.plotToEggBot()
  File "eggbot.py", line 440, in plotToEggBot
    self.recursivelyTraverseSvg( self.svg, self.svgTransform )
  File "eggbot.py", line 499, in recursivelyTraverseSvg
    self.DoWePlotLayer( node.get( inkex.addNS( 'label', 'inkscape' ) ) )
  File "eggbot.py", line 898, in DoWePlotLayer
    if str.isdigit( CurrentLayerName[:stringPos] ):
TypeError: descriptor 'isdigit' requires a 'str' object but received a 'unicode'

Easy fix:

diff --git a/inkscape_driver/eggbot.py b/inkscape_driver/eggbot.py
index b209b29..d24fa0b 100755
--- a/inkscape_driver/eggbot.py
+++ b/inkscape_driver/eggbot.py
@@ -884,7 +884,7 @@ class EggBot( inkex.Effect ):

                TempNumString = 'x'
                stringPos = 1
-               CurrentLayerName = string.lstrip( strLayerName ) #remove leading whitespace
+               CurrentLayerName = string.lstrip( strLayerName.encode( 'ascii', 'ignore' ) ) #remove leading whitespace

                # Look at layer name.  Sample first character, then first two, and
                # so on, until the string ends or the string no longer consists of

Spiral Wrapped Text extension fails if text contains any markup entities

If text contains any '&' entity, such as &amp;, it produces the following error:

Traceback (most recent call last):
File "eggbot_spiraltext.py", line 400, in
e.affect()
File "C:\Program Files (x86)\Inkscape\share\extensions\inkex.py", line 268, in affect
self.effect()
File "eggbot_spiraltext.py", line 366, in effect
markup = processMarkup( self.options.text, self.options.fontfamily )
File "eggbot_spiraltext.py", line 216, in processMarkup
if entity_refs.has_key[eref]:
TypeError: 'builtin_function_or_method' object is unsubscriptable

A small patch is necessary:

diff --git a/inkscape_contributed/eggbot_spiraltext.py b/inkscape_contributed/eggbot_spiraltext.py
index d453f3a..3a0fba2 100755
--- a/inkscape_contributed/eggbot_spiraltext.py
+++ b/inkscape_contributed/eggbot_spiraltext.py
@@ -213,7 +213,7 @@ def processMarkup( text, family='sans' ):
                        j = text.find( ';', i+1 )
                        if ( j != -1 ):
                                eref = text[i:j+1]
-                               if entity_refs.has_key[eref]:
+                               if entity_refs.has_key(eref):
                                        outstr += entity_refs[eref]
                                        i = j + 1
                                else:

PenDown uses PenUp delay

Correct me if I'm wrong, but it looks as though a copy-and-paste operation went awry in the following code (check out the delay specified in the last line):
def penDown( self ): self.virtualPenIsUp = False # Virtual pen keeps track of state for resuming plotting. if (self.bPenIsUp != False): # Continue only if pen state is up (or unknown) if ( not self.resumeMode ) and (not self.bStopped): # skip if we're resuming or stopped self.bPenIsUp = False if self.penDownActivatesEngraver: self.engraverOn() # will check self.enableEngraver ebb_motion.sendPenDown(self.serialPort, self.options.penUpDelay )

Invalid comparison between string and number for viewbox determination in eggbot.py

Reported by Matthew Beckler as https://code.google.com/p/eggbotcode/issues/detail?id=74

Here is the code section:

# Viewbox handling
# Also ignores the preserveAspectRatio attribute
viewbox = self.svg.get( 'viewBox' )
if viewbox:
    vinfo = viewbox.strip().replace( ',', ' ' ).split( ' ' )
    if ( vinfo[2] != 0 ) and ( vinfo[3] != 0 ):   # <-------------------------- this line here ------------<<
        sx = self.svgWidth / float( vinfo[2] )
        sy = self.svgHeight / float( vinfo[3] )
        self.svgTransform = parseTransform( 'scale(%f,%f) translate(%f,%f)' % (sx, sy, -float( vinfo[0] ), -float( vinfo[1] ) ) )

The issue lies with the "if ( vinfo[2] != 0 ) and ( vinfo[3] != 0 ):" line. vinfo is a list of strings, and a comparison is being done to see if two of these strings are not equal to the numeric value 0. Even if the string value in vinfo[2] or vinfo[3] is "0", that is never equal to the numeric value 0 in an inequality check like this. That is, (vinfo[2] != 0) always evaluates to True, because every string is not equal to 0.

I think we should probably wrap vinfo[2] and vinfo[3] in calls to float, making that line instead be:
if ( float(vinfo[2]) != 0 ) and ( float(vinfo[3]) != 0 ):

Again, this probably never causes trouble but is an easy fix. Here's a very small patch for it:

--- eggbot.py   2014-03-21 10:05:49.222832100 -0500
+++ eggbot_fix.py       2014-03-21 10:06:27.758685300 -0500
@@ -526,7 +526,7 @@
                viewbox = self.svg.get( 'viewBox' )
                if viewbox:
                        vinfo = viewbox.strip().replace( ',', ' ' ).split( ' ' )
-                       if ( vinfo[2] != 0 ) and ( vinfo[3] != 0 ):
+                       if ( float(vinfo[2]) != 0 ) and ( float(vinfo[3]) != 0 ):
                                sx = self.svgWidth / float( vinfo[2] )
                                sy = self.svgHeight / float( vinfo[3] )
                                self.svgTransform = parseTransform( 'scale(%f,%f) translate(%f,%f)' % (sx, sy, -float( vinfo[0] ), -float( vinfo[1] ) ) )

Alternatively, we could just use map to cast all the entries of vinfo into floats right away, and remove the float calls from the lines afterward:

--- eggbot.py   2014-03-21 10:05:49.222832100 -0500
+++ eggbot_fix_2.py     2014-03-21 10:14:22.526157300 -0500
@@ -525,11 +525,11 @@
                # Also ignores the preserveAspectRatio attribute
                viewbox = self.svg.get( 'viewBox' )
                if viewbox:
-                       vinfo = viewbox.strip().replace( ',', ' ' ).split( ' ' )
+                       vinfo = map(float, viewbox.strip().replace( ',', ' ' ).split( ' ' )) # convert all items to float
                        if ( vinfo[2] != 0 ) and ( vinfo[3] != 0 ):
-                               sx = self.svgWidth / float( vinfo[2] )
-                               sy = self.svgHeight / float( vinfo[3] )
-                               self.svgTransform = parseTransform( 'scale(%f,%f) translate(%f,%f)' % (sx, sy, -float( vinfo[0] ), -float( vinfo[1] ) ) )
+                               sx = self.svgWidth / vinfo[2]
+                               sy = self.svgHeight / vinfo[3]
+                               self.svgTransform = parseTransform( 'scale(%f,%f) translate(%f,%f)' % (sx, sy, -vinfo[0], -vinfo[1]) )

                self.ServoSetup()

EggBot_250A.exe Windows installer fails if "Inkscape Extensions" unchecked

If you run the EggBot Windows installer, and uncheck the "Inkscape Extensions" box in the "Choose Components" window but leave the "USB Driver" box checked, the installer will generate the following errors when you click "Install":

"Error opening file for writing: \Driver\mchpcdc.cat"

I think what's happening is that the installer doesn't know how to unpack and run the USB Driver installer files if the "Inkscape Extensions" don't get installed first. This happens even on machines where Inkscape is already installed and on machines where it is not already installed. My guess is that there is something in the installer script that the USB Installer section needs, but it is turned off if the Inkscape Extensions are not installed.

Tested on Win7, Win8.1 and Win10, and they all appear to behave the same.

Improve Reorder Paths for Speed extension

Copied from https://code.google.com/p/eggbotcode/issues/detail?id=19

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 (that performs better than existing extension).

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.

Path reorder fails

Whenever I try to reorder paths I get this error: Do I have to preprocess the file in some way?
Traceback (most recent call last): File "eggbot_reorder.py", line 170, in <module> e.affect() File "/Applications/Inkscape.app/Contents/Resources/share/inkscape/extensions/inkex.py", line 268, in affect self.effect() File "eggbot_reorder.py", line 149, in effect item = ( id, self.get_start_end( node, transform ) ) File "eggbot_reorder.py", line 108, in get_start_end sp = simplepath.parsePath( d ) File "/Applications/Inkscape.app/Contents/Resources/share/inkscape/extensions/simplepath.py", line 90, in parsePath token, isCommand = lexer.next() File "/Applications/Inkscape.app/Contents/Resources/share/inkscape/extensions/simplepath.py", line 31, in lexPath length = len(d) TypeError: object of type 'NoneType' has no len()

Upper/lower limit of step moves seems to be +/- 65535

From the documentation, for firmware 2.2.7 the number of steps should be a 32-bit signed integer. It seems to only accept a 16-bit signed integer. Output from my test program (note that KeyboardInterrupt triggers an EStop):

In [4]: ic.mc.sendCMD('SM,10000,0,-65535')
ic.mc.sendCMD('SM,10000,0,-65535')
Out[4]: 'OK'

In [5]: ic.mc.sendCMD('SM,10000,0,-65536')
ic.mc.sendCMD('SM,10000,0,-65536')
Out[5]: 'Major malfunction Axis2 StepCounter too high : 420906'
...
In [7]: ic.mc.sendCMD('SM,10000,0,65536')
ic.mc.sendCMD('SM,10000,0,65536')
Out[7]: 'Major malfunction Axis2 StepCounter too high : 420906'

In [8]:
KeyboardInterrupt

In [8]: ic.mc.sendCMD('SM,10000,0,65535')
ic.mc.sendCMD('SM,10000,0,65535')
Out[8]: 'OK'

Finish EBB Firmware 2.4.0 release

AxiDraw is currently shipping with the experimental EBB 2.4.0 firmware (adding the "AM" command), but this firmware does not have a binary release, currently. @EmbeddedMan, can you please wrap this one up?

Suggestion: Provide USBDriverInstaller as separate download

(Windows problem only) If somebody wants to use an EBB without Inkscape, they currently have to download EggBot_250A.exe on a machine that does have Inkscape, run it, then go to C:\Program Files\Inkscape\Driver and copy that folder over to the machine without Inkscape so they can run USBDriverInstaller.exe to install the EBB drivers.

Would it be possible to package just the Driver directory in it's own ZIP file which can then be made available for download separately? It would not need to be part of the EggBot repo so that it doesn't confuse folks who are downloading the whole EggBot software package.

Very very minor issue: X-wrap will be ignored sometimes

I mention this issue not because it's important, but because it involves pen up/down logic and I just want to check that there is no larger problem:

  • When the pen is plotting at a distance from the document border - for example when doing a spiral-text plot - and
  • if user presses the "pause" EBB button, and
  • user then selects "Resume" tab, and
  • user checks "Cancel and return home only"
    then
  • the self.bPenIsUp variable is uninitialized, and therefore
  • plotLineAndTime() will ignore user's x-wrap selection, and
  • will perform as many egg revolutions, at pen down speed, as it takes to get back home.

A possible fix is shown in the attached image, but it may be that this is but a bandaid for a larger problem? or a different problem?? Dunno, but just wanted to bring it up.

fix undefined pen up-down after resume

Handle flowtext error more gracefully

When encountering flowtext, (text typed in a box), the error is presented as:

 Warning: unable to draw <flowRoot> object, please convert it to a path first.

It should instead either be ignored, or handled the same way that text is.

Communication error could be salvaged in some cases

Currently if there is a persistent communication breakdown in plotLineAndTime which ends up returning a null from ebb_motion.QueryPRGButton(self.serialPort), then python aborts the plot with a runtime error message. This loses position reference for the plot, and thus the entire plot is ruined.

The suggested change incorporated in the attached file explicitly looks for a null response. Here if a null response occurs, the program substitutes a simulated push of the pause button. Therefore the user may be able to use the "Resume" to rescue the plot, after fixing the communication problem.

The attached file is built from a base of the proposed fix for issue 45.

eggbot (2).zip

Add "QM" (Query Motor) command to EBB firmware

This command should allow a user to see the state of the 'motion engine' and each motor individually. If there are any commands that cause some action (SM, TP with a duration, etc.) then the should be non-zero. The other two parameters only show if a motor is moving or not.

If the PC is sending long move commands, this can be used as a crude flow control mechanism to know when to send the next command. (I.e. after the motion has stopped).

// For Query Motor - returns the current status of each motor
// QM takes no parameters, so usage is just QM
// QM returns:
// QM,,,
// where:
// : 0 if no 'motion command' is executing, > 0 if some 'motion command' is executing
// : 0 if motor 1 is idle, 1 if motor is moving
// : 0 if motor 2 is idle, 1 if motor is moving

ebb_motion.QueryPRGButton(self.serialPort) can fail and cause plot to fail

  1. This is not related to recent changes regarding skip-pen-up-down, because it also occurs in v. 2.7.4 of eggbot.py. While attempting to debug the issue, I downloaded v. 2.7.5 so further debugging was/is with this version.
  2. May well be timing related, but it IS reproducible ( perfectly, without fail in several dozens of trials) here...at the 2950th node count of layer 2 of the attached .svg file. Accessed thru the Layers tab of Eggbot Control.
  3. A debugging statement inserted just before the python error issues at the last line in this snippet
    shows that strButton is in fact of zero length, so Python is correct in its error statement: "IndexError: string index out of range"
    strButton = ebb_motion.QueryPRGButton(self.serialPort)  #Query if button pressed
    if len(strButton) == 0:
        inkex.errormsg( 'NULL strButton' )

    if strButton[0] == '1': #button pressed [ERROR HERE WHEN strButton IS NULL]

cottage06 before stretch after anti-bulge+stretch.zip

EBB Firmware: Add Abort command - to stop long moves

Migrated from original report by @EmbeddedMan : https://code.google.com/p/eggbotcode/issues/detail?id=80

"Once we add 3 byte long step and duration parameters for the SM command, and add commands for homing, we start to see some things take very long times (a 3-byte duration in milliseconds is 4.7 hours). If something goes wrong, or you need to bail on a long command, it would be very useful to have an 'abort' command that would allow you to stop a long move or a home operation.

Note that, with the current system of flow-control built into USB, if you send two long SM commands back to back, the abort won't do you any good because it can't be processed until after the second long move is processed.

However, if you're careful, just send out one long move at a time, then you can abort.

In the future, we can make a more sophisticated flow control method (where there is a longer FIFO of queued moves in the EBB, and the USB interface never blocks) or something like that, and then the abort will have more meaning.

We could also use a digital input as an abort. Right now, the PRG button acts as a 'pause' button, but this is something handled up at the application level (Inkscape) rather than at the EBB level. Having a hardware Estop input might be really nice."

Update installers for Inkscape 0.91

Inkscape 0.91 will be released soon ("weeks to months"), and we would like to be ready. The current installer is not compatible with Inkscape 0.91.

Todo:

  • Check compatibility of Inkscape extensions with 0.91
  • Update installers with new file locations for 0.91.
  • Only install Hershey Text if Inkscape version is < 0.91.

For MacOS, the location of extensions in Inkscape 0.48.5 is:
/Applications/Inkscape.app/Contents/Resources/extensions/

However, in 0.91 the new location is:
/Applications/Inkscape.app/Contents/Resources/share/inkscape/extensions

Return steps moved so far when aborting move

This would be an enhancement to the brand-new much-appreciated EStop command:
(I don't have a working compiler for the firmware, so I can't test this, so it's not a proper pull request)

I wonder if this patch would make it possible to get back the number of steps actually moved before abort:

diff --git a/EBB_firmware/app.X/source/ebb.c b/EBB_firmware/app.X/source/ebb.c
index 1daa381..37ba6a0 100644
--- a/EBB_firmware/app.X/source/ebb.c
+++ b/EBB_firmware/app.X/source/ebb.c
@@ -1050,18 +1050,20 @@ static void process_SM(

 // E-Stop
 // Usage: ES<CR>
-// Returns: 0 if SM command was not interrupted, 1 if it was, then OK<CR>
+// Returns: <command_interrupted>,<steps_achieved1>,<steps_achieved2><CR>OK<CR>
 // This command will abort any in-progress motor move (SM) command.
 // It will also clear out any pending command(s) in the FIFO.
-// It will return with a 1 if an SM command was aborted or if an SM command 
-// was waiting in the FIFO and had to be discarded. This 1 indicates that some
-// position information may be lost, since one or more SM commands was not
-// finished.
-// It will return a 0 if no SM command was executing at the time, and no SM
-// command was 
+// It will return with a 1 for command_interrupted if an SM command was aborted 
+// or if an SM command was waiting in the FIFO and had to be discarded. 
+// The next return values steps_achieved1 and steps_achieved2 are then the number 
+// of steps that were moved on axes 1 and 2 before the abort command was sent.
+// It will return 0,0,0 if no SM command was executing at the time, and no SM
+// command was in the FIFO.
 void parse_ES_packet(void)
 {
-    UINT8 retval = 0;
+    UINT8 retval1 = 0;
+    UINT32 retval2 = 0;
+    UINT32 retval3 = 0;

     // If there is a command waiting in the FIFO and it is a move command
     // or the current command is a move command, then remember that for later.
@@ -1071,7 +1073,7 @@ void parse_ES_packet(void)
         CurrentCommand.Command == COMMAND_MOTOR_MOVE
     )
     {
-        retval = 1;
+        retval1 = 1;
     }

     // If the FIFO has a move command in it, remove it.
@@ -1087,11 +1089,13 @@ void parse_ES_packet(void)
     if (CurrentCommand.Command == COMMAND_MOTOR_MOVE)
     {
        CurrentCommand.Command = COMMAND_NONE;
+       retval2 = CurrentCommand.StepsCounter[0];
+       retval3 = CurrentCommand.StepsCounter[1];
         CurrentCommand.StepsCounter[0] = 0;
         CurrentCommand.StepsCounter[1] = 0;
     }

-    printf((far rom char *)"%d\n\r", retval);
+    printf((far rom char *)"%d,%d,%d\n\r", retval1, retval2, retval3);
        print_ack();
 }

eggbot_stretch works well for spheres, but...

This is not, by a long shot, a big deal - but I think the stretch algorithm could have just a little bit of refinement added to it. The current version, nice as it is, nonetheless maps the stretch function as though the print were on a sphere.

I wonder if the data/methods presented at http://www.takayaiwamoto.com/Egg_Draw/Real_Chicken_Egg.html might be used to do a more accurate mapping of SVG coordinates to the egg ovoid. A rough test, based on the below image, shows that the differential error between a sphere and the large end of an egg may be as much as 33%.

I say this in the full realization that +/- nobody will really notice the difference, but I still would be happy to take a shot at it. If further data presents itself, one might even consider having separate settings for ostrich, duck, chicken.

stretch for ovoid 01

Feature request: A pen alignment method might be useful

I assume I'm not alone when it comes to using more than one brand of pen on the same egg. For example, I like to use a Copic 0.2mm marker for the black, while using Sharpie ultra-fine for the colors. The offset from the pen-holder to the pen tip varies depending on pen brand and osmosis, resulting in mis-alignment of different layers.

I envision a system where user gets to specify an unused section of the egg as an alignment test section. User goes there with each change of pen, and walks pen/egg until a pen "peck" lines up with the peck from previous pen.

As luck would have it, I've been working on just such a feature for myself - if it would be useful, I could submit code.

Update instructions for installation

Current folder structure makes no sense and full of stuff that has nothing to do with instructions on wiki, how does one supposed to install the drivers and inkscape extension? I've read and re-read instructions 100 times, still can't install the driver, from where, which file, which folder?

Extensions / Eggbot contributed / Stretch... fails with circle

Stretch generates the following python error statement when I run it on a single circle. If the circle is embedded in a more complex drawing, stretch still fails. Circle can be any reasonable size.

I have a proposed fix, listed below the traceback.
Here's the traceback:

Traceback (most recent call last):
File "eggbot_stretch.py", line 673, in
e.affect()
File "C:\Program Files\Inkscape\share\extensions\inkex.py", line 268, in affect
self.effect()
File "eggbot_stretch.py", line 654, in effect
self.recursivelyTraverseSvg( self.document.getroot(), self.docTransform )
File "eggbot_stretch.py", line 347, in recursivelyTraverseSvg
self.recursivelyTraverseSvg( node, matNew, v, find_bbox )
File "eggbot_stretch.py", line 517, in recursivelyTraverseSvg
self.mapPathVertices( d, node, matNew, find_bbox )
TypeError: mapPathVertices() takes exactly 2 arguments (5 given)

Proposed fix:
Replace line 517 which is currently:

self.mapPathVertices( d, node, matNew, find_bbox )

With the following:

self.getPathVertices( d, node, matNew, find_bbox )

Reduce number of pen lifts in hatch fill

A drawback of the current hatch fill is that it takes a very long time for the plot to complete if there are a lot of hatch lines. If some of the pen lifts could be avoided, the hatch fill would be substantially more usable.

I have been working on this problem, and believe I'm getting very close to a real improvement in plotting speed. The only problem is, my coding style is not up-to-snuff. So...question: is there a coding standards document to which I can refer?

Set Engraver (SE) command is not synchronized with the stepper motors

Regarding timing, the Set Engraver (SE) command behaves differently from the Set Pen (SP) command and the Stepper Motor (SM) command because it is executed immediately. Therefore the engraver is not synchronized with the motion of the stepper motors when more commands are sent to the EBB at once. It would be nice to set PWM for the engraver using the CommandFIFO as it is in the case of SE and SP because then it would be possible to change PWM for the engraver along the path.

Auto detect lack of power from wall adapter

Copied from issue by @EmbeddedMan (Brian Schmalz) at Google Code: https://code.google.com/p/eggbotcode/issues/detail?id=22

"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."

From Ragstian:
"Code to manually read the voltage and current setting has been added to the eggbot extension, (eggbot.py and eggbot.inx). See this forum thread for the updated files.
http://forum.evilmadscientist.com/discussion/337/checking-ebb-motor-voltage-from-inkscape#Item_17 "

From Brian:
"The code that ragstian added works to properly detect the input voltage to the EBB. Note, however, that you need to use v2.2.3 of the EBB firmware in order for this to work correctly. Previous versions had a semi-broken QC command.

At this point, I think all it would take is a little python to send the QC command and verify a minimum voltage (say 8.5V) before the beginning of a plot."

Update StippleGen for current version of Processing

From: https://code.google.com/p/eggbotcode/issues/detail?id=58

"Steps to reproduce the problem:

  1. Install and run Processing 2.0 beta 6
  2. Install Control P5 and Toxiclibs and restart Processing.
  3. Open StippleGen_2.pde and run it.

StippleGen's UI should launch but does not.
Error displayed: "The method selectInput(String, String) in the type PApplet is not applicable for the arguments ()"

StippleGen 2.02
processing 2.0b6

I attached a patch that moves the file/path validation to the two callbacks now required by selectInput and selectOutput. Some other minor changes due to the fact that these methods no longer return a String object."

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.