Can't control RS232 and GPIB devices at the same time with labview.

[edCubed]

Actually, I don't think the event structure is the problem. I remember now that I tried removing it from the program and I still couldn't control both my GPIB and RS232 devices similtaneously with this VI.

I can control the GPIB device when I run this program, but I can't control the RS232 device when I run this program.

I'll take a look at the event structure anyway and see what I can find.

Thanks again,

[JÞB]

The problem is that a timeout event is queued up every 10 mSec that no other event fires so, when the value change fires it joins the queue at the end, behind all of the timeouts that haven't been processed yet, and cannot be processed until all the timeout events in front of it are processed.  You only process 1 event for each for loop iteration and your iteration delay becomes progressively longer each iteration.  The operator will start banging the mouse up and down trying to get that val change event to fire and queue up bunches of val change events but those are still stuck behind the timeout events.  eventually some  of those val changes do get processed yielding the wildly oscillating behavior you observed because those events happend a long time ago.  The whole system looks erratic and unpredictable.  Eventually the system locks up because the delay waits become geometrically larger and larger.  The logic there is "wait for as long a time as the loop has already been running."  ten seconds into the loop you wait 10 seconds.... then 20...40...80...

not a good "User Experience"

[Albert.Geven]

Good catch Jeff.
I was looking in vi's that had a lot of question marks and completely overlooked the timing.

[edCubed]

Hi all,

I tried taking out the event structure, but I still can't talk to the RS232 device.

I made a skeleton version of my main program that does not include any VIs for controlling my GPIB source meter. The skeleton program only initializes

, reads, and writes to the RS232 device. The skeleton program works fine. This leads me to the conclusion that there is most likely a problem using my GPIB VIs with my RS232 VIs.

One thing I've noticed is that when running the skeleton RS232 initialization program I get the following status code on my error line:

Status Code 1073676294.

This code is a status report indicating the value written to the input buffer has been successfully read and is now empty.

maybe the GPIB device VIs are interfering with this status code and causing a problem with my RS232 communication?

I don't really know what the answer is but I'm confident it has to do with my VIs for my GPIB device somehow breaking contact with my RS232 device.

Any suggestions would be appreciated.

Thanks for your continued help.

[JÞB]

The only way they could interfere with each other is if they both depend on sub-vis that have the same name.  Or the VISA alias for both devices was the same (But VISA won't let that happen)

Trust me, I mix all sorts of comms in test applications for a living.  Every darned day!

[crossrulz]

---

edCubed wrote:

One thing I've noticed is that when running the skeleton RS232 initialization program I get the following status code on my error line:

Status Code 1073676294.

This code is a status report indicating the value written to the input buffer has been successfully read and is now empty.

---

That's not true.  That warning means that the VISA Read gave you exactly how many bytes you requested.  The warning is that there could still be more data in the buffer you didn't read.

I'm with Jeff.  I have a test set the communicates with GPIB instruments, RS-232, Ethernet, and who knows how many PCI/PXI instruments.  They are not interferring with each other unless they share a common VI.

[edCubed · Accepted solution]

I figured it out!

It turns out that there were 2 parameters going into the "VISA Configure Serial Port VI" That were not set to their default values:

"Enable Termination Char" was set to false when the default value should have been true. And "timeout" was set to 1s instead of

its default value of 10s.

After changing these 2 parameters to the default values my RS232 device works similtaneously with my GPIB device.

The reason it took me so long to figure out is because when I used the serial modules alone to control my RS232 device it worked fine. But when I combined the RS232 modules and GPIB modules into a single VI I lost contact with my RS232 device. So I assumed it had to be a problem between RS232 and GPIB.

Thanks to everyone here for all of your help.

You are immeasurably helping all of the self taught, lab workers out there like me.  🙂