New dymo hardware revision breaks free-dmo

[MeisterLone]

I am not 100% sure about this one, but it looks like Dymo silently updated hardware in the latest batches of printers. Tested a known working stm32 in both old and new Dymo 550 Turbo printer and it doesnt work on the new printer. No obvious difference on the model numbers.

[apppie123]

Is it not being recognized? Or do labels simply not reset anymore?

They have added an eeprom to the board to store label usage.

There was a command added by dymo and this has been added to the firmware. Perhaps your board needs to be reflashed with updated firmware?

[eha002]

Any updates?

Is this just 550?

Ive seen a few comments saying newer machines not working but cant find anything concrete.

[KudzuKid]

I suspect SOME (if not all) of the units "not working" are either errors in the mod (cold, shorted or mis-soldered connections) and/or folks getting knock-off/counterfeit BluePills. I did my (new at the time) 5XL earlier in the Spring or so and it went very well. I've updated Connect several times with no issues. I'm personally not sure that Dymo would get a good ROI to make it worthwhile for them to rewrite firmware/hardware just to give heartburn to a small minority of users that would be brave enough to do the hack, let alone install a pre-made hack (e.g.: off eBay, etc.). But anything's possible and I've been wrong once or twice. Just my 2¢ - if anyone else has any more concrete experiences - I'd be interested to hear it.

BTW, the Betckey labels off Amazon are literally 1/10th the price of the "authentic" D*mo and work every bit just as well.

Cheers!

On Thu, Oct 10, 2024 at 4:51 AM eha002 @.***> wrote:

Any updates?

Is this just 550?

Ive seen a few comments saying newer machines not working but cant find anything concrete.

— Reply to this email directly, view it on GitHub https://github.com/free-dmo/free-dmo-stm32/issues/50#issuecomment-2404624383, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF3VKAVXUCSZMB62B75ODOTZ2ZE2RAVCNFSM6AAAAABO3VUKB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBUGYZDIMZYGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[MeisterLone]

@KudzuKid in my specific case, if you read my original comment, I have deployed 550’s that work perfectly fine (counterfeit bluepills). I wont say how many, but quite a few. Over the last year, some of my 550’s have worn out and I purchased the exact same model 550 directly from Dymo and transferred the pills from the old working printers to the new ones that visually look exactly the same, without success.

I did not reflash them with the latest code from this project though, so that is something I need to try. I am just using dymo rolls until I get to that. It is just kind of odd that the exact same model printer (visually identical) with a known working pill flashed a year ago dont work together.

[KudzuKid]

I'm not saying this is the case for you, and I'm not familiar specifically with the 550 (I have a 5XL), but here's one thing I've personally observed: The flexible circuit ribbon cables (2) in my 5XL are EXTREMELY short (I wish I knew where to get longer ones - but too lazy to research right now). You can not take the cover completely off without disconnecting them (either manually or by yanking them out of their ZIF style sockets). So, at one point, after I reassembled my 5XL for the 2nd or 3rd time - it suddenly didn't work anymore. I thought I had bricked it in a re-flash or something. Even after I took it back appat, it LOOKED AS IF the flexi-ribbons were plugged in - and they were, but one of them wasn't plugged in ENOUGH! After I reseated it, it took off working again. All this to say - there are many variables in the mix, some more obvious than others. That one was a little sneaky. This from a guy with well over 30 years of electronics and IT experience, sigh, LOL!

Good luck and keep us posted, please!

Best wishes

On Thu, Oct 10, 2024 at 7:06 PM Paul Francis Nel @.***> wrote:

@KudzuKid https://github.com/KudzuKid in my specific case, if you read my original comment, I have deployed 550’s that work perfectly fine (counterfeit bluepills). I wont say how many, but quite a few. Over the last year, some of them have worn out and I purchased the exact same model 550 directly from Dymo and transferred the pills from the old working printers to the new ones that visually look exactly the same, without success.

I did not reflash them with the latest code from this project though, so that is something I need to try. I am just using dymo rolls until I get to that. It is just kind of odd that the exact same model printer (visually identical) with a known working pill flashed a year ago dont work together.

— Reply to this email directly, view it on GitHub https://github.com/free-dmo/free-dmo-stm32/issues/50#issuecomment-2406256470, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF3VKASNKSFWFYN2YCU23ELZ24JAFAVCNFSM6AAAAABO3VUKB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBWGI2TMNBXGA . You are receiving this because you were mentioned.Message ID: @.***>

[KudzuKid]

It might be interesting to examine the contents of any onboard ROMs, NVRAMs (or wherever the firmware is stored) if someone could do a comparison to known "good" (hacked/hackable) units. I've not yet been so interested in doing a stare & compare / dump of the boards' firmware (presuming they appear identical as you say). Are you leaving the NFC connected or just running off the 'pill? In my case, I did the kind of a 'man in the middle' with it - and connected the NFC board to the 'pill. I guess you don't have to - but I didn't want to have to take it apart (or outboard the 'pill) and re-flash the 'pill if I ever changed label types. I hope this makes a little sense. It sounds interesting. I'd be surprised if D*mo re-wrote code to check for 'man in the middle' (Audrino, 'pills, Pi's, etc.) But I guess they could suddenly check for a signature/checksum or something that they weren't previously doing. Not a software engineer but I suspect it's possible to do; BUT the juice has to be worth the squeeze. All that just to keep what - maybe a couple of hundred people from using brand X labels? Please do keep us posted.

On Thu, Oct 10, 2024 at 7:06 PM Paul Francis Nel @.***> wrote:

@KudzuKid https://github.com/KudzuKid in my specific case, if you read my original comment, I have deployed 550’s that work perfectly fine (counterfeit bluepills). I wont say how many, but quite a few. Over the last year, some of them have worn out and I purchased the exact same model 550 directly from Dymo and transferred the pills from the old working printers to the new ones that visually look exactly the same, without success.

I did not reflash them with the latest code from this project though, so that is something I need to try. I am just using dymo rolls until I get to that. It is just kind of odd that the exact same model printer (visually identical) with a known working pill flashed a year ago dont work together.

— Reply to this email directly, view it on GitHub https://github.com/free-dmo/free-dmo-stm32/issues/50#issuecomment-2406256470, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF3VKASNKSFWFYN2YCU23ELZ24JAFAVCNFSM6AAAAABO3VUKB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBWGI2TMNBXGA . You are receiving this because you were mentioned.Message ID: @.***>

[eha002]

@MeisterLone Whats the first 2Letter/Numbers of your Serials that aren't working vs are?

I have 2 GQ13 5XL, 1 QG25 5XL and a QF34 550T that all work.

Im going to try on a QG41 5XL soon to see if it's a no go.

[KudzuKid]

I have a 5XL... mod works like a champ.

QG2

Hope this helps!

On Fri, Oct 11, 2024 at 1:48 AM eha002 @.***> wrote:

@MeisterLone https://github.com/MeisterLone Whats the first 2Letter/Numbers of your Serials that aren't working vs are?

I have 2 GQ13 5XL, 1 QG25 5XL and a QF34 550T that all work.

Im going to try on a QG41 5XL soon to see if it's a no go.

— Reply to this email directly, view it on GitHub https://github.com/free-dmo/free-dmo-stm32/issues/50#issuecomment-2406663601, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF3VKAWAD33GGPJUYYKX7R3Z25YDJAVCNFSM6AAAAABO3VUKB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBWGY3DGNRQGE . You are receiving this because you were mentioned.Message ID: @.***>

[eha002]

Just an update for everyone

I have got a non-working example that was purchased this year,

It's a full new mainBoard but the rest of the printer is the same including the Reader, So in theory it should be able to be bypassed in a similar way, once someone discovers how its stopping the freedmo from working.

[apppie123]

Are you running the latest firmware from here? I see several people posting that it doesn't work, but no one is able to tell they are running the latest release that contains communication fixes... Check eevblog. There was a discussion beginning of the year.

[eha002]

Yeah mate. I have 3 working units and 1 that wont Accept the module.

Ive only pulled 2 apart completely, But the one that works and one that doesn't have different PCBS

Is working are 2xQG13 1xQG25 & also have a QF34 550T that works.

But a QG41 doesn't work.

[xq1xq1xq1]

I am unsure where to find the Q model numbers listed above but we have just purchased 4 550 printers in the last 4 weeks so I assume these are the new vintage

We are totally bypassing the RFID board

Dymo Connect sees the printer but says the labels are empty and it does not reflect the label indicated by the firmware that I installed on the bluepill

Any ideas?

[KudzuKid]

The "Q number" is the serial # - it seems to always with Q, someone was all about the first 3-4 digits. Trying to track exactly if/when a hardware change took place. See earlier comments in this thread (or whatever the proper Git-vernacular is! 🫠). Found on a sticker on the bottom of the unit I believe. Seemingly, just the first 3-4 characters will tell the story.

On Tue, Nov 5, 2024, 09:04 xq1xq1xq1 @.***> wrote:

I am unsure where to find the Q model numbers listed above but we have just purchased 4 550 printers in the last 4 weeks so I assume these are the new vintage

We are totally bypassing the RFID board

Dymo Connect sees the printer but says the labels are empty and it does not reflect the label indicated by the firmware that I installed on the bluepill

Any ideas?

— Reply to this email directly, view it on GitHub https://github.com/free-dmo/free-dmo-stm32/issues/50#issuecomment-2457414306, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF3VKASGFNBYUFXUR2EGAWDZ7DNADAVCNFSM6AAAAABO3VUKB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJXGQYTIMZQGY . You are receiving this because you were mentioned.Message ID: @.***>

[xq1xq1xq1]

Thanks for the clarification

My printers are QE4080

Are these the older model from which is NOT having the problem?

[xq1xq1xq1]

In my case the label showing up in Dymo Connect does not match the firmware I loaded and it indicates that the printer is empty

[xq1xq1xq1]

It does not seem to matter which firmware I load, DYMO Connect shows Connected/Empty with the same label every time as 30251/Not in Printer

[KudzuKid]

It might help if you can describe your hack a little bit.  There are a couple of ways of doing it.  Some people eliminate/bypass/disconnect the RFID reader completely, while another option is to connect it. Are you for sure using a genuine BluePill? I understand the market is pretty flooded with counterfeits.

In my hack, I used the RFID board and kept it intact since I already had a fair supply of "AUTHENTIC" D*mo labels (I occasionally use a larger shipping label, etc.), but since I typically run brand X labels (Betckey work GREAT for my in my 5XL) - standard address size, there's no RFID core to detect, so it defaults to the 'pill, which is flashed with the appropriate image. 

One time earlier this year, after some experimentation in the early stages after I did the initial hack, I experienced exactly the same issue you are seeing!  Connect said the printer was "Empty" / couldn't detect label type (forget exact verbiage). So I carefully disassembled the 5XL, after examination, I realized one of the 2 flex ribbon cables was not completely seated in the DIP/LIF socket.  It initially LOOKED good but wasn't firmly seated. I pulled and reseated the flex ribbon, reassembled it, and all was well once again.  I'm not saying THIS is your issue categorically, but it might be worth a check.  If Dymo has redesigned hardware somehow to 'work around' the 'pill, I bet there's a way to hack the redesigned units similarly. I do see visual differences between the older and newer boards in a couple photos @eha002 posted recently, but I can't discern component function & placement.  I'm not really into SMT much and it's easy (for me) to get lost reverse engineering it. I'm not a hardware engineer, nor do I play one on the internet, LOL.

Best wishes & keep us posted. 

[xq1xq1xq1]

I checked the ribbon cables you mentioned and they looked good

When I connect in the RFID board I have from a different 550 printer, DYMO Connect recognizes the label correctly for the printer I am working on

But when I plug in the BluePill Dymo Connect shows labels are empty and the last label type that was read by the DYMO RFID board is displayed

Secondary question:

How do I select which label to use that is stored in the Firmware?

[apppie123]

It might not be the hardware. I just tried several of the SKU's in this repo and so far only some of them work.

Then I loaded the data from some SKU's I got here and they work flawlessly.

Perhaps d*mo has banned the data for the SKU's in this repo? Or could labels be regio locked?

For example DMO_SKU_30578, DMO_SKU_30252 and DMO_SKU_30572 don't work for me in a 5XL but DMO_SKU_S0904980 and DMO_SKU_S0722400 work fine.

[xq1xq1xq1]

Thanks so much for your insights.

Did you build your own firmware for these SKUs or is there some some other method of selecting the working SKU?

[apppie123]

Yeah you would need to re-compile the code and flash it to your bluepill. You can select a different SKU using the #define as explained in the code. I am trying to get insight which work and which don’t to understand why they do not work. So far it appears that the non working ones are not being sold here.

On 11 Nov 2024, at 18:01, xq1xq1xq1 @.***> wrote:

Thanks so much for your insights.

Did you build your own firmware for these SKUs or is there some some other method of selecting the working SKU?

— Reply to this email directly, view it on GitHub https://github.com/free-dmo/free-dmo-stm32/issues/50#issuecomment-2468642589, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXF3I3LLO4AN7DRE4PUZQED2ADPGJAVCNFSM6AAAAABO3VUKB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRYGY2DENJYHE. You are receiving this because you commented.

[xq1xq1xq1]

Cool - I have not built firmware before - i am spinning up a Debian VM and will give it a shot

I will let you know how I make out

Thanks for helping me move down this path!

[xq1xq1xq1]

I installed the required software from the readme file on a Debian VM

Option 1: Install the required ARM toolchain from distribution

install the ARM toolchain from distribution (e.g. on Debian-based GNU/Linux install the gcc-arm-none-eabi and libnewlib-arm-none-eabi packages)

run make to compile the firmware

I did an initial make on the given Makefile to prove that I have what I need but I get this error:

Src/main.c: In function 'InitEmulationWithDefaultData':
Src/main.c:572:31: error: 'DMO_TAG_SLIX2_BLOCKS' undeclared (first use in this function); did you mean 'EMU_SLIX2_BLOCKS'?
  572 |   memcpy(EMU_SLIX2_BLOCKS,    DMO_TAG_SLIX2_BLOCKS, SLIX2_BLOCKS*sizeof(uint32_t));
      |                               ^~~~~~~~~~~~~~~~~~~~
      |                               EMU_SLIX2_BLOCKS

line 572 is contained in this block:

void InitEmulationWithDefaultData(void) {
  //copy default tag data
  memcpy(EMU_SLIX2_INVENTORY, DMO_TAG_SLIX2_INVENTORY, SLIX2_INVENTORY_LEN);
  memcpy(EMU_SLIX2_SYSINFO,   DMO_TAG_SLIX2_SYSINFO, SLIX2_SYSINFO_LEN);
  memcpy(EMU_SLIX2_SIGNATURE, DMO_TAG_SLIX2_SIGNATURE, SLIX2_SIGNATURE_LEN);
  memcpy(EMU_SLIX2_BLOCKS,    DMO_TAG_SLIX2_BLOCKS, SLIX2_BLOCKS*sizeof(uint32_t));
}

As this is my first time I am a bit stuck in what to do to move forward?

Any guidance is appreciated!

[xq1xq1xq1]

Looking more in the main.c, I found this section:

/////////////////////////////////////////////////////////
// DMO emulation data (default emulation after power up)
//

//choose between one of the dumped SKU (roll types) for emulation
//#define DMO_SKU_S0722430  //  54 mm x 101 mm / 2.125 in x 4 in    /  220 pcs.
//#define DMO_SKU_S0722550  //  19 mm x  51 mm / 0.75 in x 2 in     /  500 pcs.
//#define DMO_SKU_S0722400  //  36 mm x  89 mm / 1.4 in x 3.5 in    /   50 pcs.
//#define DMO_SKU_1744907   // 102 mm x 152 mm / 4 in x 6 in        /  220 pcs.
//#define DMO_SKU_30857     //  57 mm x 104 mm / 2.25 in x 4 in     /  250 pcs.
//#define DMO_SKU_30336     //  25 mm x  51 mm / 1 in x 2.125 in    /  500 pcs.
//#define DMO_SKU_30332     //  25 mm x  25 mm / 1 in x 1 in        /  750 pcs.
//#define DMO_SKU_30256     //  59 mm x 104 mm / 2.3125 in x 4 in   /  300 pcs.
#define DMO_SKU_30252     //  28 mm x  89 mm / 1.125 in x 3.5 in  /  350 pcs.
??#define<200e>DMO_SKU_S0722540  //  57 mm x  32 mm / 1.25 in x 2.25 in  / 1000 pcs.
//#define DMO_SKU_S0904980  // 104 mm x 159 mm / 4 in x 6 in        /  220 pcs.
//#define DMO_SKU_

and

//choose one of the dumped original tags for UID + signature emulation. It does not have to match the dumped data
#define SLIX2_TAG_EMU 1  // 1-12](url)

so I think that it should have tried to use this for the label configuration

I am unsure if I am misinterpreting or if there is an error in main.c (which I doubt )

I am stuck for now :-(

[xq1xq1xq1]

very much a rookie mistake - there were no option uncommented

once I uncommented an option it worked as expected

[xq1xq1xq1]

No success but then I read the main.c comments closer

I will add the Inventory, sysinfo and signature data into main.c tomorrow and let you know how I make out

[xq1xq1xq1]

I added all of the Tag information 241113_main.c.txt into the appropriate spots in main.c and reflashed the bluepill for label 30323

DYMO Connect shows:

• Label 30251 not 30323
• Connected
• Empty

I am not using the RFID Board

Has anyone has success with not using the RFID board as part of the emulation?

[apppie123]

Did you try several different types of labels? For me many of them don’t work.

On 13 Nov 2024, at 17:36, xq1xq1xq1 @.***> wrote:

I added all of the Tag information into the appropriate spots in main.c and reflashed the bluepill for label 30323

DYMO Connect shows:

Label 30251 not 30323 Connected Empty I am not using the RFID Board

Has anyone has success with not using the RFID board as part of the emulation?

— Reply to this email directly, view it on GitHub https://github.com/free-dmo/free-dmo-stm32/issues/50#issuecomment-2474142348, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXF3I3IT5KNTRBFZAYHGQ4T2AN5ZHAVCNFSM6AAAAABO3VUKB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZUGE2DEMZUHA. You are receiving this because you commented.

[xq1xq1xq1]

I purchased a new box of 30323 labels from DYMO and extracted the RFID Tags and inserted them into main.c

These are the labels that we need to print on.

My thought was that if the label is current and that RFID tag is extracted that it should work but I could be totally off base.

@apppie123 Do you have an example of a label that did work for you?

[xq1xq1xq1]

@apppie123 Do you have the original RFID board connected to the Bluepill?

[Axis-3790]

Are you running the latest firmware from here? I see several people posting that it doesn't work, but no one is able to tell they are running the latest release that contains communication fixes... Check eevblog. There was a discussion beginning of the year.

I can confirm this is working on my end. I bought a brand new 5xl about a month ago and no problems on my end using the latest firmware.

[KudzuKid]

Nice meet another 5XL user!

On Wed, Nov 13, 2024, 16:06 Axis-3790 @.***> wrote:

Are you running the latest firmware from here? I see several people posting that it doesn't work, but no one is able to tell they are running the latest release that contains communication fixes... Check eevblog. There was a discussion beginning of the year.

I can confirm this is working on my end. I bought a brand new 5xl about a month ago and no problems on my end using the latest firmware.

Rant - Dymo has been a b***h to work with. I have a 450 turbo I am working on fixing. The main selling point for the new 5' series is the ability to print via lan without the need of a print server.

— Reply to this email directly, view it on GitHub https://github.com/free-dmo/free-dmo-stm32/issues/50#issuecomment-2474920224, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF3VKAR472ZZPBRHSOO6IT32APENTAVCNFSM6AAAAABO3VUKB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZUHEZDAMRSGQ . You are receiving this because you were mentioned.Message ID: @.***>

[xq1xq1xq1]

I purchased a new box of 30323 labels from DYMO and extracted the RFID Tags and inserted them into main.c

These are the labels that we need to print on.

My thought was that if the label is current and that RFID tag is extracted that it should work but I could be totally off base.

@apppie123 https://github.com/apppie123 Do you have an example of a label that did work for you?

Do you have the original RFID board connected to the Bluepill?

On Wed, Nov 13, 2024, 10:38 a.m. test123 @.***> wrote:

Did you try several different types of labels? For me many of them don’t work.

On 13 Nov 2024, at 17:36, xq1xq1xq1 @.***> wrote:

I added all of the Tag information into the appropriate spots in main.c and reflashed the bluepill for label 30323

DYMO Connect shows:

Label 30251 not 30323 Connected Empty I am not using the RFID Board

Has anyone has success with not using the RFID board as part of the emulation?

— Reply to this email directly, view it on GitHub < https://github.com/free-dmo/free-dmo-stm32/issues/50#issuecomment-2474142348>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AXF3I3IT5KNTRBFZAYHGQ4T2AN5ZHAVCNFSM6AAAAABO3VUKB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZUGE2DEMZUHA>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/free-dmo/free-dmo-stm32/issues/50#issuecomment-2474147969, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF4KUSNDFOAERKSCFTLRMX32AN57XAVCNFSM6AAAAABO3VUKB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZUGE2DOOJWHE . You are receiving this because you commented.Message ID: @.***>