Rework cutter specifics - add option to fine-tune cutter resolution

[protonenfalter]

When trying to get a Silhouette Cameo 2 (updated to most recent firmware version 1.6) running under Linux with inkscape and inkscape-silhouette I noticed that the operation was quite flaky: in 9 out of 10 cutting runs the cutter would not output anything but simply jerk around a bit and then proclaim it was finished. 1 out of 10 times the results were fine.
After sniffing USB-communication of Silhouette Studio with the Cameo 2 and a fair bit of reverse engineering I came up with a set of changes I would like to propose. I factored them into four chunks (each commit in the branch), so cherry-picking should be easier:

1. commit

The biggest problem was the non-standard communication between software and cutter. There seem to be a lot of left-overs from previous work and also quite a bit of mis-interpretation.
My approach:

• replace comma with "\x03" as command delimiter (comma is for separation of parameters within command) and properly terminate all communication
• drop all unnecessary communication (polls where result is not used, unknown commands, anything not found in the sniffed communication
• refactor communication in initialization, setup and job
• do more testing to determine actual effect of commands (well, not always successful, but I think it is an improvement)
• use cleaner coordinate transform before sending data to Cameo. Helps in offset-issue (see comment in code)

This results in much more stable and reliable operation with my cutter. I think other users could also benefit.

2. commit

The Cameo will get lost in communication if any new data is send while the machine is busy cutting. Also data chunk size in Silhouette Studio is limited to 3k chars at most and 1k is standard. In response a method "safe_write" was added as a wrapper for the write method to further split large data words (from plot commands) into more digestible chunks. Also inkscape-silhouette will now wait for the cutter to be ready before sending new data.

This results in the cutter returning to the main menu after the complete job is finished (e.g. the nifty option to advance the media into a position where the very handy cross-cutter can be used is offered). Without waiting the machine will only offer to eject the media after cutting.

3. commit

In GUI and plot code an option is implemented to chose the end position of the blade after cutting. This can be useful for some jobs. There was already some code which seemed to be intended for this purpose but was left unfinished. Frankly, I had some difficulties understanding the logic and implemented my own approach.

4. commit

The resolution of my cutter was slightly different from the magic number found in the code which was quite annoying in my use-case. I added two parameters for easier tuning and also allowed different resolutions for the two axes (in an ideal world this should not be necessary, but the Cameo 2 has its limitations, it seems)

I hope something useful can be found among my changes. Please have a look. Everything can be released under any license.

[jnweiger]

Is Silhouette 2 a newer version of the Silhouette?
Mine is ca 4 years old and works perfectly fine with openSUSE 13.1

Thanks for the reverse engineering!
The original implementation is patchwork from various sources, adding to the commands, until it started to respond. I did not take the pain to remove anything and find the minimum of codes sent.

I am no longer really active with that code base. Do you want direct commit power here?

[protonenfalter]

The Silhouette Cameo 2 seems to be a significant update of the hardware. One prominent example is a touch screen where the Cameo 1 has real buttons (not sure if this really is an improvement, though).

Direct commits would be acceptable for me (also a bit of maintenance every now and then). However, before applying the changes I would like to make sure they still work with the Cameo 1. Unfortunately I don't have one available. Would it be possible for you to test?

[EtherGraf]

Have just merged the Commits 1 to 3, as these are a prerequisite to get the regmarks working. On my Silhouette device it is working, hope on the other devices nothing gets broken. But from the comments regarding the regmarks branch, which included theses changes already, I think they are ok.

The code from Alexander is really well written and documented. Well done, thanks for sharing!

[jnweiger]

This is an old (almost historic) PR. Thanks @EtherGraf for merging most of this. Thank you @protonenfalter for the cleanup and contributions.
The remaining unmerged part is about the odd 19.83 / 20.0 scaling issue on (your?) Cameo2. Not sure what to do about it.
Has anybody else seen such a scaling issue? It is roughly 1% error in aspect ratio. With my old cameo1, I am pretty sure, I would have noticed that, as I did lots of measurements then.

I could imagine some variation along the y-axis (height) due to thick or thin material, or using a cutting mat.
With variation along the x-axis (width) I'd first think of a worn out belt. But that should make the needed steps per mm larger, not smaller. So it could be a slightly thicker belt, or some dirt accumulating on the motor pulley?

I suggest to merge that last commit to not lose the idea of fine tuning here, but go with a nominal step_per_mm_along_width = 20.0 for now.