Multi application cooperation design - advice needed

[ceties]

Hi dear LabVIEWers!

I am currently developing application for valve train measurements of the combustion engine. I would like to use some sort of modular approach of creating flexible measurement system. By flexible I mean that I would like to create separate applications for each of bellow mentioned tasks. Those applications would be used either together for this particular measurement or alone for other kind of measurement.

To make it simple there are the tasks that has to be done:

1] to drive electromotor via the RS485 and the USS protocol - this part I have already coded. The electromotor is used to drive the camshaft of the engine.

2] 2channel DAQ from laser probes (NI PCI 6120) - measuring the position and velocity of the valve according to the angle of displacement -> IRC sensor used as source of external sampling clock

3] Postprocessing - visualization and other computation of acquired data

The reason for this modular approach is that we perform many different types of measurements on the engine. Thus, it would be silly to create one huge application that would have to be installed when we, for example, would only like to drive the engine and measure temperature .

The applications HAVE TO BE CAPABLE OF EXCHANGING INFORMATION/DATA BETWEEN EACH OTHER if working together but also of working standalone.

The logic is following:

1) User enters the whole spectrum of the rpm he wants to use. For example I want to perform the measurement on: 1000, 2000, 3000, 4000… rpm of the crankshaft.

2) Then when the rpm is reached the DAQ should be performed

3) Then 'data quality check' should be done and if the data are OK the postprocessing applied. If not the measurement would have to be performed again

4) Then another rpm should be set.

5) In the same time check of all crucial values like oil temperature and pressure has to be monitored and if needed warning displayed.

QUESTION:

I am familiar with queued state machines, producer consumer design and I used that during past two years intensively. But the problem is that overall concept works within one application. Here I would like to have three exe files cooperating.  How to achieve the information exchange between those? - As far as I know the queues cannot do that. Is the Shared variable the way to go? What about it's efficiency since the data sets might be big (tens of MB but fast processing required). What would be the best design pattern for that?

Thanks for sharing your knowledge

Message Edited by ceties on 02-12-2009 05:27 AM

[AdnanZ]

Yes, you will need to use shared variables or native TCP/IP nodes. Here are the benchmarks provided from NI for both approaches:

Using the LabVIEW Shared Variable # Benchmarks

Message Edited by Adnan Z on 02-12-2009 03:47 PM

[ceties]

Hi and thanks. My problem is that I don't see how to drive from within the APP1 the APP2. The shared variable seems good for passing data but what if I want to pass states instead? I cannot pass queue reference so how to achive that the APP1 sends 'instruction' to perform STATE1, STATE2 in the APP2 and another set of states in the APP3. If it was within one app I would just simply pass states to the queues but here I am puzzled. Thanks

Message Edited by ceties on 02-13-2009 10:32 AM

[Ben]

There are some conflicting goals here.

Passing info between app instances can be done but not as effieciently as pass data with a single app context.

It is possible to use TCP/ip to talk between app instances on the same machine. So a TCP/IP comm protocol could be used.

Anothe approach coudl utilize VI server >>> Invoke node Call by reference to open an Action Engine that is running in one context and invoke it from another context.

If the AE offered methods to allow access to queues then you have what is effectively cross context queues. Agreed, the queues will not be able to be transfered "in-place" like can be done from within a single context, but it can be done.

Now another idea:

Stick with a single context and dynamically load the tests you will be using today. No cross conext challenges involved. I used this approach in an app I recently delivered (actually Mike Porter and myself). It was an implementation of the classic challenge "Create controls on the Fly". SInce I the develper did not know what or how many kind of widgets the user wanted on their screen, I created a background process for each widget and passed commands and updates around uing queues. At one point I had at least 100 widgets with about 400 queues to provide all of the data paths required.

have fun!

Ben

Message Edited by Ben on 02-13-2009 12:28 PM