LabVIEW
Is NI-VISA reentrant?
Is there a VISA Configure somewhere upstream? There are a couple things here that should be able to speed stuff up.
1- VISA Read and VISA Write are both set to Synchronous; change them to Asynchronous and see if it helps (right click -> Synchronous IO mode). Synchronous mode locks the calling thread until the whole Read process is finished. The article I sent earlier has some more info on that but it's kind of a complicated subject. I'd try switching it and seeing if it helps 🙂 Another possible option would be to launch this VI using Start Asynchronous Call, which I think gives the launched VI its own private thread to operate in. Just guessing here.
2- If there isn't a VISA configure, add one and configure it to use termchars. The AC Measurements subVI is only requesting 20 characters and your Write is something around that number, so the transfer itself should be blazing fast. Thus, the delay could come from:
2a- The unit may be waiting until it receives a command to make the measurement, which means it takes a finite amount of time to make a single measurement. How long does this measurement take? Maybe you can have the instrument constantly make measurements then ask what the current value is? Just guessing, this would be a Yokogawa question, not a LabVIEW one though.
2b- If you're using timeouts for serial comms instead of termchars, you will have some delays. VISA Read is requesting 20 characters, so if the reply is 8 characters (or whatever) and your timeout is 2 seconds, then all calls to VISA Read will take 2 seconds to return. VISA Read will return when one of the following happens:
-Termchar received
-Number of bytes requested is returned
-Timeout reached
You absolutely want to use termchars unless you have a specific reason *not* to do that (those cases are few and far between, but it happens).
You can do some experiments to see what your bottleneck is. Try running one instance of the VI in a For loop to do, say, 100 measurements or something and see what the time per measurement is.
Regarding the baud rate, if you're sending and receiving about 20 bytes each:
(40 bytes * 10 bits/byte) / 9600 bits/sec = 42 ms transmission time
I doubt that's it. If I had to guess your instrument starts the measurement after the command is sent, meaning there's an unavoidable delay during that period. If your serial comms are set to Synchronous they (might) block each other. Ideally you could send "Take measurement" to each one, but it seems like the second Write command isn't executing until after the first Read command has finished. It still smells like the Async mode being an issue but man, I'm not sure.
Maybe try adding some timing capabilities to your read/write loops to see what's taking the loops so long. Since they're clones you can't use probes, but you could add a queue in there so each one enqueues an element when it's finished reading or writing.
I attached a quick and dirty timing logger library I whipped up for a project once that might help. It needs the OpenG library installed... you basically can "start" a logger, then add elements to it and it'll record timestamps.
Welp I think you've just about hit the limit of my guessing ability. The only possible ideas left are to 1- get rid of two of the identical ones so you're talking to two separate instruments, see if the issue persists and 2- launch your read/write VI's with Open VI Reference, which IIRC gives them their own thread so there's no possible way the caller threads are getting locked somehow.
Otherwise I'm all out of ideas 😕 Maybe you can raise a support ticket to see if R&D can elaborate a bit? This is an area I'm very interested in, as I do lots of serial communication and I'd like to know exactly how VISA calls can block each other.
I stumbled across some more reading regarding sync/async mode:
https://forums.ni.com/t5/LabVIEW/VISA-Synchronous-asynchronous-gt-Confused/td-p/878609
tl;dr: VISA Read is reentrant, but using it in sync mode will likely cause the issue you're seeing where it can only talk to one device at a time (at least, that's how I'm reading things).
