[StefanL38]

Hi Windell,

I made the modification factors 10000 and 10 to setup higher speeds.

Through step_scaling_factor = 0.5  now I can use the standard svg-files without modifiyng 

the documentsize to 6400×1600. And this did even cover speed-adjusting.

Thank you very much for the tip.

As I could test now higher speeds. It turned out that my arm is not stiff enough for speeds of more than 1200 steps

per second. (which means 2400 steps per sec for a 400-fullstep/rev motor)

I found another thing that is a bit annoying. Somewhere in the sourcecode I read that 

if option start centered is chosen the first line has to start at a centered position.

What’s so hard about calculating the difference between a first position with ANY coordinates

and the centered position?

As I started to modify the code. I have several ideas how to polish the code 

remove hard coded factors that they CAN be replaced through parameters

if parameter not found use hardcoded default value.

How about using the *.INI-file standard Identifier=value?

I’m a delphi programmer

does python support INI-file-reading writing with commands or would I have to write everything from scratch?

changing move-direction in the manual register through +- is annoying. 

How about more buttons to just do a click on each command?

Where is the GUI of the eggbot control defined?

How much evolution of the python-code would you allow?

should it be 100% downwards compatible or would you allow changing some things?

best regards  

Stefan

[StefanL38]

Hm that’s seems to be pretty hard to do.

Why would you like to take out the egg and then put it into the eggbot again? Why not do all the marking at once?

my spontaneous ideas:

two sticks in V-shape above and below the egg to center the egg while rotating the egg axle

mounting a non-marking pen doing a “dummy marking”

mounting a laserpen with a real small light-point starting a dummy-marking of adjustable length (number of lines) watching the deviation and then correct egg or arm-position

repeat this until dummy-marking fits sufficient to existing marking

best regards  

Stefan 

[StefanL38]

Hi Windell,

thank you very much for your answer.

I will test this tomorrow.

How about a pen-adapter for exact repositioning made by a 3D-printer?

best regards  

Stefan 

[StefanL38]

Hi Ragnar,

I guess my motors can move pretty fast because of the specs

current up to 1.7A holding torque 0,89 Nm.

I bought them from here

http://www.pollin.de/shop/dt/NTQ1OTg2OTk-/Motoren/Schrittmotoren/Schrittmotor_PSM57BYGHM201_0_9_.html

For pen Up/Down I got the idea of a linear magnet. But maybe the move down is to fast damaging the pen.

Would you mind to share your modified construction?

For exact repositioning the pens. One idea that I have is to mount some kind of quick mount/release part

on the pens which have a standardised shape which can be mounted / released easily in an exact position

on the arm. some kind of a cone or at least something rectangular where you push both parts together

on plane surfaces.

As I have looked into the code. The protocol seems to be quite simple. Send duration, Motornumbers and coordinates sending back “OK”

I’m coding for the 8-core propellerchip. There are step/dir drivers that include ramping. 

But I guess it is still some weeks of work to get a propeller-based EBB to work with the existing

EggBot-extension.

best regards  

  Stefan 

[StefanL38]

EDIT2:

through some more try and error I found this codeline

strOutput = ‘,’.join( ) + ‘r’  #this line determines the plotting-speed 

The first parameter of the SM-command is “duration” which means the time within the move to the new coordinates

shall be finished. So a smaller value means less time => higher speed. So I added a “/ 4” divide by four

to get shorter duration-values. This means now the speeds setup in the eggbotcontrol must be multiplied by 4

to get the real speed. 

But that’s no good coding-style. Can somebody explain to me how the code works or modifying the code in a way that higher speeds than 1000 steps/per second is possible and the speed-value in the eggbot-control represents the real speed? 

The construction of my DIY-eggbot-mechanic has to parts that form the arm holding the pen.

Inside this arm there is a little play (space) which means the horizontal part of the arm can move a little bit where it shouldn’t. You can seen this at higher speeds as overmove of the pen through inertia. 

Any ideas on how to get rid of the play? The original Kit has a a plastic joint which is just one part.

Very clever solution cheap and stiff against moving and as it is just ONE part there is no space for play possible.

 best regards  

  Stefan 

[StefanL38]

OK so I have done some more tests.

As long as I run the motors over the manual function I can increase speed up to 10000 steps per second.

the Inkscape-plugin limits the speed to this value. So as the number of steps is limited to 3200 steps through 

the inkscape-plugin.

in plotting a drawing thinkgs work as expected up to a speed of 1000 steps/sec.

As soon as I go over this limit even at 1001 steps/sec The motors are driven at a much higher speed.

I estimate 5000-10000 steps per second. It is the same thing for speed pen up and pen down.

Whenever one or both of the speeds are over 1000 steps/sec the motors run at a much higer speed when I try

to plot a drawing.

So does this mean that the InkScape-plugin has a bug that it calculates the wrong speed?

EDIT:

I took a look into the python sourcecode

I guess these lines cause the problem

self.nTime = int( round( 1000.0 / self.fSpeed * distance( self.nDeltaX, self.nDeltaY ) ) )

strOutput = ‘,’.join( ) + ‘r’

self.doCommand( strOutput )

nTime = int( math.ceil( 1000 / self.fSpeed * distance( self.nDeltaX, self.nDeltaY ) ) )

I did’nt analysed the code in detail but I guess because these calculations are based on “1000” 

that values above 1000 are causing the problem.

best regards  

Stefan

[StefanL38]

Hi Ragnar,

yes the Egg(x) axis wraps around option is activated. should it be disabled?

best regards  

Stefan

[StefanL38]

Hi Brian,

thank you very much for your testings and info. Next thin I will do is checking the firmwareversion.

I noticed another effect/bug.

With a 400 steps per rev. Motor the canvas is 6400×1600 steps. If I use the hole area of 6400 steps

some parts of the drawing is shifted to another position. So this caused me to think that the software is “thinking” 

oh I’m near to one full revolution (which normally is 3200) I’ll do move optimisation and moving backwards to the new position. 

As long as I do a move that does only move the egg-axle everything is OK but if a try to draw some small rectangles

that are distributed over an area of 6400 pixels the rectangles that are beyond the 3200 steps border get misplaced.

If you tested the command SM this sounds like sending a single command to the EBB. Did you do some testing with the Inkscape-extension?

Is this problem located on the EBB or in the Inkscape-extension?

best regards  

 Stefan 

[Author]

Posts