Community Nugget Series: Application Development- Installment 1

[JÞB]

---

F. Schubert wrote:, I always like graphical sketches. So the basic idea of the interaction between the business entities could be drawn using boxes and arrows.

Felix

---

Of course Felix is right.... so Here is the base diagram of the Automated Test System in a thousand words or its equivallent.

[GregFreeman]

How did you get 2011 SP1 already?!

Anyways, I really like this nugget and look forward to more of them. I think once people have become "fluent" in LabVIEW, large application development is the next big step. But still, after using LabVIEW for a few years, I find the hardest thing for me is large application architecture, specifically communicating between all of it. It is very true that the design patterns that are preached on these forums every day are invaluable, and expandable, but the larger an application gets, the more difficult I feel it is to get everything to go where it is supposed to so-to-speak. And even more difficult to get everything to shut down as you would like without loss of data ala handshaking (i.e. dynamically called VIs which may be consuming data so we don't want the main VI to exit, thus destroying queue references, before all data has been dequeued).

That said, I think these nuggets seem to be taking us in the right direction to cover more difficult concepts that are not as well documented or discussed. I really like the mulitple loop architecture here because it provides expandability. As was asked earlier, couldn't this been done in just a couple loops? Yes, it could. But when someone comes back and says we have 10 new requirements, or it would be cool if it did this, or we're gonna scope creep you into bankruptcy, it is much easier to add the code in. Basically, having an extra loop or two I don't feel will hurt you much, but it can buy you a lot in the long run.

Ok, that's my 2 cents.

[Ben]

Thanks Jeff.

Picutres make a big difference!

Ben

[johnsold]

Greg,

You wrote ..."more difficult to get everything to shut down as you would like without loss of data"...  This is one of the reasons I have never liked closing queue references as a way to shut down parallel loops.  I prefer two way communications as shown in Jeff's diagram.  The boss sends shutdown commands to each of the subsidiary loops.  After they shut down their tasks, the last thing they do before the loop stops is to send a "stopped" message back to the main loop.  When main has received the stopped status message from each of the other loops, then it releases queues and shuts down the program.  Of course you need to have a backup plan in case a loop stops for some reason without sending a status message (unless your programs never have bugs).

Lynn

[JÞB]

Lynn Wrote:
This is one of the reasons I have never liked closing queue references as a way to shut down parallel loops.

---

I can't agree more!  Worse, I've found that when a dequeue element returns because the queue is released you get the Default value of the queue data.  If that contains a Command (case selector) you will execute the case associated with the default value for selector element- this can lead to unpleasant consequences in medium to large apps.  You will observe in this series that All Queues will have an Exit case.

---

---

Greg wrote:
But still, after using LabVIEW for a few years, I find the hardest thing for me is large application architecture, specifically communicating between all of it. It is very true that the design patterns that are preached on these forums every day are invaluable, and expandable, but the larger an application gets, the more difficult I feel it is to get everything to go where it is supposed to so-to-speak.

PS, I can't Type the app will be developed in 2010 SP1 And Requests for downconversion for any examples posted will require community support (I'm currently media limited )

---

Time for me to admit something here since Greg is knocking at the door of an important concept I was going to hammer home in this series anyhow. And BEN has eluded to the concept already.

Modeling: I could have chosen ANY model as an analogy for the application we'll put together in this series.  IMHO a Business model is fairly straightforward and approachable by a wide audience.  The terminology of basic business functions is clear of "Jargon" that applies to a limited set of persons.  I CHOSE the MODEL before selecting the Architecture and only after defining my intended audience.  The model becomes a indispensable part of the project organization and function VI's Names, Control names, Queue names and structure should conforms as close as possible to the Model selected.  This is yet another result of a philosophy to "Code by intention."

Adhereance to the model gets you two good benefits:

First, as you develop the sub-components you can apply scope from the model- where do I make decisions about what to do next? That's an executive function so Operations, Accounting, and CC GUI don't need this info.  You can see that I've named the data paths (queues) between the major blocks according to the model.   We "notify" the Executive when its common to call these "commands" although, the result and implementation are similar,  the "Notifications" will be an ENUM that selects a case in the Executive QSM.

Second, After you're done the app is going to be revisited sometime by someone.  The closer the architecture conforms to the model the easier it will be to find the area and scope of each sub-function in the project.  In medium to large apps this code maintenance and modification is near impossible for the poor slob who got the code dropped on him and very difficult for the developer who wrote it 5 years ago-----  UNLESS, of course, the developer found some great way to help you grasp an underlying style defining the code. 

On the other hand: selecting a "Bad Model" or even executing the model with poor adherance (Such as, in this case, having the GUI directly interact with Hardware) can make changing the code in the future much more "challenging." 

[GregFreeman]

---

@johnsold wrote:

After they shut down their tasks, the last thing they do before the loop stops is to send a "stopped" message back to the main loop.  When main has received the stopped status message from each of the other loops, then it releases queues and shuts down the program.  Of course you need to have a backup plan in case a loop stops for some reason without sending a status message (unless your programs never have bugs).

Lynn

---

Exactly what I did in my most recent app. Yes, there is some extra coding involved for handling errors as you have mentioned, but assuming nothing errors out you can say with 100% certainty no data has been lost. I think we are all in agreement an error wire from a queue wired to the stop terminal of the consumer loop is NOT a good method for shutting down an application when data consumption by that loop is critical.

[Ben]

---

@Jeff Bohrer wrote:

Lynn Wrote:
This is one of the reasons I have never liked closing queue references as a way to shut down parallel loops.

I am on the same page here as well.

---

@Jeff Bohrer wrote:

...
Modeling: I could have chosen ANY model as an analogy for the application we'll put together in this series. ...

---

And it is here that we find the difference between those walk the way of the LV-Wizards (Express VIs) and the LV Architechts is not that much difference than the difference between a printer and an artist. Designing and refining those interction diagrams and then deciding how to cover all of the requirements using standard techniques to cover the bulk of the requirements while developing unique and novel widgets to fill the uncovered gaps.

Thanks again Jeff for bringing this topic to the fore.

Ben

[Ben]

...and another thought regarding this stage of the game.

After drawing up the interactions I step back and look at the diagrams with an eye toward performance. Most interactions don't require much review but for any data pat that is carrying lots of data, I stop and concider the perfomance impact of various communications methodolgies. Carefully concidring the detials at this phase can save a lot of re-work latter to try and patch up poor performance. Although I can often applying standard comm techniques the application requirements will sometimes rule out the standard solutions and we have to develop our own. In one particularly interesting (to me anyway) was one of those "24 X 7" never goes down never looses data apps. There were mulitple levels of reduncancy implemented so that data collected on a distributed node was never over-wrttine or lost until the data was confirmed to have been writtien to disk. Queues would not work since there was the potential of loosing info if a crash occured while in the queue.

My point today is think about your data paths before you code your data paths.

Ben

[JÞB]

---

@Ben wrote:

...and another thought regarding this stage of the game.

My point today is think about your data paths before you code your data paths.

Ben

---

Excellent Point!  So let's discuss how the ATS application is going to be used and what risks are involved with data loss.

This app will be used for production testing of electronic assemblies.  It performs an experiment where the NULL hypothesis can be stated as "The MFG process failed to produce a "Good Widget."  Disproving the hypothesis results in a widget operating as intended by the design-production team and the unit may have market value if there is demand for widgets.  A class A error results in a good widget incorrectly deemed bad and a class B error risks putting a bad widget on the market.  Loss of data for a particular unit has minimal impact since re-testing is possible (net loss a couple of operator man minutes,)  so the cost of developing "bullet proof 24/7 code" is not justified in this case.  I would expect that an application designed to control a manned space mission would have different data path structures since a worst case loss of the system could involve a space vehicle and an un-controlled rendezvous with a population center.  

This system level thinking can assist you in organizing the components of a system.  For example: the ATS has a component that makes a selected comparision Its a Polymorphic VI and the DBL instance will probably irritate some software "Purists."  On the other hand, from a useage standpoint, I can count on the engineering team to set appropriate test limits that have a greater safety margin than machine episillon. 

[djs_at_eaton]

I've also found it good, but not easy, to make archtecture drawings.  It helps other programmers (or me 6 months later) comprehend what's supposed to happen.