Lars-Göran

Name: CLL Dialog

File Submitter: Lars-Göran

File Submitted: 03 Jul 2009

File Category: User Interface

LabVIEW Version: 7.1

Version: 1.0.1

License Type: Creative Commons Attribution 3.0

Potentially make this available on the VI Package Network?: Undecided

Copyright © 2006

All rights reserved.

Author:

Lars-Göran Andersson

--see readme file for contact information

Description:

This library gives similar functionality as Three Button Dialog.vi but with some extra goodies.

It doesn't strictly conform to the guidlines for a dialog box, instead it shows my personal preferences.

CLL (Common LabVIEW Library) is my way of tagging VIs that have made it into my library of reusable code.

Version History:

1.0.0:

Initial release of the code

1.0.1:

Added version info to the description of CLL Dialog.vi

Changed some default values for TEST CLL Dialog.vi

Click here to download this file

Hi!

Just want to give a link to some code I added a couple of years ago in the Code Repository: CLL Dialog.zip

I don't want to join the contest, but maybe the code is worth a look anyway.

/Lars-Göran

QUOTE(MATTW @ Nov 14 2007, 05:10 PM)

I hadn't thought of continuously generating internal triggers. I'm not sure if this would work but you could ignore the internal queue entirely, and send the internal triggers to the external queue. Personally I like the concept of iterations since it seems to makes timing data acquisition used by the statechart easier.

I meant that each trigger would have it's own cluster (or none), and states that trigger off of that it would have access to that cluster. Much like NewVal in the event structure for a value change event, which only turns into a variant if there's multiple controls with incompatible types.

Matt W

Interesting idea, ignoring the internal queue altogether and instead use an external queue for both kind of triggers. I will try this out.

I'll also have to check out the NewVal functionality you describe.

Lars-Göran

QUOTE(MATTW @ Nov 13 2007, 07:38 PM)

You lose the use of the inputs and outputs of the statechart (which I've found useful). And there's an easier solution, just use a synchronous statechart with your own queue of data inputs and trigger. I posted a very trivial example on ni's forum.

http://forums.ni.com/ni/board/message?boar...ssage.id=280719

This still requires a while loop, but if you embed it in a subvi you effectively have the same thing. I found the concept of iterations to be helpful once I started using the inputs and outputs of the statechart.

This would be easier if trigger's had built in (and typed) way to pass parameter's with the trigger. Which is a feature that needs to added in my opinion (and can be added onto the current statechart models). Currently I can either use a variant (losing static type checking) or a large cluster (wasting memory).

Matt W

Hi Matt!

I think there's one problem with your solution. If a statechart continously generates internal triggers, your external trigger will never have the chance to get into the statechart.

What I would like, is to have the InternalQueue exposed to the ouside of the statechart, so that external and internal triggers are handled on equal terms.

(The queue then of course isn't internal anymore, so perhaps it should be renamed to "TriggerQueue").

As mentioned before, we will then also have the benefit of rendering the loop around the statechart superfluous.

And as you pointed out, if we could get triggers to carry data along, that would be great. I think I would prefer a variant instead of a cluster, to avoid sending data that is not of relevance for a specific trigger.

Lars-Göran

Hi all!

I have tried to come to terms with the statechart implementation in the Statechart Module, but I miss the option of running a statechart without the notion of iterations. I have experimented with sending external triggers along with variant data via a queue to the internal of the statechart. Here it is dequeued in a dedicated state, where the trigger is sent to the internal queue and the variant is converted to data and put into its place in StateData.

Benefits of this model:

- The statechart will run (without being in a loop) until an exit trigger is generated internally or received from the outside of the statechart. This is more like the original statechart concept.

- You can send specific data along each external trigger.

- You avoid this situation: When an asynchronous Run Statechart is waiting for a trigger, it has already read its Inputs making it impossible to send data at the same time as the trigger is generated.

The model above seems to work, but wouldn't it be nice if this third statechart type (aside from syncronous and asyncronous) with its trigger/variant queue was built-in?

If I don't get any serious objection to this idea, I will post it in the Wish List.

Lars-Göran

Perhaps I should rephrase the question: does anyone who's not bound by the legal issues of the beta program any info?

//Lars-Göran

Anyone having knowledge/gossip of the LabVIEW Statechart Module?

NI made an invitation to a 1.0 Beta Program for this in april 2007.

//Lars-Göran