Support for different off-the-shelf press wheels

[skrutt]

The latest printables support changing wheels and there are also user such as myself who will want support for their own language, that has other or more characters than A-Z.

One suggestion from Andrei:

• On the settings there could be a text form to write all the 43 characters present on the wheel, so they would be supported (today there is a Regex to validate the chars) and transmitted to the machine.

in theory it should be possible to move the whole mapping into a string modified from the settings, but with the caveat that the "special" characters such as CUT, 0, 1 would need to be present and in the same place on all wheels used.

But having a regex in the settings could at least ease the experience of a somewhat arduino-savvy user, modify the character map and the string in the ui and you are done. or if there is a list of different wheels already implemented in the future, those with a "new" layout could add theirs to the list.

Also a thought, should the character map be moved into an own file? or reside in opt_config? It's a bit hidden right now.

[sedorr]

Moving it into its own file and creating a bit of extra documentation for using different dasy wheels would definitley be cool. For me p. ex. it's quite hard to get a uppercase english wheel without importing it (I refuse to pay 7€ import tax for a 2,50€ item) so it would be quite handy to be able to use a Nordic version (or the lower case version, as that is for some reason available as well...).

[andreisperid]

So, these are the types of daisy wheels that I have here with me. Are we talking about the same models?

From left to right:

• Spec A (currently supported): alphanumeric upper-case plus ♡☆♪€@
• Spec B (@skrutt?): alphanumeric upper-case plus ÄÖÜÅÆ
• Spec C (@sedorr?): alpha lower-case plus '"#$@♂☏♀ (and another one I'm not sure what it is right now.)

A study need to be made on compatibility with daisy wheels with differing character quantities. The Spec C has 36, instead of the original 43 with A and B.

---

For a hard coded way to make it work with any 43-char daisywheel (Spec A/B):

Firmware:

• modify the respective characters

Web App:

• modify "regex" in the useRegex function

---

Now... Sketching below an idea for how it would work in an user friendly way (user configures everything through the web app).

Settings page (Web app):

• have a text input form to write all the characters present on the wheel (need to check if all special characters will be transmittable);
• by setting it, inform the validation Regex on the app (might need a local config cache file, need to see if that will work with a web app);
• transmit the character string to the machine.

Firmware:

• if a new character set is received, parse to determine the amount of characters (for instance, the lowercase daisywheel has 36 chars, instead of 43)
• save the character string to flash memory (if nothing is read from this address, assume standard characters (spec A)
• reboot, check flash memory for charset
• merge the charset to the numbers and positions (need to investigate if that can be made on the fly)
• on start, the web app must receive the charset in which the device is configured through the API.

Device:

• investigate the compatibility with number of chars different than 43.

Documentation:

• information of all available daisywheels, and how to change them (both on web app & physically on device)
• charset strings ready to be pasted on app settings, for all daisywheel Specs.

PS: for the 0/O and 1/I optimization, I guess the treatment could be kept whatever would be the daisywheel.

[sedorr]

B & C is what I can get. The Motex I recently ordered Is Spec B as well.

I just searched around a bit and it seems like these three wheels are all that you can get, so you can probably get away with just making three presets to choose from.
If there are really only three variants then the only use case for allowing people to define their own charset would be for people who actually make their own 3d printed daisy wheels.

[skrutt]

Yes, i have the spec B, Nordic wheel. I would place a vote for predefined presets(1,2,3), for "the most common" wheels. If there are only these three, then that should be quite easy... If needed/wanted, then have a user defined (preset 4?), Custom variant. This can then be a future update, since it's more work and more exotic. Just to state the obvious; you need some kind of preset or selection between different wheels in order for changing wheels to be useful, otherwise each time you change the wheel you also need to update the character string and then you'd need a reference source for this.

…

On Tue, Apr 18, 2023, 22:41 Andrei Speridião ***@***.***> wrote: So, these are the types of daisy wheels that I have here with me. Are we talking about the same models? [image: image] <https://user-images.githubusercontent.com/15098003/232891044-63235768-2240-4e1d-bbc6-94f62f2af4da.png> From left to right: - Spec A (currently supported): alphanumeric upper-case plus ♡☆♪€@ - Spec B ***@***.*** <https://github.com/skrutt>?): alphanumeric upper-case plus ÄÖÜÅÆ - Spec C ***@***.*** <https://github.com/sedorr>?): alpha lower-case plus '"#$@♂☏♀ (and another one I'm not sure what it is right now.) A study need to be made on compatibility with daisy wheels with differing character quantities. The Spec C has 36, instead of the original 43 with A and B. ------------------------------ For a hard coded way to make it work with any 43-char daisywheel (Spec A/B): Firmware: - modify the respective characters <https://github.com/andreisperid/E-TKT/blob/main/src/LabelMaker.cpp#L137> Web App: - modify "regex" in the useRegex function <https://github.com/andreisperid/E-TKT/blob/main/data/script.js#L271> ------------------------------ Now... Sketching below an idea for how it would work in an user friendly way (user configures everything through the web app). Settings page (Web app): - have a text input form to write all the characters present on the wheel (need to check if all special characters will be transmittable); - by setting it, inform the validation Regex on the app (might need a local config cache file, need to see if that will work with a web app); - transmit the character string to the machine. Firmware: - if a new character set is received, parse to determine the amount of characters (for instance, the lowercase daisywheel has 36 chars, instead of 43) - save the character string to flash memory (if nothing is read from this address, assume standard characters (spec A) - reboot, check flash memory for charset - merge the charset to the numbers and positions (need to investigate if that can be made on the fly) - on start, the web app must receive the charset in which the device is configured through the API. Device: - investigate the compatibility with number of chars different than 43. Documentation: - information of all available daisywheels, and how to change them (both on web app & physically on device) - charset strings ready to be pasted on app settings, for all daisywheel Specs. PS: for the 0/O and 1/I optimization, I guess the treatment could be kept whatever would be the daisywheel. — Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA326WEIKL26KZVWSQOPWZDXB337NANCNFSM6AAAAAAW7XFXVQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[andreisperid]

You both have good points on having presets! For now I think that it might be the best approach.

... but, I was trying to thinking why I came to that over engineered solution and remembered that David Knochenhauer suggested several months ago that we could try to create custom daisy wheels. He even programmed a parametric daisywheel on OpenScad. I will ask if he would join the discussion here.

Since I have a resin 3D printer now, I might give a shot. Not sure if a standard resin might stand the pressure needed for embossing. But imagine creating vintage embossing, with contemporary typefaces? Or whatever symbols... Cool!

So, in that way we might need a real customizable charset...

[skrutt]

That would be cool! I don't have any resin printer though :( I think the custom wheels are fully possible, and also a (or, will be) a logical next step after implementing presets. As a technical question, anyone know how to integrate feedback from firmware to the webpage? As i understand it the page is fully defined from the sipps image, and the characters used and regex will need to be handed over from code to web. There are ofc infinite ways but what's the clean way? - written to a sipps file by firmware? - another endpoint for js to fetch? - other ideas?

…

On Wed, Apr 19, 2023, 21:21 Andrei Speridião ***@***.***> wrote: You both have good points on having presets! For now I think that it might be the best approach. ... but, I was trying to thinking why I came to that over engineered solution and remembered that David Knochenhauer <https://github.com/Knochi> suggested several months ago that we could try to create custom daisy wheels. He even programmed a parametric daisywheel on OpenScad. I will ask if he would join the discussion here. Since I have a resin 3D printer now, I might give a shot. Not sure if a standard resin might stand the pressure needed for embossing. But imagine creating vintage embossing, with contemporary typefaces? Or whatever symbols... Cool! So, in that way we might need a real customizable charset... — Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA326WD2WNCOLD3UPFFVF6DXCA3NJANCNFSM6AAAAAAW7XFXVQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Knochi]

Feel free to use my customizable press disc. I didn’t test but it’s customizable via OpenSCAD

https://github.com/Knochi/OpenScad
(Presscarousel.scad)

[andreisperid]

@Knochi thank you very much, I'll make a test!

@skrutt you mean create some kind of message from the device to the web app? The best way might be via the JSON API. What are you planning to use it for?