iOS 11 Bluetooth Disconnection Issue with Zebra Printers

would it be possible to provide a sample application that shows this fix?  Is a sample containing this fix already within the SDK sample?  If so, which project/module?  A code snippet would be helpful; even though it might seems straight forward.

thanks,

Hi Steven,

I also tried to implement your solution. However, when I set the print mode to CPCL line_print, the "status = [printer getCurrentStatus:&error];" returns nil, which means I can't test if the print is complete before closing the connection, and that the loop you gave would run forever. I tried to change the print mode to ZPL, and got a return value all right. The content printed out, even though the formatting kind of lost. Could you please tell me why the status returned is 'nil' when I use CPCL line_print mode, and what can I do to fix it, so that I can check the status before I close the Bluetooth connection?
Thank you!

Steven, thank you for the example.  I'm trying to deal with a similar problem myself, but I wanted to be sure I understood how the error arose in the above example.

In your performConnectionDemo method, you open the connection, then perform the 100 labels loop, and finally close the connection.  Specifically, you are not closing the connection during the loop at all, yet you say that the departure event would happen before the end of the loop.  Since you are implying that the trouble starts when the connection is closed before all the data is flushed, I would have to conclude that your test actually consists of running the performConnectionDemo method multiple times, and that when the error occurred during the loop, it was actually due to a premature closing on the previous call to performConnectionDemo.  Am I understanding this correctly?

Also, would I be right in assuming that the 1 second sleep in the status checking loop is not necessary for the solution, but that the important thing is to not close the connection until the printer reports 0 for numberOfFormatsInReceiveBuffer?

In our test app, what we are doing is opening a connection which we never close.  Nevertheless, on iOS 11, after some random number of minutes, we will get a disconnection event, after which we can no longer see the printer unless we "forget" and "reconnect" with it in the iPad Settings/Bluetooth screen.  So since we get the disconnect event eventually, even though we don't close our connection (and therefore presumably don't prematurely lose buffered data), it makes me think there's some other cause involved.

Thoughts?

Thank you for your response.  You indicated that iOS 11 made some Bluetooth timing changes.  Based on that, do you recommend any changes to the Zebra SDK default values of the 3 setTimeToWait* parameters when running on iOS 11?

Steven, thank you for your very helpful comments. In answer to your question, I have two similar test apps, one which uses the latest Zebra SDK, and one which uses only the Apple frameworks. They both exhibit the same problem of disconnecting after a random number of minutes, even though the app never closes the connection at all unless it gets a disconnection. It typically happens after about 15-25 minutes. This wouldn’t be a big deal if we could simply reconnect to the device, but just as in the case of the app prematurely closing the connection, we can no longer reconnect without going through the manual “forget” & reconnect steps. I’d be happy to send you the sources for the test app if you’d like to investigate further.

Hi Michael,

In the above example, the departure event happened before all 100 labels being printed out by the printer. Timing wise, the departure event happened after the completion of loop for 100 labels and when the [connection close] got executed. That's why we recommend to add a block of code to check the printerStatus before closing. We only need to run  performConnectionDemo method once to reproduce the problem in the above example. Sorry for the confusion. I should have made it clear in the description.

The purpose of the delay in the loop of printer status check is to avoid hogging the CPU time. What happens with [printer getCurrentStatus:&error] is that it may return nil if the data channel is busy in transmitting label data. So I threw in 1 second delay here for illustration. The delay can be any other values. Indeed, the important purpose to get the printer status and make sure there is no pending print job, i.e. numberOfFormatsInReceiveBuffer is zero.

In our test app, what we are doing is opening a connection which we never close.  Nevertheless, on iOS 11, after some random number of minutes, we will get a disconnection event, after which we can no longer see the printer unless we "forget" and "reconnect" with it in the iPad Settings/Bluetooth screen.  So since we get the disconnect event eventually, even though we don't close our connection (and therefore presumably don't prematurely lose buffered data), it makes me think there's some other cause involved.
In your case, do you use the API from Zebra SDK for your application? If we use the API from SDK, we should not see the above issue. If you use the API of Zebra SDK, there are other parameters in Bluetooth connection can be adjusted to adapt to different Bluetooth radio performance requirements.
- (void) setTimeToWaitAfterReadInMilliseconds:(NSInteger) aTimeInMs
- (void) setTimeToWaitAfterWriteInMilliseconds:(NSInteger) <em>aTimeInMs</em>
- (void) setTimeToWaitBeforeCloseInMilliseconds:(NSInteger) aTimeInMs
If you use your own mechanism to communicate the iOS Bluetooth module, then you can add some debug log in your open and close methods. So you can gauge the timing when the departure event happens. Hope that helps on debugging.

Hi Michael,
The 3 setTimeToWait* API are designed for applications to adjust the wait time for read, write and close operations on a connection to achieve a desired performance level. These wait times are not affected directly by the timing changes at the OS level in iOS 11. The current defaults of the wait times are 10ms, 60ms and 5,000ms for read, write and close operations respectively. Shorter wait time results in greater throughput or better performance.

For printing a batch of labels, let's take the above example of 100 labels, the shorter wait time after each write operation would mean the data of 100 labels would be transmitted quicker to the printer and the printer would print out the labels quicker with less delay between the labels. This gets interesting. If we could set the wait time of close operation long enough to get through all the data of 100 labels being actually printed at the printer side, then the departure event may not happen. Then the question is how long of the wait time is long enough? If each label has different amount of data (depending on the content of labels, such as ZPL, graphics, etc), then the estimated wait time is problematic. So the safest way is to check the printer status before closing the connection.

Steven,

I am working to implement your recommendations from Nov. 13th.&nbsp; I am hoping you can clarify why you wrote:

while (status == nil || status.numberOfFormatsInReceiveBuffer)

instead of:

while (status == nil || status.isReceiveBufferFull || status.numberOfFormatsInReceiveBuffer)

Isn't status.isReceiveBufferFull a reason to not close the connection?

Thanks,
Del

Hi Michael,
One more thing I forgot to mention early was that we also have observed the same departure event then using the GC Dispatch Queue to send labels through the Bluetooth connection. We should avoid using dispatch queue to send labels on the Bluetooth connection, if we cannot ensure that there is only one label at a time. Generally, this is hard to guarantee when using dispatch queue, especially with asynchronous.

We will see the same departure event happen, if we do so when each label consists of a large amount of data. For example, if we replace the code between line 45 and line 47 inside the loop of 100 labels with a function that uses dispatch queue to print the label, we would almost hit the departure event immediately. So we should treat the Bluetooth connection as singular and avoid using multi-thread to send large amount of data simultaneous. Hope this would solve most of the problems.

Hi Jianghua,

When [printer getCurrentStatus:&amp;error] returns nil, you can check the error object to see what the exact error is. It’s probable @"Malformed status response - unable to determine printer status". This is because the getCurrentStatus: is not designed to work in line_print mode. If we look at the API documentation for <a href="http://techdocs.zebra.com/link-os/2-13/ios/content/interface_zebra_prin…; and <a href="http://techdocs.zebra.com/link-os/2-13/ios/content/protocol_zebra_print…;, we will see that the SDK only supports <em>PRINTER_LANGUAGE_ZPL</em> and <em>PRINTER_LANGUAGE_CPCL</em>. You need to change the language mode to CPCL instead of line_print mode. You can specify the language mode through getInstance:withPrinterLanguage: API in <a href="http://techdocs.zebra.com/link-os/2-13/ios/content/interface_zebra_prin…;​ in the SDK. <a href="http://techdocs.zebra.com/link-os/2-13/bestpractices/">The Best Practices</a> also documents on how to set the language mode in SDK and on the printer.

Hope this will solve the problem.

Hi Steven,

I am facing the same problem as described above , getting @"Malformed status response - unable to determine printer status" during checking printer status.

- We are using latest zebra sdk (V1.5.1049)
- Printer Model: ZEBRA iMZ320
- iOS version 11.2.1

As I learn, I don't need to set printer language specifacally for iMZ320 as getInstance method will put the printer ZPL mode. Then why SOMETIMES we are getting this error during checking Printer status?

I have put a code sample and details description here: <a href></a>

Could you please let us know your feedback as we are strugling with this issue after IOS 11 release.

In advance thanks.

This doesn't sound like an issue in Print Language setting. It's more like a timeout or corrupted response data. See my comments in <a href="/message/95784#95784">iMZ320 in iOS:Sometimes getCurrentStatus shows ErrorCode=7</a>

Dear Zebra-Dev-Team,

is there any chance that the your Framework will take responsibility of managing the proposed delay?
I guess that every iOS developer is facing this problem and I don't think that every client should implement this.

I also noticed that there hasn't been an update for the iOS SDK in a while. Is there an update on its way?
On your website I can only find v1.5.1049.

Thanks in advance and best regards,
Benedikt

is there any chance that the your Framework will take responsibility of managing the proposed delay?I guess that every iOS developer is facing this problem and I don't think that every client should implement this.The above is a good point. We will bring this to the engineering team for consideration.

Yes, v1.5.1049 is the latest as of today for iOS. It was released in Oct, 2017. We don't have update on any future releases.

Hi Matthew,

As already documented in the release notes of <a href="https://www.zebra.com/us/en/products/software/barcode-printers/link-os/… SDK for iOS v1.5.1049</a>, Apple requires to use version 2 of iPod Accessory Protocol (IAP) to manage Bluetooth connections in iOS 11 and beyond. Due to this requirement, applications that connect with Zebra Bluetooth enabled printers on iOS 11 devices need further ensure that the Bluetooth connection is open and stays open if Bluetooth data transmission is still going on. If apps don't follow this guideline, it would manifest into various undesired behaviors, ended with the same EAAccessory Departure message as shown below in device log. Once we see this message, the app won't be able to re-open the Bluetooth connection even the printer appears connected in settings, unless we forget and re-pair with the printer.
CoreAccessories accessoryInfo for departure = {&nbsp;&nbsp;&nbsp; ACCExternalAccessoryPrimaryUUID = "A0D9D23F-0DBF-4946-8396-F2E0FFD36158";&nbsp;&nbsp;&nbsp; IAPAppAccessoryCapabilitiesKey = 1;&nbsp;&nbsp;&nbsp; IAPAppAccessoryDockTypeKey = "";&nbsp;&nbsp;&nbsp; IAPAppAccessoryFirmwareRevisionKey = 001;&nbsp;&nbsp;&nbsp; IAPAppAccessoryFirmwareRevisionPendingKey = "";&nbsp;&nbsp;&nbsp; IAPAppAccessoryHardwareRevisionKey = 001;&nbsp;&nbsp;&nbsp; IAPAppAccessoryMacAddressKey = "AC:3F:A4:00:0D:DD";&nbsp;&nbsp;&nbsp; IAPAppAccessoryManufacturerKey = "Zebra Technologies";&nbsp;&nbsp;&nbsp; IAPAppAccessoryModelNumberKey = ZD410;&nbsp;&nbsp;&nbsp; IAPAppAccessoryNameKey = 50J153200124;&nbsp;&nbsp;&nbsp; IAPAppAccessoryProtocolsKey = &nbsp;&nbsp;&nbsp; {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "com.zebra.rawport" = 90;&nbsp;&nbsp;&nbsp; };&nbsp;&nbsp;&nbsp; IAPAppAccessorySerialNumberKey = 50J153200124;&nbsp;&nbsp;&nbsp; IAPAppAccessoryVehicleInfoInitialDataKey = &nbsp;&nbsp;&nbsp; {&nbsp;&nbsp;&nbsp; };&nbsp;&nbsp;&nbsp; IAPAppConnectionIDKey = 37125317;}Here is an example of how to reproduce the EAAccessory Departure error and how to prevent it from happening. We use the Connectivity module in ZSDKDeveloperDemos project that comes with the release of <a href="https://www.zebra.com/us/en/products/software/barcode-printers/link-os/… SDK for iOS v1.5.1049</a> for this example. To reproduce the problem, we add a loop to print out 100 labels inside performConnectionDemo: function. Depending on the size of data sent through
[connection write:data error:&amp;error], the EAAccessory Departure error would occur before all 100 labels being printed out.
- (void) performConnectionDemo {&nbsp;&nbsp;&nbsp; NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; self.performingDemo = YES;&nbsp;&nbsp;&nbsp; [self.testButton setEnabled:NO];&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; [self.connectivityViewController setStatus:@"Connecting..." withColor:[UIColor yellowColor]];&nbsp;&nbsp;&nbsp; id&lt;ZebraPrinterConnection, NSObject&gt; connection = nil;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if(self.connectivityViewController.isBluetoothSelected) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; connection = [[[MfiBtPrinterConnection alloc] initWithSerialNumber:self.connectivityViewController.bluetoothPrinterLabel.text] autorelease];&nbsp;&nbsp;&nbsp; } else {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NSString *ipAddress = [self.connectivityViewController.ipDnsTextField text];&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NSString *portAsString = [self.connectivityViewController.portTextField text];&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int port = [portAsString intValue];&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; connection = [[[TcpPrinterConnection alloc] initWithAddress:ipAddress andWithPort:port] autorelease];&nbsp;&nbsp;&nbsp; }&nbsp;&nbsp;&nbsp; // Take out the preset delays from the connection to make the reproduction of the problem simplier.&nbsp;&nbsp;&nbsp; [connection setTimeToWaitBeforeCloseInMilliseconds:0]; // Last value was 105&nbsp;&nbsp;&nbsp; [connection setTimeToWaitAfterReadInMilliseconds:0];&nbsp;&nbsp;&nbsp; [connection setTimeToWaitAfterWriteInMilliseconds:0];&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; id&lt;ZebraPrinter,NSObject&gt; printer = nil;&nbsp;&nbsp;&nbsp; BOOL didOpen = [connection open]; // Open the connection&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if(didOpen == YES) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [self.connectivityViewController setStatus:@"Connected..." withColor:[UIColor greenColor]];&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [self.connectivityViewController setStatus:@"Determining Printer Language..." withColor:[UIColor yellowColor]];&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NSError *error = nil;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; printer = [ZebraPrinterFactory getInstance:connection error:&amp;error];&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if(printer != nil) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PrinterLanguage language = PRINTER_LANGUAGE_ZPL; // Preset the printer language to ZPL on the printer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [self.connectivityViewController setStatus:@"Sending Data" withColor:[UIColor cyanColor]];&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; id&lt;GraphicsUtil, NSObject&gt; graphicsUtil = [printer getGraphicsUtil];&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for (int j = 0; j &lt; 100; j++) { // Print 100 labels in one open connection &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NSString *testLabel = @"^XA^FO20, 10^BY2^BEN,70,Y,N^FD8033609249442^FS^XZ";&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NSData *data = [NSData dataWithBytes:[testLabel UTF8String] length:[testLabel length]];&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [connection write:data error:&amp;error];&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } // For-loop for j&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } else {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [self.connectivityViewController setStatus:@"Could not Detect Language" withColor:[UIColor redColor]];&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }&nbsp;&nbsp;&nbsp; } else {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [self.connectivityViewController setStatus:@"Could not connect to printer" withColor:[UIColor redColor]];&nbsp;&nbsp;&nbsp; }&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; [self.connectivityViewController setStatus:@"Disconnecting..." withColor:[UIColor redColor]];&nbsp;&nbsp;&nbsp; //&nbsp;&nbsp;&nbsp; // Checking the print status before closing the connection//&nbsp;&nbsp;&nbsp; NSError *error = nil;//&nbsp;&nbsp;&nbsp; PrinterStatus *status = nil;//&nbsp;&nbsp;&nbsp; do {//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; status = [printer getCurrentStatus:&amp;error];//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (status == nil) {//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NSLog(@"MyLog - getCurrentStatus returns nil");//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } else if (status.isReceiveBufferFull) {//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NSLog(@"MyLog - Receive Buffer is full");//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } else if (status.numberOfFormatsInReceiveBuffer) {//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NSLog(@"MyLog - There are still %ld jobs in receive buffer", status.numberOfFormatsInReceiveBuffer);//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }////&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sleep (1); // Delay by 1 sec. for another iteration of checking//&nbsp;&nbsp;&nbsp; } while (status == nil || status.numberOfFormatsInReceiveBuffer);&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; [connection close]; // Close the connection&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; self.performingDemo = NO;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; [self.connectivityViewController setStatus:@"Not Connected" withColor:[UIColor redColor]];&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; [self.testButton setEnabled:YES];&nbsp;&nbsp;&nbsp; [pool release];}If we uncomment the block of code above to check the printer status and to make sure there is no print job in the receive buffer before we close the Bluetooth connection, then we would not see the EAAccessory Departure error. This is just one example of the timing things. In essences, we cannot solely rely on the return of connection.write() as an indication that the data has been sent to the printer. The return of connection.write() only means that the data has been written to the Bluetooth send buffer successfully. Therefore, we need always to make sure that all data has been transmitted to the printer before closing a connection, and make sure that the connection is truly closed, before open another connection.

Hope this helps.

Hi Del,

Thanks for bringing up a very good point. The the status.isReceiveBufferFull is YES, it well indicates that there could be some un-transmitted packets remaining on the host. Therefore the connection should remain open. I agree with you to add status.isReceiveBufferFull in the condition check.&nbsp;

I've the same problem on Xamarin.Forms Application. Printing is ok in IOS 11.2.1 but never work in IOS 11.2.2.

The error is "malformed status responde" on CheckPrinterStatus method.

My printer is Zebra IMZ320. I use LinkOS.Plugin version 1.1.75

How i can fix? I'm sure that only one thread is open and only 1 ipad is connect with printer.

Hi Nicola,
Could you please put your comment in below link:

<a href></a>

I have the same problem that I am discussing with Steven (Zebra developer)

In advance thanks,
Molay

I have a similar problem with iOS 14+ but it occurs at this line  id printer = [ZebraPrinterFactory getInstance:connection error:&amp;error]; with no prior connection (Ex: fresh pairing with a printer restart).
<a href="https://developer.zebra.com/forum/25732">https://developer.zebra.com/fo…;