I have a Directlogics PLC that I need to send label information to a Zebra GC420T printer.
I can only send ASCII characters. Is it possible to send a file of ASCII characters of a ZPL code and if so,
any tips would be appreciated.
Start by matching the serial communications between your PLC and the printer. Either change the settings on the PLC to match the printer or the printer settings to match the PLC.
Default Zebra settings should be: 9600 baud, 8 data bits, 1 stop bit, no parity, and XON/XOFF. PROTOCOL should be set to NONE.
Depending on the way your PLC serial port is pinned, you may need a null modem cable.
Try sending the following ZPL code from your PLC to the printer as a test:
^XA
^FO50,50
^B8N,100,Y,N
^FDTEST^FS
^XZ
Related
I created a label program using C# and the Zebra SDK. It works great except when a user desides that they printed the wrong labels and they power off the printer. When the printer comes back on, it goes through a quick calibration (I believe that's what it's doing) and then the light changes to a solid green. When they try to print again, one label prints correctly and then two blank labels "print" and the status light changes to a blinking red light. In order to get the printer back into a working condition, it needs to be recalibrated and I use the ZPL command ~JC.
We were using ZebraDesigner software to print labels and the printer never had issues with being powered off, back on and then printing as normal. I captured the data that is printed from that software and added the ZPL to my code but it doesn't help the printer recover when the printer is powered off. I don't know if the ZebraDesigner software is actually sending multiple sets of commands and I'm only capturing the last set or not.
It was suggested to me on another forum that the printer might still have some of the old ZPL data from the last print job and it would need to be cleared. The last thing I tried was adding the soft reset command ~JR to my code but it didn't help. I also tried to clear anything in the buffer using ~JA with no different results.
Here is is my original ZPL code and it does not include the ZPL that I captured from ZebraDesigner becuase it didn't help. I've gone through the ZPL guide multiple times and I'm just not having any luck figuring out what I'm missing that isn't allowing the printer to recover without being calibrated.
All words in {} are replaced by the actual values when imported into my program.
^XA
^PW330
^FO 0,65
^FB 350,1,0,C,0
^A0N 25, 25
^FD{COMPANYNAME}^FS
^FO 0,90
^FB 350,0,0,C,0
^A0N 28, 28
^FD {PRICE} {COLOR} ^FS
^FO 0,120
^FB 350,1,0,C,0
^A0N 25, 25
^FD {TYPE} ^FS
^FX FO 0,215
^BY2
^FT85, 215
^BCN,60,Y,N,N
^FD>9{BARCODE}^FS
^PQ{QTY}
^XZ
After more testing, I found the command. It's ^MNY
I found it by running through the file generated by Configure Printer Settings in Zebra Setup Utilities. I ran that ZPL with my ZPL and it fixed the issue. I then narrowed down the code until I found the command that allowed the printer to contiue to function after being turned off. I did see this command in the ZPL guide and thought I tried it but maybe I messed something up.
I have Openwrt router with Arduino connected via USB FTDI adapter.
Serial port is /dev/ttyUSB0
Arduino code prints some data:
First part of data printed with delay via command print(), for example:
Serial.begin(9600);
Serial.print(var1);
delay(1000);
Serial.print(var2);
delay(1000);
Serial.print(var3);
delay(1000);
And second part printed with println() command:
Serial.println("");
Serial.println(var4);
Serial.println(var5);
Serial.println(var6);
So when I open Serial port in terminal I can see something like this:
1
then timeout in 1 sec, then
1 2
next timeout. and then
1 2 3
last timeout and
1 2 3
4
5
6
It works in Terminal program and in console in OpenWRT, for example screen /dev/ttyUSB0
I need make a Lua script that will read Serial port and print the data in the same way. I have a simple script, but it doesn't work as expected.
rserial=io.open("/dev/ttyUSB0","r")
while true do
chain = nil
while chain==nil do
chain=rserial:read();
print(chain)
end
end
it shows all data at once.
it doesn't show first 3 vars one by one with delays.
Seems it is because of rserial:read() - it will read until it receives a newline character.
It stated in similar question:
How to read from a serial port in lua
I tried to run this command as was advised there:
stty -F /dev/ttyUSB0 -icanon
but it doesn't help and I don't understand why.
Is it the way to fix this behavior via stty?
or I definitely need to use another Serial libs for Lua script?
All of these libs seems pretty outdated for now and I don't want to use outdated stuff..
From the Lua Reference Manual:
When called without formats, it uses a default format that reads the
next line (see below).
A new line is anything in the buffer until the next newline character.
So as long as you don't send a newline character Lua will wait one as it has been told by calling read()
Once a newline character is received you will be prompted any other character in that line.
Terminal programs usually update every byte to show what they receive in "real-time".
So if you want to have the same behaviour you may not use read() without any arguments.
Use read(1) to read every single byte without waiting for anything else.
I need to read/write cards using a RFID Reader
more specifically this:
https://www.parallax.com/product/28440
I am not very clear about how to do this since it is my first time with hardware devices connected to the USB port.
I find out there is a TComPort library, I allready installed it on my Delphi Berlin 10.1
From the parallax documentation I found this:
Serial Communication (9600 baud default) Timeout is 100ms
Write to RFID card:
Send ASCII character 'w' to initiate write mode.
Device will respond with 0x01 and will expect 4 bytes of data in return which will be the information entered in
the 'Membership Year' Text box.
Device will respond with 0x02 and will expect 4 bytes of data in return which will be the information entered in
the 'Membership ID' Text box.
Read:
Send ASCII character 'r' to initiate read mode.
Device will send 4 bytes of data (send to Card ID text box) and wait for a 0x01 response.
Device will send a further 4 bytes of data (Membership Year), and wait for a 0x01 response.
Device will send a final 4 bytes of data (Membership ID Number)
The question here is, how can I perfom these actions to write/read using the TComPort component?
By using Windows' CreateFile call you're able to connect to a connected USB device directly. All you need is the full, correct 'port name', see the GetPortName method here
I was watching several wifi captures in wireshark and I bumped into two specimens I had never seen before. First of all, I thought that a IEEE 802.11 data frame would always be followed by a LLC header (802.2), provided that the frame actually contained data. Now I have a two wireshark captures showing otherwise !
First one, we can see an Ethernet II header following the wifi header :
Now that's the first thing I don't understand. How is an interface supposed to know, when reading the 802.11 Data header, that it is going to be an Ethernet II following ? There is no field in the 802.11 header specifying what's coming next.
Second is "raw data" directly following the wifi header.
Same question as before, how are we supposed to know that Data was following, and not LLC ?
First question:
To quote a comment in the Wireshark 802.11 dissector:
/* I guess some bridges take Netware Ethernet_802_3 frames,
which are 802.3 frames (with a length field rather than
a type field, but with no 802.2 header in the payload),
and just stick the payload into an 802.11 frame. I've seen
captures that show frames of that sort.
There is no field in the header that says "this is a bridged Netware Ethernet_802_3 frame", so Wireshark has to use a heuristic. The heuristic is "if the first two bytes of the payload are not both 0xAA, the first 6 bytes of the payload equal the destination MAC address, and the next 6 bytes of the payload equal the source MAC address, then this is a bridged Netware Ethernet_802_3 frame", in which case it calls the Ethernet dissector. Because this is a heuristic, it is, of course, not guaranteed to get the correct answer all the time.
IEEE Std 802.11-2012 says, in section 5.1.4 "MSDU format":
This standard is part of the IEEE 802 family of LAN standards, and as such all MSDUs are LLC PDUs as defined in ISO/IEC 8802-2: 1998. In order to achieve interoperability, implementers are recommended to apply the procedures described in ISO/IEC Technical Report 11802-5:1997(E) (previously known as IEEE Std 802.1H-1997 [B21]), along with a selective translation table (STT) that handles a few specific network protocols, with specific attention to the operations required when passing MSDUs to or from LANs or operating system components that use the Ethernet frame format. Note that such translations may be required in a STA.
"ISO/IEC 8802-2: 1998" is also ANSI/IEEE Std 802.2, 1998 Edition, so that says that the payload should begin with an 802.2 header. At least as I read IEEE Std 802.1H-1997, Ethernet frames without an 802.2 header should be translated to SNAP frames, using their Ethernet type value, when bridged to a LAN using 802.2, such as an 802.11 LAN. I guess, since Netware Ethernet_802_3 frames don't have a valid 802.2 LLC header and don't have a type field (they have a length field; I think that, as they don't have an 802.2 header following the Ethernet header, this means that they technically aren't valid Ethernet frames), they aren't covered by the specifications in question, so it's not technically a protocol error to just put the Ethernet packet, starting with the Ethernet header, into the data field. Presumably those packets are sent only to bridges, under the assumption that the bridge knows how to Do The Right Thing.
Second question:
The most common reason to see "Data" after an 802.11 header is that the packet in question is encrypted (WEP or WPA/WPA2) and Wireshark doesn't have the password for the network (and, for WPA/WPA2 Personal/Pre-shared key mode, doesn't have the initial EAPOL handshake in the capture; decrypting in Enterprise/802.1X mode is not supported).
Are you capturing on a "protected" (WEP or WPA/WPA2) network?
I'm developing an IOS app that reads Arduino serial output via redpark cable.
In the Arduino side, it uses Serial.println() to send out strings.
The string is in the format of "12.34x334.45x0.34x123x33". Essentially it's a combination of doubles with "x" in between as a special split character.
My initial thought was that in the app side, it would get the Arduino output line by line so I would just use
NSString *testString= #"12.34x334.45x0.34x123x33";
NSArray *array = [testString componentsSeparatedByString:#"x"];
to get a NSArray contains 12.34 334.45 0.34 123 and 33.
Somehow after reading questions and answers posted here, I figured out there is no way for redpark sdk to treat the Arduino output line by line, it's always in a X bytes basis.
In order to parse the Arduino output string correctly, what should i do? Would it be a good idea to add leading and tailing 0 to my double data to make the original string to be sent in a fixed length?
(i.e. "03.45x45.50x02.30" to make it 17 bytes and try to read 17 bytes of data using redpark sdk?)
The Redpark SDK only grabs the incoming serial data stream, but doesn't (despite having a few helper routines) interpret it as packets. You'll need to code that yourself. As suggested by agentatlarge in the comments to your question, read the data into a buffer using readBytesAvailable:numBytes until you get a new line character (ASCII 13), at which point you have your string to parse and can start over.
Alternatively, skip the initial string: read the incoming data until you get an "x" (at which time you add a string to an NSMutableArray) or a new line character (at which point you process the array and start a new one.
Be aware that, using the default settings (configurable in redparkSerial.h) data will be fed to you in chunks limited to 100ms (rxForwardingTimeout) or 16 bytes (rxForwardCount), whichever comes sooner. So your system will need to be able to handle multiple reads until it is certain that it has received all the data in a packet (printed line), evidenced by the arrival of the new line character.