I have two barcodes that I am working with. They are clearly different, but both scan as code 128. One is weird and one is normal. I have tried to reprint the data for the barcode in every way I can think of to I can see what subset (A, B or C) is being used.
For the normal one I know it is A for the first 10 chars then it changes the encoding to B.
I cannot seem to find out how to see what the encoding is on the other (weird) one.
I am using a symbol scanner. (I turned on the prefix char but that only told me D (Code 128)
Is there any tool to allow me to dig into the barcode symbologies?
I know very little about barcodes and zero about non-european ones, but for weird implementations of Code 128, there is also GS1-128.
This online barcode generator looks quite nice and can generate a lot of formats you might want to check against.
Chiming in late here, but the ZXing library (I'm a developer) reads Code 128. You could have it scan the barcode while you attach a debugger to the code. It would show you exactly what's happening, step by step, in the decoding, including subset changes.
I know the problem is fixed. But here's some more resource in case someone's in need :)
Like Pekka mentioned, a Code 128 have subsets like Code 128A, Code 128B, Code 128C and GS1-128(UCC/EAN-128). Here is more information on Code 128 barcode, with encoding pattern illustration.
Thanks for those that answered and commented.
Turns out the company that made our barcodes had a printing error. That caused the barcode to look different.
How it ever successfully decoded I do not know. Anyway. I am going to award the question to Pekka because he gave me a workable solution.
Related
I'm an ABAP programmer and I was asked to make a minor modification to an IPL label.
Easily done, but now I was tasked to fix a long running error within said label.
I know nothing about IPL and the lack of a online viewer makes everything worse...
The problem is that "tabulation" right in the middle of a text (I underlined it in blue on the Label's pic).
I checked the code and there's nothing there that should make that tabulation appear.
I spent a whole month reading manuals and trying to fix it, but nothing changes...
Here's the code and the resulting label:
<STX>R<ETX>
<STX><ESC>C<SI>W791<SI>h<ETX>
<STX><ESC>P<ETX>
<STX>F*<ETX>
<STX>H1;f3;o220,52;c34;b0;h2;w1;d3,300052947-FANDANGOS PRESUNTO 140GX14 LD<ETX>
<STX>H2;f3;o130,52;c33;b0;h1;w1;d3,Val:<ETX>
<STX>H3;f3;o130,204;c34;b0;h1;w1;d3,QTD.Unidade:<ETX>
<STX>H4;f3;o90,33;c34;b0;h0;w1;d3,16/08/21<ETX>
<STX>H5;f3;o90,302;c34;b0;h1;w1;d3,14<ETX>
<STX>B6;f3;o375,44;c2,0;w6;h102;r0;d3,17892840816329<ETX>
<STX>H7;f3;o275,44;c26;b0;h17;w17;d3,17892840816329<ETX>
<STX>H8;f3;o130,490;c34;b0;h0;w1;d3,Lote:<ETX>
<STX>B9;f3;o090,600;c2,0;w2;h45;r0;d3,0005218177<ETX>
<STX>H10;f3;o130,600;c34;b0;h0;w1;d3,0005218177<ETX>
<STX>D0<ETX>
<STX>R<ETX>
<STX><SI>l13<ETX>
<STX><ESC>E*,1<CAN><ETX>
<STX><RS>1000<US>1<ETB><ETX>
Label
Can you guys help me, please??
Edit: Just to make it clear, I did that blue line on that image to show what's the problem.
Here are some tests I did by changing the data:
Test1
Test2
The error always appear at the same point in the label, as long as there's a space in that text.
Have you looked at the raw data of the output? Is it POSSIBLE that what looks like a space is actually some special character that is making IPL choke blue? Because it is literally the 1 character between the "O" and "1". For grins, you might also try to change the character in the data to a "-" just for purposes of confirming data context. It might even just be a TAB character.
I have done IPL years ago and have actually gone to the point of defining a pre-defined label template and generating output that says to use template X (whatever # I created as),and pass the data along that fills into the respective fields.
A final option I would throw in is this. Take the sample output you have and just force sample data into each of the output areas. So, instead of your literal data, put fake data in similar context just to see if it is data specific or other. Such as
<STX>H1;f3;o220,52;c34;b0;h2;w1;d3,300052947-FANDANGOS PRESUNTO 140GX14 LD<ETX>
becomes
<STX>H1;f3;o220,52;c34;b0;h2;w1;d3,123456789-TESTING-SAMPLEDATA-123XY12-AB<ETX>
Notice same context of data, but no spaces and using dash "-" just for testing. Is there something special about the actual data. This is a good way I have done historically for similar strangeness early on doing IPL labels.
User decided to not spend anymore time on this issue, so now I'm unable to further test the label.
Unfortunately this problem will go unsolved for now. Hope I get another chance to fix this and learn more about IPL.
Thanks you so much for your answers!
Really hope that somebody will be able to help with this as I'm near losing my mind trying to understand why this happens.
I'm getting different results when scanning the same value in a Code 39 barcode using a regular USB barcode scanner and using my phone camera.
When scanning the value of 482168 using the barcode scanner, I get a value of 142673096 pasted into notepad;
When scanning the value of 482172 using the barcode scanner, I get a value of 142673122 pasted into notepad;
Values 482169 and 482171 are pasted correctly.
I thought initially that the problem was with the app that generates these barcodes, however, the same is happening when these are generated here https://barcode.tec-it.com/en/Code39FullASCII?data=482168
I thought that the length and width of the barcode may have been the problem, but adjusting them did not have any effect.
Has anyone ever stumbled upon anything similar and could suggest why these would be read and encoded differently?
I found this problem to be really interesting, so I compared the various barcode types to see what could be causing the scanner to mis-identify the barcodes. It turns out that Italian Pharmacode (also known as Code 32) is an exact match. Code32 is actually code39 using a compression scheme.
Here is 482168 in code39:
And 142673096 in code32:
It looks like your scanner is prioritizing code32 over code39. So you just need to disable code32 in your scanner.
I know this might be rather a simple issue to ask for and we can also set the barcode format to be scanned by Zxing, like this:
(1)intent.putExtra("SCAN_MODE", "QR_CODE_MODE"); //or any other format
if we do this:
(2)intent.putExtra("SCAN_MODE", "SCAN_MODE"); //for all modes`
While doing the #2 mentioned right above this line, the scanner sometimes seems to scan part of the barcode and picks up wrong information. For example if I try to simply scan a UPC barcode, 98% of the times it works beautifully, but sometimes it just returns me a wrong barcode. I think I know whats happening here, I have an idea up in my head, but what is the exact technical explanation for this? (Anyone familiar with barcodes can help) Thanks in advance guys.
SCAN_MODE is not a valid value. It is ignored and you are scanning for all formats.
It is not reading the wrong information from a barcode; it is finding a 'phantom' barcode among all those white and black lines, of another format. The usual culprit is UPC-E, which is the easiest to accidentally see.
This is why it is far better to restrict the scan to the format you are interested in with a correct value of SCAN_MODE.
Are there any good validation tools for Intel hex files. Im looking for something that will validate checksums, as well as being able to identify and extract things like start address records?
This one is tricky... Well in any case I'm sorry to say this but the best way to do it is to use a HEX editor and cross reference with things you know exists in the start or end address. So in other words the best way is to do it manually by hand.
UPDATE
I may have something that you would find interesting http://en.wikipedia.org/wiki/Intel_HEX. At the bottom of the page is exactly what I believe you are looking for but I stay by my standpoint that validating it by hand is still the best.
You can use the following .NET library: IntelHexFormatReader for this.
(Disclaimer: I wrote the library).
Validating a single line in the HEX file could look like this:
string hexRecordLine = ":100130003F0156702B5E712B722B732146013421C7";
IntelHexRecord record = HexFileLineParser.ParseLine(hexRecordLine);
Console.WriteLine(record.ByteCount);
Console.WriteLine(record.Address.ToString("X4"));
Console.WriteLine(record.RecordType.ToString());
Console.WriteLine(record.Bytes[5]);
Console.WriteLine(record.Bytes[9]);
Console.WriteLine(record.CheckSum);
Resulting in the following output:
16
0130
Data
94
43
199
The tools does exhaustive validation (check the unit tests in order to get an idea of what validations are in place) and also allows you to return a full "memory representation" for a full Intel Hex file.
Is there an easy way to manually (ie. not through code) find the size (in bytes, KB, etc) of a block of selected text? Currently I am taking the text, cutting/pasting into a new text document, saving it, then clicking "properties" to get an estimate of the size.
I am developing mainly in visual studio 2008 but I need any sort of simple way to manually do this.
Note: I understand this is not specifically a programming question but it's related to programming. I need this to compare a few functions and see which one is returning the smallest amount of text. I only need to do it a few times so figured writing a method for it would be overkill.
This question isn't meaningful as asked. Text can be encoded in different formats; ASCII, UTF-8, UTF-16, etc. The memory consumed by a block of text depends on which encoding you decide to use for it.
EDIT: To answer the question you've stated now (how do I determine which function is returning a "smaller" block of text) -- given a single encoding, the shorter text will almost always be smaller as well. Why can't you just compare the lengths?
In your comment you mention it's ASCII. In that case, it'll be one byte per character.
I don't see the difference between using the code written by the app you're pasting into, and using some other code. Being a python person myself, whenever I want to check length of some text I just do it in the interactive interpreter. Surely some equivalent solution more suited to your tastes would be appropriate?
ended up just cutting/pasting the text into MS Word and using the char count feature in there