[Discuss] TLB - Top-Level Baseline

[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 September 23, 2010 by mprim

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

[PeterB]

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.

...... 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 .

Hi Norm,

after reading as much as I can here on LAVA and from last year's NI Week presentation on the JKI vs TLB SMs, I appreciate and would like to thank you all the work you have been doing on the TLB and LVx up until now.

I work at ResMed where I've been championing LabVIEW now for 8.5 years. I've actually been using and loving LV since '94 to be precise. For my last major project I used ExpressionFlow's QSM. A colleague and I at ResMed are having our own little head to head as we standardise on a State Machine architecture which satisfies many interesting and competing requirements.

My colleague has already warmed to the JKI SM to support his own template efforts to date however I am really keen to put forth the TLB + LVx as a worthy contender. If necessary I will teach myself how to use LVx should your examples/documentation not be ready, BUT just in case your efforts to remove that black mark are close to being finished I thought I'd first check here with you. Any ETA you have in mind ? Don't worry I won't hold you to it.

In the mean time I'm struggling to find the latest posted version of LVx. This version of LVx is dated Feb 2008 - like 3.3 years ago now !!! Do I also need to request some behind the scenes, off-the-record , skunk-works release of LVx as you offered Dave ?

happy wire working.

regards

Peter

[Norm Kirchner]

Peter,

It's great to hear from you.

LVx has finally hit puberty and is ready to come out, but now as REx (Remote Exports)

I have a version of TLB created that gives a TLB w/ the REx core constructs built in as well.

I'm fighting the build process on VIPM for a few other work related things.

I'm putting a reminder on my calendar for 2 weeks out (vacation inbetween) to reply to this post w/ the version of REx and it's dependencies that I have along w/ some video.

Thanks for seeing the value in all of this and hope to hear from you soon

~,~

Norman Kirchner

[Val Brown]

Norm,

FWIW, I'd like to hear about this as well as (kudos to JKI for all the wonderful work, truly!) I really don't want to have to deal with OpenG or VIPM, if it's possible; and I really liked what I heard during NI Week.

Have a great vacation! And I hope to see you i Austin again this year.

val

[PeterB]

Hi Norm,

that is great news. Thanks for following up on this and I look forward to what you can provide in a couple of weeks' time.

[lideyouhit]

I like it

[Fab]

Do we have the latest TLB version with REx?

[__Karol]

Could you explain me, why in 'Create New TLB' diagram you make a 'Creating' state instead of just simply use inside the case 'Create new' action 'Build New TLB'? I think that final effect would be the same.

What determined if we need to create new state instead of add new system trigger inside 'Idle' state?