Minimum delay between two VISA write operations

[TKassis]

Dear LabVIEW users,

I've browsed the forums quite a bit and haven't really found an exact answer to my question.

I'm running two consecutive VISA write operations (without closing the session in between them). After the first 'write' I know that the device will return a '\r'. Right now I have a 100 ms delay between these two operations (please see attached). I would ideally like to reduce that to the minimum required time. I was thinking of doing a read operation after the first write to read the \r but is there a more efficient way to do multiple writes after each other? Speed is critical for my application.

Thank you,

[Dennis_Knutson]

There is no minimum time except for what your instrument requires. If the instrument returns a carriage return, then all you need is a read. If this is serial, make sure termination character is set to be the same and the read will terminate as soon as the instrument responds. Fixed waits are usually a bad practice.

What is the point of the flush buffer?

[TKassis]

Thank you Dennis. I tried implementing the 'read' after the first write, but it is not working as expcted. It doesn't seem to be waiting until the return symbol is returned (although I've used it in another subvi and it works). By the way, I had a slight typo in my previous post. The termination character by the device is \n and not \r.

I attached the vi and a snapshot if you would like to take a look. And the reason I was flushing out is because I don't close the visa session after each operation. Is that not needed?

[Dennis_Knutson]

You did not attach the ppcontrol subVI so I have no idea what is going on with the VISA writes/reads.

There is no VISA Configure Serial Port so I'll assume it is one of the missing subVIs but if it's not, then the default behavior for a VISA Read is terminate as soon as the termination character is detected and the default termination character is \n. It willl NOT return the termination character from the read.

No, the flush buffer is not at all required. The way you are using it, it would only discard data if some is left in the buffer.

[TKassis]

Apologies. I attached the missing VI. The part that isn't working for me though is not associated with this sub vi.

[Dennis_Knutson]

I don't understand what you mean when you say it is not waiting. How can you tell? Depending on your instrument, the time it takes for the VISA Read could be very short.

Your other statements are also confusing. The VIs that you posted do not match the images. You also say that time is important but in the subVI, you open and close the VISA session each time. That is a big time sink.You've got a lot of 100ms waits in the top level VI. Did you modify something and not post the modification?

p.s. Get rid of the useless sequence structure.

[TKassis]

Let me take a step back and clarfy what I'm trying to do.

I'm trying to serially control a peristaltic pump. What I'm doing is having it output a flow waveform based on a sequence of flow rates I give it (for example a sinusoidal waveform). I'm using the 'PP Control' vi to initialize the pump and set some initial values. Timing in this case is really not important. Where things become critical is just inside the timed while loop I have. In the loop I give the pump a flow rate and then read off the pumps rotational speed (in RPM) as an indication of the actual flow rates being used by the pump. I was successfully doing this by using the two 'PP Control' vis in the loop. One for setting the flow rate and then subsequently reading the RPM. The entire process was taking around 160 ms to execute so I thought if I stop starting and ending the VISA session with each loop iteration I might be able to speed that up. Hence I arrived at the 'main.vi' I provided where I initialize a VISA session outside the loop once and then keep using it inside the loop, but with the current implementation it is only working if I put a fixed delay between the first 'write' process and the second. Whenever I try to read the output from the first 'write' as an indication to proceed things don't work.

So in the loop I have several things going on:

1- Setting the flow rate

2- Reading the RPM

3- Plotting the RPM on a chart

What is the best way to speed up this while loop? Oh, and the only reason I have the sequence structure in the while loop is just to time how long the loop is taking so I can optimize it. I will get rid of it when I maximize execution speed.

Thanks!

[Dennis_Knutson]

What you posted is not what you just described.

What exactly do you mean by ' don't work'? How fast does the vendor say you can communicate?

[TKassis]

The first image that I posted had the time delay which worked fine but I wanted to get rid of the artificial delay.

The second image is where I implemented the 'read' functionality. In this case, the program is just moving too fast between the first and second 'write' operations that my pump does not respond. It responds again when I put the delay back in. I was under the assumption though that as soon as I get a response from the first 'write' operation (i.e. a '\n') then I should be able to send another command to the pump. There is nothign in the pump manual that indicates how fast I can send commands, but isn't it a safe assumption that once I get a response from the pump that the first command was recieved I can go ahead and send another one?

Thank you,

[TKassis]

I think I figured out what the problem is. In my first 'write' operation the response from the pump actually alternates between '\n' and '*' since I give it two different commands and each has a different response. How can set up my VISA such that VISA Read looks for two termination characters ('\n' OR '*') instead of just the '\n'?

I've found some forum posts that suggest ways to do this, but I need the most efficient implementation. In other words I want to wait until one of these characters is received and then proceed immediately.