Help!!! About Programming Architecture

[xyl4804]

Dear All:

Recently I am trying to develop a software in LV that only performs DAQ tasks, but some challenges are alway annoying me so that I post its requirement here to expect to get your valuable suggestions about it. This software is somewhat similar to the Device Test Assistant  in Measurement&Automation Explorer, however, it could include several DAQ tasks running in parallel at the same time. 

It must meet lots of functionalities as follows:

 1.Can be fully customized. When start to run the application, it should prompt the user to customize specified DAQ tasks as needed. As you know, if the DAQ tasks are unique and given beforehand programming its code could be very simple and quick with LabVIEW, but if such tasks are unknown in advance, how to do?  Probably, in this case it is required to automatically create a while loop to process a corresponding hardware task(such as AI task with NI PCI6232 board). Does it meens that I have to use VI Scripting techniques?

2,This software should provide interfaces to other applications for use such as Report, Display, etc. 

One sentence to describe our purpose to develop this software is that we expect it can do much of our testing requirement(obviously,here, only the DAQ tasks like MAX does) without having to rewrite the test software because of its fully customized characteristic, and with it our user can operate it freely to perform DAQ no matter what he or she is familiar with LabVIEW or not. Although, I have some knowledge about LabVIEW design pattern like state machine or producer/consumer, for now I really have no idea about its architecture and very hope to hear your opinions about this topic, which point we could get start and what techniques we have to use? quite thanks for your valuable tips and help!

                                                                                                                                 Jasper, ShangHai

帖子被xyl4804在 10-14-2009 09:47 AM

时编辑过了

[cirrusio]

Jaspar,

If you are not comfortable with LV yet or need to beef up your programming skills, start small.  Break the project down into smaller individual tasks (poor wording given we are talking about DAQmx).  Consider exactly what you have to do.  What exactly will this program be expected to do?  Surely you are not expecting it to perform just any function?   Will it be sending out an analog signal?  Acquiring digital inputs?  Will the program be expected to respond to user inputs?  

I would suggest that, based on the cursory overview that you give above, you can immediately divide the program into to independent  VIs:  the first is a configuration editor that will allow the user to customize not only the look and feel of the interface itself but will also allow the user to: 1) decide what data to acquire, 2) whether the data acquired will be written to a file, 3) where and how the files might be stored, etc.  This configuration would be written to an .ini file that can be read by the second independent VI.  This second VI would be the actual VI that does all the acquisition and whatnot.  This VI, based on what you say above, should probably at the least consist of a state machine and might possibly contain an event structure to handle requests for viewing data.

But, your requirements are fairly vague, so it is truly tough to make more detailed suggestions.

Hope this helps, Matt 

[F._Schubert]

I guess what you wrote down is the specs you have so far. The phrase Can be fully customized tells me, that the customers (or internal customers) does not yet exactly know what they want. In such a scenario, it might be a good idea to get a program out as fast as possible (with bugs and forth and a lot of missing functionality) and get their response, if it is what they would like to see or if you are far off and need a second start.

If they say, that demo looks good, freeze the code (either a SCC tag or as a zip file) and continue adding the features and fixing bugs and try to have a running version all the time. Maybe you want to search for Feature Driven Developement (an agile method). In this case you also might want to give a 'bug tracker' (such as bugzilla, mantiss, ...) a try to keep track of not only bugs but also the feature requests.

Back to the main design, I would start by a simple scenario such as only using 1 channel analog input of 1 device.

For the Main program, I would start with a state machine:

Init -> Configure device -> Aquire Data -> Shutdown

Init and Shutdown won't be code for now.

Configure device could be a dialog. Cancle will move to the shudown state

Aquire data could be a producer/consumer design. Producer is the DAQ loop and consumer is the display. You could also add a 'Restart' and a 'Reconfigure' button.

Keep track of the states either as bubble and arrow or uml design document. This will evolve over time:

After the init a check for devices state might be placed. After the Aquire Data State a Interface State might be placed...

So for the interface spec: Maybe you can jump off cheap and just save all data to plain ascii, so they could use Excel, other software written in LV, whatever. Otherwise you could develope some kind of plugin architecture. So for a given folder, each vi inside it will be called one after the other vi VI server. Whatever they place in there will need a defined connector pane (you can provide a template for that).

A different approach would be to write all data into a shared variable or something else including a flag 'all data written', and it is duty for the other software to read all data and process it and reset the written flag so your software can overwrite it again.

Hope this stuff helps you. Keep us updated if you need more ideas.

Felix

[xyl4804]

Hi Matt

Thanks for your reply and I really get more from your words. First, I indeed need to think over our requirements throughly...even if we are just beginning to think of it, but one point is certain that the program is expected to do everything associated with a DAQmx device(for clear, still take PCI6232 board for example, such tasks includes AI, AO, DI, DO CTR).Second, I also agree that some *.ini files are required as you proposed. but the issue is that how to design the main VI , which can do several different DAQmx tasks in parallel and can also work normally when the tasks change/increase/decrease  in  the *.ini for the same 6232 board, or when a device are changed from 6232 to PCI 6601.

I think the challenge is that the architecture of this top level VI must be very flexible and have a capacity to handle a large number of  DAQmx tasks in paralell specified by user. Maybe state machine is a perfect solution I could involve in, but the design architecture is a difficult, do you think so? for one thread, I can use a state machine to implement the state transfer to ignore some no working tasks, but how to do to a parallel no working thread, might I use multiple-loops queued state machine desigh pattern with sufficient states in every sigle while loop for future expansion ? Thanks for your patience!

[F._Schubert]

About your last post. What level of syncronization of the tasks is needed?

I will provide you an advanced example for software start (means a difference of 2 ms can be possible), but it can be modified to do hardware sync. You will need a launcher design. Every kind of task (ai, ao, di,...) will have a template (*.vit). With vi server you can open a clone of all those vit's for each task. Use the SetControlValue and RunVI property/methods (btw, there are good wrappers of these in OpenG packages). Each of these vit's will have a notifier for the triggering (so your main VI will send a notification to have all running syncronously. Each (outputs will report their writings) of these vit's will have a queue to report the data to your main loop.

I hope you get the design concept I wrote, it is really very flexible...

Felix

[xyl4804]

Dear Felix

Thanks very much for your valuable solution and I believe they apparently can give me more help to design my program.  I am very interested in your example with less than 2ms syncronization level, could you provide me some refernce about it? I think if the syncronization level  can reach a level of less than 5ms on Win OS, it could be extremely useful to resolve some low level RT tasks that must be implemented on RT OS we have encountered before.

Return to the Main VI Design problem, I got the design concept you mentioned and it looks like the daemons technique involved in LV Advanced 1 Training Course. Good Idea, and I am going to trying it...besides, there is still a small problem that by using vi sever to open a series of clone vis how to specify the informations for each task such as device number,channels,its inner notify name,and its inner queue name...,multiple global variables may be needed, doesn't it,thanks again!

[F._Schubert]

Concerning the demon design pattern (I never was on the course, but they did call it so on a webcast; I prefer 'launcher' as the name and 'rocket' for the deamon; a demon is some background monitoring task and not dynamically spawned vit's): Use the 'Set Control Value' methode (invoke node) and afterwards the 'Run VI' methode (Invoke node). Both are wrapped in OpenG VIs.

Also make sure that the calling conventions are reentrant to get the clones, I don't have the link to the tech paper right here

For sync, I would pause all VIs until they receive the notification. For better timing, you need the start trigger from one task to be assigned as start trigger to the others. So you would need additional connectors IsMaster? and Start Trigger (in the case of the master task you need an indicator + the 'Get Control Value' methode and just add a small delay befor that and the Run VI so it is set correctly). For multiple devices this would require RTSI (on PCI) or PXI.

Felix