Understand and report on status codes

[maresb]

It would be nice to figure out the status code so that dymoprint could report the status. Here is the manual for a different DYMO printer where they explain the status codes, but the LabelManager PnP is different, especially since it has a battery. Here are some sample codes I get from subsequent prints:

[96, 0, 18, 100, 13, 181, 0, 0]
[96, 0, 2, 100, 13, 186, 0, 0]
[96, 0, 2, 100, 13, 186, 0, 0]

[maresb]

I think the first byte is the so-called "status byte" as described in the above technical manual.

96 = 64 + 32 = 2⁶ + 2⁵.

Within this byte, I think bit 5 means "busy" and bit 6 means "cassette present". (If I call getStatus() when the printer is idle, I get 64. If I remove the cassette, I get 0.) That bit 6 is "CASSETTE" matches with the spec for the 450, although for the 450, bit 5 is "Ignore".

The second byte seems to be always zero.

The third byte seems to be either 18 or 2, and 18 = 2⁴ + 2¹. Usually it's 2, but occasionally it's 18. I don't have any good guesses here.

The 4th byte seems to be always 100. Not sure if this is 100% something or 2⁶ + 2⁵ + 2².

The 5th byte seems to be 13 or 14. When it is 14, it seems to indicate that the 6th byte is below some threshold.

The 6th byte is very interesting, and I strongly suspect it has to do with the battery. If I continuously query the status, its value fluctuates fairly wildly, is sensitive to vibrations, in particular if I wiggle the battery. Here are some samples from continuous monitoring:

[64, 0, 18, 100, 13, 255, 0, 0]
[64, 0, 18, 100, 13, 255, 0, 0]
[64, 0, 2, 100, 14, 8, 0, 0]
[64, 0, 2, 100, 14, 7, 0, 0]
[64, 0, 2, 100, 14, 6, 0, 0]
[64, 0, 2, 100, 14, 5, 0, 0]
[64, 0, 2, 100, 14, 4, 0, 0]
[64, 0, 2, 100, 14, 4, 0, 0]
[64, 0, 2, 100, 14, 3, 0, 0]
[64, 0, 2, 100, 14, 3, 0, 0]
[64, 0, 2, 100, 14, 3, 0, 0]
[64, 0, 2, 100, 14, 2, 0, 0]
[64, 0, 2, 100, 14, 1, 0, 0]
[64, 0, 2, 100, 14, 3, 0, 0]
[64, 0, 2, 100, 13, 255, 0, 0]
[64, 0, 2, 100, 14, 1, 0, 0]
[64, 0, 2, 100, 14, 1, 0, 0]
[64, 0, 2, 100, 13, 255, 0, 0]
[64, 0, 2, 100, 13, 255, 0, 0]
[64, 0, 2, 100, 13, 255, 0, 0]

[maresb]

Some more continuous monitoring, but this time while printing:

[64, 0, 18, 100, 14, 8, 0, 0]
[64, 0, 18, 100, 14, 8, 0, 0]
[64, 0, 18, 100, 14, 8, 0, 0]
[64, 0, 18, 100, 14, 7, 0, 0]
[64, 0, 18, 100, 14, 8, 0, 0]
[96, 0, 18, 100, 14, 8, 0, 0]
[96, 0, 18, 100, 14, 8, 0, 0]
[96, 0, 18, 100, 14, 8, 0, 0]
[64, 0, 2, 100, 13, 252, 0, 0]
[64, 0, 2, 100, 14, 2, 0, 0]
[64, 0, 2, 100, 14, 4, 0, 0]
[64, 0, 2, 100, 14, 6, 0, 0]
[64, 0, 2, 100, 14, 7, 0, 0]
[64, 0, 2, 100, 14, 7, 0, 0]
[64, 0, 2, 100, 14, 6, 0, 0]
[64, 0, 2, 100, 14, 7, 0, 0]
[64, 0, 2, 100, 14, 7, 0, 0]
[64, 0, 2, 100, 14, 7, 0, 0]
[64, 0, 2, 100, 14, 7, 0, 0]
[64, 0, 2, 100, 14, 7, 0, 0]
[64, 0, 2, 100, 14, 7, 0, 0]
[64, 0, 2, 100, 14, 7, 0, 0]
[64, 0, 2, 100, 14, 7, 0, 0]
[64, 0, 2, 100, 14, 7, 0, 0]
[64, 0, 18, 100, 14, 7, 0, 0]
[64, 0, 18, 100, 14, 7, 0, 0]
[64, 0, 18, 100, 14, 7, 0, 0]
[64, 0, 18, 100, 14, 7, 0, 0]

We see the first byte switching from 64 to 96 during printing. There was also some time here where the printer gave no response.

[maresb]

I spent a few minutes wiggling the battery and recording values for bytes 5 and 6. Here's a graph of the results:

When byte 5 is 13, byte 6 can apparently be anything between 41 and 255, plus one recorded instance of it being 34.

When byte 5 is 14, byte 6 is between 0 and 10, with a few outliers having values 106, 133, 134, and 142.

There was one additional outlier where byte 5 was 12 when byte 6 was 221.

I'm not sure if these outliers represent some valid rare condition, or if they're some sort of electrical glitch.

[nathancatlow]

Hi,

Firstly, thankyou for writing this handy utility, I have been using it for years (the python2 version) until the battery ran out and caused me issues. In the process of working this out I rigged up a bench power supply to the battery terminals and gradually reduced the voltage then did a print and recorded the response to try to simulate a dying battery, fyi here are my findings;

8v   [96, 0, 2, 100, 13, 128, 0, 0]
6v   [96, 0, 2, 100, 13, 141, 0, 0]
5v   [96, 0, 2, 100, 13, 132, 0, 0] print very faded
     [96, 0, 2, 100, 13, 180, 0, 0]
     [96, 0, 2, 100, 13, 142, 0, 0]
4v   [96, 0, 2, 100, 13, 136, 0, 0]
     [96, 0, 2, 100, 13, 132, 0, 0]
     [96, 0, 2, 100, 13, 146, 0, 0]
3v   [96, 0, 2, 100, 13, 132, 0, 0]
     [96, 0, 2, 100, 13, 156, 0, 0]
     [96, 0, 2, 100, 13, 154, 0, 0]
2.5v [96, 0, 130, 100, 13, 131, 0, 0]
2v   [68, 0, 130, 0, 7, 39, 0, 0]

Hope this is of some use. The 96 - 68 flip could indicate 'battery missing'.

[maresb]

@nathancatlow thanks so much for the report, that is very intriguing!!!

I was expecting the 6th byte to be correlated with voltage, but that's evidently not the case. I wonder what it could be... maybe something to do with temperature?

Firstly, thankyou for writing this handy utility,

I can't take credit for much. My contribution was primarily refactoring and modernizing. Most of the thanks should go to Sebastian Bronner, @computerlyrik, and the rest of the contributors.

[maresb]

My printer unfortunately seems to have mostly failed. Presumably it's a battery issue.

The status I see most of the time looks like

[64, 0, 130, 0, 10, 102, 0, 0]

These values are significantly different from what I measured earlier. Currently I'm getting a solid blue light, but most of the time I was getting a flashing blue light (3 flashes, pause, repeat).

It did manage to print a faded label one time with the status

[96, 0, 2, 0, 10, 90, 0, 0]

Under no load, my battery measures 8.0V with a multimeter. It's rated for 7.4V 650mAh 4.81Wh, but I'm not sure what is the expected voltage without load.

There are some interesting suggestions regarding the battery on the dymo website. Unfortunately nothing that helped in my case.

@nathancatlow, do you have any suggestions for how to rig up a simple hardware hack without much equipment? I don't own a power supply. I'm tempted to try rigging 5 alkaline batteries in series, but then I'd be worried about the batteries being charged and thus destroyed. Would I be safe if I used rechargeable batteries?

[maresb]

Hi @nathancatlow, thanks for your previous interest in dymoprint. Do you still have your LabelManager PnP? I received a PR in #54 for a full DymoPrint GUI, but I can't test it personally since my device is unfortunately dead. (I have another one on order, but it has not yet shipped.)

If you can spare the time, I'd really appreciate a test or review of that PR.

[tomek-szczesny]

I extracted a few post-send responses I got before I charged the printer for the first time. I got responses only when I tried printing longer text (one or two responses).

[64, 0, 146, 0, 11, 135, 0, 0]
[64, 0, 146, 0, 11, 136, 0, 0]
[64, 0, 146, 0, 11, 139, 0, 0]
[64, 0, 146, 0, 11, 139, 0, 0]

Here are responses from successful prints:
4-letter string (two attempts)
[96, 0, 18, 2, 12, 84, 0, 0]
[96, 0, 18, 2, 12, 84, 0, 0]

5-letter string and a small square picture (two attempts)

[96, 0, 18, 19, 12, 129, 0, 0]
[96, 0, 18, 19, 12, 129, 0, 0]

[96, 0, 18, 24, 12, 141, 0, 0]
[96, 0, 18, 24, 12, 141, 0, 0]

Something different about half an hour later (Dymo connected to PC USB):
[96, 0, 18, 53, 12, 219, 0, 0]

Indeed the first byte has something to do with "ability to print".

Similarly, the third byte seems to somewhat correlate with device status. I think that only three bits are in use there:
10010010
As seen in my examples above, there is a third bit (Bit 7), which indicates some sort of fault condition. Bit 1 has always been =1 in our collected data so far.

The third byte seems to be either 18 or 2, and 18 = 2⁴ + 2¹. Usually it's 2, but occasionally it's 18. I don't have any good guesses here.

Bytes 5 and 6 could be a battery voltage. Notice in my case it's slowly rising over time.
The formula might be: (Byte5)*256 + (Byte6).
The lowest value I observed would be 11*256+135 = 2951
The highest value I recorded is 3291.

Those values, if interpreted in milivolts, are very reasonable voltages of a li-ion cell. Except Dymo PnP has a 7.4V battery, indicating two cells in series (each with 3.7V nominal voltage, just like any li-ion cell).

The device may measure battery voltage divided by two for technical reasons. The ratio could be anything really.

Thus the lowest value for the whole battery pack, in my measurements, would be 5.902V and the highest 6.582V. Note the highest value I have observed was during printing, when the voltage may be much lower than with no load.

The highest value reported by anybody else would be 3592, which, if my theory is correct, would indicate 7.184V.
This is not quite 7.4V, but a probable figure if it was captured during printing.
If this is the highest value we can get without printing, there may be a protective diode inside the device that drops some of the battery voltage. Still, I think my theory makes a lot of sense.

And while we're at it, the fourth byte could simply be a battery status in percents. Note however that it doesn't have to immediately follow the battery voltage. Calculating battery capacity is a complex task that involves integrating current flowing in and out the battery to calculate its capacity and how much charge is left in it. This is probably why it did not changed when battery with varying voltage was simulated.
If someone took a printer apart and made a hi res photo of electronics I could try deduce if "coulomb counter" circuit is present. No wonder it always shows 100% if we give printer no chance to discharge. :)

In fact, I think the reason so many people have problems with batteries in these printers could mean it discharges them way below the safety threshold and destroys them. This may happen if it drains batteries in storage and probably will not happen when connected to USB port all the time. Li-ion cells should never drop below 2.5V or 3V to begin with (remember, the battery pack has 2 cells).

[maresb]

Hey @tomek-szczesny, thanks so much for the detailed report, and the various other feedback! It's really excellent to have an EE.

I have a broken LabelManager PnP. I've done a teardown, but unfortunately I didn't take any photos. Once I get a few hours I'll open it up again take a bunch of photos.

I can't promise any particular time, I have a lot going on these days.

[tomek-szczesny]

If my predictions are all correct, your printer could be fixed by adding a big capacitor instead of a battery. Much cheaper and will not die again - capacitors cannot be killed by discharging them down to 0V.

If you prefer, you could mail me your printer instead. We both live in EU so that's feasible. I'll tear it apart myself and inspect it. I'll also attempt a repair with a big capacitor instead of a new battery. When it works I'll send it back to you, and I'll write a gist about it, so a few thousand people will be able to fix their printers. If you like the idea, feel free to e-mail me, mctom@tlen with polish country code.

If you don't feel comfortable with this offer, then a photo of a torn down printer will be equally appreciated. Thanks. :)

[maresb]

Thanks @tomek-szczesny, I sent you an email.

[tomek-szczesny]

Seems like I forgot to follow up on this thread.
I did experiment with a broken printer from @maresb as well as my own, using two huge capacitors instead of a battery. It did work, the printer answered USB queries and so on, except the printing itself, in which case it was blacking out.
So there is an answer to my question - they added a battery to these printers just to support extreme demand for current required for thermal printing.

[maresb]

Ah, interesting! Thanks for the followup.

By "blacking out" do you mean "not responding"?

Do you think the capacitors used were not large enough to sustain the power?

Do you think there's potential for a simple and cheap solution (like the 9V battery trick, only better)?

I wouldn't read too far into failures of the unit I sent since it was already broken and then I disassembled/reassembled it.

[tomek-szczesny]

By "Blacking out" I mean draining capacitors below threshold voltage in which the printer gives up. Stops printing and responding via USB, which suggests microcontroller reset.
More precisely, this is formally called "Brown out". Many digital circuits have "Brown out detectors", that force them to reset themselves if input voltage is insufficient - otherwise it may work incorrectly, which is worse than not working at all.

Two capacitos that I used were a bit larger than the original battery, there's no way of putting more capacitance in there, without using supercapacitors, or ultracapacitors. But they share chemistry and drawbacks of actual batteries, so that doesn't make sense, giving their high cost.

There are rechargeable 9V batteries on the market, and they could be used as replacement for a worn out battery. Some of them have in fact nominal voltage of 7.4V, which is even better, and would take a bit of trial and error to figure out which is the best.
Here someone listed some good candidates: https://michaelbluejay.com/batteries/9v.html

But they may be damaged just as the original batteries, by deep, uncontrolled discharge.
It is possible to design a small circuit, that could be placed between a 9V rechargeable battery and Dymo contacts, that would protect it against undervoltage - something Dymo clearly lacks. But for now I keep my printer connected to USB at all times, if it changes I could develop this solution.

[maresb]

So if I understand correctly, you would recommend buying a generic rechargeable 9V battery and keeping it under USB power 24/7 to maintain the voltage?

I see 2 pcs. rechargeable 9V for €12 on amazon.fr, so that is a lot better than the replacement from Dymo.

[nathancatlow]

For information;

The battery pack in my Dymo PnP consisted of a pair of these;

14430 Battery 3.7V Li-ion (14 x 43mm 4/5AA) 650mAh

I dismantled the 'pack' and replaced the cells. YMMV. I agree that these have a capacitance function, I presume the printer pulls too many amps from the USB whilst printing resulting in 'brown out' (and usb reset).

[tomek-szczesny]

So if I understand correctly, you would recommend buying a generic 9V battery and keeping it under USB power 24/7 to maintain the voltage?

That is the state of my knowledge as of today. Personally I'd do that, exactly.

I dismantled the 'pack' and replaced the cells.

Fixing a battery is of course possible, as it doesn't seem to have any controller in it of any kind, but I was thinking about either an easier solution, or the one that is immune to complete discharge by extended storage time.