Architecture ideas/suggestions

[Stagg54]

So here is my situation

I inherited some code that has a bunch of parallel loops. Several of them share hardware. Specifically we have 1 channel of AO that goes to amplifier/speaker setup. Normally we use this channel to output realtime signals from our sensors. But there is a portion of the program that can "hijack" this AO channel and use it to output data from a file. The problem is not only interrupting the realtime output but also that the 2 tasks have different parameters/setup (for example sample rate, continuous vs. finite samples, etc.) So when this was developed they previously had 2 seperate programs and when they combined them they ran into all kinds of problems, so they invented this crazy scheme using all kinds of global variables to coordinate and do some handshaking. It's a mess. Its super-buggy and it needs rewritten. We also have a similar issue with an AO that is used for injecting test signals (we have 2 different types of test signals).

I would like to implement an OOP solution. I'm still trying to wrap my mind around the problem, but I'm thinking about having some sort of arbiter class. It would decide who gets control of the resources. I'm thinking that to do it that way the arbiter would have to be by-ref. I was thinking of having some sort of "Output Data" method, where you pass it the data you want to ouput and tell it what type of output it is and it handles setting up the resources and coordination.

Any thoughts? Am I on the right track? Would you use a different approach?

Also, I'd kind of like to draw this up in UML. Anyone know of any good UML tutorials (as it pertains to OOP and classes)?

thanks,

Sam

[jdunham]

I would like to implement an OOP solution. I'm still trying to wrap my mind around the problem, but I'm thinking about having some sort of arbiter class. It would decide who gets control of the resources....

Any thoughts? Am I on the right track? Would you use a different approach?

Normally to arbitrate a shared resource, you use a "mutex". You can use the LabVIEW Semaphore as a mutex. If one process holds the mutex, any other process requesting it will have to wait until the first one releases it.

I don't see how OOP will buy you anything extra in this case.

Jason

[Stagg54]

Normally to arbitrate a shared resource, you use a "mutex". You can use the LabVIEW Semaphore as a mutex. If one process holds the mutex, any other process requesting it will have to wait until the first one releases it.

I don't see how OOP will buy you anything extra in this case.

Jason

Well simple is usually better.

[Stagg54]

in this case though I'm not entirely sure.

The problem is the realtime output is continuous.

So to make a simple semaphore work I would have to:

Periodically stop the realtime task

Release Resources

Release the Semaphore

Reacquire the Semaphore

Reacquire the resources

Resume output

Playback from the file only occurs rarely. So I would constantly have the overhead of releasing the resources and then reacquiring them and 99% of the time it would just simply release and immediately reacquire. I'm not a DAQmx genius (in fact I know very little about it, just the basics) but I have to think that would chew up a lot of CPU time/resources. It kinds seems like polling versus being more event driven.

It seems that even if I were to use a semaphore I would have to use some sort of notifer/event (or something similar) as well to stop the continuous output task so that I am not constantly stopping and starting it.

Hence I was thinking that if I have to incorporate both a notifier and a semaphore that bundling them in a class might make sense.

Am I still making it more complicated or is there an easier solution?

oh and to add another wrench into the works

there is talk of building the part of the program that does playback from files into its own seperate application, which opens a whole new can of worms.

[Black Pearl]

I had some similar design issues. The solution I came up was a state machine and a queue for communication. The state machine periodically checks the queue (timeout=0ms) if it gets a 'Pause' message. In the pause state, the SM waits (timeout -1) until it receives a 'resume' command. In the state transitions, the tasks are closed/initialized.

About semaphores. I think it is easier to use the subVi boundary for this. An action engine always protects data from concurrent access.

Concerning uml, it's not really that complicated. Most you can find on wikipedia. Another ressource was M$ Visio, which gives a nice intro but is not always compliant with the uml standard. Also keep in mind, that uml is not a programming language where you will get compiler errors. It's for modelling, so you are allowed to make incomplete models.

If you can choose an uml tool, make sure it supports all diagrams you might want. I use eclipse/papyrus for this. You certainly want Class Diagram, State Diagram and Sequence Diagram (for modelling the communications).

Felix

[jdunham]

in this case though I'm not entirely sure.

The problem is the realtime output is continuous.

So to make a simple semaphore work I would have to:

Periodically stop the realtime task

Release Resources

Release the Semaphore

Reacquire the Semaphore

Reacquire the resources

Resume output

Playback from the file only occurs rarely. So I would constantly have the overhead of releasing the resources and then reacquiring them and 99% of the time it would just simply release and immediately reacquire. I'm not a DAQmx genius (in fact I know very little about it, just the basics) but I have to think that would chew up a lot of CPU time/resources. It kinds seems like polling versus being more event driven.

It seems that even if I were to use a semaphore I would have to use some sort of notifer/event (or something similar) as well to stop the continuous output task so that I am not constantly stopping and starting it.

Hence I was thinking that if I have to incorporate both a notifier and a semaphore that bundling them in a class might make sense.

Am I still making it more complicated or is there an easier solution?

oh and to add another wrench into the works

there is talk of building the part of the program that does playback from files into its own seperate application, which opens a whole new can of worms.

With the caveat that I may not be totally clear on your concept, here are my thought.

You can poll the semaphore to see if anyone else is waiting on it. If you keep the reference open, this is a very quick operation (even if not, it's probably still quite fast). So there's no reason to release the resources from your main process unless you detect that someone else is waiting (that is, another thread has requested the semaphore).

With regard to "chewing up a lot of resources", the processor has to run anyway. Sure, events are cooler than polling, but unless your app is actually not performing adequately, then worrying about polling is not the best use of your time.

If you have to share the resource with a separate app, then I would recommend writing a third app (a driver of sorts) to manage the resource and then have both of your apps request it's service rather than trying to have the apps communicate with each other directly to manage the resource sharing. This may mean you have to expose an API with some of these functions like "tell me whether someone else is requesting the resource."

You can do it all with LabVIEW and build your driver into a DLL, and use CLF nodes, or else you can use VI Server calls into the driver app and it will be a lot like LabVIEW.

Jason