LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Community Nugget Series: Application Development- Installment 1

Thanks for all the great discussion points.

 

Installment 2 (with example code) may be found Here

 

A parting thought for this nugget  for now.....

.  After we went through all the effort to plan and document the Project Model Why not make it a perminent, easy to find, part of the project?  A "cute" way to do this is shown below:

Tree.PNG


"Should be" isn't "Is" -Jay
Message 21 of 31
(2,602 Views)

djs posted this image

 

 

 

Someday, if I am good, maybe, just maybe, I'll someday open someone else's code and find a digram like that.

 

Ben

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 22 of 31
(2,540 Views)

I really like this setup and am hoping to use this structure in my next project.

 

My only concern is for programs that constantly update a few front panel objects (oscope software or video capture software for example).  Do you think it is wise to pass these updates via events to the CC GUI loops or would it make more sense to split the CC GUI loop into one event driven loop for inputs (and perhaps some front panel modifications) and one queue driven loop for updating these frequently updated front panel objects. 

 

I worry that in this case the large number of updates being sent to these FP objects will bog down the event structure and cause the FP to freeze up.

 

Any suggestions would be helpful.  Thanks.

Message 23 of 31
(2,467 Views)

 


@GollumGTH wrote:

I really like this setup and am hoping to use this structure in my next project.

 

My only concern is for programs that constantly update a few front panel objects (oscope software or video capture software for example).  Do you think it is wise to pass these updates via events to the CC GUI loops or would it make more sense to split the CC GUI loop into one event driven loop for inputs (and perhaps some front panel modifications) and one queue driven loop for updating these frequently updated front panel objects. 

 

I worry that in this case the large number of updates being sent to these FP objects will bog down the event structure and cause the FP to freeze up.

 

Any suggestions would be helpful.  Thanks.


 

Thanks! A couple of points to ponder. 

First, The model in this series does not anticipate the GUI operating on large data sets however, there is no event generated by writing the Value property of a control or indicator so I fail to see where high speed updates to a FP object would do harm.  True, the module responsible for updating the object may block (that is one function of the modules- to prevent race conditions) but usually, this can be remedied with proper handling of the data.  For example: I've never noticed the FP of the NI Scope Soft-front Panel to become unresponsive (but I bet they manage data decimation for display and max refresh rate well too!)  But just displaying well handled data sets should not interupt user generated events and the FP remains responsive unless the event strucure itself is busy doing things it should have handed off. 

 

Second: passing large data sets to the FP should be avoided if possible. Use DVR's or Queues to avoid copying data unnecessarilly and display nothing more than the user can make use of!  You have a very powerful machine capably of fine discernment and calculations much more accurate than a user.  In this application the user "pushes a button" and "gets a banana" a different straegy would have been employed to obtain the user's judgment or analisys (and one that would be inherantly prone to error)

 

 


"Should be" isn't "Is" -Jay
Message 24 of 31
(2,460 Views)

I guess I was interpreting your diagram to mean that all FP updates (including value changes) go through the CC GUI loop.  Perhaps I'm looking at it wrong.  Thanks.

0 Kudos
Message 25 of 31
(2,453 Views)

 


@GollumGTH wrote:

I guess I was interpreting your diagram to mean that all FP updates (including value changes) go through the CC GUI loop.  Perhaps I'm looking at it wrong.  Thanks.


The actual implementation of the GUI can be found here

 

Data is passed directly to the FP objects through special AE's to present data to the user from any place in the app instance.


"Should be" isn't "Is" -Jay
0 Kudos
Message 26 of 31
(2,440 Views)

 


@Jeff Bohrer wrote:

Installment 1: Code by intention and basic code components

 

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!

Did you ever get to those sequence files?

=====================
LabVIEW 2012


Message 27 of 31
(2,320 Views)

Yes, but I'm having some IP issues that are stalling out the series.  Smiley Sad

As a teaser I can show a step definition and a partial sequence file containing two steps. the documentation for the two tenors used is

 

Tenors: Tenors perform groups of actions under control from the selected sequence file

 

Null: The Null tenor reports “Done” and is the default tenor.  Used to trap errors for debugging 

Type Def : None

Step Data Reuse: None

Use cases: None

Prototype for ini:

                Null Step = “0,Null,,,None,STR,None,Auto,Normal,-1,0,All,NR”

                Null Step = “”

 

Init: This tenor may be used to selectively initialize all modules or selectively re-initialize any module 

Type Def : Init Var.ctl 

Step Data Reuse: None

Use cases: Establish a known system state and expose a specific xxx project command set defined in the xml file path.

Prototype for ini:

                Initialize = “0,Init,,,None,STR,None,Auto,Critical,-1,0,All,NR”

                Initialize = "\00\01\00\01PTH0\00\00\00<\00\00\00\05\01C\Somefile.xml\00\01\00\01\00\01\00\01\00\01\00\01"

 

untitled2.PNG

 

I cannot answer every question about some of the enum types but you can get some grasp of how I did it for xxx project and intuit some of the advanced functions possible.

 


"Should be" isn't "Is" -Jay
Message 28 of 31
(2,312 Views)

Hmmm... Interesting. I am looking forward to the continuation of this series.

=====================
LabVIEW 2012


0 Kudos
Message 29 of 31
(2,304 Views)

I can't view the Main Rev A.png for some reason.  It showed a broken link.

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

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 30 of 31
(2,032 Views)