Different behaviour of ComWrt() in CVI5 and CVI6

[markus kossmann]

In CVI5 on Windows NT4 SP5 a ComWrt(Port, Buffer,Count) commmits the Buffer to the serial port at once. With CVI 6 on the machine ComWrt seems to wait until the Outputqueue for that port (defined in OpenComConfig()) is filled or you do read from that port. Is that difference intended and how do you switch back to old behaviour ?

[Chris Matthews]

The serial library didn't change. What did change was that we went to a multithreaded debugging environment. Now when you stop your program at a breakpoint, the background threads (that handle the queueing) are going to be suspended so you won't see them dump to the port while you are single-stepping through the program since the queue threads are on hold as you step through the main thread. So if you are seeing this in debugging, it's normal and it wouldn't happen during normal execution. Another possible cause for this would be if you have upgraded OS's as well to Win2000 or XP. They have newer serial drivers that do have some behavior differences. I'm not familiar with all the changes, but we have seen similar symptoms as a result of upgrading OS's.


Best Regards,

Chris Matthews
National Instruments

[Craig Leidholm]

I've seen this as well, and am concerned this will cause problems since the behavior of the software is going to be different in debug vs executable. I can imagine some timing issues rearing their ugly heads in the executable that weren't there in the debug stage.

What are NI's suggestions to alleviate this possible problem?

[Chris Matthews]

The difference in behavior is only when single-stepping through the program, not just running in debug mode. If you really want to eliminate this, then don't use queues for serial. You can set the queue size to a negative number and it will disable the queueing for output. Any multithreaded program is going to single step in this way though with the other threads suspended.

[Craig Leidholm]

My concern is with the single-stepping. Often the reason for single stepping through sections that utilize rs232 commands is to analyze the input and output to determine what might be going wrong, and in these cases, the suspended threads would make this difficult. I have run into an issue using IntallComCallback() where data coming back from an instrument gets out of sync, and has one or two missing or extra bytes in it. Analyzing this was very difficult, partly because the commands were not sent immediately, and was only solved by using a multithreaded approach such that the communication is never interrupted.

What does the "this" refer to in "If you really want to eliminate this, ...". The suspended threads in single-step mode? Or do I
understand that there is no way to use single-step mode without running into this issue of ComWrt() commands not being sent immediately?

Thanks.

[Chris Matthews]

No, if you disable the output queue (set queue size to a negative number as stated in the help), then ComWrt's will happen immediately and not work off of a queue in another thread. You could at least do this while debugging.

Chris

[Craig Leidholm]

Thanks. That will help a lot.