[Discuss] TLB - Top-Level Baseline

[Norm Kirchner]

Name: TLB - Top-Level Baseline

Submitter: Norm Kirchner

Submitted: 19 Apr 2011

File Updated: 19 Apr 2011

Category: *Uncertified*

LabVIEW Version: 2010

License Type: BSD (Most common)

This is the official release of my LV State Machine template; the TLB - Top-Level Baseline. It was presented at the State Machine vs. State Machine presentation at NI Week 2010.

This is worth using because it implements most of the common functionality that you end up creating w/ most / all LV state machines anyway:

• Error handling
• Idle cases
• Interactive event driven execution
• Shutting down parallel loops gracefully
• String based queued states
• Handling the Panel Close? event

Some techniques used are not immediately intuitive, but each design decision was made with the idea of scalability and ease of use in mind.

Please post your 'Why did you do that?' questions and I'll gladly inform and instruct why the design choices were made (including why did I use colors)

Click here to download this file

[jgcode]

Thanks for posting.

[jzoller]

Please post your 'Why did you do that?' questions and I'll gladly inform and instruct why the design choices were made (including why did I use colors)

Okay, I'll be a downer...

Why would you use this over something much simpler?

Joe Z.

[mje]

Thanks, Norm. I can't wait to dig into this, I've been waiting for the finished version.

One thing I'd like to see an example and brief explanation of is implementing inter-process communication.

[Norm Kirchner]

Why would you use this over something much simpler?

Joe, this is a great question.

Other than the dynamic event registration of the 'User Parameters', what do you see as not necessary?

The 'App Init' section could be flat, but then that portion of the code gets REALLY cluttered, I have seen this time over time.

The Shifter could just be defined inside of some kind of init case like in the JKI state machine, but that gets REALLY crowded once you have a variety of things in there. and that frame just gets unwieldy.

Take out a case for error handling??? yeah, didn't think so

perhaps take out the 'default' case but what about the typos

Take out the Idle case? but what about when you want to have that

Take out the event structure, ok, but what about elegantly handling the panel close operation or killing the two parallel loops

Don't use 'User parameters' or 'Display Values' inside of the shifter..... but what about when a control value needs to be used in two places? Use local variables?....I think not.

The 'Much Simpler' option could be considered the built in, producer consumer template.

But what about all those things that you need to add every time, also what about the BD real estate.

The 'much simpler option' 8 times out of 10 needs one or some of the options of the better option.

So since you can start out with something that operates as quickly and agile as the 'simpler option' that gives you a scalable, clean, well organized and thought out design,

why would I ever consider going for anything else.

You say simpler, I say more work coding the same stuff over and over and less consistency in code.

I'm not saying mine is the end all design.... but if you don't like it, then you should make something with similar options for yourself to save design time and create a consistent coding experience.

It will provide a quality experience for the coders and those looking at the code.

[Norm Kirchner]

One thing I'd like to see an example and brief explanation of is implementing inter-process communication.

Yeah, I'm working with a guy internally that has a knack for taking my ideas and concepts and working them into the least common denominator of understanding.

So although I could just toss it out there, I've gotta keep chipping away at it to have able to be understood by more people than me.

soon.... soon

In the meanwhile, I strongly suggest you check out the 'Actor Framework' on NI.

It is a different beast w/ different options, but will keep your mind whirring until I get LVx posted out.

[jcarmody]

It doesn't fit on my screen.

[ShaunR]

It doesn't fit on my screen.

Better put in a capital req for that 42" LCD TV monitor.

Edited August 31, 2010 by ShaunR

[jcarmody]

Better put in a capital req for that 42" LCD TV monitor.

It's not December yet.  We can't have 2010 capital until there's not enough time in the year to spend it.  We save a fortune that way. 

[Daklu]

This might be a stupid request, but is there any chance of giving the package a meaningful name? I'm not likely to remember what 'tlb' means when scanning 75+ package names. (VIPM 2010 can give the package a meaningful name in VIPM while leaving the package file name unchanged.)

Just out of curiosity, is there any sort of package naming standardization in the works internally at NI? Currently I have ni_util_packagename, nise_packagename, nise_util_packagename, nise_lib_packagename, etc.

[jgcode]

Just out of curiosity, is there any sort of package naming standardization in the works internally at NI? Currently I have ni_util_packagename, nise_packagename, nise_util_packagename, nise_lib_packagename, etc.

Maybe we can start the standardization right here on LAVA.

Start the revolution now!

(New thread started as not to be rude)

[Norm Kirchner]

It doesn't fit on my screen.

Before I go into this too deep, are you operating at at least 1024x768?

Assuming that you are, let me lay out why this design holds up against the 'bigger than 1 screen argument.

We'll start big and work our way down.

Vertical resolution of at least 1024 (1280x1024 or 1600x1050)

You will easily see the code that you will be working with 98+% of the time (Event handler loop and Primary Execution)

Does the fact that the other 2% or less of the time you can't see that other code?

Personally I would rather have more real estate to route wires cleanly and document than cram. period. end of story

Also, in this case, you will only need to scroll in one direction, which by most of our standards, is ok style practice if the situation warrants (see previous point)

Resolution of 1024x768

Although you lose visibility of 40% the architecture at this low resolution take into consideration what is the largest loop.

The Primary Execution Loop, the one that you will interact with 93% of the time or more.

So although there will be a lot of scrolling when working with the other sections potentially, you are still able to follow the primary flow of your program without needing to scroll in the process.

In summary

You will find that although you have an architecture in front of you that goes beyond your monitors display,

as you implement code, the containment of sections of code into monitor digestible sections makes it Very usable.

[jzoller]

...what do you see as not necessary?...

It depends on the use case. I prefer YAGNI over the "everything always available" option.

I'll probably throw together a sample with your system, though. It's intriguing.

A more detailed question: Why a sixteen element queue?

Thanks,

Joe Z.

[jcarmody]

Before I go into this too deep, are you operating at at least 1024x768?

[...]

I should have used an emoticon, sorry.  I agree that BD size is not an issue with the TLB.

[Norm Kirchner]

I should have used an emoticon, sorry. I agree that BD size is not an issue with the TLB.

that's OK that you didn't.

It gave me a chance to put down in words a response that will be needed at some point to someone that really does feel that way.

[Daklu]

Personally I would rather have more real estate to route wires cleanly and document than cram. period. end of story

QFT.

[Norm Kirchner]

A more detailed question: Why a sixteen element queue?

??? where do you see a sixteen element queue?

Or are you talking about the data structure of the AMC?

[jzoller]

??? where do you see a sixteen element queue?

Or are you talking about the data structure of the AMC?

Sorry, poor phrasing. It's my besetting sin.

Yep, it's the data structure of the AMC. I had initially assumed it was something a little less sophisticated than a queue tracking system.

Joe Z.

[Fab]

Norm,

Thanks for sharing this, I like this template a lot. For one thing, it does not have a broken arrow to begin with and you can run it (albeit it doesn't do anything particular) and exit gracefully. Also

Why did you decide to run as a "wizard", was that to show a "working" example of the template? I like that it creates not only the template, but all the supporting files as well nicely packaged in a project. Are there any other reasons?

Other than the dynamic event registration of the 'User Parameters', what do you see as not necessary?

I believe you mentioned it during the presentation at NI Week, but I don't remember exactly, so, why do you use the dynamic event registration as opposed to adding event cases for all the individual user parameters?

Please post your 'Why did you do that?' questions and I'll gladly inform and instruct why the design choices were made (including why did I use colors)

So, why did you use colors? I like it, because it gives you a "map" of where you are at and ... well... it looks "pretty"

Thanks again for sharing,

Fab

[Norm Kirchner]

Why did you decide to run as a "wizard", was that to show a "working" example of the template? I like that it creates not only the template, but all the supporting files as well nicely packaged in a project. Are there any other reasons?

I'm assuming that you're talking about the springboard as a tool. It's because a side effect of using this template is that there are supporting files. And the only elegant way to make a new version of a template and it's supporting files is to copy a library. Doing so maintains linkages and namespaces the VI. So by having my create wizard, I save the end user the cumbersome process of copying an existing library from disk to create a new one.

I believe you mentioned it during the presentation at NI Week, but I don't remember exactly, so, why do you use the dynamic event registration as opposed to adding event cases for all the individual user parameters?

Have you ever had 15 things registered for the same event? How wide was that case selector, How difficult was it to see what was registered for that frame, how easy was it to add a new registrant.

By using the dynamic events, I keep the case selector compact, I easily add elements that are registered, and I easily can see and understand who is registered

So, why did you use colors? I like it, because it gives you a "map" of where you are at and ... well... it looks "pretty"

I did it for those reasons, and it helps focus your attention to an area of interest.

For those still questioning this decision, What do you feel is easier to look at? Which makes it easier to follow which section to go to?

[Mark Balla]

My turn.

I have not seen a nested event structure used before.

How does the event structure inside an event structure work?

When do you put an event in the the innermost one and when do you create one in the outermost?

MArk

[Norm Kirchner]

How does the event structure inside an event structure work?

When do you put an event in the the innermost one and when do you create one in the outermost?

The basic idea is that ALL registered 'User Parameter' fire that generic event case, but if one of the controls needs to have a more specific action fired as well then explicitly register that specific 'User Parameter' for that inner event structure.

It works just as you might imagine, and they must be nested to ensure that the 'Update User Parameters' get's enqueued first.

So although unorthodox, the flow of data and events and states are valid and useful.

There are other ways to skin the cat, but really this one is resistant to issues caused by changing control labels and the removal of controls.

An example is one of a device handle.

Although considered a simple 'User Parameter' and expecting to follow the same flow, when you change the value, you likely would like to close the session to the previously selected item.

So in this case, the instrument handle selector would be a 'User Parameter' amongst the rest, but I would have a specific nested event that is registered for the Instrument Handle specifically that enqueues the command 'Disconnect Instrument'

[Cat]

For those still questioning this decision, What do you feel is easier to look at? Which makes it easier to follow which section to go to?

Deleted: B&W vs. color pics

My first reaction when seeing them side-by-side was that color is not needed. It flows from left to right (init/run/exit) and top to bottom (event handler/executor) like I would usually set up this sort of design.

Except... being a radical non-conformist ( ) I would put the init section in the 0 frame of a stacked sequence structure, the main code in the 1 frame, and the exit/cleanup code in the 2 frame.

(I know, heresy, but I use a 1024x768 screen for my least common denominator target machine and don't have a lot of real estate. With a stacked sequence, my main body of BD code can use the whole screen and I don't have to scroll around. But I digress and really don't need to hear more about how evil stacked sequences are. I agree they can be horribly misused.)

If I wasn't going to do the above design with a stacked sequence and didn't mind scrolling around, then Norm's colors would come in very handy for letting me know exactly what part of my very big block diagram I am currently looking at. So here's 1 vote for colors!

[mprim]

Norm,

It was mentioned in the NI Week 2010 State Machine vs State Machine powerpoint that the TLB State Machine "Can communicate to anything made in LV anywhere in the world." How do I go about making two TLB state machines communicate with each other?

Also this work appears to be a derivative of your previous LVx work. Also previously packaged as RFSE Tools. Do the examples created for LVx apply in the TLB state machine?

Thanks,

Mark

[Norm Kirchner]

Also this work appears to be a derivative of your previous LVx work. Also previously packaged as RFSE Tools. Do the examples created for LVx apply in the TLB state machine?

Mark,

Thank you for bringing this up. You are correct in your observation that the two technologies (LVx and the TLB) work together and work together well.

However one is not reliant upon the other, just as the JKI exports were not critical to the overall JKI SM.

LVx is the technology that enables the interprocess communication and has been in a state of preparation for mass distribution for a while and that statement still holds.

Currently the process of making a new command is too cumbersome and desperately needs tools to aid in the process of creation of new commands.

That and some good documentation (although the code is very clean)

So if you use the TLB, because of the structure, adding LVx (LabVIEW Exports) to your baseline implemented code should be simple.

I am very tempted to post the current version out here, but then the process installing a package once I finish it will cause conflicts, so I hesitate for a minute.

Will you be able to wait a little bit till I package it up in a VIP?