04-18-2011 09:20 AM
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:
04-25-2011 07:50 AM
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
05-02-2011 02:45 PM
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.
05-02-2011 04:10 PM
@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)
05-02-2011 06:43 PM
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.
05-03-2011 11:21 AM
@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.
06-08-2011 01:03 PM
@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?
06-08-2011 01:28 PM - edited 06-08-2011 01:32 PM
Yes, but I'm having some IP issues that are stalling out the series.
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"
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.
06-08-2011 01:39 PM
Hmmm... Interesting. I am looking forward to the continuation of this series.
05-03-2012 10:08 AM
I can't view the Main Rev A.png for some reason. It showed a broken link.