TCP Host to Multiple cRIO Architecture

[CraigC]

Hello All,

 

Started a post on NI Forums but didnt get much luck so I decided to try here after lurking for years

 

Just trying to come up with some ideas for architecture implementation.  I am needing to communicate to multiple cRIO modules and typical use TCP in the past to communicate with each cRIO module.  I now have the problem of having multiple cRIO modules running and I want to be able to split the command set into generic and specific commands.  i.e a Generic command is received and handled in the same way for each cRIO chassis from the host controlling PC.  This allows me to have a generic type def command set and several specific type def command sets within a project.  I was hoping to use a poly on the cRIO side (and the host) in order to adapt to which command set it has received and use a different state machine (Which will all be similar) depending on which type def command it has received.  This should avoid me having one large type def CMD enum which contains all of the generic commands, all the commands for cRIO A, all the commands for cRIO B etc.

 

Essentially I know this isn't going to work but is there any other ways of doing this?  Is this touching on the realms of dynamic dispatch by selecting which vi is run at runtime? Is it time to bite the bullet and use classes? Etc etc

 

If anyone can shed some light it would be appreciated.

 

I have thought of workarounds but that is not what I am after really, just if there is a way of doing it properly and if so where to go read up next.

 

Since Posting on NI forums I have been looking into Dynamic Dispatch and this seems like an ideal use case.  However any pointers are still welcome on where to go next.

 

Many Thanks in advance

Craig

LabVIEW 2012

[ShaunR]

Take a look at Dispatcher in the CR

It may provide most of your TCPIP architecture as it is publisher/subscriber and can cope with many clients/servers.

[CraigC]

Hi Shaun,

 

Hope all is well with you, been a while since I was up your way.  I have looked into Dispatcher and I like the principle although I wont really need peer to peer type comms.  the cRIOs should run independantly and just act on commands from the host and report functionality / status back.  I probably could use Dispatcher for this purpose but not sure how to handle who is in "Control" (Probably just need to write some sort of state machine in the host to handle that as the connection manager handles all pubs/subs anyway).

 

I have run through some of the OOP stuff and it looks Ideal for what I am after here.  Dynamic Dispatch is what I require and Flattened class data seems to include type information in it from what I have read.  However I think diving into OOP in this project is a bit much to ask so have decided to stick with what I know and have come up with a workaround for this particular problem.

 

Reading the OOP material and doing some of the exercises I think the penny has dropped as to its potential so have a hobby project in mind to learn the Command Pattern and the factory pattern without TCP comms.  This should put me in a good position to fix the TCP bit in the middle at a later stage.

 

In essence after hours of reading I think I have answered my own question but thanks for the suggestion.

 

Cheers

Craig

[ShaunR]

Hi Shaun,

 

This should put me in a good position to fix the TCP bit in the middle at a later stage.

 Yes. That's the tricky bit though since you cannot serialise LabVIEW objects so it's not just a case of "(un)Flatten To String" to get them across a network..

This thread on "Lapdog over the network" will highlight most of the issues (and solutions)..

Edited July 12, 2013 by ShaunR