46 replies to this topic

[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?

[mprim]

Norm,

I can definitely wait a bit. I have the previous versions on my machine and have been playing with them. In the meantime is there any good documentation on TLB and the AMC class that it uses extensively?

Thanks,

Mark

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?

Edited by mprim, 23 September 2010 - 09:11 PM.

[Norm Kirchner]

In the meantime is there any good documentation on TLB and the AMC class that it uses extensively?

The AMC is on NI's website and was developed by another Systems Engineer Christian Loew.
Documentation on it is listed there.

The TLB's documentation is ..... in work although the presentation is a good starting point.

Most parts other than the dynamic event registration are straighforward, but the rules of thumb and guidelines need to be well noted somewhere.

[mprim]

Norm,

I noticed in the AMC documentation that it is suitable for use in machine to machine communications over TCP/IP networks. Is LVx implementation superior to the AMC implementation?

Mark

The AMC is on NI's website and was developed by another Systems Engineer Christian Loew.
Documentation on it is listed there.

The TLB's documentation is ..... in work although the presentation is a good starting point.

Most parts other than the dynamic event registration are straighforward, but the rules of thumb and guidelines need to be well noted somewhere.

[Norm Kirchner]

I noticed in the AMC documentation that it is suitable for use in machine to machine communications over TCP/IP networks. Is LVx implementation superior to the AMC implementation?

It's not quite a fair apples to apples comparison between the two technologies.
I would not say that it is 'superior' but it accomplishes some different things.
The primary difference, is that LVx is an event driven system. Where you have a Component of a System (an implementation of the TLB) which acts as a receiver of requests. That component registers for multiple events that it can receive from external sources (or internal).

Also the biggest difference is that LVx is setup (by default) as a command response architecture. Where each command/request can contain both input parameters and response information. It allows you to create true 'virtual instruments' and send commands to them as you would any instrument and get information back in the response or simply just sending commands.

As a secondary, because I use LVOOP as the core of the data which flows, there is no need for flattening or unflattening of data as there would be within the AMC.

So LVx covers some more ground in what it accomplishes out of the box. (Event driven, LVOOP based, response embedded)

And as soon as I greatly simplify the process of making a new command elegantly, we'll all be much further down the road to using it for a variety of things.

[NeilA]

My VIPM is crippled by my works proxy and rediculous IM rules so I was wondering if it is possible that these be shared in a non VIP format?

I will continue to try and get the VIPM solution fixed but at the moment I would love to see this design pattern if it is at all possible.

Many Thanks,

Neil.

[Norm Kirchner]

My VIPM is crippled by my works proxy and rediculous IM rules so I was wondering if it is possible that these be shared in a non VIP format?

I will continue to try and get the VIPM solution fixed but at the moment I would love to see this design pattern if it is at all possible.

If you can at least download the file then you should be able to view the files by extracting them w/ a .zip extractor.
Let me know if you can't even get that far

Best,
Norm

[NeilA]

If you can at least download the file then you should be able to view the files by extracting them w/ a .zip extractor.
Let me know if you can't even get that far

Best,
Norm

Thanks, yeah didn't realise that was possible, I can see them I will take some time later to see if I can extract them for use.

Many Thanks!

Neil.

[UliB]

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)

Hello Norm,

today I worked with the TLB template for the first time and I want to ask two questions.
1. Why did you use a LV object as user event data typ for the exit event?
2. The AMC library from NI has an "AMC Destroy Message Queue" VI, which is not used in TLB template. Why don't you destroy the queue?

Uli

[Norm Kirchner]

Hello Norm,

today I worked with the TLB template for the first time and I want to ask two questions.
1. Why did you use a LV object as user event data typ for the exit event?
2. The AMC library from NI has an "AMC Destroy Message Queue" VI, which is not used in TLB template. Why don't you destroy the queue?

Uli

Uli,
Thanks for giving the TLB a go.

1. I didn't have a good definition of data that I might like to be sent along with an exit request, so I put the most powerful / flexible data type as the definition of the event. IOW the LV Object
The idea is that if you have async running processes, that the event ref would be shared amongst all, so although in the template, there is no use for the data, the other components added to the system may add value by using the data space of the exit event.
2. Simple oversight. I'm working on the next revision of the template (1 bug fix and some other additions). I'll be sure to add that in.

Keep the feedback coming. And don't forget that this is good for both very simple & moderately involved UI

[Daklu]

Hey Norm,

Lately I've been reviewing some of the publically available implementation patterns. I primarily use a bottom-up dev process. As I combine lower level components into higher level components, I want to be able to test out the component as though it were an application in and of itself. (Yes, I know I should be unit testing instead... corporate inertia is tough to overcome.) Once I've tested it adequately I want to convert it to headless operation and incorporate it programmatically into some higher level component.

How would you go about converting an app based on this template to a headless component?

-Dave

[Norm Kirchner]

Hey Norm,

Lately I've been reviewing some of the publically available implementation patterns. I primarily use a bottom-up dev process. As I combine lower level components into higher level components, I want to be able to test out the component as though it were an application in and of itself. (Yes, I know I should be unit testing instead... corporate inertia is tough to overcome.) Once I've tested it adequately I want to convert it to headless operation and incorporate it programmatically into some higher level component.

How would you go about converting an app based on this template to a headless component?

-Dave

Well.... the way I do it currently is through LVx, which has become a bit of a black mark on my name here on LAVA because I still have never compiled it into a full package w/ some damn documentation.
What that Acutally means, is that I create an API for the panel. That API enables remote control of a 'Top Level' component.

The idea works very very well, enabling both interactive manual control / headless automated control (for example through TestStand) / and a mixture of both for debug.
But as with regards to the implementation, it has it's pro's and con's.
The biggest con, being that I have not released the proper documentation or tools to debug and create new commands. If you're willing to climb up the learning curve w/ out them, then I'll pass along the most recent version if you setup a time in the evening that we can teleconf and I can walk you through .

[Daklu]

Well.... the way I do it currently is through LVx, which has become a bit of a black mark on my name here on LAVA

I thought those black marks were a mustache and goatee. I had no idea they had anything to do with LVx.

If you're willing to climb up the learning curve w/ out them, then I'll pass along the most recent version if you setup a time in the evening that we can teleconf and I can walk you through.

Oh man, as much as I'd love that I don't think I have time right now. (I keep putting off my CLA exam because this other stuff sounds so much more interesting...) I'm pretty sure you have posted stuff about LVx somewhere around here, but my fabulous search skills turned up zero. Can you give me a two sentence overview of what it does?

What that Acutally means, is that I create an API for the panel.

If I'm understanding correctly that sounds similar to MVC implementations I've done in the past. You basically create a functional component (model) and a ui component (view) separately, then tie them together with a third component (controller,) yes? I like doing that, but have a hard time justifying the time it takes to implement the ui and controller components when they are essentially throw away code.

Instead of implementing a full-blown MVC architecture, lately I've been using a mediator loop between the ui and all the functional components. (I'll try to post a screenshot on Mon or Tues.) The mediator loop acts as the app's mailroom, receiving, filtering, and rerouting messages as appropriate. For the most part the mediator loop is a direct replacement for the controller component. The main difference is the mediator loop ties together the functional code and UI code on the UI's block diagram, instead of on its own (controller) block diagram. This obviously makes the functional code a dependency of the UI code, but since the UI is going to be thrown away it doesn't really matter. The nice thing about having a mediator loop is that it provides a natural seam to remove the UI and replace it with programmatic method calls.

TLB doesn't have a mediator loop though; the UI and functional code interact with each other directly. I'm having a hard time wrapping my head around exactly how hard it would be to convert an existing TLB app with UI to a pure headless TLB component. Maybe I'll understand it better when I have time to study LVx.

[Norm Kirchner]

but my fabulous search skills turned up zero.

Lava Search sucks

Can you give me a two sentence overview of what it does?

LVx provides a pipe into any LV program (LV EXE, Async Component, Subpanel VI, etc) for which a command can be sent and a response given.

If I'm understanding correctly that sounds similar to MVC implementations I've done in the past.

This isn't quite an MVC implementation because of the reasons you've highlighted
The basic idea is that you make a program. Which has both FP and BD which runs whatever functionality you desire. This can stand alone. But then you make an API to extend the functionality of that program (FP and BD). So in a sense, the M & the V are the FP and BD, and the C is the 'whatever else' that calls that API

So no components are really throw away, but at the same time, all parts are not fully modularized (can't take off the FP, but you can just not show it which gives the same feel)

So headless in LV world is a mis-normer
Any VI that is running has a Head.... it's just a matter of if you show it or not.

[Daklu]

The basic idea is that you make a program. Which has both FP and BD which runs whatever functionality you desire. This can stand alone. But then you make an API to extend the functionality of that program (FP and BD). So in a sense, the M & the V are the FP and BD, and the C is the 'whatever else' that calls that API.

Hmm... suppose your UI has a "Start" button. You're not using LVx to trigger a start by referencing the front panel control are you?

[Michael Aivaliotis]

Just want to give an update that we've moved this to the LAVA CR. That way, it's easier to do revision updates. And it gives better visibility.

Also, there is a new version. That was just posted.