I am trying to printing TID FROM ZPL COMMANDS
getting JJL179464
can anyone please tell me
what is this character
To partially answer your question:
Are you reading an ASCII encoded data? Because your result: "JJL179464" does not look like a valid RFID tag data, unless it is in ASCII. Data encoded in RFID tags are encoded in binary. Depending on reader settings, the data can be outputed in binary, hexadecimal or ASCII format. Judging by the first three symbols "JJL", your reader is set to output ASCII data, or there is an error in your code.
Try to answer us the following questions:
What are you trying to achieve?
Provide us your code. (whole, structured)
What device are you using to read the RFID tag?
Provide us the settings of your reading device. (unless they are a part of the code)
Do you know the data content of the RFID tag you are trying to read? That means, can you validate that the reading was successful?
Edit:
Thank you for your code:
^XA
^FN1^RFR,H,0,12,2^FS^FH_^HV1,256^FS
^XZ
It seems that there could be several issues in your code.
Firstly, your ^HV command is incomplete. It is missing 3 parameters. The first one (third parameter) sets the data prefix. Next one data termination. And the last one specifies when to return data. You should include all of them in the ^HV command.
There is already a good example how the ^HV command needs to be set:
^RFR,^FN1,^HV1 not sending output to computer
The second issue, at least I think that it is an issue but I don't have the means to verify it, is that you are using ^FH_ command. There are no hexadecimal values for encoding special characters in your code, so there is no point in using it. So I would try to omit it.
Also, I am not sure about the order of commands. The ^FN1 command should be after ^RFR and before ^FS commands.
Try this code:
^XA
^RFR,H,0,12,2^FN1^FS^HV1,256,HEADER,TERMINATION,L^FS
^XZ
That should give you output in format:
HEADERhexadecimaldataTERMINATION
It is a little bit hard to read, but if it will work, then you might proceed to format it nicely.
The words HEADER and TERMINATION serve as prefix and postfix of data from ^RFR command. So if this will work you can replace them with brackets or whatever suits your needs.
I am also concerned about 2 things:
The number of bytes to read - 12. Usually it is 8, but it varies depending on the type of RFID tag and the data format. I don't say that it is a mistake, just unsual to me.
The last parameter in ^HV1 command may be "F" instead of "L". The "F" is default value and it seems that in your case it was working with it. At least you got some output, so maybe it should be "F". But try it with "L" to get a response for each label. "F" means getting a response after the entire job is done.
I hope this will work. Currently we are in lockdown and I don't have the means to verify this on real devices. But theoreticaly it should help.
Please let me know the results.
Related
I am using BarTender to design a set of labels to print to ZPL printers. One of my requirements is for a Royal Mail Mailmark label which uses the CMDM Barcode.
We output to file using alias values in the label fields.
We then run an application which swaps out the alias values and replaces them with the database values we actually want to print.
The issue is when I open label designs previously used to create the template files, the output (which previously was in simple text form) has now been outputted into a DGR....GRF format. (Please see below)
Unfortunately the CMDM barcode on BarTender is designed so that I can't just use an alias. That is my understanding anyway.
^FT407,1137
^A0B,28,34^FD*ship_to_zip^FS
^FT659,1148
^A0B,25,31^FDOur Reference ^FS
^FT564,1148
^A0B,25,28^FDCustomer Reference^FS
^FT595,1148
^A0B,25,28^FD*po_nbr^FS
^FT697,1148
^A0B,25,28^FD*distro_nbr^FS
^FO553,300
^BY2^BCB,124,N,N^FD>:*carton_nbr^FS
^FO28,72
^XGR:SSGFX000.GRF,1,1^FS
^ISR:SS_TEMP.GRF,N^XZ
~DGR:SSGFX001.GRF,1352,13,:Z64:eJydk9ERBCEMQtMB/XdJBxzE3D93ruP6nDHBoMDvjYBEDoZqYeSF8TiCSqC7vD2IEvK5Z3cNTkRqZ2phnM4zKyZbSIic0YprcIAMLrpqUHQSV8UOUo/dij1dBTGXCaT1oAIrdEp6Kbeig/jlCCZNC7H3Sk6U4ADMEV3+TdrAXoxLjRL4HoUjjFqIOM+2/i2k7PEY++/A+fTd2cKz+ElVCTN7XVdqC/b1pK4FFeRlnNT3agv4p30AH1GDtw==:D4A2
^XA
^ILR:SS_TEMP.GRF^FS
^FO242,308
^XGR:SSGFX001.GRF,1,1^FS
^PQ1,0,1,Y
^XZ
Has anyone come across this problem or know of a ZPL command I can use for this type of Barcode?
The main issue is Royal Mail want the Latch to C40 at the beginning of the barcode. When I print a standard 2D DataMatrix barcode, this latch to C40 code appears in the middle of the code.
Just need to know if I can move it to the beginning of the code.
Thanks
The ZPL datamatrix command does not support manually encoding the code words, which is what you need to force a latch to C40. But you can use BarTender to get around this. (I am not associated with Seagull Scientific, but my clients often use it.)
Instead of programmatically modifying the BT format file directly, you should be generating a data file that provides the field data for the label. BarTender calls this "data file integration".
See this video for more information: https://support.seagullscientific.com/hc/en-us/articles/227353867-Print-Document-Using-a-Data-File-Integration-Video-6-31-
The question mark "?" appears only in the front of the first field of the first row to insert.
For once, I changed the ftp upload file type to text/ascii (rather than binary) and it seemed resolve the problem. But later it came back.
The server OS is aix5.3.
DataStage is 7.5x2.
Oracle is 11g.
I used ue to save the file to utf-8, using unix end mark.
Has anyone got this thing before?
The question mark itself doesn't mean much as it could be only a "mask" for some special character which is not recognized by the database. You didn't provide any details about your environment, so my opinions here are only a guess. I hope it can give you a little of a light.
How is the text file created? If it's a file created in a windows environment you're very likely to have character like this due brake lines {CR}{LF} characters.
What is the datatype for the oracle table?
Char datatype will "fill" every position according to the size of the field, I'd recommend to use varchar instead on this case.
If it's not the case, I would edit the file in Hex mode and check for the Ascii code for this specific character then use a TRIM (if parallel) or Convert(if server) to replace the character.
The convert function would be something like this:
Convert(Char([ascii_char_number]),'',[your_string])
Alternatively you can use the Trim function if your job is a parallel job
Trim([your_string],[ascii_char_number],'L')
The option "L" will remove all leading characters. You might need to adapt this function to suit your needs. If you're not familiar with the TRIM function you can find more details at the datastage online documentation.
The only warning I'd give when doing this, is that you'll be deleting data from your original source of data, so make sure you're not deleting any valid information when manipulating a file like this as this is not a very recommended practice between the ETL gurus out there.
Any questions, give me a shout. Happy to help if I can.
Cheers
I had a similar issue where unprintable characters were being displayed as '?' and datastage was throwing a warning when processing these records. It was ok for me to not display those unprintable characters, so I used the function ICONV which converts those characters into printable ones. There are multiple options, I chose the one which will convert them to '.' which worked for me. More details are available in the IBM pages below:
https://www-01.ibm.com/support/knowledgecenter/SSZJPZ_11.3.0/com.ibm.swg.im.iis.ds.parjob.dev.doc/topics/r_deeref_String_Functions.html
http://docs.intersystems.com/ens201317/csp/docbook/DocBook.UI.Page.cls?KEY=RVBS_foconv
The conversion I used:
ICONV(column_name,"MCP")
I would like to use a qr code to transmit yaml.
Is there anyway to keep the text formatted when a scanner reads the code?
Where can I read about implementing a custom format for a qr code?
Just include line breaks, tabs and spaces in the text payload, if that's what you mean. You can't force a reader to honor all that when displaying the payload. But you can include it all the same.
You will need to URL Encode the text before you encode it as a QR code.
Just as the space symbol is encoded as %20 linebreaks are commonly encoded as %0A
See http://en.wikipedia.org/wiki/Percent-encoding for details.
Generally speaking the JavaScript function escape() is good enough for this, although you may want to look at encodeURI() or encodeURIComponent() depending on your needs - see http://www.javascripter.net/faq/escape.htm for a good discussion on the differences.
Objective : To have multi language characters in the user id in Enovia v6
I am using utf-8 encoding in tcl script and it seems it saves multi language characters properly in the database (after some conversion). But, in ui i literally see the saved information from the database.
While doing the same excercise throuhg Power Web, saved data somehow gets converted back into proper multi language character and displays properly.
Am i missing something while taking tcl approach?
Pasting one example to help understand better.
Original Name: Kátai-Pál
Name saved in database as: Kátai-Pál
In UI I see name as: Kátai-Pál
In Tcl I use below syntax
set encoded [encoding convertto utf-8 Kátai-Pál];
Now user name becomes: Kátai-Pál
In UI I see name as “Kátai-Pál”
The trick is to think in terms of characters, not bytes. They're different things. Encodings are ways of representing characters as byte sequences (internally, Tcl's really quite complicated, but you shouldn't ever have to care about that if you're not developing Tcl's implementation itself; suffice to say it's Unicode). Thus, when you use:
encoding convertto utf-8 "Kátai-Pál"
You're taking a sequence of characters and asking for the sequence of bytes (one per result character) that is the encoding of those characters in the given encoding (UTF-8).
What you need to do is to get the database integration layer to understand what encoding the database is using so it can convert back into characters for you (you can only ever communicate using bytes; everything else is just a simplification). There are two ways that can happen: either the information is correctly shared (via metadata or defined convention), or both sides make assumptions which come unstuck occasionally. It sounds like the latter is what's happening, alas.
If you can't handle it any other way, you can take the bytes produced out of the database layer and convert into characters:
encoding convertfrom $theEncoding $theBytes
Working out what $theEncoding should be is in general very tricky, but it sounds like it's utf-8 for you. Once you've got characters, Tcl/Tk will be able to display them correctly; it knows how to transfer them correctly into the guts of the platform's GUI. (And in scripts that you actually write, you're best off replacing non-ASCII characters with their \uXXXX escapes, because platforms don't agree on what encoding is right to use for scripts. Alas.)
In ruby how to check a string is an actural string or a blob data such as image, from the data type of view they are ruby string, but really their contents are very different since one is literal string, the other is blob data such as image.
Could anyone provide some clue for me? Thank you in advance.
Bytes are bytes. There is no way to declare that something isn't file data. It'd be fairly easy to construct a valid file in many formats consisting only of printable ASCII. Especially when dealing with Unicode, you're in very murky territory. If possible, I'd suggest modifying the method so that it takes two parameters... use one for passing text and the other for binary data.
One thing you might do is look at the length of the string. Most image formats are at least 500-600 bytes even for a tiny image, and while this is by no means an accurate test, if you get passed, say, a 20k string, it's probably an image. If it were text, it would be quite a bit (Like a quarter of a typical novel, or thereabouts)
Files like images or sound files have defined blocks that can be "sniffed". Wotsit.org has a lot of info about the key bytes and ways to determine what the files are. By looking at those byte offsets in your data you could figure it out.
Another way way is to use some "magic", which is code to sniff key-bytes or byte-types in a file to try to figure out what its type is. *nix systems have it built in via the file command. Do a man file or man magic for more info or check Wikipedia's article on Magic numbers in files.
Ruby Filemagic uses the same technique but is based on GNU's libmagic.
What would constitute a string? Are you expecting simple ASCII? UTF-8? Or text encoded some other way?
If you know you're going to get ASCII text or a blob then you can just spin through the first n bytes and see if anything has the eight bit set, that would tell you that you have binary. OTOH, not finding anything wouldn't guarantee that you had text.
If you're going to get UTF-8 Unicode then you'd do the same thing but look for invalid UTF-8 sequences. Of course, the same caveats apply.
You could scan the first n bytes for anything between 0x00 and 0x20. If you find any bytes that low then you probably have a binary blob of some sort. But maybe not.
As Tyler Eaves said: bytes are bytes. You're starting with a bunch of bytes and trying to find an interpretation of them that makes sense.
Your best bet is to make the caller supply the expected interpretation or take Greg's advice and use a magic number library.