1 of 1 people found this helpful
Currently we do not have an SDK for Win10, so your methodology sounds correct. I'll try to explain some of the best practices you should know about when it comes to Bluetooth printing.
The newer, what we call, Link-OS printers, like your iMZ220 have 2 channels (com ports) associated with Bluetooth. This is not standard for Bluetooth, but we have a reason for the two channels. If you send communication on one port, it will respond on that port. The difference is one is considered a raw port that you can send anything on and we recommend for your printing. The other is for getting status or settings (S.G.D.) only. This is so that getting status and settings does not interfere with printing.
The Link-OS printers also have the ability to provide S.G.D.s in JSON format. It is highly recommended that you use this in order to ensure you are receiving a complete response to your query. The response delay varies from setting to setting and model to model, so this really is the best way to make sure you are receiving a full response. Otherwise the delay could be up to several seconds for some commands.
So say you want to set the variable location, the SGD is:
! U1 setvar "device.location" "My Desk"\r\n
You will not receive any response to this command, so to check the setting was properly set you send:
! U1 getvar "device.location"\r\n
Response: "My Desk"
With JSON, you can do the same workflow by sending:
If you just want to get the current value, send a null as the value:
Hope these are helpful hints to get you started.
I have done some further work on this....
The printer is definitely sending back bytes on the same COM port I send them on, depending on what prot is set as the "outgoing" one.
I can get to the following (catch 22) situation:
If I write my own code to handle the writing and reading to the COM ports then I can send and receive S.G.D. information over the outgoing COM port for the device.
However I don't really want to do this as I don't know of a way to ascertain programmaticly which COM ports are being used to print to which printer, especially if they change around as I have seen before. I can see the management of these being a nightmare.
My code at the moment therefore hooks into windows print routines. This works fine and my code can enumerate and print to the printers as "normal" windows printers. However when I use this method to print to the printers "windows" hijacks the port and prevents me monitoring the bytes coming back in response to the SGD command (i.e. I cant open a port for reading that the device already has open, and I suspect, there's all sorts of horrible timing issues in there as well?).
Therefore I have no way of utilising S.G.D commands (I.e. two way communications) via bluetooth that can be reliable and robust to printer (dis)connects and pairing, repairing?
So "should" the printer send the byte responses back on the other COM port? if so is there a setting somewhere to change this, or is it a bug that wont be fixed "any time soon" (tm.).
Please could you clarify the situation for me, so that I can decide how to progress.
Many thanks in advance.
Thanks for getting back to me.
Noted about using JSON over SGD and I can see how it makes it easier to ensure the correct, and full response.
Regarding the Bluetooth printing itself:
1. I am using a dongle in a desktop PC rather than any "inbuilt" solution. Not sure of that makes a different as such but sometimes I loose communication and have to fix things. For example: Yesterday I had my IMZ220 printing out on Com 24 and receiving on Com 23. Today after rebooting i see that the Com ports have swapped (I have no idea why). Now Com 23 is listed as the outgoing port and Com 24 is listed as the incoming port for the printer/device driver. This is not such a big issue, once I realised "why" my printer stopped working, and rejigged the ports in the driver accordingly.
I am assuming this is a feature of the Bluetooth dongle I am using and its interaction with the O.S. rather than anything to do with the printer? Is this correct - don't suppose you have come across this type of issue before? If so any pearls of wisdom at all?
2. I'm not sure I follow your comments about the behaviour of the two ports. Currently my Bluetooth printer has Com 23 set as the outgoing port and Com 24 as the other (incoming I assume) port. If I understand what you say correctly if I send and SGD command out either as SGD or JSON I would expect it to go out over Com 23 and i "should" see a result over Com 24?
In my tests here I am sending out over Com 23 and yet my Monitoring Software tells me the response to the command is being sent back over the same port i.e. Com 23 rather than Com 24. Please could you clarify what "should" be happening please.
Please note... If I monitor Com 24 I see no "traffic" either out or in.
As always any help, comments much appreciated.
Hi Clive, Sorry for the late response.
Answer to Update #1: I believe this is an issue with dongles in general and virtual ports. We do see this type of problem regularly with USB and the virtual ports there. With USB, we have the benefit of being able to pull a vendor ID that is a standard part of USB handshaking. The best I can recommend for you is to try the port and see if it responds the way you expect. I'll look into if there is a way to find out from the printer which port is which.
Update Question #2: Your dongle may be calling COM 23 an output port and COM 24 an input port, but the printer is not going to treat them that way. The printer thinks it has two independent, bi-directional connections and will handle them that way. Only one of those ports can be used to print, but both can be used to get settings and status. So if you send an SGD over COM 23, you should expect the response on COM 23.
No problems, I had come to similar conclusions myself from testing, but its nice to have the confirmation about the ports both being available for S.G.D. commands and responses.
In the end i have made a basic application to prove the concept and have found that when running on a device (tablet) with embedded Bluetooth the solution is a lot more stable in operation.
Thanks for the help.