I´m currently working with the ZT610 from Zebra. My goal is to read the rfid-tag embedded and then print the number on the tag in form of an QR-Code.
So I need that first part of the ZPL-Code the read-tag to my program (already working),
the second and third part is just some fix data, which will be filled before print,
and the last section should include the QR-Code with the Tag-Number (or if not possible the whole EPC).
^XA
^FX first section Getting TAG
^RFR,H^FN1^HV1^FS
^FX Second section: Label/Header
^CF0,60
^FO,50^FDLFS-Nr.: ...^FS
^FX Third section: Additional information
^CFA,30
^FO50,150^FDAnkunftsdatum: ...^FS
^FO50,190^FDKFZ-Kennzeichen: ...^FS
^FO50,230^FDFraechter: ...^FS
^FO50,270^FDLieferant: ...^FS
^FO50,310^FDSublieferant: ...^FS
^FO50,350^FDSortiment: ...^FS
^FO50,390^FDAbgangsort: ...^FS
^FO50,430^FDSchaetzmenge: ...^FS
^FX Forth section: QR-Code and separator
^FO5,490^GB800,3,3^FS
^FO250,740,^BQN,2,10^FDQA,{HERE FOR THE QR CODE THE TAG-NUMBER IS NEEDED}^FS
^XZ
Does anyone know how to achieve this? I can´t find a satisfactory solution..
Thank you!
Related
I'm trying to print some RFID tags and retrieve their TIDs to store them in my system and know which tags have been printed. Right now I'm reading the TID and sending it back to my computer (connected via USB with the my ZT421 printer) with the following code:
^RFR,H,0,12,2^FN0^FS^FH_^HV0,24,,_0D_0A,L^FS
^RFW,H,2,12,1^FD17171999ABABABAAAAAAAAAB^FS
This is repeated for each tag that I'm printing. However, when printing 10 tags, I only get 9 TIDs. If after that I try to print 7 tags, I still get 9 TIDs. To be honest I'm a bit lost now, because even trying to use the code examples from the ZPL manual (I've tried the ^RI instruction also) it doesn't seem to work.
The communication with the printer is beeing done through Zebra Setup Utilities' direct communication tool.
I tried to retrieve each printed tag TID with:
^RFR,H,0,12,2^FN0^FS^FH_^HV0,24,,_0D_0A,L^FS
^RFW,H,2,12,1^FD17171999ABABABAAAAAAAAAB^FS
but I always get 9 TIDs.
I also tried getting the TID with the ZPL manual example for the ^RI command:
^XA
^FO20,120^A0N,60^FN0^FS
^RI0,,5^FS
^HV0,,Tag ID:^FS
^XZ
And I got absolutely nothing returned to the computer, just a mssage saying "Tag ID:" and no value shown.
I would really appreciate some help with this...
Thanks in advance!
I've fixed the issue, but I'm going to leave the solution here just in case someone else is facing the same problem.
I thought that maybe it wasn't a code issue, but something related to the computer-printer communication. It turned out to be the case. The Zebra Setup Utilities program has a button that says "options". If you click it, a new screen will open and there you can configure the seconds that the program will wait for the printer response (in this case through USB). By default it's set to 5, i changed this value to 100, which is the maximum. This meant that instead of just printing and retrieving the TIDs of 6-9 tags, now I can do it for about 100.
This is not amazing because in my case it implied creating 25 files for the 2500 tags I had to print and store the TIDs, however it's far better than before.
I have a string that is 928 characters that I am using to create a qr code for. The issue I am having is that, although the QR code scans fine on Iphone, android devices seem to struggle detect it. I believe this is due to the size of the QR code. I wanted to know if there was a way I could truncate that 928 character string to under 50 characters and then expand it when I use it after scanning the QR Code. Upon researching, I found many QR question and a lot of questions on how to shorten text, but nothing specifically relating to my question.
The QR HTML is:
<qrcode
[qrdata]="qrUrl"
[allowEmptyString]="true"
[attr.ariaLabel]="'QR Code image with the following content...'"
[cssClass]="'center'"
[colorDark]="'#000000ff'"
[colorLight]="'#ffffffff'"
[elementType]="'canvas'"
[errorCorrectionLevel]="'M'"
[attr.imageSrc]="currentUser.imageData ? currentUser.imageData : './assets/default-logo.png'"
[attr.imageHeight]="75"
[attr.imageWidth]="75"
[margin]="4"
[scale]="1"
[title]="'A custom title attribute'"
[width]="300"
></qrcode>
Changing the error correction to L fixed the issue.
I am trying to extract libraries from the Dyld_shared_cache, and need to fix in external references.
For example, the pointers in the __DATA.__objc_selrefs section usually point to data outside the mach-o file, to fix that I would have to copy the corresponding c-string from the dyld and append it to the __TEXT.__objc_methname section.
Though from my understanding of the Mach-O file format, this extension of the __TEXT.__objc_methname would shift all the sections after it and would force me to fix all the offsets and pointers that reference them. Is there a way to add data to a section without breaking a lot of things?
Thanks!
Thanks to #Kamil.S for the idea about adding a new load command and section.
One way to achieve adding more data to a section is to create a duplicate segment and section and insert it before the __LINKEDIT segment.
Slide the __LINKEDIT segment so we have space to add the new section.
define the slide amount, this must be page-aligned, so I choose 0x4000.
add the slide amount to the relevant load commands, this includes but is not limited to:
__LINKEDIT segment (duh)
dyld_info_command
symtab_command
dysymtab_command
linkedit_data_commands
physically move the __LINKEDIT in the file.
duplicate the section and change the following1
size, should be the length of your new data.
addr, should be in the free space.
offset, should be in the free space.
duplicate the segment and change the following1
fileoff, should be the start of the free space.
vmaddr, should be the start of the free space.
filesize, anything as long as it is bigger than your data.
vmsize, must be identical to filesize.
nsects, change to reflect how many sections your adding.
cmdsize, change to reflect the size of the segment command and its section commands.
insert the duplicated segment and sections before the __LINKEDIT segment
update the mach_header
ncmds
sizeofcmds
physically write the extra data in the file.
you can optionally change the segname and sectname fields, though it isn't necessary. thanks Kamil.S!
UPDATE
After clarifing with OP that extension of __TEXT.__objc_methname would happen during Mach-O post processing of an existing executable I had a fresh look on the problem.
Another take would be to create a new load command LC_SEGMENT_64 with a new __TEXT_EXEC.__objc_methname segment / section entry (normally __TEXT_EXEC is used for some kernel stuff but essentially it's the same thing as __TEXT). Here's a quick POC to ilustrate the concept:
#import <Foundation/Foundation.h>
int main(int argc, const char * argv[]) {
#autoreleasepool {
printf("%lx",[NSObject new]);
}
return 0;
}
Compile like this:
gcc main.m -c -o main.o
ld main.o -rename_section __TEXT __objc_methname __TEXT_EXEC __objc_methname -lobjc -lc
Interestingly only ld up to High Sierra 10.14.6 generates __TEXT.__objc_methname, no trace of it on Catalina, it's done differently.
UPDATE2.
Playing around with it, I noticed execution rights for __TEXT segment (and __TEXT_EXEC for that matter) are not required for __objc_methname to work.
Even better specific segment & section names are not required:
I could pull off:
__DATA.__objc_methname
__DATA_CONST.__objc_methname
__ARBITRARY.__arbitrary
or in my case last __DATA section
__DATA.__objc_classrefs where the original the data got concatenated by the selector name.
It's all fine as long as a proper null terminated C-string with the selector name is there. If I intentionally break the "new\0" in hex editor or MachOView I'll get
"+[NSObject ne]: unrecognized selector sent to instance ..."
upon launching my POC executable so the value is used for sure.
So to sum __TEXT.__objc_methname section itself is likely some debugger hint made by the linker. The app runtime seems to only need selector names as char* anywhere in memory.
I am attempting to encode the EPC of a GS1 RFID using ZPL statements on a Zebra 410R printer.
First, consider the following ZPL :
^FD51,0,6,111111,2,33,444^FS
What I am attempting to do, is replace the 444 with a value stored in a field number (^FN).
^XA
^DFE:RFID^FS
^RB96,8,3,3,20,24,10,28
^RFW,E
^FD51,0,6,111111,2,33,^FN11"Enter Barcode"^FS
^XZ
So, How do I replace the '444' portion of the field data with the value stored in the field number (^FN11) ?
Thank you in advance.
Well, maybe a little bit too late, but to anyone, who may have the same question - DF is a pair command, you need to pair it with XF. DF is Download format - here you use the varible ( FD, FN). XF is Recall Format - here you declare the variables.
So, your code just miss the definition of variable, here is the whole code:
Your code:
^XA
^DFR:RFID^FS
^RB96,8,3,3,20,24,10,28
^RFW,E
^FD51,0,6,111111,2,33,^FN11"Enter Barcode"^FS
^XZ
^XA
^XFR:RFID
^FN11^FN444^FS
^XZ
dig -v
DiG 9.9.4-RedHat-9.9.4-18.el7_1.1
That's the version of dig. When I use it to query DS information, it inserts a space into the digest result for type 2 digests:
dig DS domblogger.net. +short
2085 7 2 E3E1BEF53CF187DFA6B0AE1C5CE93AF9D597A64C97317A9A1E45C6A6 03E10D32
2085 7 1 3F3FBE538DA52E982299D7E7BA13A35400536C11
You can see the space before the 03E10D32 for the type 2 digest, probably because of its length.
I've looked at the man page and googled around, I can't seem to find what option to pass to dig to get it to not insert that space. It also does it with a few other record types as well related to DNSSEC.
I can fix it post query in my script but it sure would be nice if I could just pass it an option where I don't have to. Any help would be appreciated.
The behavior you observed was not how it was intended to work, and has now been corrected.
The change will be in future releases of BIND 9.9, 9.10, and (when released) BIND 9.11 but if you want it now you can retrieve a diff from the ISC public git repository.
This is change you want:
4101. [bug] dig: the +split option didn't work with +short.
[RT #39291]
and I believe this link will take you directly to the diff in the ISC gitweb viewer.
Whitespace in the digest hex string in DS presentation format is explicitly allowed (see RFC 4034 section 5.3), so your code pretty much have to be able to deal with it.