Best architecture for large number of VISA devices

[gintree78]

I am about to begin developing a system that will communicate with about 300 devices via RS-485.  I am using the NI PCIe-8431/16, 16 Port RS485/RS422 Serial Interface.  I'm using 11 ports, each port has 27 devices on it.  Before I start development, I'm really just fishing for some advice on the most efficient/simplest architecture for a program like this. I'd like to monitor output from the devices as often as possible.  Based on these outputs, I'd send commands to the devices occasionally.  I plan on using the VISA vis for communication.

I'm thinking something like a parallel loop set up where one loop sends commands and the other reads the output.  This doesn't seem too tough until I start thinking about how to manage 300 devices across 11 ports!  Any advice, examples, or thoughts on setting this up would be much appreciated.  

Thanks!

[crossrulz]

Actor Framework would actually do well here.  Lots of OO design though.

But in general, I would have a single VI with a Queue to accept commands from and a single loop.  When you get a message, you send and/or read from the designated device with the data supplied in the message.  Use the Queue's timeout to periodically check to see if any data has come in.  If it has, read it and pass it out to somewhere.  I would use a User Event so that whoever needs the data can have their own copy.  Now the real trick: make this VI reentrant.  Now you can call as many of these interfaces as you want.

That VI should be as generic as possible.  Now in order to send a command to an instrument, you just have to use the right queue to send the message to the right interface and supply the instrument's address.  I find Action Engines and Variant Attributes particularly helpful here so you can use a look up string to get the right queue reference.  Turn this whole look up and sending into a library so you just use a simple API in the main loop(s).

[gintree78]

Thanks crossrulz.  Just to be upfront, that answer is packed with info and much of it is over my head, so I'm going to ask a few questions here.  I apologize if I am misinterpreting your suggestions.  I'm new to user events, action engines, variant attribute, etc, so please bear with me.  

First, I'll explain a little more about the application.  Each device has a stepper motor that I will send position commands.  These commands may be manually entered by an operator, or position commands may be generated and sent programatically.  The device also has 2 sensors (load and position) which I want to monitor as often as possible.  I may use these sensor readings to trigger position commands as a sort of closed loop control system.  The devices are acted upon by outside forces, so I'd like to continually update my load and position readings across all the devices.  I will be able to send a command to the device for a status and it will return the sensor readings.  It seems like I should be constantly polling the devices for position/load and when I want to move the motor, I send a position command.

-You are saying the actor framework would do well, but it is not what you are describing in the subsequent 2 paragraphs?

-Do I just have 1 queue for all commands, or should I have 11 queues, one for each port? If 1 queue for all commands, will I be opening and closing port references each time I send a command?

-Does it make sense to use the queue timeout to poll the position/load from the device?  Or would it be better for something like an event timeout in my main program to send the position/load poll command to the queue?

I tried to start implementing some of these ideas as I understood them and it ends up looking a lot like a producer/consumer architecture just split into 2 vis!  I'm wondering if there are any examples out there to help me better understand the architecture you are recommending. I've attached a couple snippets of my vis for reference.  They are not fleshed out, just high level architecture type stuff.

Thanks!

 

[crossrulz]

---

@gintree78 wrote:

-You are saying the actor framework would do well, but it is not what you are describing in the subsequent 2 paragraphs?

---

I like to mention Actor Framework as something for people to look at.  But if you are not familiar with Object Oriented concepts, there is a HUGE learning curve.  So what I described is a stepping point to the Actor Framework (thinking in parallel processes, which are often called Actors in the CS world).

---

gintree78 wrote:

-Do I just have 1 queue for all commands, or should I have 11 queues, one for each port? If 1 queue for all commands, will I be opening and closing port references each time I send a command?

---

You want a single queue for port.  This way you can command a port directly just by calling the right queue.  If you shared, then you cannot say who will end up reading the command.  You will want to leave those ports open.

---

@gintree78 wrote:

-Does it make sense to use the queue timeout to poll the position/load from the device?  Or would it be better for something like an event timeout in my main program to send the position/load poll command to the queue?

---

Use the queue's timeout, like what you have in the second snippet.  The only thing I would do differently is you should let the port handling VI maintain the queue (ie open it and close it).  Again, I like to use an Action Engine to hold the queue references and let the main VI use that for sending the commands.