Cameo 4 max speed

[LoveisAFK]

Hello mossblaser, first, thanks 10000 times for this library, it is making possible some nasty projects :) kudos to you!

I own a Cameo 4 and I noticed the max speed (1000.0) results in a higher speed than say 500.0 but it's still bellow the speed it reaches using the proprietary software.

I hardcoded the max speed in device.py line 144 to 10000.0 and timed a couple of speeds for a line from [10,10] to [200,280] Each speed test was run 3 times:

Speed = 500, time=7.1149 /7.0731/7.0902 sec Speed = 1000, time=4.5055/4.4952/4.4840 sec Speed = 2000, time=2.1528/2.1674/2.2061 sec Speed = 3000, time=1.6441/1.6745/1.6684 sec Speed = 4000, time=1.6907/1.6497/1.7107 sec

Please note that the max speed I time (using my phone) with the proprietary software for the same test is around 1.2 secs but

So it seems to me the actual max value for speed is at 3000 for the cameo 4 :)

You will find bellow the code used for the timing (I time the time travel from origin to start point, then to end point.

d.set_speed(3200.0)
d.set_force(7.0)
d.move_to(10+offset_x, 10+offset_y, False)
d.move_to(200+offset_x, 280+offset_y, True)
d.move_to(200+offset_x, 280+offset_y, False) #this makes the cameo pull up the tool without waiting for next move
t_start = time.time()
d.flush()
while d.get_state() == DeviceState.moving:
            continue
t_end = time.time()
print(t_end-t_start)

d.move_home()
d.flush()

I'm not sure how you could adapt your code to take this into account, but if anyone owns a cameo 4 and would like to go faster, they can hardcode the max speed to 3000 in device.py line 144.

Thanks again for the library!

[mossblaser]

Thanks so much for the kind words! I'd be thrilled to hear what you've been up to if you have any links ;). My apologies for the slow response!

Great sleuthing on the increased maximum speed. As usual, the excellent Inkscape-Silhouette folks have worked this out and come to the same conclusion. (Alas I don't have access to recent hardware!) It seems that all I need to do for py_silhouette will be to add the max speed to here (see here for the default.

If you'd be happy to confirm that the change works for you I'll gladly cut a release as soon as I get chance!

[LoveisAFK]

Hello again,

I mainly use the cameo 4 as a pen plotter. In the beginning, I was happy enough witht he proprietary software but recently I had to get more control on the tool (pen) motion. py_silhouette is perfect for that in my use case as it allows for changing parameters (speed essentially) during the plot. Also, I might use this library to plot in real time (ig, having the cameo 4 plot while the algorithm generates the design) You can have an impression of my work on my freshly created ig account: https://www.instagram.com/loveisafk/ The last two posts where created thanks to py_silhouette. Those are photo plots (a led plots the design on photo sensitive paper, the goo'old b&w photo paper) so speed control is a must. I am still running tests and calibration, all of this is work in progress :)

Back to our topic, I have made some discoveries since the last time. I measured the actual speed to draw 12 circle diameters of lenght 100mm using a pen tool (my hypothesis was that the angle might influence the actual speed)

Here are some findings: -Not all speed values affects the speed: -1500/1700/1900/2000 result in the same measured speed -For some speed values, the measured speed is not consistent, meaning that I will measure different speeds for the same line lenght, but different orientation. For most use cases (pen plotting, cutting), this difference will be without consequence. In my case, it is, as I need to have a good control of the time of exposure, thus, the speed. -Some speed values result in the same measured speed: -100/150 -200/250 -1500/1700/1900 -2100 and above -The time of tool down/tool up is approx. 0.41 sec

In conclusion and according to this very test: -The max admissible speed value is 2100 (anything above still works but without a significant increase in speed) -There is a subset of speed values that result in consistent speeds, no matter the line angle. Those are: 300/500/900/1000/1500/2100

All of this will propably be irrelevant for most use cases, except if one needs an accurate control on speed. I hope this helps :)

BR

[mossblaser]

First off, wow! Those are beautiful!

So, just to be sure I understand, there are speed ranges like 100-150 and 200-250 over which the actual measured speed is actually fixed? Curious! Likewise the apparently "useless" extra speed values... I wonder what's going on there...

Anyhow, it sounds like what needs doing here is nevertheless to set the maximum speed appropriately for the Cameo 4 so you can use it without having to hack anything so I'll do that!

[mossblaser]

I've pushed up a new release of py_silhouette (v0.4.3) which allows speeds of up to 3000 for the Cameo 4 which should hopefully allow you to continue without the need to patch anything! I added a comment in attribution of your work on this -- please do let me know if you'd like this changing or some alternative kind of attribution.

If you find anything else which would be good to control or where py_silhouette isn't letting you do what you want please do let me know!

Finally, just as a side note, if you find yourself wanting to combine algorithmic and "hand made" graphics -- or perhaps algorithmically manipulate things, you might find one of my other libraries, svgoutline useful. You can feed this an SVG file (as produced by many vector graphics packages, e.g. Inkscape) and it'll spit out an equivalent set of straight-line segments, taking care of things like text and curves.

Very best of luck with your experimentation and artwork and thanks again so much for your thorough notes!

[LoveisAFK]

Hello @mossblaser Thanks a lot for your work and kind words, much appreciated!

-Attribution: perfect, your comment is way enough for my contribution :) -New lib: I just tested it, it's all good on my side (see bellow for more details) -svgoutline: I currently use the fantastic svgpathtool from mathandy + py_silhouette, that covers all of my workflow (I actually use svg files only for control, everything else is done using coordinates)

Speed Tests: I just ran a more exhaustive speed test. For each speed parameter, I plotted 12 10cm diagonals (from noon to 6, from 1 to 7...) and measured the actual speed. I tested speeds from 100 to 3000 with a 100 step

Findings: 1-For speed param = 100/600/700/800/1200/1300/1400/2000 I have differences in measured time of travel greater than 0.16 seconds (for 10 cm) The only notable difference here is the angle of the plotted line Hypothesis: -Either the actual speed can change depending on line orientation, or, maybe the tool down/up time changes randomly? That said, the observations are consistent over different tests, so hypothesis 1 is most likely to be true

2- Some speeds result in same measured speeds as others: Speed: [1500;2000] measured speed ~152.3 mm/sec Speed: [2000;3000] measured speed ~ 203.17 mm/sec

Some speeds show finding 1 & 2 behaviours Bellow is a plot of my measures.

If you find anything else which would be good to control or where py_silhouette isn't letting you do what you want please do let me know!

Thanks a lot for asking, so here is my wish list (I am not expecting you to dev those features, just answering your question :)) I don't know if that's possible but something that would be great is to have the control over the tool down/tool up motion.

So, instead of writing:

d.move_to(10, 10, False)
d.move_to(30, 30, True)
d.flush()

I would have to write:

d.move_to (10, 10, False)
d.flush() #move to starting point

d.tool_down() 
d.flush() #dive the tool into the material (pen in paper for instance)

d.move_to (30, 30, False)
d.flush()#plot or cut or whatever

d.tool_up()
d.flush()#release tool from material

That way, I would have a better control of every step of the process and would be able to inject other instructions in between (for instance, "turn on led" after the tool reaches the material, then move to next pos)

Another thing would be nice to control the speed of d.move_to(x,y, false), if that's possible

Finally, I monitor cameo's state using a loop:

while self.cameo.get_state() == DeviceState.moving:
    continue

I am not sure if that's ideal as it keeps requesting the get_state until the device stops moving. So far, I could not notice any weird behaviour but if there is a better way of monitoring the device state, it would be awesome (for instance, an event that triggers when an instruction is done.

Again, your library is super helpful as is, just giving you my impressions as requested :)

Thanks again for everything!