We are finding that setting the printer response time and initial timeout
is causing operations to be very slow. With the below code -
thePrinterConn.SendAndWaitForResponse(Encoding.UTF8.GetBytes(zplData),
960,650, "null")
^XA
^RFW,H^FD30361F8A7803428000000001^FS^FN1
^RFR,H^FS^HV1^FS
^XZ
We need to ensure that we first encode each tag & then read the data on
each tag, but with the send and wait for response command, and the values
960 and 650 - the process is very slow. However when we decrease the
values, then the printer ends up skipping tags & we do not have control on
the tags.
We are using the UsbConnection Class - not the driver printer class.
Can you advise us how to optimize the SendAndWaitForResponse(Byte[], Int32, Int32, String) method?
Or an alternative and faster way to send commands and get a response from the printer?
following is code for ref:
Connection myConnection = new Zebra.Sdk.Comm.DriverPrinterConnection("ZDesigner R110Xi4 300 dpi");
for (int i = 1; i
Can you advise us how to optimize the SendAndWaitForResponse(Byte[], Int32, Int32, String) method?// Expert user has replied. |
1 Replies
There are a few things to keep in mind. First of all, the RFID tag read/write plus label printing is generally slower than a regular ZPL label printing. Secondly, the USB connection generally is slower than TCP connection. The sum of the two timeouts in SendAndWaitForResponse() API will be the max time to wait before the API returns. If we can shorten either one of them, we will shorten the total time to wait. One thing noticed in your post is that "null" is passed to the API call for the string terminator parameter. If we know the response string from the printer is ended with a specific string, we can pass that specific string as the terminator to the SendAndWaitForResponse() API call, so that the API call will return immediately after receiving that specific string. If we don't know the specific ending string, we can always use "\r" as the terminator because all response string will have it at the end. This way we can shorten the second timeout.
Another way to improve this is to use myConnection.write() and myConnection.read() directly, which bypasses the inherent delays and timeouts in SendAndWaitForResponse() API. Hope this helps.