Hello,
At the top of this image where you see .. I SGD.GET device.host_status. Where you see sensor.p:.. is me requesting sensor.peeler.. the odometer:.. is me requesting odometer.total_label_count. Each time the printer prints.. I get this device.host_status bleeding into my other responses.
I've also limited my code to only issuing the SGD.GET("odometer.total_label_count", Conn); ,but I'm getting the value of device.host_status even though it was never called. The image below is me trying to determine where that unexpected data was coming from (030,0,0,0112,000,0,0,0...). If you look near the bottom you will see after the label prints I begin to get the expected results.
I believe SGD just wraps ZPL or similar commands and fetches the odometer.total_label_count from ZPL ~HQ. In doing so it is not always parsing the value to return for odometer.total_label_count correctly.
I'm using LinkOS SDK and developing in Visual Studio C# .NET
5 Replies
Robin,
Yeah I don't have the Zebra Status Monitor either. I'll explain what I'm trying to do so maybe that would be easier. We are printing barcode labels and the user needs to specify the quantity between cycles. Lets say they print 2 barcodes. We have a peeler attachment so we want to print and wait until the user peels it so we check sensor.peeler until we get a 'clear' status. Then the next label will feed. They click the print button and repeat this cycle. It's a simple process, but what's causing me headaches is that when I send a Print to draw the barcode I can not seem to capture an event that the print has ended. If I use Windows EndPrint event it triggers immediately. So I changed my approach and monitored the jobs on the device, but it always returns 0. Every setting I think to monitor or event I try to catch leaves me empty handed. This is why I had went the route of monitoring the odometer and making sure the label qty had printed before I began looking at the sensor.peeler to see if it was clear. I believe even if I write a loop that after Print() is called to monitor the odometer and peeler that it will still give me this unexpected response containing the device.host_status. I will confirm this unless you have another solution.
It seems that as soon as I send the Print() call it spools and I'm not able to find anywhere to catch an event that its complete. Is there a way to trigger an event from the device when its done printing that label. Or a way you would suggest for me to monitor.. If I monitor the sensor.peeler itself there is room for error and the app can get stuck in a unexpected flow. So I really need to know that a label has printed before I start reading from the sensor.
Thank you very much for your time
HI Kenny,
If you look at the code I sent, we do tend to recommend the status checking loop after sending the print job, but on the same thread. It will start checking while the print job is working. You can use the odometer to do this. You can also use the "printerStatus.numberOfFormatsInReceiveBuffer" by checking the count on this status to see when each print out is complete.
The device.host_status is what get's called by the ZebraPrinter.GetCurrentStatus(); function in the SDK. If you are using that as well, it might be why you are getting this response on different threads. When GetCurrentStatus() receives bad or garbled data, it throws a "malformed status response" .
There is also the ZebraNet Alerts system. The "PQ JOB COMPLETED" and "LABEL READY" are alerts you may want to look into. I can't guarantee they they won't get garbled with the other USB communications though.
I hope this is helpful,
Robin
The above image was produced with the following call: LinkOsPrinter.GetSettingValue("sensor.peeler");
I believe I have limited this to firmware as before I uploaded the firmware I was not getting this problem. Unfortunately I'm not able to find a firmware archive so that I can get our printers back into production until we get a proper answer on where the bug lies in LinkOS