Visa Write go slow

[pgaastra]

I have a LabVIEW program which uses a duplicate session to write stuff to an Arduino and read stuff from an Arduino.  After running for some time, occasionally some of the VIs "freeze".  This was on an executable so I haven't investigated what's going on there.

I put an EZ Tap Pro snooper on the Tx and Rx in the Arduino and found that the characters were being written with a delay between characters.  The Arduino reply is quick as normal.

I am struggling to see how the  VISAWrite can decide to go slow.  The Visa session is set to have no handshaking. To me the whole string should be written into the PC write buffer and the UART should spit the thing out the serial port with no delays.  The PC is connected to the Arduino via USB but as far ask I know the PC thinks it's like a serial port.

Can there be anything in VISA Write which drip feeds characters to the UART?

This is early days in solving the problem.  The software runs well for hours and hours without crashing

Thanks for any clues

[nyc_(is_out_of_here)]

---

@pgaastra wrote:

I have a LabVIEW program which uses a duplicate session to write stuff to an Arduino and read stuff from an Arduino.  After running for some time, occasionally some of the VIs "freeze".  This was on an executable so I haven't investigated what's going on there.

I put an EZ Tap Pro snooper on the Tx and Rx in the Arduino and found that the characters were being written with a delay between characters.  The Arduino reply is quick as normal.

I am struggling to see how the  VISAWrite can decide to go slow.  The Visa session is set to have no handshaking. To me the whole string should be written into the PC write buffer and the UART should spit the thing out the serial port with no delays.  The PC is connected to the Arduino via USB but as far ask I know the PC thinks it's like a serial port.

Can there be anything in VISA Write which drip feeds characters to the UART?

This is early days in solving the problem.  The software runs well for hours and hours without crashing

Thanks for any clues

---

clues?

how about posting your VI ?

[pgaastra]

I have attached the file.  I think the lockup will be elsewhere but this is the thing I would like to clarify.

[johnsold]

Some things about that VI do not make much sense.

- What is the purpose of the Serial Send Queue? Nothing is ever enqueued into it. The Dequeue will wait forever if there is nothing in the queue. Setting and checking a timeout might help.  You also do not Release the queue.  Are these things done in a parallel or higher level VI?

The Rx Data loop seems unnecessarily complicated. Why do you need the Wait on Event and Bytes at Port? Set the timeout when you configure the session (default is 10 seconds), and just let the Read wait for the termination character.

- Your subVIs were not included so we cannot tell whether any problems might be lurking in there.

- Does Wait on Event generate an error on timeout?  That might cause the Rx Data loop to spin without producing any data, although you might see the error on error Rx.

Lynn

[pgaastra]

Serial Send Queue is fed from elsewhere.

I don't release the queue.  I thought I wouldn't have to release it until the program is finished.

Rx data is badly written.  I will try to improve that. For a start I need shift register on the Rx loop for the error cluster for a start.

The general idea was to have the transmit and receive loops going independently without causing any hold ups waiting for replies.

I was not concerned about those things.  My question is:  If I write a string with VISA Write, what could cause the string to go out slowly, 1 character at a time, with a delay between characters? 

[johnsold]

I don't see anything which would cause a delay between characters on write.  How much delay occurs?  Is the delay consistent or does it vary?  What is the length of the messages being sent?  Are there any special characters in the messages?

I think you need to be more careful with named queues regarding releasing the queue.  Look at the detailed help file for Obtain Queue.

Lynn

[pgaastra]

Thanks Lynn.

I read the thing about releasing the queue in the help as you suggested.  I will change that.   Perhaps the memory that is being grabbed each time it looped caused some kind of problem elsewhere.

Sorry, I didn't save the record of how much time between characters but it may have been 1/4 second.  Each string is a max of about 20 characters.  No special characters except a line feed at the end.

[Dennis_Knutson]

There is nothing in a VISA Write that be set for some inter-character delay. It must be programmed or you have a conflict between the write and read. I would suggest getting rid of the simultaneous read and write and only doing a read when you are not sending.

[pgaastra]

Thanks Dennis.

I have some replies from the Arduino which happen long after a  command is given with other replies intervening.  I was trying to get the Tx and Rx loops totally independent of each other.  I got the Duplicate Visa Session idea from somewhere on the web/NI site.  It seems to work well for quite a while usually.   

The other symptom of this problem is that the LabVIEW stops reading the Arduino Replies.  As johnsold  (Lynn) said my read code could be simpler.

I will investigate these suggestions.

[RavensFan]

I would get rid of the serial events mechanism.

If you have a termination character, then read a sufficiently large number of bytes to get a message.  Set a timeout value that is longer than how long you would normally expect between messages.  If the timeout occurs, do nothing.  If you get data, then proceed with processing it.

If you don't have a termination character, then read bytes at port.  If the number is 0, then do nothing except wait a small amount of time.  If the number is greater than 0, than go ahead and read that many bytes and process it.

Either of these should be responsive enough to the serial port and shouldn't overwhelm the serial port or the CPU with a loop burner.