ComCallback CTS event firing when CTS apparently not changing

[cosmo]

I'm getting errors sending/receiving data from hardware over a serial port. Supposed to be using RTS/CTS hardware flow control, so I enabled this after opening the port and flushing both queues. Confirmed baud rate, parity, etc is set correctly for my device.

In an attempt to debug whether CVI or hardware/cable is malfunctioning, decided to post callback events to a listbox. Normally inbound data results in CTS low, read, then CTS high--which is correct. But following a send, might see 3 CTS high, then read, then another CTS high--which is wrong. Next time might see another 3 CTS lo-hi-lo, then read, then CTS high. Also, when first opening port might see 14 CTS high, some read fragment, then 5 more CTS high. I guess I can just code to ignore if the flag isn't changing (flaky event), but are there other problems at work here with the CVI RS232 library?

Thanx,
Orlan

[JLS]

Hello,

I wrote a response but for some reason it did not post! I hope this one does because I'd rather not compose a third time 🙂 So, you are using the RS232 library in CVI, and there are at least two possibilities that come to mind based on experience with NI-VISA. First, NI-VISA defines 3 states, asserted, unknown, and deasserted, and perhaps you are seeing the results of a callback indicating transitions to asserted or deasserted from unknown, but where the unknown state itself does not indicate a transition. Another possibility is that some of the transitions occur very quickly, and are not caught. Now, the driver for a native serial port will be Windows SDK (at the user level, or just below) so you could check the microsoft developer network to see how exactly indication of the line state is dealt with. That is, if change indication is all that is returned, it is possible that a fast transition from hi to low to hi would show up as a hi-hi in your application, because the callback may not execute until the line is hi again, and read this back to the user (where of course the toggling of the line was handled in HW faster than the SW could poll the information). A couple questions come to mind, albeit rather practical:

0. What is your desired functionality?
1. Can you achieve your desired functionality despite the current behavior?
2. Have you tried using NI-VISA as opposed to the RS232 library in CVI?

I look forward to your repost!

Thank you,
JLS

[cosmo]

Hi JLS,
I appreciate your response. I haven't used NI-VISA yet, but after a glance at the help file it just might do the trick.

Here is what I need to accomplish:
-I'm using a single RS-232 port (EIA-574)
-the serial port is connected to a single wireless base station (for barcode scanners)
-1 or more barcode scanner can be wirelessly associated to that base station
-all command and response strings go to the base, and it muxes/demuxes data from the scanners
-each unique barcode scanner will be controlled, at present, by exactly one application running on the server (3 scanners = 3 apps, etc.)
-the server application is from another development environment, so I must 'expose' any required functions of the wireless base and scanners to the controlling application(s)

I have used the CVI RS-232 libraries in a CVI DLL in the past in a one-to-one situation, but never in a many-to-one 'shared-use' situation with RTS/CTS. The base could receive 2 commands from App #1, a command from App #2, then a few more from App #1, all-the-while responses will be inbound--all day long. Hardware flow control is a concrete requirement. If I design for more than 1 scanner, then it will certainly work for 1 scanner by itself. I only want to design this thing once.

Based on the little bit that I have read about NI-VISA from the help file, I need exactly one VISA session per application. Actually, only one of the apps needs to initialize the hardware connection and they all will use a shared lock to share the serial port. How I need to implement this with a DLL I don't know yet. I need to finish reading the VISA documentation and then come up with a game plan. I've already refreshed myself about issues related to sharing data within a DLL. If I must use memory mapped files then so be it. Do you have any recommendations, or am I off the grid already?

Thanx for your assistance,
Orlan

[MJF]

Hello Orlan,

If I were tackling your problem, I would use a single application and spawn a new thread for each scanner that connects. I would also use VISA to control the serial port, it is just a lot cleaner solution than the RS232 library functions.

What you will have to do is have some sort of central thread to control and monitor the serial port. That thread would receive data from the scanners and route it to the appropriate threads to process it. This central thread would receive commands from the scanner threads and send them via the serial port as necessary.

Using thread safe queues would be the way to go because they make it easy to ensure that you don't have two threads trying to use the same hardware at the same time.

I think this is a better solution than trying to access the same serial port from multiple applications (I don't even know if that is possible to be honest).

[JLS]

Hello,

Martin's suggestion is a good one. As a note, you can access the same serial port by opening unique sessions from multiple locations (using VISA) as long as you parameterize the open function (on the first call) with "duplicate session" set to true. Otherwise VISA will attempt to use the same session, and across applications this can cause the error VI_ERROR_RSRC_BUSY which notes, "The resource is valid, but VISA cannot currently access it."

Best Regards,

JLS