Interrupt VISA

[JasonWB]

Hi,

I am in the process of changing over an old program to what appears to be an improved structure. Originally, the entire program was one big case statement; now, it is four loops - one for reading network packets, one for writing them, one for processing the network commands, and one for checking the front panel.

The problem is that although the structure is probably more "appropriate" in terms of proper LabView programming, it just doesn't seem to meet timing requirements. The network read loop reads in a header, length, command, and data, whereas the old structure read in the header, length, command, (then branched to the command handler), and then the data was read in in the middle of the command processing.

With this old structure, we did not progress from one case in the case statement to the next until the current one was complete because there was only a single loop. Hence, the entire packet was read in before the command was processed and even though the VISA read had to wait, the timing was fine. Now, because sometimes there is no character available, the program goes off and does other things and by the time it gets back to the VISA read, we have dropped a character or two. We are running at 115kBPS, so it only takes about 89uS per character.

One possible solution I supposed is to make the VISA read interrupt driven. Another is to somehow manipulate the timing. I am not sure how to ensure that the network read loop gets highest priority. I know that one can put a mS delay block in the loops - I put a 0mS delay in the network read loop. What really happens inside of that delay - how are the other tasks called? Is there a way to control this? I am used to C programming where I can set priorities, but I haven't found such functionality in LabView - does it exist?

Sorry for the long explanation, but I wanted to be clear.

Thanks,

Jason

[Shawn B.]

Jason,

I'm not really sure I understand what you mean by "by the time it gets back to the VISA read, we have dropped a character or two". Do you overwrite your data if it is not processed fast enough?

Also since you are doing TCP/IP there really isn't any kind of interrupt that you can capture through VISA. You may want to take a look at the VIs found on the Advanced»Synchronization palette, or consider using timed loops if you want to change the priorities of your loops.

Hopefully this helps a little!

Shawn B.
National Instruments

[JasonWB]

What I mean is that I have four independent loops running and that VISA input is continually receiving data at 115kBPS. The VISA will read a character, then try to read another and when there isn't one there, that causes that loop to pause and allow other loops to run. Characters are being overwritten in the input buffer before that other loop gives up control and returns to the VISA read loop.

So, I would like to be able to make the loop that reads the VISA interrupt-driven. I don't know if LabView has that capability, but when doing programming on most processors, one can either poll a serial port or have it interrupt driven, in which case the most likely implementation is that the ISR reads a character and puts it in a buffer.

Also, I can find no documentation anywhere on how task switching is handled in LabView. What happens when a VISA tries to read a character and none is present? Will that loop allow other loops to run, similar to what happens when a 0mS delay is encountered? Can one force that behavior to stop? How many characters can be stored in the PCMCIA RS-485 before an overrun occurs, if the VISA Read isn't called?

Thanks,

Jason

[tst]

I'm not sure I fully understood you, and I just got back from the dentist, so I don't feel all that well, so my answers will be a bit erratic. hopefully, they'll be helpful.
For buffer problems, the best thing to use is a queue. The queue VIs can be found in the advanced>>synchronization subpalette.
I don't think you should worry about processor time here, because there should be enough.
You don't have to read one byte at a time. You can use the Bytes at serial port to know how much you have waiting and wire that into the read. According to the VI documentation "The operation returns only when the transfer terminates", so appearantly if you try to read a character that isn't there the VI will wait until it is there.
There is documentation in various places in this site about the execution system, but I don't remember where at the moment. Try looking for "LabVIEW as a programming language" or for "Dr. VI" or for "Labview zone articles".

[JasonWB]

Your advice for using a queue is good. That is how the incoming data is handled after it is received, but the VISA read appears to be what is dropping characters due to an overrun. I looked around and figured out that I can change the input buffer size, but that is the size of the buffer AFTER the data is read.

How many characters can the PCMCIA card hold before one gets an overrun? Most serial ports handle either 2 or 16, depending upon whether or not there is a FIFO built in.

The problem I have is that I am receiving characters in a state machine; that is, I have to look for a 1-byte header, a 2-byte length, and 2-byte command and then data. If I don't get the header, I look for it again, if the command is bad, I start over, etc. I suppose that I could read a bunch of bytes, then process them, but that would dramatically slow things down AND would cause significant timing problems because if what you say is true, that the VISA read locks up the program until a character is available, we would spend a lot of time waiting and hence waste even MORE time. (It would be nice to confirm that behavior because one would think that if a VISA read was called on an empty port, the loop containing that read would allow for other loops to run while it is waiting). Can anyone confirm the behavior of the VISA? How big is it's input FIFO on the PC card?

Thanks,

Jason

[tst]

STUPID! Stupid, stupid, stupid! I forgot that the configure VISA VI has a timeout setting which sets the timeout for the VISA session, so obviously if you ask 3 bytes and the timeout occured, the function will return with an error and probably with what it got so far. I'm not sure what would happen if you wire in -1 (probably nothing) but you can try. That's what you get for going to dentists.
Anyway, it won't lockup the program. It will just prevent its own loop from going forward until it is done. This is a basic principle in LV - execution continues when all things are ready. I don't think that the size of the hardware buffer has anything to do with VISA because it is a software implementation for accessing the hardware, it doesn't change the HW itself. Anyway, I've done some work with serial comm, both with VISA and the old style VI and there is no problem with reading a large number of bytes from the buffer (I'm not sure how much, though. I've done most of my work in TCP/IP). Try looking at the VISA advanced palette. Hope this helps.

[JasonWB]

No, no, no, not stupid at all! Yes, there is a timeout, but I can't find documentation on what happens if the routine is still waiting. One would think it might come back to check later. I suppose I could put in a timeout of -1 (the default), which would cause it to wait indefinitely. I guess what happens sort of IS the question. You're right - it will prevent its own loop from progressing forward, but does it transfer control to others while waiting for the timeout period to expire?

It is so strange - I had a single loop before that would read in the header, length, command, then transfer to a state in the case statement to handle that command, then read all of the data. This never dropped any data. But now when I separate it into what is supposedly a "better" structure, it fails. The strange thing is, I can't get the VISA Read to report a FIFO overrun error.

I guess I will have to play with it. I wish there were ways to time the loops down to the uS level, not just mS. A single character takes 87uS to transmit, 10 bits, at 115kBPS, so I am sort of trying to use a PC a pseudo-real-time.

Jason

[tst]

Don't count on a PC on the uS or ms levels. Are you really recieving data at 115 kBPS? Maybe if you post your code someone can go over it and better understand it.

[Shawn B.]

Jason,

Ok, when you said network packets I assumed you meant TCP/IP. Now that I know you are doing RS485 I might be able to answer some of your questions about what VISA does behind the scenes.

Like you have stated most serial boards have an onboard FIFO. This usually can be configured to be 1-16 bytes. You can set this in the Windows Device Manager under Port Settings»Advanced. If you have your receive FIFO set to 14 bytes, an interrupt will be set when you have received 14 bytes. If you have opened a VISA session to that port VISA will automatically get that interrupt and transfer the data in the FIFO to a buffer in your PC memory. Performing a VISA Read reads the data in the buffer in your PC memory, not your serial boards FIFO.

Since you are not receiving an error, and the default size for your PC buffer is 4096 bytes, I doubt you are experiencing a buffer overrun error.

Are you opening and closing your VISA session in every iteration of your loop? This would cause you to loose data while the session is closed. Also have you verified that your data is actually being transmitted the way you expect it. Perhaps by running your old program which originally worked?

I would recommend posting your code as well so we might be able to see your configuration.

Shawn B.
National Instruments

[JasonWB]

Ok, here you go. The first one with the single loop does NOT drop data.

Jason

[Molly K] Removed attachment per user request.

Message Edited by Molly K on 02-22-2005 03:25 PM