Open sunjaxx opened 1 year ago
may different settings for cutting strategy https://github.com/fablabnbg/inkscape-silhouette/blob/be1e1550ac9a2fa25adb0cf6942c893c11666edc/sendto_silhouette.inx#L101 can help?
The same happens with other strategies.
I can see in the command log that it happens when you see the many "....":
FGFGTB71FATG0FN0TB50,0\0,0Z60000,12000J1FX30,1TJ0!4,1FC0,1,1FE0,1FF0,0,1FF0,0,1FX30,1TJ3FC0,1,1M3322,3574D3338,3588D3353,3597D3368,3601D3382,3601D3396,3597D3409,3589D3422,3579D3433,3566D3443,3552D3452,3536D3466,3502D3471,3484D3474,3468D3475,3452D3473,3438D3465,3404D3452,3373D3435,3346D3415,3322D3391,3301D3365,3283D3336,3269D3306,3258D3274,3249D3241,3244D3208,3242D3175,3242D3142,3246D3110,3252D3079,3261D3050,3272D3025,3284D3002,3298D2980,3312D2959,3328D2939,3345D2921,3363D2888,3401D2861,3443D2838,3488D2820,3535D2807,3584D2798,3635D2795,3686D2796,3737D2801,3789D2812,3840D2826,3889D2846,3937D2869,3983D2889,4015D2910,4045D2933,4074D2957,4100D2982,4125D3009,4149D3037,4170D3065,4190D3095,4209D3126,4225D3157,4240D3189,4253D3222,4265D3255,4275D3289,4283D3323,4290D3358,4295D3393,4299D3428,4300D3463,4301D3499,4299D3534,4296D3569,4291D3604,4285D3639,4277D3673,4268D3707,4257D3741,4244D3773,4230D3806,4214D3837,4197D3868,4178D3907,4151D3944,4122D3979,4092D4012,4059D4042,4026D4071,3991D4097,3954D4121,3916D4144,3878D4164,3838D4181,3797D4197,3756D4211,3713D4223,3670D4232,3627D4240,3583D4245,3538D4248,3494D4249,3449D4248,3404D4245,3359D4240,3314D4233,3270D4224,3225D4213,3181D4200,3138D4184,3095D4167,3053D4148,3011D4126,2971D4103,2931D4077,2892D4043,2846D4007,2802D3968,2760D3928,2722D3886,2685D3842,2652D3797,2620D3751,2592D3703,2566D3654,2542D3604,2521D3553,2503D3501,2487D3448,2474D3395,2463D3341,2455D3287,2450D3233,2447D3178,2446D3123,2448D3069,2453D3014,2460D2960,2469D2907,2481D2853,2496D2801,2513D2749,2532D2698,2555D2648,2579D2599,2606D2551,2636D2504,2668D2450,2710D2399,2754D2351,2800D2306,2848D2265,2898D2226,2951D2190,3004D2157,3060D2127,3117D2100,3175D2076,3235D2055,3295D2037,3357D2023,3419D2011,3482D2002,3545D1996,3609D1993,3673D1993,3738D1996,3802D2002,3866D2011,3930D2023,3994D2038,4057D2056,4119D2077,4181D2101,4242D2128,4302D2158,4361D2191,4418D2227,4474D2265,4528D2314,4590D2366,4648D2420,4702D2476,4753D2534,4801D2595,4845D2658,4886D2722,4923D2788,4957D2856,4987D2924,5014D2994,5037D3065,5057D3137,5074D3210,5087D3283,5097D3357,5103D3431,5105D3505,5105D3579,5101D3653,5093D3727,5082D3800,5067D3872,5049D3944,5028D4015,5003D4085,4975D4154,4943D4221,4908D4287,4870D4351,4828D4413,4782D4482,4726D4547,4667D4608,4606D4665,4541D4719,4474D4768,4405D4813,4334D4855,4260D4893,4185D4926,4109D4956,4030D4982,3951D5004,3870D5022,3789D5037,3706D5047,3623D5053,3540D5056,3456D5055,3372D5049,3288D5040,3205D5027,3122D5010,3039D4989,2957D4964,2876D4936,2796D4903,2717D4867,2640D4826,2564D4782,2490D4734,2417D4682,2347D4618,2271D4552,2199D4482,2131D4410,2068D4335,2009D4257,1954D4177,1904D4095,1858D4011,1816D3925,1779D3837,1746D3748,1718D3658,1694D3567,1674D3475,1658D3382,1647D3289,1641D3195,1638D3102,1640D3008,1647D2915,1657D2822,1673D2730,1692D2638,1716D2548,1744D2459,1777D2371,1814D2285,1855D2200,1901D2118,1951D2037,2005D1959,2064D1875,2134D1796,2208D1722,2285D1652,2366D1588,2449D1528,2535D1473,2624D1423,2715D1377,2808D1336,2904D1301,3001D1270,3099D1243,3199D1222,3300D1205,3402D1193,3504D1186,3607D1184,3711D1187,3814D1194,3917D1207,4020D1224,4123D1246,4225D1273,4325D1304,4425D1341,4523D1382,4620D1428,4715D1479,4808D1535,4899D1596,4988D1661,5074D1699,5120D1739,5165D1779,5209D1820,5251D1905,5332D1993,5408D2085,5478D2180,5543D2277,5603D2377,5658D2480,5707D2584,5751D2690,5790D2798,5823D2908,5852D3018,5875D3130,5893D3242,5905D3355,5912D3468,5914D3581,5911D3694,5902D3807,5889D3919,5869D4031,5845D4141,5815D4250,5780D4357,5740D4463,5694D4567,5643D4669,5587D4768,5525D4865,5458D4958,5386L0\0,0M0,0J0FN0TB50,0
If I send the same file but using the "dry run option" (so without actually sending the commands to the machine), that issue does NOT happen:
FGFGTB71FATG0FN0TB50,0\0,0Z60000,12000J1FX30,1TJ0!4,1FC0,1,1FE0,1FF0,0,1FF0,0,1FX30,1TJ3FC0,1,1M3322,3574D3338,3588D3353,3597D3368,3601D3382,3601D3396,3597D3409,3589D3422,3579D3433,3566D3443,3552D3452,3536D3466,3502D3471,3484D3474,3468D3475,3452D3473,3438D3465,3404D3452,3373D3435,3346D3415,3322D3391,3301D3365,3283D3336,3269D3306,3258D3274,3249D3241,3244D3208,3242D3175,3242D3142,3246D3110,3252D3079,3261D3050,3272D3025,3284D3002,3298D2980,3312D2959,3328D2939,3345D2921,3363D2888,3401D2861,3443D2838,3488D2820,3535D2807,3584D2798,3635D2795,3686D2796,3737D2801,3789D2812,3840D2826,3889D2846,3937D2869,3983D2889,4015D2910,4045D2933,4074D2957,4100D2982,4125D3009,4149D3037,4170D3065,4190D3095,4209D3126,4225D3157,4240D3189,4253D3222,4265D3255,4275D3289,4283D3323,4290D3358,4295D3393,4299D3428,4300D3463,4301D3499,4299D3534,4296D3569,4291D3604,4285D3639,4277D3673,4268D3707,4257D3741,4244D3773,4230D3806,4214D3837,4197D3868,4178D3907,4151D3944,4122D3979,4092D4012,4059D4042,4026D4071,3991D4097,3954D4121,3916D4144,3878D4164,3838D4181,3797D4197,3756D4211,3713D4223,3670D4232,3627D4240,3583D4245,3538D4248,3494D4249,3449D4248,3404D4245,3359D4240,3314D4233,3270D4224,3225D4213,3181D4200,3138D4184,3095D4167,3053D4148,3011D4126,2971D4103,2931D4077,2892D4043,2846D4007,2802D3968,2760D3928,2722D3886,2685D3842,2652D3797,2620D3751,2592D3703,2566D3654,2542D3604,2521D3553,2503D3501,2487D3448,2474D3395,2463D3341,2455D3287,2450D3233,2447D3178,2446D3123,2448D3069,2453D3014,2460D2960,2469D2907,2481D2853,2496D2801,2513D2749,2532D2698,2555D2648,2579D2599,2606D2551,2636D2504,2668D2450,2710D2399,2754D2351,2800D2306,2848D2265,2898D2226,2951D2190,3004D2157,3060D2127,3117D2100,3175D2076,3235D2055,3295D2037,3357D2023,3419D2011,3482D2002,3545D1996,3609D1993,3673D1993,3738D1996,3802D2002,3866D2011,3930D2023,3994D2038,4057D2056,4119D2077,4181D2101,4242D2128,4302D2158,4361D2191,4418D2227,4474D2265,4528D2314,4590D2366,4648D2420,4702D2476,4753D2534,4801D2595,4845D2658,4886D2722,4923D2788,4957D2856,4987D2924,5014D2994,5037D3065,5057D3137,5074D3210,5087D3283,5097D3357,5103D3431,5105D3505,5105D3579,5101D3653,5093D3727,5082D3800,5067D3872,5049D3944,5028D4015,5003D4085,4975D4154,4943D4221,4908D4287,4870D4351,4828D4413,4782D4482,4726D4547,4667D4608,4606D4665,4541D4719,4474D4768,4405D4813,4334D4855,4260D4893,4185D4926,4109D4956,4030D4982,3951D5004,3870D5022,3789D5037,3706D5047,3623D5053,3540D5056,3456D5055,3372D5049,3288D5040,3205D5027,3122D5010,3039D4989,2957D4964,2876D4936,2796D4903,2717D4867,2640D4826,2564D4782,2490D4734,2417D4682,2347D4618,2271D4552,2199D4482,2131D4410,2068D4335,2009D4257,1954D4177,1904D4095,1858D4011,1816D3925,1779D3837,1746D3748,1718D3658,1694D3567,1674D3475,1658D3382,1647D3289,1641D3195,1638D3102,1640D3008,1647D2915,1657D2822,1673D2730,1692D2638,1716D2548,1744D2459,1777D2371,1814D2285,1855D2200,1901D2118,1951D2037,2005D1959,2064D1875,2134D1796,2208D1722,2285D1652,2366D1588,2449D1528,2535D1473,2624D1423,2715D1377,2808D1336,2904D1301,3001D1270,3099D1243,3199D1222,3300D1205,3402D1193,3504D1186,3607D1184,3711D1187,3814D1194,3917D1207,4020D1224,4123D1246,4225D1273,4325D1304,4425D1341,4523D1382,4620D1428,4715D1479,4808D1535,4899D1596,4988D1661,5074D1699,5120D1739,5165D1779,5209D1820,5251D1905,5332D1993,5408D2085,5478D2180,5543D2277,5603D2377,5658D2480,5707D2584,5751D2690,5790D2798,5823D2908,5852D3018,5875D3130,5893D3242,5905D3355,5912D3468,5914D3581,5911D3694,5902D3807,5889D3919,5869D4031,5845D4141,5815D4250,5780D4357,5740D4463,5694D4567,5643D4669,5587D4768,5525D4865,5458D4958,5386L0\0,0M0,0J0FN0TB50,0
Any ideas? Thanks!
in order to get things reproducible could you please
Sure, here you are:
I attach the SVG file and the logs. (Let me know if anything else is missing, thanks again!)
Does the pause occur alwyas on the exactly same point? If not, it looks really like a buffer or transmission problem.
Is the plotter connected by usb or bluetooth?
The unknown chars in the cuttercommands are normaly 0x03, but at the long pause a sequence of 0x1b,0x05. I am not sure of the exact meaning of it, but could be some status bits meaning 'busy'
I am connected via USB. The pauses seem to happen exactly at the same point(s), see the appended log: cuttercommands.txt
(By the way, I did not know this extension works also with Bluetooth? I can pair the PC to the cameo, and it briefly says connected but then goes to "paired" again.... but this is another issue, I guess?)
The unknown chars in the cuttercommands are normaly 0x03, but at the long pause a sequence of 0x1b,0x05. I am not sure of the exact meaning of it, but could be some status bits meaning 'busy'
seems like status query (ESC, ENQ) is occurring every then and when (which is skipped on dry_run) https://github.com/fablabnbg/inkscape-silhouette/blob/ed0c19b22cf09dd0b89a0aebc8b4e8ec5e61678b/silhouette/Graphtec.py#L698
So does that mean it's something related to the USB connection? Or what else? Any idea on how to resolve that? :-)
PS: if it helps, I have tried the same cameo 4 pro on a (different) Debian machine, and I get the same behaviour.
Have you ever tried another svg file? Just to rule out, that it has something to do with this very source file.
For me it looks like the plotter has some problem and stops cutting, therfore in the protocol are the status requests. (1b,05) After some time the status is ok and the cut continues. But i have no idea for the root cause.
The log file doesn't contain the status answer from the device. I have no idea, if there is an easy way to include this information into the log file.
I had just a look at the sourcecode. This seems to be by design. The buffer sends data in chunks of 1k size and waits for the status 'ready'. While the device tells another status, e.g. is 'moving', no data is sent until 'ready'. In the logfile I can see such 1k blocks and then a pause.
I never observed such pauses at my device (Silhouette Portrait), but maybe because I do only cuts at lower speeds.
@sunjaxx as a quick and dirty workaround you may try to replace safe_write
with write
https://github.com/fablabnbg/inkscape-silhouette/blob/ed0c19b22cf09dd0b89a0aebc8b4e8ec5e61678b/silhouette/Graphtec.py#L637
although beware this has not been tested yet and could cause unexpected failures...
Have you ever tried another svg file? Just to rule out, that it has something to do with this very source file.
Yes I've tried another simple shape (a square and a circle) and the same happens.
@sunjaxx as a quick and dirty workaround you may try to replace safe_write with write
I tried that, and the cameo stops plotting midway (I have the impression at the time the first pause would have occurred before the code change...)
Any other ideas? This extension is promising, and I'd be happy to help (as much as I can)!
can you construct a reprocase for the command line, so others can easily test on their own plotter models? i.e.
python [/path/to/extensions/]sendto_silhouette.py --mention=all --your=applied --options=here --so=others --can=reproduce failing_svg_1.svg
you may check the available options using --help
nb: ensure you use the latest version of inkscape-silhouette
I am on LInux here and have no acces to the windows software.
Does the pause also occur in the original windows software too, or is the movement there smoothly? Can anyone confirm this?
The pauses do not occur when using Silhouette Studio (Designer edition) on Windows (on the same SVG)
@sunjaxx can you update your sendto_silhouette.py to this latest version and repost a new logfile with this changes?
@sunjaxx Just out of interest I have tried to plot your spiral svg document.
The only problem with it was the size. On my device i cannot plot 500x700mm. So it runs on bounding box and gets limited on the page border. But if I scale it to A4 size I can plot it without any visible pauses.
(My system is a really old Ubunutu Linux 18.04. Inkscape 0.92. extension version 2020-12-29 tb, v1.24, but at least it shows, a fluent plot is possible.)
@sunjaxx as a quick and dirty workaround you may try to replace safe_write with write
I tried that, and the cameo stops plotting midway (I have the impression at the time the first pause would have occurred before the code change...)
My bad: replacing safe_write with write does NOT result in the pauses! (When i tried last time the paper was not there or properly in place, that's why I think it stopped...)
@sunjaxx can you update your sendto_silhouette.py to this latest version and repost a new logfile with this changes?
here it is: log.txt
@sunjaxx Just out of interest I have tried to plot your spiral svg document.
The only problem with it was the size. On my device i cannot plot 500x700mm. So it runs on bounding box and gets limited on the page border. But if I scale it to A4 size I can plot it without any visible pauses.
(My system is a really old Ubunutu Linux 18.04. Inkscape 0.92. extension version 2020-12-29 tb, v1.24, but at least it shows, a fluent plot is possible.)
In my case it also happens with this A4 version (unless i change "safe_write" with "write" in graphtec.py)
@sunjaxx thank you for sharing this new dump. here on Cameo3 your svg plots like a charm with some nearly invisible pauses (tiny fraction of a second).
ps: my cuttercommands look very similar with lots of query commands (0x1b,0x05) in it.
@ anybody please test and report back the behaviour of your plotter (cameo 1,2,3,4,pro)
python /path/to/sendto_silhouette.py --active-tab=silhouette --x_off=0 --y_off=0 --cuttingmat=no_mat --toolholder=1 --tool=pen --media=300 --speed=4 --pressure=30 --depth=-1 --preview=true --dashes=false --autocrop=false --bbox-only=false --multipass=1 --reversetoggle=false --endposition=start --end_offset=0 --regmark=false --regsearch=false --regwidth=180 --reglength=230 --regoriginx=15 --regoriginy=20 --wait_done=false --sharpencorners=false --sharpencorners_start=0.1 --sharpencorners_end=0.1 --overcut=0.5 --strategy=zorder --orient_paths=natural --fuse_paths=true --sw_clipping=true --logfile=/path/to/log.txt --log_paths=true --cmdfile=/path/to/cuttercommands.txt --inc_queries=true --append_logs=false --dry_run=false --force_hardware=DETECT --bladediameter=0.9 /path/to/201445909-7db6cae2-c891-4792-aa94-54d85c43d9db.svg
maybe newer models can profit from some tweaks?
@EtherGraf do you remember why safe_write()
by Alexander Senger was introduced by cd1ef0c3647238ed03589b6d429fc98946c7893d
https://github.com/fablabnbg/inkscape-silhouette/blob/7561e548ba8a59a33aecac89eb953d2ea1126f32/silhouette/Graphtec.py#L609-L619
Maybe we could raise or skip the safemaxchunksz
limit for all or some of the newer models? - your opinion on that? any experiences to consider?
Sorry no, i do not know why this function safe_write was introduced.
Possibly it is/was needed for some older devices. Or the flow control for the buffer has not worked or was not even known in the past. I have no idea, how the buffer flow control works without the safe_write method or if there is some limit for huge data chunks. This will need some tests.
If I find some time I can test the next weeks at least with my equipment, if the extension works without the safe_write() method.
Any update? Thanks!
Has there been anything done for this? If not, is the workaround the way to go?
@henryso can you share any observation on this? which device do you have? which workaround does work for you? hopefully this can help fix this nasty hw issue...
@henryso can you share any observation on this? which device do you have? which workaround does work for you? hopefully this can help fix this nasty hw issue...
My observation is the same as the opening post. Every so often the device will pause, the lights will blink, and then it will continue. I have a Silhouette Cameo 4 under Linux, Inkscape 1.2.2, and I'm using commit a1941b6f740466a20dfa116415dd599b1e496302. The workaround that works for me is to change self.safe_write(data)
to self.write(data)
in the safe_send_command(self, cmd)
function in Graphtec.py. It works perfectly when I do that.
@henryso did you test huge svg files already? if not can you try some on your own and report back? do you have access and could try on some older hw?
@t0b3 What do you mean by huge svg file? I've tried cutting a letter size sheet of paper filled with 32mm-diameter circles. I don't have any other devices than the Silhouette Cameo 4.
Some more observations. I test plotted a bunch of text made using the Hershey Text extension. With safe_write
, I get the occasional pauses and with write
, I get no pauses (so the behavior here is the same). Either way, the plot does eventually complete successfully. However, I noticed that with safe_write
, the device handles pauses better. With safe_write
, after pausing, in a second or so, the eject button lights up (and I can eject the media) or i can unpause to have the device continue. If I hold the button down, eventually the plot continues (as if I had just tapped the button to unpause). With write
, after pausing, all I can really do is unpause. The eject button never lights up until the plot is complete. If I hold the button down, it makes the device unresponsive and I can no longer unpause the plot and my only recourse is to turn the device off.
Maybe the thing to do here is make the use of write
instead of safe_write
an "advanced" user option. Use at your own risk.
I also see this with the Cameo 4. It's not too bad when cutting but sometimes it leaves rougher spots.
I am testing this extension (on win 10). I tried to sketch (with a pen) a simple, small shape (a spiral), but while sketching, the machine (cameo 4 pro) pauses for a second few times (and the buttons light up when that happens) - like it's waiting for the data / buffering. (That is not ideal when sketching because the pen will stop and leave a larger ink dot when that happens.) Any ideas? (I can provide a video if unclear) Thanks!