Installment 1: Code by intention and basic code components In this Nugget series we will discuss application development, the different ways we use to access data and information, develop a GUI that has Controls, Indicators and other front panel objects accessable from sub.vi's in multiple ways and explore a software developers approach to LabVIEW without OO but exposing OO concepts. I'll be starting with basics and moving to a real-world app designed specifically for Test Automation. Many of the concepts have wide ranging application but as this is my first "Nugget" and "Series" I'll chose to speak from my strengths. I hope you all forgive me. So lets show how to start: I do it thusly NOTE: The vi hasn't even been saved yet! The FP and BD are blank (OK - Use a template if you want to save time but for this demo I'm starting from scratch) This is where software starts, with the end user(s) firmly in mind! <Sea Story> I grew up as an Electronics Technician. One day a test instrument rep demo'd a new o'scope with advanced math functions. We were impressed with the capabitities - untill it took 5+ minutes to perform the operations. Automate that! [prompt user "please wait while device X does some math. Ensure sliptick oil resivour remains above "critical.""] We called it "Same Day Display." The instrument MFG did not think about the end uses for the product when archetecting the system. < Let's not do that here. Overall Achietecture: 4 main interlocking Queued P-C loop vi's defined as: (If I may borrow from a business case to aid visualization) Corporate Communications ( CC or GUI): Executive: Operations: Accounting: Each of these loops Consumes exactly 1 Queued loop: 1: CC is primarrilly an Event Loop. After initialization it responds to FP events. These events can be caused by direct user action or by indirect actions when something in the application generates an event the GUI needs to respond to. It produces the "Executive" Queue and may generate events. It keeps the user informed and happy. It is the primary abstraction layer between the developer and the user. If the user can do it CC needs to respond - If the developer expects the user to do something it Must be intuitive or explained by Tip Stips and / or on screen instructions. 2: Executive is a QSM (Queued State Machine) it consumes the "Executive" Queue, generates the "Operations queue, and may generate events for CC. This is the main abstraction layer between the developer and the application enviornment. In this demo we will perform "Tests" defined as a sequence of things do much like the tasks your manager asks you to take to acomplish an objective. Its the manager scheduling how when and what to do and has a really great Admin department that knows the business, what can be done by the Ops dept and has a list of activities that should be performed to satisfy the customers (yep! sequence files!) We'll get to those in another nugget in the series! 3: Operations is another QSM it consumes the "Operations" Queue, generates the "Accounting" queue, and may generate events for CC . This is the main abstraction layer between the developer and the system components or HAL (Hardware Abstraction Layer). All interaction between the application and other resources (except the file system and KVM) takes place here. Again- we'll save that for another nugget. 4: Accounting is another QSM it consumes the "Accounting" Queue, generates "Executive" queue, and may generate events for CC . Its job is to let the Executive know what the result of the operations are so managemant can make an informed desicion on what to do next. And it files reports in whatever format the Admin assistant's policy says to do it in. Each of these four main functions exist in all applications and all LabVIEW code. Here is CC GUI A.vi after saving the GUI responds to user clicks of "stop"(Tip Strip Val ="Press to stop this vi ") and the vi changes state on the next loop iteration. Executive functions are encapsulated in the while loop itself Management is simple: "Unless the last operation was True do the same thing again" (and the constant 10 is our admin assistant!!!! change it and the app behaves different) Operations "list of things the vi knows how to do" is limited to Update i, Wait (n)mSec and (AN,D not then, no data dependancy so we are multitasking!) read Stop Accounting is in the condition terminal reporting the value of stop- and we chose not to report anything- could have reported Array of Stop, Last i, or any of the values we see either to the FP, any file whatever! just illustrating a point. Our requirements a a bit more detailed and we'll get back to the GUI next nugget:GUI FP object encapsulation.

LabVIEW

Never mind, I can see it now.

------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!

Message 31 of 31

(358 Views)

What do you need our team of experts to assist you with?

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?