asychronous custom device timed loop timing v.s. VISA read/write timing

[MileP]

I'm trying to create serial communication custom device, and just noticed the VISA read/write timeout default is 10sec (configured by timeout input of Configure Serial Port).

The asynchronous custom device timed loop period is 100ms (I assume this is adjustable).

If the target system updates the value and sends the value to serial port every 1ms, what kind of timing I should configure for timed loop period and VISA read/write operation time? I'm confused...

[Pie56694]

There are three rates you need to be concerned with.

1. Primary Control Loop Rate - The rate of the PCL is important because the asynchronous device input and output channel FIFOs are read and written once per iteration.
2. Asynchronous Custom Device Loop Rate - This loop provides the interface between the DUT and the PCL.
3. Device Under Test Rate - You need to accommodate the DUT's rate.

I'm going to talk about a generic Device Under Test, not any particular serial device.  If the DUT generates data at 1KHz, then the asynchronous custom device TL needs to iterate at 1KHz to keep up with the DUT.  If the rest of the NIVS system needs the information from the DUT, then the PCL has to iterate at 1KHz to keep up with the asynchronous device TL.  In this situation, the timeout might be less than the loop period if I didn't want the loop to be late if I hadn't heard from the DUT.  The timeout might be 10 seconds if I wanted to sit there and wait for a new message from the DUT.  This works the other way around as well; if NIVS generates data for the DUT at 1KHz, then the TL needs to run at 1KHz to keep up with the PCL, and a 1ms timeout is sufficient in this direction.  The timeout recommendation can only be made by understanding your requirements, which I don't.

Serial devices typically do not communicate deterministically, and are more commonly used in instrumentation applications than closed-loop real-time systems.  You've noticed that the default VISA timeout is relatively long.  Well, when you send a bench-top oscilloscope a "MEAS:VOLT: DC?" command, it might take that instrument a few seconds to get into the right mode, take the measurement, and write the result to the port.  I really like the suggestions Devin gave about passing commands via boolean channels, and Stephen's recommendation to pass the measurement data through a channel (rather than the serial data) sounds like the way to go for a typical instrumentation task.  We'd probably be able to provide more specific or different recommendations if we had some details about your requirements and the nature of the serial communication and overall system.

Steve K

[MileP]

Thank you Steve.

The requirement is like this:

one input for memory address

one output for data read from memory address

upon power up, the custom device should set up the serial communication automatically without any button control

user enter the memory address and get the output data.

[MileP]

I don't understand - even if you pass the commands and meansurement data via channels, you still have to transmit them as serial data. Isn't it?

[Pie56694]

• What is the format of the memory address?  For example, is it: 1111FF11, MDR07, 6523130?
• Is the memory address always the same?  For example, can you write a constant on the block diagram or do you need a channel that will pass a new memory address to the custom device?
• How often will you request data from memory?  Just once, continuously, on demand?
• When you request data from memory, how soon do you need it back?  Do you want the rest of your NIVS system to wait for the data to be returned or do you want NIVS to continue processing other tasks while you're waiting?
• What is the format of data read from the memory address?  For example, is it: 201, DEVICE ACTIVE, 01000101?
• Typically when you poke an address you get 8, 16, 32 or 64 bits back; is this the case or could the data from memory be different length?
• How long is it from when you request data to when you get data back?  What is the jitter?

You are correct, eventually you'll have to write serial data, because that's how the DUT communicates.  Devin's suggestion is to create an Application Programming Interface with the custom device.  An API makes it easy for one module to use another module.  Basically, the LabVIEW code inside the custom device will do the actual serial communication.  The API will be a set of NIVS channels that correspond to commands you'll send to the DUT.  Like I wrote in my last post, it's common to talk about instrumentation over serial.

To elaborate on the idea:

• You build two channels in the initialization VI.  The channel names are "Get DC Voltage" and "DC Voltage".
• You build code in the RT Driver that looks at the "Get DC Voltage" channel.  When the code sees the channel transition from 0 to 1, then it sends "MEAS:VOLT: DC?" to the serial port.  This string tells the instrument to take a voltage reading.
• You build code in the RT Driver that parses the string returned by the instrument.  Then, you convert the string to a number.  For example, the instrument returns "2.01".  You convert that string to a number 2.01d.  Then the custom device sends 2.01 (as a double, not a string) back to NIVS through the "DC Voltage" channel, and then the rest of the system has access to the data.

Steve K

[MileP]

Thank you!

Memory address is 32-bit hex value

The memory address could be any value - this is will be passed in from a VS channel

The data is requested from memory on demand at the beginning, then depends on the refresh rate (1ms) on target.

At the moment, the custom device only has two channels, input memory address and output data. I don't know what you meant by other tasks. Do you mean the NIVS tasks outside of the custom device?

The data read from the memory address is numeric, could be 32-bit single precision float, 32-bit integer, or boolean.

The data length depends on the response from the target and can be different.

The jitter is 1ms

Creating an API with the custom device is a good idea, but I'm still confused.

RT FIFO Read reads all the input channels including the "Get DC Voltage"

So the code inside the Timed Loop has to retrieve "Get DC Voltage" value and sends command to serial port.

While the Timed Loop period is 1ms (to match DUT), will it add too much work inside the loop? What if I have to add more boolean channels later?