nice idea with the adhesive label! With decreasing stickyness of my cutting mat, removing the fine rectangles from the cut stencil gets more and more annoying :) (Maybe also my knive gets dull?)
I tested the new code, and it works very well! (cuts now full size of the mat, if media size is specified accordingly!!!)
Here two suggestions for code modifications:
1) affects the dice(strokes) method in optimize.py The additional if-clause prevents two lines of zero length to be added to the list, when the last point in the .pic-file's list is identical to the first (true for most stencil I did so far).
def dice(strokes): lines = [] for s in strokes: p = s[0] for q in s[1:]: lines.append((p[0],p[1],q[0],q[1])) lines.append((q[0],q[1],p[0],p[1])) p = q if p != s[0]:# AZ 17.11.13 lines.append((p[0],p[1],s[0][0],s[0][1])) lines.append((s[0][0],s[0][1],p[0],p[1])) return lines
2) I furthermore thought about how to optimize the time consumption for a stencil to be cut. Your algorithm sorts all lines for a given angle by the Y-coordinate of the starting point. This causes the Plotter to move in X-direction extensively, if pads are spread over the sheet and slightly different in Y. Nevertheless Movement in Y-direction is minimal. (once through per angle) I therefore modified the optimize(strokes, b) method in optimize.py in an attempt to save some time:
Lines are now divided into bins along the Y-axis, with a bin width of 0.5 inch. (Experimental value) For each of these bins, lines are sorted by their X-value! (not Y!)
Now the plotter goes not only left/right, but also back/forth during an angle cut. In this way, it moves less, and cuts more.
for ang in range(0,16): a = [] for x in lines: if ang==angle(*x): a.append(x) if not a: continue emit_training_line(ang)#angle has at least one line ->append training cut to list
for section in range(-1,30):#do this for every 0.5 inch section...
b = []
for item in a: if item[1] > section*0.5 and item[1] <= (section+1)*0.5:#Y-coordinate of start point within section? b.append(item)#add line to temporary list
b.sort(key=lambda s:(s[0],s[1]))#sort temporary list by X-coordinate (not Y!) for x in b: emit_line(*x)#emit lines for this Y-section
# a.sort(key=lambda s:(s[1],s[0])) # for x in a: # emit_line(*x) return r
I don't know, whether the additional movements in Y accumulate in larger errors. I am currently cutting a A4-sized stencil with the modified code. It went out perfectly before, but took ~5 hours. I am curious, how and how fast it will turn out now. :)
Cheers Andre
Edit: Done in less than two hours, compared to 5 hours. Result is as excellent as usual! :)
In the gerber2graphtec python file, comment out the line
g.closed_path(border_path)
This will skip the border cut.
But what exactly did you do to cut large area files? mine just stops cutting after some "invisble" border in y direction, and I did not find any such hard limitations in the code, yet I do not understand all parameters that are set in the cutter initialization steps...
My guess: coming from the training position with high speed, the cutting head does not come to complete rest before starting to cut, and overlays some kind of mechanical oscillation with the straight cut. Do the commands sent to the Cameo allow to slow the head down, or wait shortly at the new position before starting the cut?
[quote author="reserve"]Look at the attachment, there is the result with the default optimize.py file[/quote]
Hi Tobi,
thanks for testing and your time! Interesting - so my Cameo is not different from yours... Interesting that no one else encountered this kind of difficulties with the default script. I'm also not sure why this happens - maybe the cutter gets its move cut commands too close after the move commands, so the head still has some "speed left", and does some kind of mechanical oscillation, after it moved that far from the "training area" outside the stencil? This is te only explanation I can think of...
Good to know, that it works with the modified version :)
I use the same transparencies as Tobias (I think since they are the "default" ones to obtain in Germany *g*), and get equal high quality results, using the default gerber2graphtec options (two passes, speed 2 each, force 8 and 30) and blade option "2", with my modified optimize.py.
Tobias - would you mind trying to reproduce the faulty behaviour I obtained with the original optimize.py (which was my reason to look into it closer)? See the attached Photo in this post: viewtopic.php?f=68&t=5341&start=15#p52227
One word to clarify the amount of cuts for each pass: Each Gerber file object is converted to a rectangle in the scripts, using just the four first corner points of the object. This is trivial/same for rectangles, but more complex objects are also possible - see the example.1gbr file, that comes with the g2g package, the pads have more points there. Further point are in this case skipped. Now each stroke of the rectangel (four) is cut twice, once from each side, to ensure a "punch through"-point of the blade at each side. Doing so, each rectangle is cut with eight cuts, from four different angles.
I solved my recent problem with the Cameo (see ~2 pages backwards), not cutting every area of the stencil correctly.
I did so, by modifying the optimize.py of the gerber2graphtec tool. The tool by default adds *plenty* of "knife-positioning" cuts just outside the area of the stencil. This takes a lot of time, and also needs to move the cutting mat back and forth again and again. Somehow (??) my cutter messed up with that, and made the cuts not straight...
I modified the python code to just do a single "training" cut per cutting angle that is used in the file, and then do all cuts with this angle in a row. This needs the mat to be moved completely only once per angle.
I don't know, whether Peter (author of gerber2graphtec) added this by purpose or not (already contacted him), but for me it works reasonably faster and better without the zounds of training cuts in between.
Please find my modified version attached - maybe it is useful for some of you.
I just received my Silhouette Cameo after I got excited reading *this* thread :)
I use it together with the great gerber2graphtec tool In principle it works as expected and according to what is promised here :)
But trying to print "large" (~10x10 cm²) stencils, I always find a "spot", where the rectangular shapes are "distorted", and not repeated exactly in the different cutting passes... (gerber files are okay!)
Please find a picture attached
Has any of you encountered similar things, or have an explanation for this?
Open Source Hardware