NI488.2 Reading Data Timeout - is Timeout Synchronous?

[rfdes]

When reading data using the synch read function - ibrd - if a timeout occurs, does the abort process happen in sync with the data. i.e. is it possible to lose a byte of information. I am hoping that the timout abort would occur at the completion of a byte read. thanks..

[GPIB_Guru]

No, the timeout is not synchronous because there is no way of knowing when a byte completion will occur (no timing is required in IEEE 488.1). Typically, a timeout implies that something bad has occurred on the bus (the device is not accepting/sending data). Therefore, it is not usually a problem that a byte can be lost.

The timeout on a read function should be set larger than you expect the transfer to take (typically an order of magnitude or such to make sure that you don't miscalculate the time required by the device). If the device is not responding to the request during this extended timeout, than no bytes are on the bus and a byte will not be lost.

If you could provide more information about how you are using timeouts, there may be a better way t
o solve the problem without timing out. For example, if you are not acting as a controller, but instead are acting like a device, I would recommend that you use NI-Device instead of NI-488.2 as your driver. NI-Device is designed for device-side applications.

[rfdes]

Hello..
I have a situation where I want to set the interface board into a Listen-Only mode by using the ibconfig routine. I want to 'know' when data was being received from a 'Talker' so that I could alert the user that a data transfer was taking place. When you set the interface board to 'Listen-Only' the LACS bit in the ibsta variable is always set. Normally, if the board was configured to operate in the usual addressing manner, I would monitor this bit periodically to dermine if the board had been addressed by a talker.

My method regarding the timeout, was to setup a timer interrupt which would fire about every 250 mSec. The interrupt routine would set the TMO value to about 20 mSec, then attempt to read data using ibrd or ibrda. If the ibrd function returned a TMO condition and the ibcnt variable was > 0, then I knew that a data transfer was in progress. I would then reset the TMO to something much greater, alert the user to data being transmitted, then finish the data transfer by calling ibrd again. This is why I was concerned that the TMO condition would cause the possible loss of a data byte. This sounds a bit convoluted and if you have another method, I would appreciate your help.

Using the NI-Device will not be feasible for me.

My desire is to have the card configured as a 'device' using my software. I didn't want the user to have to use the NI-MAX tool to set the card to a 'non-controller' configuration. Therefore, is it possible to dynamically set the interface card to a non-controller configuration? The only way that I know how to do this is from the configuration tool. I would have thought that there would be a NI488 board function that would do this, but I could not find one.

In summary, I want to:
1) Dynamically set the board to non-controller
2) Set the board to 'listen-only' [no addressing]
3) Start an asynch read (ibrda)
4) go off and do other 'cool' things
5) Every 250mSec, determine if a data transfer is
taking place and alert the operator.
6) Process the data collected once the ibrda END
has completed.

Anyway, I hope that my explanation is sufficient for you to provide some help. Thanks for any advise that you may offer..

Jim

[GPIB_Guru]

NI-Device should be feasable, but not necessary. I think you are pretty much on the right track. Your list at the bottom is slightly different from your description at the top and should work for you. I have looked at your list and commented as follows:

1) Dynamically set the board to non-controller
ibrsc 0 will set the board to be a non system controller. This is the equivalent of unchecking the system controller box in the configuration utility.

2) Set the board to 'listen-only' [no addressing]
Continue to use the ibconfig option.

3) Start an asynch read (ibrda)
ibrda does not use any timeouts, so you should be pretty safe here. This is the "deviation" I mentioned above. You describe using synchronous reads (
ibrd). An asynchronous read is much safter and allows #4 below.

4) go off and do other 'cool' things
...

5) Every 250mSec, determine if a data transfer is taking place and alert the operator.
Every 250 mSec, you can call ibwait 0 and check for cmpl. You may get a couple of options here. You could get CMPL only, which means you received the entire buffer worth
of data. You could get CMPL and END, which means that you received a complete message, or you could get some error, which is rare and probably fatal. You would then restart the ibwait.The I/O could also complete if it receives a device clear, which you may want to ignore or pass on as appropriate.

6) Process the data collected once the ibrda END has completed.
...

Another option you have is to use ibnotify. This runs in a separate thread and will simply notify you when the I/O is completed. It behaves like an asynchronous ibwait. You would probabl call it with ibnotify CMPL to be notifie
d when the I/O is complete.

Hope this helps.

[rfdes]

Thanks.. Some good suggestions. I will try some this weekend. Take care.
Jim