andreisperid / e-tkt Goto Github PK

Maybe consider posting stuff (Like a Teardown) on iFixit. I already created a wiki and a guide as an example for you: Link.

Frequently the font serving from the ESP32 takes more time than usual and the web app starts without the correct aspect, eventually getting stuck in that state.

It would be cool if you could add a Centroid File and PCBWay compliant BOM File to make it easier to make use of turnkey assembly services. I'm personnally not that great at soldering and don't like looking for ICs at all of the suppliers so I would happily spend the money for these services and I'm sure a lot of people are the same.

Maybe even upload your files on PCBWay so that people will have an easier time ordering the PCB and you'll get some money if people order through them.

Maybe add support for StallGuard4 and StealthChop2 via the TMC2209. It should be relatively easy since you already use the standard driver modules used in 3d printers.
If you don’t need stall detection the TMC2208 should even be a drop in replacement for the A4988 (in legacy mode at least as far as I know).

As in: https://hackaday.com/2022/06/15/diy-automated-printer-kerchunks-out-classic-embossed-labels/#comment-6484170

By replacing the ESP32-WROOM-32 by a ESP32-S3-WROOM-1 or -2 we could get rid of the expensive FT231X plus it has more processing power

The machine seldom mistakes the correct letter (rare), seems related to processing hiccups.

As commented, currently the LEDs (ledChar and ledFinish) are using analogWrite, which are by convenience supplied by the ESP32Servo library. This might be bad for modularity in case another library is used, or any changes in the architecture are made.

And, maybe there are other opportunities by using this official method.

Sometimes the status feedback (reel, cut, feed, print) does not update correctly and gets stuck.

I was looking a few labels I did with the original manual embossing machine, and right before it broke it started advancing the tape less than needed.

It created a "condensed" effect. Maybe it is a nice feature, both aesthetically and functionally, to be able to place more or less characters in the same space.

There could be a dropdown menu in the web app for that. The default could be as it is right now, and the other option would be the "condensed".

I've used symbols, components and footprints installed on my local global library.

To facilitate collaboration and further iterations, I will try to bring this library locally to the project's KiCad directory.

One of the things that never made me happy with the device is the cutting performance. Its still quite random.

What happens now:

• the machine presses three times to make sure the blade is able to pierce through both the label and liner;
• sometimes the labels are perfectly cut, sometimes not;
• eventually, there are white marks on the extremities, due to excessive press (energy is applied in the wrong place?);

Hypothesis:

• it seems that depending on the first cut, the label tilts a bit creating a better clearance for the next cut;
• maybe the label thickness varies, impacting performance;
• the blade gets dull (or comes with irregular sharpness?);
• the press might be hitting erratically, missing the ideal daisywheel spot;
• the homing might be imprecise, leading to the item before;
• the current servo might be enough for the characters, but not for cutting;

The ideal scenario would be:

• fully cut the label, but leave just a tiny bit of liner uncut to make sure the label isn't carried by the daisywheel and get entangled;
• prevent damaging the tape (white marks);
• make sure the little tab (double cut) is functional to help removing the liner, which means fully cutting the external (except tiny bit of liner), but for the inner, only cut the label, but not the liner;
• press only once to cut;

I think it would be a good idea to refactor the E-TKT from its current (largely) single file structure into one that encapsulates its functionality into multiple classes. There are many advantages to this, but the biggest I see are:

• Breaking functionality into smaller parts will make it easier to follow logic.
• Smaller files are easier to read, and therefore more maintainable.
• Breaking up functionality makes it easier to avoid conflicting changes if multiple people work on the project simultaneously.
• Bugs are less likely if the state for the device isn't all tangled together everywhere.
• Extending functionality is easier to do (ie for different hardware) when responsibilities are clearly defined by a class structure.
• Adding tests will be easier if most classes depend on abstractions of the hardware rather than the arduino methods themselves.

These are the typical upsides of breaking up and encapsulating functionality. As usual it also comes with some downside, if things are broken up naively then it can often become more work to add functionality because the relationships between parts doesn't reflect what they actually need to do. My goal would be to avoid that, and I think I'm familiar enough with the project to do it well. I have a lot of professional experience doing this kind of thing, though not specifically with C++.

Here is how I'm initially thinking of breaking things up:

• Printer.h - A "main" class created at the start which initializes everything and keeps track of global state like print progress, busy, etc
• Helpers.h - Static utility methods, like the ones for handling utf-8 text.
• Carousel.h - Manages everything having to do with the carousel geometry, its stepper motor, and homing.
• Sound.h - Manages making sounds/music with the buzzer.
• Display.h - Manages all the logic for displaying info on the oled.
• Server.h - Sets up the webserver, its callbacks, and passing info from requests to where they need to go.
• WiFi.h - Handles the logic for connecting to WiFi, AP Config mode, mdns, etc.
• Button.h, Light.h, Motor.h - To handle smaller units of hardware. These classes will probably be very simple.

While actually untangling the relationships whats needed might change, but I think its likely things will look close to this.

From my personal experience its better to make big changes like this quickly all at once to minimize the time it impacts people with pending changes. Id want to break it all up quickly and coarsely in one PR, when go through and refactor/clean up individual classes by themselves at a more leisurely pace.

Alternative would be to check-in each new class one at a time, slowly carving out functionality from LabelMaker.cpp. This is less disruptive to concurrent contributors but can take a lot longer to complete.

As things are broken up I'd like to move toward enforcing a C++ style, the most obvious choice is probably Google C++ Style with clang, but any of the common alternatives would be fine so long as its adhered to, including something we make custom. Most projects choose one of the well-known styles (Google, Microsoft, Mozilla, etc) and then just override rules as they see fit.

@andreisperid You have your finger on the pulse of whats going on with this project currently. Do you think this is a good idea, and if so do you think now is a good time to do it?

Instead of using an independent breakout (keyes ky 003), the PCB could directly hold the hall sensor with an SMD form factor.

This could help with:

• more solid positioning to avoid later homing calibration issues;
• avoid usage of different hall sensor specs (44E 402 vs 3144) populated in the same ky 003 module, which have completely different sensor outputs when exposed to the magnetic field;
• simpler pillar piece;
• much easier assembly and less screws;

That would impact:

• PCB: would encompass the sensor (but SMD), a resistor and a LED that are currently in the breakout;
• F_pillar;
• I_nema_wheel_hub: would need to bring the magnet closer to the PCB, without colliding with the P_press;

I have experimented printing @Knochi parametric design for the custom daisy wheels.

Keep in mind I'm just beginning at 3d printing with resin, there are among my first dozens of pieces. If anyone has experience with it, might be super useful.

Good news:

• the resin wheel characters are able to emboss the label (manually for now, using a plier since the model is not mountable into the device right now)
• it is pretty fast to print both bottom and top parts together (below 2h)

Bad news:

• I have used Anycubic's both Water-Washable Plus and Eco resins, and both are super brittle during the removal of supports. So a few teeth have gone already during the process.
• lets hope the actual embossing with the device is less harsh than the support removal, but I think it will be worse, meaning that probably the wheel will not stand the use with current settings.

What I have experimented with:

• materials: Eco resin is too oily, I didn't like both the result and process. The Water-Washable: much better, still as brittle as the first;
• models angle to the printing base: the bottom part works well horizontally, but the upper gets detached from the supports. I've managed to tilt it +- 20 degrees to lessen the adhesion area to the FEP. The bad news is that there was a subtle distortion on the final piece;
• supports: I have tried diminishing the intersection of supports to the models, but it ended up detaching them both. In the end, I have kept the default light settings for the Anycubic slicer, but increased the number of supports to avoid object distortion.

I have changed a few things on the model too (e3cacbc / 27d45fe):

• overall clearance between upper and bottom part
• increased the text inset height and lateral expansion on the upper wheel
• to be done: modify the bottom part with a coupling the daisywheel to the wheel cube so it can be tested with the real device (might need a custom wheel cube).

So, I think there might be at least two ways to tackle these issues:
1 - better suited material: I've seen people recommend mixing Siraya Tech's Blu and Tenacious to achieve a semi-flexible result.
2 - different design: to try not forcing a design that was meant for thermoplastics into resin. Maybe thickening the arms, for instance.

On the J_top-Part there is a screw hole hitting a countersink.

I often find myself wanting to print labels longer than the maximum 18 or 20 characters enforced by the printer website, so I'm making this issue a starting point to discuss how to implement that. To me it looks like there are two main things that would need to be changed to accomodate this:

1. The "PRINTING" screen on the microcontroller would need to be changed to indicate the progress of a label that doesn't entirely fit on the little oled screen.
2. The label-dependent-jingle should shorten itself somehow for very long labels. Otherwise it just kind of drones on for an uncomfortably long time and doesn't feel "fun".
3. The website would need to be changed to also render its textbox in a way that doesn't choke for longer strings. This should be done in a way that doesn't impede its currently very mobile-friendly sizing.

It would be cool if you could Group and Lable your assemblies to make navigating the STEP file easier, as currently it's kind of hard to find anything since stuff like the Electronic and mechanic assembiles aren't seperated and all parts are simply named brep.

I don’t have my pc with me right now so I can’t check what the screw hole diameter of the models is, but on my parts I had quite a lot of screws spinning freely in the hole.
It might just be a tolerance issue with my printer, but maybe consider adding a version with 2,5mm diameter holes that the user can then cut a thread into.

On mobile safari on iOS, and no other browser, the 'user-select: none' CSS attribute is interpreted as disabling an element completely. This makes the UI unusable for the device, as text can not be entered into the label textbox and emoji buttons can't be clicked.

I'll make a PR that fixes this.

A fellow redditor (and @Knochi also, if I'm not mistaken) suggested that we could use kerning to improve the readability.

Maybe kerning pairs are something to look for, but on the other hand the most critical ones seem to be the Y, V, T, L, P, I, not to mention the tape feeding right now is not so precise, so it could be super simple. Just a matter of roughly balancing the negative space between chars.

It should count as a web app option, because the messed characters are part of the charm.

The printer will sometimes print "J" incorrectly as the first letter of a print. After some debugging I've identified it happens any time the previous print ends with the same letter that the following print starts with. for example printing "HI THERE" followed by "EARTH" will result in "HI THERE" being correctly printed but then "JARTH".

This appears to be because the printer uses the "prevChar" variable to avoid moving the carousel between sequential identical letters. It doesn't get reset during a home, so the when the printer homes at the start of a print and moves to "J" prev char is still set to the last letter of the previous print.

Its a simple fix, I'll make a PR.

Most M3 20mm could probably be replaced with at least 16mm screws. As I already mentioned in issue 29, 2,5*(outer thread diameter) screw-in depth is theoretically enough. 20mm are quite long and tedious to screw in.

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.

This keyboard autocomplete bar has reappeared on Chrome (didn't test others).

I have tried getting the type="search" back to the <input> and it worked while keeping the "send" functionality.

@sabeechen do you have anything strongly against that? Not ideal, but it works...

As in https://hackaday.com/2022/06/15/diy-automated-printer-kerchunks-out-classic-embossed-labels/#comment-6484189

Suggestions: https://www.youtube.com/watch?v=F0E5adLQ-AY&lc=UgwwJ4s63TFKkHuZJst4AaABAg

Right now, if a label is sent to be printed in a device, and then a second device connects to the machine, the latter progress is shown based on whatever is written on the second input label (not the actual label being printed).

For instance, below a second device which had nothing written, while a printing was already been started prior. It misleads the user as if that placeholder text was being printed:

Any device should show the actual characters that are being printed, with its respective progress.

For that, perhaps the device should advertise the current label.

Now that we are just about to allow longer labels to be embossed, I got thinking that we might want to cancel it during print.

A flow would be something like this:
1 - user writes the label and hits print
2 - user desires to cancel, which happens after a modal confirmation (just in case)
3 - the device receives the instruction and finishes the process of embossing up to 1 letter
4 - the device feeds once, then cut
5 - idle and ready to receive new instructions

If the printer website is suspended while its printing, it remains in the "busy" state after coming back online even if the print is finished and allows no further interaction. Reloading the page resolves the issue. This is particularly a problem on mobile devices, because the page is typically suspended when the screen goes to sleep.

Instead of the small 28BYJ, a NEMA stepper motor could be used to increase the feed speed, precision and reliability.

Since there is no need to use both the char and feed at the same time, I had the idea of having a single A4988 driver to control both via switching. With that, the ULN2003 could be eliminated.

The down point is that a major structure redesign should be made, since the NEMA is way bigger.

The printer website gets a 404 when attempting to load the label font, fontwhite.tff. This is because the file uploaded in SPIFFS is named fontWhite.tff with a capital W.

The device has got two switch buttons that could be used to facilitate the wi-fi configuration by using push-button WPS:

• FN: only used to enter the bootloader mode
• Wi-fi: used to clear the wi-fi settings if pressed during the boot, but not using for anything else.

The second one seems more suitable for the purpose and the label already placed. Ideally, there should be a dedicated WPS button to avoid confusion.

So instead of entering the device's captive portal and inserting the SSID and password, the user could simply auto configure by pressing a button on both the device and the wi-fi router.

Use flow:

• with wi-fi not configured, the screen will instruct the user to either log into the captive portal (current method) or press the Wifi button for WPS automated process
• user presses the WPS button on the device
• screen instructs the user to press the WPS button on the router
• with success, inform in the screen and reboot the device

This example seems to have potential, but I didn't analyze it in depth yet.

Restarts occur occasionally when loading the web app or sending commands, and it seems related to processing peaks that trigger the task watchdog.