SubVI/Instrument Driver Causing Slow Response Time

[AnthonyMN]

Good morning,

I had an AC source working with amazing reponse time yesterday but this morning I tried to add reporting to it and the whole system takes quite a while to respond now.

I can attribute this to the "Measurements" sub VI that was included with the instrument drivers for the power source. I timed my VI and the driver VI and its response time accounts for about 97% of the time of the program.

I guess the solution is remaking the VI to respond faster. I'm still quite new to LabVIEW and was wondering how to get a specific read off of an instrument with multiple values? I'm also guessing that the "Call Library Function Node" function is out of the question for this, as I think that may be what is taking so long.

[RTSLVU]

You need to break this up into separate tasks and use a proper architecture like a state machine or producer/consumer, not one big loop with a flat sequence.

BTW you do not even need the flat sequence at all. Think "data flow" and use the error cluster to enforce it.

Also DON'T IGNORE THE ERROR CLUSTER.

[Kyle97330]

While RTSLVU is correct that your VI could use some work, if it is true that the one manufacturer's VI is taking 97% of the run time, it's an unrelated problem.

I see that the 61600 series has options for RS232 communication and GPIB communication.  Which are you using?  If RS232, what's the baud rate?

If you look at the inside of the Measurement VI, you'll see that it measures 12 things every single time, whether you use those 12 things or not.  If it's using something like RS232 at 9600 baud, best guess is that every call to that VI will take at least 100 ms (best case scenario) to send and recieve 12 items over 9600 baud.  Since you have a Zero timeout on the event structure in the loop with it (in the default case) it's not surprising it's taking up the majority of your time.

Is it possible to either increase the baud rate of the RS232 connection or switch to a GPIB connection?

Failing that, perhaps you can switch to GPIB?  Or, I'm not going to bother to register on their web site to download the manual, but perhaps you could dump the manufacturer's drivers and use your own drivers with standard VISA commands so instead of sending 12 queries each time you only get the 3 you're interested in.

[AnthonyMN]

Yeah I know, and while there are a couple of things I'd like to redo about the looping, but for now I'd just like to start by getting it up and running. I started up last week with LabVIEW because it's the purpose of my internship, so it's a constantly improving process. 

I'm actually using GPIB for it, but the drivers required the IVI input instead. I was honestly a bit afraid that I'd have to rebuild the drivers in order to get the information properly. Maybe the IVI command for fetching a measurement will work for the case for now? I'll let you know on that, but if not I can get in at the ground level and rebuild things.

[RTSLVU]

---

@AnthonyMN wrote:

Yeah I know, and while there are a couple of things I'd like to redo about the looping, but for now I'd just like to start by getting it up and running. I started up last week with LabVIEW because it's the purpose of my internship, so it's a constantly improving process. 

I'm actually using GPIB for it, but the drivers required the IVI input instead. I was honestly a bit afraid that I'd have to rebuild the drivers in order to get the information properly. Maybe the IVI command for fetching a measurement will work for the case for now? I'll let you know on that, but if not I can get in at the ground level and rebuild things.

---

I will have to say I have not been impressed by anything Chroma produces.

Forget their IVI drivers (actually I can't say I have ever seen a set of IVI drivers that worked properly from any manufacturer) and use the SCPI commands in the manual to make your own set. I ended up having to do that myself with a Chroma DC load, because in short their drivers are crap. Besides, building your own set of instrument drivers using SCPI is a good way to learn LabVIEW and the proper operation and programming of the Chroma AC source.

[natasftw]

---

@Kyle97330 wrote:

While RTSLVU is correct that your VI could use some work, if it is true that the one manufacturer's VI is taking 97% of the run time, it's an unrelated problem.

---

It is and it isn't.  If the manufacturer's VI is taking that long once we add logging in, you can find ways around this using a better architecture to mitigate the hit we're seeing (a producer/consumer only handling the logging every n iterations as an example).  It's not uncommon to use a better architecture to get around limitations we'd see in a more primitive architecture.