We are trying to intercept data between pos and printer.
The problem we have ran into is the POS reports the printer x is offline when we connect it to com0com endpoint.
an instance of hyperterminal on each side of com0com endpoints do communicate with each other.
I never knew there was a way to detect if hardware was actually connected to the serial port. Normally I write to the com port regardless if there is a device listening. I know the pos uses opos as it's underlying way to communicate to the printer. What event is opos firing to notify the pos application to think the printer is offline? How does the hardware identify if a device is connected? Is there anyway to circumvent this event when using com0com?
OPOS follows three a step process: Open(), ClaimDevice(), and Enable. Calling Open() will cause the OPOS Common Control Object (OPOS CCO) to construct the vendor-provided device specific Service Object (SO), and it will then call the Open() method on the SO. This initializes the software, but probably will not attempt to talk to the device at this time.
ClaimDevice() negotiates with the SO to make sure the device is shareable and available to the app. It is at this time that the device could be reported offline. ClaimDevice() will raise an exception with a ResultCode indicating OPOS_E_OFFLINE.
Setting Enable to true, or performing print activities can fail the call if the device is offline. Someone might unplug the printer in the middle of printing, for example.
The SO is responsible for performing the negotiation and communication with the device. The vendor's provided OPOS installation package typically installs and configures the SO for you. But it is your responsibility to make sure the SO is properly configured to talk to the correct port and device. If it is not properly configured, you will get a device offline error when ClaimDevice() is called.
Related
I am controlling a device over serial connection using LabVIEW (version 7.0). It is connected using USB, and is installed as a virtual serial port on the computer (running Windows XP). Every now and then my device crashes when my program sends a command, and it is unable to accept any more input (the device itself also stops working) until it has timed out.
I've looked at the serial port traffic using Portmon. Whenever the device crashes the serial driver sends the command I send using my program four times instead of just once, with an IOCTL_SERIAL_GET_COMMSTATUS command in between. I cannot see what this last command returns, but I assume something happens in the communication earlier on. I'm thinking my configuration of the port is not entirely right, but I have no idea how or why. I open and close the connection to my device every time I want to write something to it.
For completeness' sake: it has a baud rate of 9600, 8 bits, no parity, 1 stop bit, and no flow control. I'm aware that the correct settings of these parameters depend on the device, but the manufacturer has not supplied any recommended settings.
The driver is a DLL of some sort? If so, this is the most likely source of your problem, and you likely will need to contact the author of the driver. LabVIEW does have crashing bugs, but by far the most common source of crashes in simple communications apps is a buggy third-party DLL.
In other words, I doubt this is a LabVIEW problem at all and that you would have the same difficulty if you wrote a C program to talk to this driver. I only know what you've posted here about your system, but after many years of chasing down such issues, I would start with the device manufacturer/driver author.
If you have evidence to the contrary, please share.
I want to try to set up an ESP8266 (using the Arduino IDE) to occasionally connect to a wifi SSID to send telemetry back. I also would really like to be able to have it running a softAP for configuration/settings purposes. (i.e. so if you want to change internal settings in your code, you can connect directly to the device to access a web form to do so)
The problem is, I am not 100% sure how I know which is which when making an outgoing telemetry json query. I want it to go out on the STATION mode connection. Presumably in most cases the AP mode won't be connected, but there may be rare instances where both are connected at the same time. Thus how do I tell the device to specifically use the STA side of things when it needs to send data back over the internet?
I can't even seem to find any specific examples to ask if one or the other is connected. (you can poll WiFi.status() but - which one is it reporting?)
Any help is appreciated
I'm writing a Linux program (using Qt 4.8 and libusb 1.0) which will communicate with a custom USB device (currently being programmed by a co-worker).
Step 1 is to have a "heartbeat" going back and forth over USB at regular intervals.
I'm currently using asynchronous bulk transfer.
For testing, I've put my "Send_Heartbeat()" on a button click. If I click on the button a LOT and queue up a number of messages to send, as long as I keep my queue busy, the messages keep sending and my USB device keeps receiving them.
If I stop for a few seconds, then resume and add more messages to the queue, the USB device stops receiving them.
BUT, my program's Transfer Callback DOES return with a transfer status code of 0, indicating success, even though my USB device isn't receiving them.
My questions:
Why does the callback's transfer status indicate success if my USB device appears to have stopped receiving them?
Has anyone heard of this type of behaviour?
It's worth noting that if I disconnect the USB device, I get proper status codes returned in my callback indicating that the device has gone away.
If the USB Device is left connected and running, and I "Detatch" and then again "Attach" to force a re-connection and try sending more test heartbeats, it works! The USB device starts receiving messages again.
My "Detatch" is the following calls:
libusb_release_interface()
libusb_reset_device()
libusb_close()
Then my "Attach" is:
libusb_get_device_list()
libusb_get_device_descriptor()
libusb_open()
libusb_set_configuration()
libusb_claim_interface()
My next step is to narrow down which of the libusb commands is re-establishing the communication.
Meanwhile, I'm hoping someone recognizes these symptoms and has a suggestion.
As it's my first time programming USB communication, I'm wondering if there is some fundamental which I've missed.
Thanks!
The issue is here I guess:
My "Detatch" is the following calls:
libusb_release_interface();
In your detatch, you need to attach kernel driver
detatch_kernel_driver();
libusb_reset_device();
libusb_close();
Then my "Attach" is:
libusb_get_device_list();
libusb_get_device_descriptor();
libusb_open();
libusb_set_configuration();
Here you need to check if the kernel driver is active or not. So,
check what attach_kernel_driver(); returns, and call detatch_kernel_driver(); if needed
libusb_claim_interface();
I have a GSM ModeM connected to a serial port, and I use it so send SMS upon certain events.
Since it is not Plug-and-Play, I am confused as to how I'll detect its connection status. Win APIs like GetCommState will obviously not work.
I could periodically send packets of data and check whether the data is being consumed or not, but I'm wary about the risks of polling over performance and clogging up the buffers which might be in use.
So, is there any other method, or some interrupt based thing, which I could use to check whether is still connected, via a serial port, to my system?
I'd be grateful for any help on this.
Thanks.
From Windows 7 onwards, use Windows Mobile Broadband API to get information about a GSM modem.
Serial ports are very primitive communication devices, they date from the very early days of computing. It is what you plugged your ASR-33 teletype into to start banging in your Fortran program. The only reason they are still around is because they are simple, hardware vendors like them because they don't have to spend money developing and supporting a custom api to use their device.
Still, even back in the sixties did a computer have a need to find out if a teletype was attached. Which is done through the hardware handshake signals. The DSR signal, Data Set Ready, is turned on by the device when it is powered up. If you use the .NET SerialPort class then you can check that signal with the SerialPort.DsrHolding property. If you use the winapi then use GetCommModemStatus(), MS_DSR_ON flag.
That still only tells you that some device is attached. If you want to find out that it is the modem that you wrote your program for then you can interrogate it with AT commands, a protocol that's specific to modems. No vendor implements this exactly the same way but you can usually count on an identification from the modem with the ATI command. Check the programming manual for the modem for details.
I have an SMS Appliaction, which receives the messages through GPS Modem and revert back through GPS Modem. The Modem is using COM1.
Now, i need two more appliactions which can send messages through the same GPS Modem. I tried making a webservice which can access the COM1 to send data, but when i try to connect through webService, it throw an error saying, 'COM1 is already occupied, Access denied.'.
Can anybody help me to connect through the modem in above scenario.
Khushi
You have to make sure only 1 connection is made.
Easiest (and most low-tech, but probably most flexible) is having a script checking a directory for files regularly and sending the messages in the file to the modem. The webservice then just writes a file for every SMS it received. (this can be trivially extended to accept emails, web requests, etc, ...)
A bit more sophistacated is to start a thread to do the communication and push the messages on a FIFO like datastructure provided by your favorite programming platform. A BlockinQueue would be perfect. The thread reads the messages from the queue and sends them to the GSM modem.
If you want to have confirmation the SMS is sent (which in my experience does not mean anything and certainly not that the recipient actually received it) you'll need to find a way to return feedback to the caller. This can be as simple a setting a boolean flag in the message to sending another message or performing a callback. But I would not bother. I had situations where 30% of messages dissapeared even when we had confirmation of the message central.