A retro tkt #24
Replies: 10 comments 14 replies
-
|
Hey @skrutt ! Really cool to see another build, I'm really happy. Maybe @sabeechen could post his build in a discussion topic like yours 💡 PS: I love the color 🍏! About the power section: since you didn't implement it yet, maybe you can do a few adjustments so you can use a 12v power supply.
PS: that part of the diagram below is wrong, it should be at max 5v (7v as a stretch), but not 7-12v. But... if you use the 12v stepper version, then 12v is the exact right voltage.
The little screen is so cute... I only changed to a bigger one in the current version because it is too small to read the QR... Anyways, the basic information will fit the smaller, but if you might want to change to a bigger one (128x64px) you would be able to take advantage of the new firmware versions that @sabeechen is contributing to. Regarding the microswitch, I'm not sure if that would work better than the hall since 3d printers are linear and the switches are placed at the end-stops, differently from the E-TKT, where there is no physical end (cylinder). Maybe you would need to change the daisywheel cube to have some relief to trigger the switch, but it might be a mechanical challenge to adjust it perfectly. Do you have anything against using the hall sensor? |
Beta Was this translation helpful? Give feedback.
-
|
I don't have anything against the hall sensor per se, not apart from being stubborn! And some half baked reasons about adding complexity, cost and more parts. Otoh a switch will actuate at least once per printed letter so I guess a contactless solution might be longer lasting. I guess we shall find out 🤓 For the mechanical alignment, i think it'll be ok, it has some give in the lever arm so as long as it clicks.. and rotationally I'll adjust in software :) For the stepper, i just double checked the ones i got and all are 5v.. i guess the only component needing more than 6v are the NEMA stepper. Could it be worth testing that at 6v also? Is the stepper performance/torque critical? Regarding 7806, i think it will run pretty hot, a TO220 package can dissipate around 1w before overheating, not sure how much the servo needs but say 0.5A would already be 3w. Anything more than that and the heatsink size will skyrocket. But i might have some suitable switchers in stock :) As an update: |
Beta Was this translation helpful? Give feedback.
-
|
Nope, A4988 stepper driver is 8v minimum, so not possible with 6v supply only.. |
Beta Was this translation helpful? Give feedback.
-
|
I think my power supply rated "7V" was more than 8V instead (didn't measure under load though), so that makes sense for the A4988 minimum... But I did use the 7806 with this 8V input and it does not heat too much. But, a 12V input would surely... About the OLED display, it does "flicker" because of the refresh rate. I remember old CRTs, another retro feature? 😝 |
Beta Was this translation helpful? Give feedback.
-
|
There are quite a lot of wiring in this machine, and so far I have spent 0 time to tidy the cabling up so it really looks messy. Just to top it of, the screen fell of after i had verified everything was moving. It'll need some strain relief for sure, the sacrificed jumper duponts have barely any copper in them. Also saw some erratic behavior, i had not added any capacitance anywhere so hopefully that will be an easy fix. I was a bit concerned that i had gotten the wrong servo delivered, since i could rotate it several revolutions by hand, but once connected correctly it seems to work without issue. With regards to the power dissipation of the linear regulator, it seems like it might be fine! I only tested at a conservative 9v but it stayed cool to the touch, so there seems to be quite some headroom to the 100+degrees where the thermal protection kicks in. I also added a diode between the 5v and 5v-in on the esp board, so USB while powered should be ok. And wired up a microswich for homing, but unfortunately I'll need to find some more suitable time for soldering/cleaning up before I get a chance to try coding that part.. |
Beta Was this translation helpful? Give feedback.
-
|
Wow, what a ride.. did a first hacky mount of the microswitch yesterday as a proof of concept. i printed a small wedge shape that got superglued into place, and then sacrificed the nema mount because of proximity of the part and suitable hole pattern.. i can say it works! The day before though i actually did some first tries with the movement, tried to see if the press and feed mechanics worked but i just could not get any consistent results at all, so i actually caved and placed and order for the hall sensor and magnet, since i just had such a hard time. But then since i still had to wait, i figured that it was really the homing that was missing to go from chaos into order, so i went after the homebrew you see here.
After updating the code to use the digital input, i first had really no results at all. it would always move a bit and then stop in an arbitrary location. It was not until i really dug down and did: while(stepchar.move()) that i realized that it must be the input that was misbehaving, and sure enough a quick google did reveal that pin 34 does not have any pullups. DOH. After a quick solderjob to add one it was more sensible, and i realized that the char stepper was rotating the wrong way. this would actually go on to be a longer issue as i added a define for inversion of step direction but only for stepsperchar, to some moves where still backwards. Long story short, that is now rectified and all moves are clockwise, homing works and i've done quite some testing with calibration! After finding that the ui for saving the calibration has a small bug, it does not send a valid rest command -> finally i had an excuse to use postman for the first time and i actually managed the first real print! 😄
And i apparently placed it upside down in all the excitement! 🙃 |
Beta Was this translation helpful? Give feedback.
-
|
Happy to see some embossed labels! The build is getting nice! I got wondering how the sound of the embossing would be on every homing, must be cool (I love the microswitch clicks!). The stepper direction is something that gave @sabeechen some headaches too. Glad that you figured it out! For the stepper cables, you might just cut them out because the full sized length will surely not fit inside 🤓 PS: loved the ö for 😲 |
Beta Was this translation helpful? Give feedback.
-
|
Well, the ö was meant to be a star 😄 Do you have any thoughts on this? I have not spotted any provisions for different wheels in the software, though i know you made the wheels changeable. I didn't count yet but guess my wheel has fewer glyphs aswell since there is åäö and also the Danish æ. Maybe it's more Scandinavian than Swedish.. Anyhow, i can read JavaScript but otherwise not very good at "web stuff", so not quite sure how to tackle that. But åäö is printable on keyboard so should also be compatible with no specific handling, except in the character map. Yeah I really need to sort the cables, some of the jumpers are really low quality and have a tendency to slip out! It's very clicky indeed, and seems reliable enough. I have some alignment issues but they seem consistent, and i think might be related to the mechanics.. maybe the shape of the press related to print quality or maybe because I couldn't get the actuator to seat properly, the character pressed is maybe half a character to the left of window center. In actual printing it's currently a bit silly, i implemented a double tap with a fast search followed by a slow accurate touch on the switch, but only rotating one way that means a whole rotation. And then since the placement is not the same as the original, it first goes to 'j', another half turn, followed by the actual character, could be almost a full turn! So that's like three rotations, for each letter! I'm for sure gonna look into optimizing that some time, it seems rock solid not loosing steps so i think one homing should do, at least as long as the stepper can stay energized. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, happy accidents! So you have the wheel that does not have the symbols but instead these special characters... I used that one in my first prototype too, but when I bought new wheels, I've got the other version with the symbols. There is a physical possibility for changing the wheel, but the software to support is not developed yet. Would you please open an issue for us to discuss? Maybe 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. As @sabeechen made improvements to support Unicode characters, I guess there would be no big problems on transmitting the åäö, etc. For the alignment, its the most critical part of the machine, and this is why I've created a fine calibration mode on the newer revision, for both daisywheel alignment and the press angle... I was wanting to experiment with a single homing too, I guess that could make the printing process at least 10% faster. Anyways, the movement should be always clockwise to avoid entangling the tape on the wheel's teeth. So, for instance, if you go from letter B to A, you still need that almost 360 degree revolution. If you test this single homing, please let me know how it went! |
Beta Was this translation helpful? Give feedback.
-
|
Will try it! I think it can be much faster than 10%, and there is
additional time to save if the logic for feeding could move straight to the
next position instead of one character at the time.
I have some time tomorrow to try it out again :)
…On Thu, Apr 13, 2023, 15:33 Andrei Speridião ***@***.***> wrote:
Ah, happy accidents!
So you have the wheel that does not have the symbols but instead these
special characters... I used that one in my first prototype too, but when I
bought new wheels, I've got the other version with the symbols.
There is a physical possibility for changing the wheel, but the software
to support is not developed yet. Would you please open an issue for us to
discuss? Maybe 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. As
@sabeechen <https://github.com/sabeechen> made improvements to support
Unicode characters, I guess there would be no big problems on transmitting
the åäö, etc.
For the alignment, its the most critical part of the machine, and this is
why I've created a fine calibration mode on the newer revision, for both
daisywheel alignment and the press angle...
I was wanting to experiment with a single homing too, I guess that could
make the printing process at least 10% faster. Anyways, the movement should
be always clockwise to avoid entangling the tape on the wheel's teeth. So,
for instance, if you go from letter B to A, you still need that almost 360
degree revolution.
If you test this single homing, please let me know how it went!
—
Reply to this email directly, view it on GitHub
<#24 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA326WE5YRMSIBDE35C7S3TXA76DDANCNFSM6AAAAAAWPD7ITI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
OK, so i did not look into the homing, but i did get the integration into Home assistant working! Playing with the API did find me some strange behaviour, for one i managed to lock the device in "feeding", where it did not want to return to idle. I did see a note about that in the code so i guess it's not a new thing 😄 One obvious thing here. since i just put the "command" api value on the dashboard to show what it's doing, there is no idle state! Or rather, i guess there is no "State" at all, which might be nice if building integrations. Not that hard to add in the integration step instead but i do prefer writing c/c++ over YAML! 😱 Picture from UI: Here is the configuration details for any interested souls: And a quick draft of a lovelace card for UI: |
Beta Was this translation helpful? Give feedback.
-
|
That's nice! A few questions:
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's the home assistant. I have a *Home assistant blue" more
specifically, but regardless of hardware should work the same.
I'll have to double check that i have the latest version, otherwise i'll
update. But it's all json for the api
…On Tue, Apr 18, 2023, 21:32 Andrei Speridião ***@***.***> wrote:
That's nice!
A few questions:
1. What home assistant are you developing to? Do you have more info on
that? (is that one? https://www.home-assistant.io/)
2. What E-TKT firmware are you building over? Because this stuck in
"feed", etc, was a problem that happened before @sabeechen
<https://github.com/sabeechen> implemented the JSON API
<#16>
—
Reply to this email directly, view it on GitHub
<#24 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA326WFWDOD5OJCEXD5IKWLXB3T5XANCNFSM6AAAAAAWPD7ITI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
@andreisperid In a serendipitous twist, Home Assistant happens to be the same automation platform I write that addon for. I like the idea of being able to print a label from Home Assistant, I was going to make something very much like this once, but I decided I just love that little website too much to give me a reason not to use it :) sensor:
- platform: rest
resource: http://192.168.1.154/api/status
name: "E-TKT Status"
unique_id: 17cfa33b-4ff1-4008-96a6-ee60177fd955
value_template: "{{ value_json.command if value_json.busy else 'idle' }}"Though I think you'd need to the sensor to query/update constantly in order for it to ever show anything useful. I suppose you could write an automation that calls the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! thats a very clean way to template the idle state. With regards to the sensor being useful, i feel thats a bit of a.. almost philosophical question. Generally you are either using the device or not using it, and you need to fetch you label either way, so i feel that it's closer to a novelty than real world usefulness. BUT i still want it to be working and perfect ofcourse, otherwise i would not be here 😄 i have not actually looked yet but i would guess there is a way to control the polling rate of the rest sensor? And if you can do that in real time, you should be able to template that into a higher update rate when the print service is called + a reset when idle is detected again. Either way, for myself i feel that if i want the extra polish to the integration i might just do a custom component instead, as that would tie both the state and the service into one and provide a (better) place for things like translations and polling rate. Or, perhaps mqtt discovery? I do like the discovery feature... hum. With regards to the feeding, i had 8 commits that i merged yesterday. Quite suprised that it was auto-merged, since i basically changed and split pretty much every file in the src dir. i dont see any changes to the relevant code, but i believe there is a race condition... oh wait, typing here and reading the code simultaneously! When feeding, there is a delay(1000); at the end of displayQRCode();, after busy is reset! My guess is that the new request landed just after busy = false;
Maybe is good enough? According to the docs, calling vTaskDelete with null will terminate the calling task, so should be closer to the intended result in this case. My tkt is on the healing bench right now awaiting new crimps that actually fit the contact housings so i cant test it right now. |
Beta Was this translation helpful? Give feedback.
-
|
BTW, did any of @andreisperid or @sabeechen look into my fork? i feel a little bit silly since i painted myself into my own special corner, and this makes it more difficult for me to contribute upstream. If you do have a look, i would love to hear your thoughts on the layout of split files, new defines etc. it should still support a "normal" etkt, but since i dont have one to test on i cannot promise i didnt make any mistakes 👀 And more stuff also means more clutter so i want to be respectful of the original artists intent. I realize that me wanting to test my ideas might not be of interest to add to official support. |
Beta Was this translation helpful? Give feedback.
-
|
I'm loving that interaction around the Home Assistant, which I didn't know until now but will figure it out little by little. May be interesting to any other ideas. What kind of possibilities do you think it brings to E-TKT @sabeechen @skrutt ? I'm particularly interested on voice commands and automation with other chained tasks. And @skrutt I hadn't looked at your fork yet, thanks for letting me know! I see you have several things implemented, can you please list their main ideas so we can try to figure out what could be part of the V1.0.0 onwards? If they make sense, we can figure a way to bring them ;) Regarding the questions related to the Home assistant on the previous post, I will do a bit of research and read it with calm later, but I guess that @sabeechen might already have the answer. |
Beta Was this translation helpful? Give feedback.
-
|
The freeze up around setting The biggest advantage for Home Assistant integration I think would just be having a convenient place to print labels, since many are already using it as a kind of dashboard or homepage. It might be cool for to be able to say "Ok Google, print a label that says 'Spices'" though I'm not sure I trust that robot's voice recognition enough to get that right. Being able to cancel a print in progress over voice might be cool too. WRT a custom HA component, I think that would be cool. IIUC mqtt autodiscovery doesn't let you create services, so I don't think that would work, but you can have custom components autoconfigure themselves through network discovery too (not sure how it works precisely). I think it would be good to have the device advertise itself somehow, like over mdns. Rest sensors only allow a constant polling frequency, but you're separately allowed to call the You should also know that over the API, the server doesn't check to make sure the label is long enough to be retrieved from inside the machine, you'll need to add padding spaces manually for shorter labels (under 7 chars I think), but thats also likely to change in the future. @andreisperid If you ever have trouble getting started with Home Assistant don't be afraid to ask me. Its notoriously difficult for beginners and I've already trialed and errored my way through every problem you could possibly run in to. |
Beta Was this translation helpful? Give feedback.
-
|
Well, the biggest thing i think is the smaller display. To integrate this
in a more structured way i split the display functions out into their own
files, complete with headers and such.
Originally i had a pretty simple idea for that split, cut, paste and
include, but quickly realized that platformio is a bit rigid in the
compilation of source etc so the path of least resistance became a more
formal layout.
Overall the changes:
* Refactor and defines for different display support.
* Reimplementing 32px screen
* Add support for microswich homing, +define
* Define for reversing char stepper direction
* Removal of double negatives for clockwise char stepper
* Minor tweaks, such as renaming optconfig.cpp to .h
…On Tue, Apr 25, 2023, 01:39 Andrei Speridião ***@***.***> wrote:
I'm loving that interaction around the Home Assistant, which I didn't know
until now but will figure it out little by little. May be interesting to
any other ideas.
What kind of possibilities do you think it brings to E-TKT @sabeechen
<https://github.com/sabeechen> @skrutt <https://github.com/skrutt> ? I'm
particularly interested on voice commands and automation with other chained
tasks.
And @skrutt <https://github.com/skrutt> I hadn't looked at your fork yet,
thanks for letting me know!
I see you have several things implemented, can you please list their main
ideas so we can try to figure out what could be part of the V1.0.0 onwards?
If they make sense, we can figure a way to bring them ;)
Regarding the questions related to the Home assistant on the previous
post, I will do a bit of research and read it with calm later, but I guess
that @sabeechen <https://github.com/sabeechen> might already have the
answer.
—
Reply to this email directly, view it on GitHub
<#24 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA326WFFS4HPDFTAR7QFFGLXC4FMBANCNFSM6AAAAAAWPD7ITI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
These thing might have potential for a pull request:
My only concern is how compatible these changes are to the current code. I've just merged a PR from Stephen recent main changes. Maybe you could update your branch and see if is there any conflict. Then you can make some PRs. What do you think? PS: I love the small display (though I think it isn't as readable) and the microswitch is a viable alternative for homing, but supporting both in the main project at the same time as the current solutions would be a bit confusing. |
Beta Was this translation helpful? Give feedback.
-
|
Well, I was afraid you would say that, as i’m not sure on how the split into several files will work in a pull request. Or if I can figure out how to.
But overall I *think* it might be possible, git has a certain quality of magic after all. Only way to know is to try 😊
With regards to home assistant, one of my goals for that is to make it more usable to family and friends. If it’s on the same webpage, there is less things to remember. I noticed that the raw api did not add any spaces to the label so I just added two before and two after.
And regarding busy or not.. it a tricky subject that can involve quite some theory. But I think the current API “philosophy” (me reading between the lines of code), is quite fortuitous. The device is either busy, or not, and if the switches in between are cleaned up a bit more this should not really come up.
There might be a few clock cycles between busy = false and the termination of the thread, but that should also be actually OK since the work is done and there is memory to spare.
|
Beta Was this translation helpful? Give feedback.
-
|
Ok, so i had a look, and a think, and i think i need to change my approach. I'll try to keep upstream compatible features in own branches so that they can be put in a PR, and me-specific ones in their own branch. Also means i kind of need to start over! Happy Walpurgis night! |
Beta Was this translation helpful? Give feedback.
-
|
Nice @skrutt @sabeechen brought the initiative of doing a refactoring in #42, which might be a good opportunity for you to sync in with the main E-TKT branch. I'm also learning a lot, it is my first ever opensource interaction :) PS: didn't know about Walpurgis night, so it seems you are from Germany? |
Beta Was this translation helpful? Give feedback.
-
|
PS: maybe we can collaborate on the custom daisy wheel issue. As I did with Stephen in #17, I focused on the user interface. |
Beta Was this translation helpful? Give feedback.
-
Starting a thread for my e-tkt build!
It's been in the making for half a year now, or at least in thought. Between waiting for parts, running out of filament and a general lack of free time 😅
Between the time when I "started" and downloaded the files, Andrei produced the PCB and made a bunch of updates to the design. I had already printed all the parts when I noticed, and also have the old esp module. So I'll "press" on, and see where i land.
I have currently assembled most of the PCB, still missing a power section and some cabling. Also not sure what power supply to use when it's ready..
Originally my plan was a pretty bare bones implementation, a workhorse integrated into my home assistant instance, even without the screen, since you are probably not looking at the device when you are typing your label.
Then i realized that I actually have several fitting screens on hand! And also that this cute project might be more involved than my first guess, it's always nice to have good feedback when testing stuff.
Today i got the spiffs partition flashed and started on modifying the code to support the smaller screen again, and splitting the display functions into separate files in my fork with a flag for what screen you have. Not quite sure why anyone else would walk my current path by choice, but most of the great open source projects such as marlin have ludicrous support for different hardware so, I'll give it a try.
I'm also planning to try out a microswich for the homing, if it works for homing a 3dprinter it should work here right?
Here are some current pictures:
Beta Was this translation helpful? Give feedback.
All reactions