10-11-2017 10:19 AM
Hi my fellow labVIEW folks,
I am trying to create a measurement VI with a Queued message handler, with an addition of an acquisition loop I have two simultanious measurements to conduct:
1. A pressure measurement (1 pressure meter, 1 control valve)
2. A flow measurement (8 pressure meters, 8 flow meters, 8 control valves).
These will all be connected to 1 bus system (RS-232).
So I want to have one main vi in which I can start and stop both measurements separately. I was thinking about sharing the bus system VISA refnum between two parallel while loops, one while loop for the pressure measurement and one for the flow measurement.
Or should I try to put them both in one while loop and enable the measurements with a case structure around the VISA Read/write?
Any help will be greatly appreciated 🙂
Solved! Go to Solution.
10-11-2017 10:42 AM - edited 10-11-2017 10:43 AM
Are you sure it's a RS-232 bus? RS-232 is point to point and cannot be used to talk to different instruments. May it be a RS-485 instead?
In any case, the serial bus is really serial: you cannot run communications in parallel this way. Do all queries in a single loop.
Second: you do not need the shift register, just wire the VISA resource constant to the VISA functions.
Your example code is very crude (you probably already know this): you don't write anything to the bus and probably you are not initializing shift registers properly (it seems that the resource constant is wired to a tunnel and not to the shift register).
Finally: you probably need to initialize the serial port and close it after the loop is stopped.
10-11-2017 11:09 AM
I agree, you should keep this in one loop. You can run into weird conditions where the reply of one query could end up in the other's read. There are other ways around this, but keeping it all in a single loop is a lot simpler.
10-11-2017 11:14 AM
Theoretically you could use this architecture safely, if you add VISA lock/unlock or semaphores around your write-read pairs so that they wouldn't collide with each other.
10-11-2017 11:21 AM
@arteitle wrote:
Theoretically you could use this architecture safely, if you add VISA lock/unlock or semaphores around your write-read pairs so that they wouldn't collide with each other.
But now it's starting to get Rube-ish. 😉
10-11-2017 12:40 PM
Yes, it is indeed RS-485 communication. I know that you can only send a request and receive 1 datapoint at a time, using hexadecimal commands and the visa write and read function. The problem is that I have around 20 sensors and valves in total. If it were to be in one loop, this would be a very long train of vi's. Of course I could put them in a sub-VI, but there is one problem.
Ideally I would like to have a separate state machine for measurement type 1, and a separate state machine for measurement type 2, running at the same time in the same vi. This way you can separately start/stop measurements. I understand this could be done using semaphores.
But if all the VISA commands are in one while loop (as suggested), how do I separate the measurement types if I am to start and stop the measurements at different moments?
10-11-2017 12:43 PM
Yes, it is indeed RS-485 communication. I know that you can only send a request and receive 1 datapoint at a time, using hexadecimal commands and the visa write and read function. The problem is that I have around 20 sensors and valves in total. If it were to be in one loop, this would be a very long train of vi's. Of course I could put them in a sub-VI, but there is one problem.
Ideally I would like to have a separate state machine for measurement type 1, and a separate state machine for measurement type 2, running at the same time in the same vi. This way you can separately start/stop measurements. I understand this could be done using semaphores.
But if all the VISA commands are in one while loop (as suggested), how do I separate the measurement types if I am to start and stop the measurements at different moments?
10-11-2017 12:55 PM
Everything is very simple and without any synchronization. Make a request (read and write) in the form of a SubVI. And you can easily call them from different cycles. The function will not be called until the previous call ends.
10-11-2017 02:05 PM
10-11-2017 02:30 PM
I would probably do something along these lines using a Queue and a Notifier
Not complete just the bones to start the scheme:
with Main
Calling a get
The Query is a simple W/R replae the to string and to data string functions with your device commands