new design pattern needed

[sydney]

At this point in time I have an application that is pretty much done and meets the original project requirements; however, the requirements recently changed which is why I am posting this question. My application is designed to talk to embedded software in a VME chassis using TCPIP and UDP. I made a producer-consumer design where the consumer loop is also a FSM as well as receiving messages from a message queue. The FSM sends out TCPIP messages, while a third loop constantly checks for TCPIP receive messages (ignoring time out from the RxTCP msg vi), and these messages do come through very infrequently. The more frequent data that I have to display is received via UDP in another loop. This works well, and the block diagram is rather large, but orderly, even though I do use a lot of subVIs!

My problem is that now I am required to talk to 7 separate boards in the VME chassis, each with it's own IP address! Adding code to the consumer loop to do this is not a problem, but I now have to add another loop to the block diagram to receive TCPIP messages from each board and to another set of loops for the UDP data being received. Although the code changes are straightforward, this going to take up a lot of block diagram space!

What I would like to do is to open each socket on the block diagram and then put all the code that normally would be in a separate processing loop into it's own subVI, and have that subVI stop on command from the FSM/consumer loop, pass out the reference to the TCPIP close vi. I suppose that what I really want to do is to place this code into its own thread, so I may be in need of investing in RT LabVIEW, but I have not used this package. Any feedback on this would really be appreciated.

[Black Pearl]

You can dynamically launch 7 reentrant SubVIs for each reader. The most recent post on this is the Tale of Two Servers on the dark side. It has evolved into a discussion about queue references and LVOOP, but in the code the launching is shown pretty well. There are also some nice little VIs to assist in the OpenG Application palette.

And if you get a two huge spaghetti bowl with the queues, you also might have a look on the event message bus implementation.

Felix

[ohiofudu]

My problem is that now I am required to talk to 7 separate boards in the VME chassis, each with it's own IP address! Adding code to the consumer loop to do this is not a problem, but I now have to add another loop to the block diagram to receive TCPIP messages from each board and to another set of loops for the UDP data being received. Although the code changes are straightforward, this going to take up a lot of block diagram space!

Sydney,

Just wanted to add that you can wrap your loops as sub vis too to reduce the block Diagram space.

Ohiofudu.

[Christian_L]

My problem is that now I am required to talk to 7 separate boards in the VME chassis, each with it's own IP address! Adding code to the consumer loop to do this is not a problem, but I now have to add another loop to the block diagram to receive TCPIP messages from each board and to another set of loops for the UDP data being received. Although the code changes are straightforward, this going to take up a lot of block diagram space!

You could also create a single loop/subVI for TCP and UDP each, which create and manage multiple connections. Store the array of TCP/UDP references in a shift array and then go through and peridically check for data received from each of the connections. The A Multi-client Server Design Pattern Using Simple TCP/IP Messaging article on DevZone shows an example of implementing this. It use a Connection Manager VI to store/handle all of the connections for you.

[Eugen Graf]

May be my web chat is interesting for you. You will find there the server and a client. Server supports an unlimited count of clients. For each client a dynamic VI will be started on the server side.

http://lavag.org/index.php?app=downloads&showfile=86

Edited January 8, 2010 by Eugen Graf

[PaulL]

What is possible (and what I would do) is package the messages as objects. Each message object includes an object that corresponds to the relevant board. Then in a single controller loop (since the controller has common behavior for all boards--depending only on the current state of the board concerned) the controller uses dynamic dispatching for the particular message (command) for the particular board, based on its state.

This is an implementation of the Command Pattern and State Pattern together. It isn't obvious how to do this the first time (my experience) but it is really simple, elegant, and powerful once understood.

[Mark Smith]

I had to solve a very similar problem. The application is a little different from the multiple clients/single server (which is more common) since you need a single client that connects to multiple servers. My app did not require UDP, but it does manage TCP/IP connections to 54 unique ports on 9 IP addresses. The approach I took was to create a collection of clients and then manage that collection. Each client is responsible for managing the connection to one socket. That connection can come and go without interrupting or interfering with any of the other connections. Each client consists of a TCP/IP connection VI that has a write queue and a read queue running in separate loops. There's also a UI VI that has a read loop that pops messages from the TCP/IP connection VIs write loop. In my case, I have the read VI write to an indicator property node since I've got to get all 54 streams displayed on the front panel and the wires would be a nightmare. Then, the UI uses an event structure to respond to message send requests from the user - this event structure just puts messages on the appropriate TCP/IP write queue.

Like Black Pearl said, these VIs are all re-entrant and launched dynamically. When I launch, I use the clone name of the TCP/IP connection VI to create unique queue names for each instance. I keep the queue names to manage the connections. When I need to close a connection, I force the release of that queue and that stops the TCP/IP connection VI and the UI listener. It doesn't affect any other connection.

So, to the user the applications appears as a single client but it's really a collection of completely asynchronous unique clients for each socket.

Mark