Data Acquisition problem with multiple length of commands and data received.

[BIRA_PXI]

Hello,

I need to write a program to communicate with a Data Acquisition board. There are about 10 commads and each has a different number of bytes associated with it. For example command-1 has 4 bytes which need to be send to the DAQ, command 2 has 6 bytes, Command 3 has 4 bytes etc...

When the board responds back to the commands I send, it responds back with different number of bytes for each command. For example, When Command 1 is send to the board, it responds back with 3 bytes of data, whereas when command-2 is send it responds back with 5 bytes of data.

Each data byte received by my labView program from the board, needs to be displayed after some processing has been done. This processing may or may not happen on all the bytes of data got back.
I want the program to be scalable, so that if more commands are added later on, the display and the processing changes in accordance with that.

What will be the best approach for such a system ? I want the system to be dynamic, and dont want to repeat or re-write the code for each case statement ( case statements will be decided by the commands).

Any input is welcome.

Thanks,

birapxi

[Dennis_Knutson]

It doesn't sound much different than what has been done for thousands of instrument drivers. With only ten commands, you can write a subVI for each. At http://www.ni.com/devzone/idnet/ you can find infromation on how to develop a driver.

[BIRA_PXI]

Hello Dennis,

That is certainly one way of doing it, but it is the brute force method. Is there any way to use clusters and add the data bytes coming in and going out to clusters. Also when the user sends a specific command out, can I use the unbundle by name function to send the bytes corresponding to that command.

For displaying the data received, can I follow a similar approach and use unbundle by name function to just display the specific data bytes for the command i have received.

Thanks for your input,

birapxi

[Dennis_Knutson]

I agree that using 10 separate functions for 10 separate commands might be a little brute force but 10 functions is pretty trivial compared to some really complex instrument.

I would still recomend that you look at the instrument driver pattern. Most of the functions in a driver can be configured for multiple options and few of them ever send or receive the same number of bytes. Using a cluster is one way but a varying number of bytes can also be easily represented in an array.