Barcode generator

[Benoit Maag]

Just bought an HP-41C Wand barcode reader.
I would like to generate barcodes for some programs (the magnetic cards I have are not very reliable anymore). Found a few options but many of the download links are broken. Can someone suggest an available software for PC for barcode generation?

Also, I am trying to understand the checksum algorithms but the HP documentation is not very clear - is there a simple explanation somewhere?

Thank you,

[Didier Lachieze]

I’m using Leo Duran excellent HP41UC - User-Code Utility.

[Pierre]

You are never better served than by yourself...
I therefore use my own interface to generate the barcodes.

You can therefore download it from my site clone.phweb.me
or directly here.
(works in Excel)

[Benoit Maag]

Thank you both - will give it a try

[ThomasF]

(05-04-2024 07:06 PM)Benoit Maag Wrote:  Also, I am trying to understand the checksum algorithms but the HP documentation is not very clear - is there a simple explanation somewhere?

Hi,

The algorithm is fairly easy, for most bar codes the first byte is a 8-bit checksum of all bytes in the code:

Code:

    int chkSum = firstLine ? 0 : prevLineChecksum;
    for(int n=1; n<bLen; n++) // Loop over all bytes (except the first one)
        chkSum += barcode.bytes[n];
    while( chkSum & 0xFF00 ) // Check if any overflow
        chkSum = (chkSum&0xFF) + (chkSum>>8);
    barcode.bytes[0] = chkSum; // Save the checksum in the array

bLen is the length of the array holding the bytes, and barcode.bytes is the array.
barcode.bytes[0] will contain the calculated checksum.

For program bar codes (multiple lines), the checksum is initialized with zero (0) for the first line, and for all other lines the checksum is initialized to the checksum of the previous line (a running checksum).

The exception are paper keyboard bar codes.
- The one-byte bar codes which has no checksum, instead the second nibble is the same as the first but reversed (e.g. hex "DB" = binary "1101 1011").
- And two bytes codes, where the checksum is only 4 bits (nibble[0]) and is the 4-bit checksum of the other three nibbles.

Hope that clear up any confusion ...

Cheers,
Thomas

[aurelio]

(05-05-2024 06:53 AM)Pierre Wrote:  You are never better served than by yourself...
I therefore use my own interface to generate the barcodes.

You can therefore download it from my site clone.phweb.me
or directly here.
(works in Excel)

Thank you Pierre, your is really a great tool, I've "played" with it a few years ago, and I remember at the beginning a problems with the new OS W10, problem that I think meanwhile you sure had solved.. For that reason I decided to keep a PC with XP for that usage (and not only) but later, actually I don't remember well how, I succeded with a workaround in using it it with the new OS.
Happy to read you and thank you one time more.

Edit: typos
greetings from Italy

[Pierre]

(05-09-2024 02:04 PM)aurelio Wrote:  Thank you Pierre...

Thank you especially to you and to all those who use my programs which I only do to have fun and to please others.
I always liked producing bugs to have to fix them so I continue in retirement.
So don't hesitate to let me know what you find.
(I have just made corrections in my interface thanks to Benoit Maag)

[Benoit Maag]

Thank you Pierre - I love your tool and the interface could not be any simpler to use.

BTW I tried to laminate some barcode pages to limit wear but the wand could not read the laminated barcodes, I suppose because the laminator film is glossy. Does anyone know whether matte finish laminator pouches work?

[Benoit Maag]

Thank you Thomas for the clear explanation.

(05-06-2024 12:25 PM)ThomasF Wrote:  

(05-04-2024 07:06 PM)Benoit Maag Wrote:  Also, I am trying to understand the checksum algorithms but the HP documentation is not very clear - is there a simple explanation somewhere?

Hi,

The algorithm is fairly easy, for most bar codes the first byte is a 8-bit checksum of all bytes in the code:

Code:

    int chkSum = firstLine ? 0 : prevLineChecksum;
    for(int n=1; n<bLen; n++) // Loop over all bytes (except the first one)
        chkSum += barcode.bytes[n];
    while( chkSum & 0xFF00 ) // Check if any overflow
        chkSum = (chkSum&0xFF) + (chkSum>>8);
    barcode.bytes[0] = chkSum; // Save the checksum in the array

bLen is the length of the array holding the bytes, and barcode.bytes is the array.
barcode.bytes[0] will contain the calculated checksum.

For program bar codes (multiple lines), the checksum is initialized with zero (0) for the first line, and for all other lines the checksum is initialized to the checksum of the previous line (a running checksum).

The exception are paper keyboard bar codes.
- The one-byte bar codes which has no checksum, instead the second nibble is the same as the first but reversed (e.g. hex "DB" = binary "1101 1011").
- And two bytes codes, where the checksum is only 4 bits (nibble[0]) and is the 4-bit checksum of the other three nibbles.

Hope that clear up any confusion ...

Cheers,
Thomas

[Benoit Maag]

Thank you Thomas for the clear explanation.

(05-06-2024 12:25 PM)ThomasF Wrote:  

(05-04-2024 07:06 PM)Benoit Maag Wrote:  Also, I am trying to understand the checksum algorithms but the HP documentation is not very clear - is there a simple explanation somewhere?

Hi,

The algorithm is fairly easy, for most bar codes the first byte is a 8-bit checksum of all bytes in the code:

Code:

    int chkSum = firstLine ? 0 : prevLineChecksum;
    for(int n=1; n<bLen; n++) // Loop over all bytes (except the first one)
        chkSum += barcode.bytes[n];
    while( chkSum & 0xFF00 ) // Check if any overflow
        chkSum = (chkSum&0xFF) + (chkSum>>8);
    barcode.bytes[0] = chkSum; // Save the checksum in the array

bLen is the length of the array holding the bytes, and barcode.bytes is the array.
barcode.bytes[0] will contain the calculated checksum.

For program bar codes (multiple lines), the checksum is initialized with zero (0) for the first line, and for all other lines the checksum is initialized to the checksum of the previous line (a running checksum).

The exception are paper keyboard bar codes.
- The one-byte bar codes which has no checksum, instead the second nibble is the same as the first but reversed (e.g. hex "DB" = binary "1101 1011").
- And two bytes codes, where the checksum is only 4 bits (nibble[0]) and is the 4-bit checksum of the other three nibbles.

Hope that clear up any confusion ...

Cheers,
Thomas

[Massimo Gnerucci]

(05-11-2024 04:13 PM)Benoit Maag Wrote:  Thank you Pierre - I love your tool and the interface could not be any simpler to use.

BTW I tried to laminate some barcode pages to limit wear but the wand could not read the laminated barcodes, I suppose because the laminator film is glossy. Does anyone know whether matte finish laminator pouches work?

The protective plastic film inside the wand box was matte IIRC.

[Pierre]

(05-11-2024 04:13 PM)Benoit Maag Wrote:  Thank you Pierre - I love your tool and the interface could not be any simpler to use.

Thanks to you who trusted me (despite a bug that I was able to quickly correct).
Don't hesitate to let me know of any improvements or corrections I could make.

Merci à toi qui m'a fait confiance (malgré un bug que j'ai pu corriger rapidement).
N'hésite pas à me signaler les améliorations ou corrections que je pourrai apporter.

[Mike]

(05-09-2024 10:07 PM)Pierre Wrote:  

(05-09-2024 02:04 PM)aurelio Wrote:  Thank you Pierre...

Thank you especially to you and to all those who use my programs which I only do to have fun and to please others.
I always liked producing bugs to have to fix them so I continue in retirement.
So don't hesitate to let me know what you find.
(I have just made corrections in my interface thanks to Benoit Maag)

G'day Pierre. I really appreciate your work. Makes documenting programs simpler and much more fun.
Not sure if this a bug or just a limitation in Excel but I notice the following in PX41CX_Interface, it’s just a small thing. If you load a text file the following occurs:

If you have a number in the calculator such as .211327 the PX41CX_Interface automatically adds the leading zero so the number becomes 0.211327

Again many thanks for your work.
Mike

[Pierre]

(08-21-2024 09:17 AM)Mike Wrote:  [quote='Pierre' pid='186995' dateline='1715292467']
.../...
If you load a text file the following occurs:
If you have a number in the calculator such as .211327 the PX41CX_Interface automatically adds the leading zero so the number becomes 0.211327
Again many thanks for your work.
Mike

Thanks to you Mike.
I'll see if I can correct the leading zero problem, hoping that Excel will be less stubborn than me!
I try to improve my programs whenever someone asks me to.
Have a nice day.
Pierre

[Pierre]

(08-21-2024 09:17 AM)Mike Wrote:  ...so the number becomes 0.211327

I made a fix that resolves the issue. (I hope...)

The cell is no longer in Excel "Standard" format (which processed the real format depending on the content either in text or in numeric) but in "Text" format so everything that is typed is considered as text.
So .123 will remain .123 but 00.123 will remain 00.123 !

So... I updated PX41CX Interface on my site.

[Mike]

(08-21-2024 12:34 PM)Pierre Wrote:  

(08-21-2024 09:17 AM)Mike Wrote:  ...so the number becomes 0.211327

I made a fix that resolves the issue. (I hope...)

The cell is no longer in Excel "Standard" format (which processed the real format depending on the content either in text or in numeric) but in "Text" format so everything that is typed is considered as text.
So .123 will remain .123 but 00.123 will remain 00.123 !

So... I updated PX41CX Interface on my site.

Thanks Pierre

[Mike]

(08-21-2024 12:34 PM)Pierre Wrote:  

(08-21-2024 09:17 AM)Mike Wrote:  ...so the number becomes 0.211327

I made a fix that resolves the issue. (I hope...)

The cell is no longer in Excel "Standard" format (which processed the real format depending on the content either in text or in numeric) but in "Text" format so everything that is typed is considered as text.
So .123 will remain .123 but 00.123 will remain 00.123 !

So... I updated PX41CX Interface on my site.

G'day Pierre,

I found a bug.
LBL A and LBL a compile the same code CF 66, so when loaded they both appear as LBL A. Same for all lower case labels they appear as the uppercase label: eg

Code:

LBL A
SF 02
LBL a
FS?C 02
1/X

End up as

LBL A
SF 02
LBL A
FS?C 02
1/X

Mike

[Pierre]

(08-22-2024 02:45 AM)Mike Wrote:  I found a bug.
LBL A and LBL a compile the same code CF 66 ...

Sorry Mike!
But this is not really a bug but rather an oversight on my part.
I never used the LBL a,b,c,d,e because I found them impractical and confusing.
I also, which may seem like a flaw to some, had a TI-58C as my first calculator... with other LBL habits...
So I'm going to add these 5 LBLs that I probably won't use in the future...
With apologies for this omission.
Pierre

[Pierre]

One more correction...
I suspect that there are still omissions, gaps or bugs...
This is the programmer's lot...
Not to mention the missed fixes... so don't forget to save the previous version before installing the new one!
And thank you for the report which allows me to progress and improve my programs.

So... I updated (again, and again, and again...) PX41CX Interface on my site.

[Mike]

(08-22-2024 09:49 AM)Pierre Wrote:  One more correction...
I suspect that there are still omissions, gaps or bugs...
This is the programmer's lot...
Not to mention the missed fixes... so don't forget to save the previous version before installing the new one!
And thank you for the report which allows me to progress and improve my programs.

So... I updated (again, and again, and again...) PX41CX Interface on my site.

Thanks again Pierre, lower case labels now compile correctly.