Ed Dickens

You're right, it's not a big deal because the workaround is easy as you stated. And that is what I ended up doing.

How did I run across it?

I had a few charts on the panel that after the application was stopped, I wanted to turn on the captions over the chart to act like a dialog to show the status of the test.

I

I

Interesting

Changing either constant to a control makes it work correctly. It also works correctly in 7.0 and 6.1 with both values being constants.

Ed

Greetz All,

Last week, I was in on a discussion on the Developer Exchange concerning a bug in the Filter Events. The entire thread with examples can be read at the link below.

Filter Event Bug Thread

The basics of it is this. If you are using a filter event to modify some data, you shouldn't operate on that data in the filter event case unless you want to use the modified data. It seems that when you write to the filter event terminal on the right side of the structure, it modifies the data that gets operated on in memory even though execution highlighting, probes and front panel indicators display the unfiltered data.

So using the attached example with execution highlighting on, right click on the front panel to fire the Mouse Down? event and generate a '2' for the button value. Watch the diagram and you see the left hand Button terminal generate a 2. The 2 is wired to the equal function along with a constant 2, they are compared and the Equal generates a False.

An NI App Eng checked into it and has verified it as a bug. He said memory space is being shared where it shouldn't be. The workaround for now is to force the writing to the right Button terminal until after you have operated on the original value.

This bug has actually been in the filter events since the event structure was released in LabVIEW 6.1

Ed

Download File:post-47-1096290206.vi

Ed,

Is the element First Call? in the palette Advanced->Synchronisation not what you were looking for?

Didier

1606[/snapback]

The First Call? function by itself can't fire an event. You'd either have to write to a Value Signaling property node or have a Case Structure around your Event Structure to catch the First Call? value. I've used both in the past, but the Dynamic Events is much cleaner in my opinion. You end up with just a While Loop with an Event Structure and just a single VI outside the loop.

Plus, if you need to run your init code again, you just need to fire the First Call user event.

Ed

I know all of these features can be accomplished registering a dynamic event and triggering a user event for them, but it would be nice not to have add all that extra code since these are two things that almost every application needs.

1600[/snapback]

So the dynamic events sounded promising to me after I said it, so I made up an example of how it would work.

The sub-vi on the left creates and registers the dynamic events. It also can fire the first Run event so it will run right away. The Trigger Error sub-vi watches the error cluster and will fire the error user event when ti sees one. Pushing the code into sub-vis cleaned up the diagram a lot and saves space. (until NI adds these events natively to the event structure )

I've attached the example library if your interested.

Ed

Download File:post-47-1094056528.llb

I think two needed events for the <This VI> Event Source are First Run, and Error Handler.

The First Run could be used for any initialization code you need to do. I've faked this function by wiring a Select function to the Timeout terminal with a 0 and -1 and when the While loop iteration terninal equals 0, it passes in the 0 so it times outs right away, then on the next iteration, it passes in the -1 so it never times out. Of course, if you don't need the Timeout feature for some other reason, you'd need to add a Case structure in the Timeout event case to run different code when the loop count does not equal 0.

The Error Handler event would watch a single error cluster and if it contains an error, that case would run any error handling code that have.

I know all of these features can be accomplished registering a dynamic event and triggering a user event for them, but it would be nice not to have add all that extra code since these are two things that almost every application needs.

Ed

Ed, here (attached) is a spec file that will package NI's PID Control Toolkit, if its installed.

This won't work with the current release of the OpenG Package Builder, since the package builder does not allow pathroots in the Source Directory of a File Group.  I will re-release a new version of the OGPI that does support this feature, so that the ni_control.spec file will build correctly.

I can work with you to create spec files for all the toolkits, which will allow you to create your own OpenG Packages, from the installed toolkits.  You can, oviously, only distribute the OpenG Packages inside your organization, insofar as you have appropriate software licenses for the toolkits.

Regards,

-Jim

1282[/snapback]

The idea I had for doing this would work like this.

You install the tool normally into the oldest version of LabVIEW that the tools supports. Then run the tool and it would copy all the needed files to whatever other versions of LabVIEW you specify.

This would allow you to build the tools and distribute them without worrying about licensing since whoever uses it wold have to have the tools to start with.

I actually did this with the older versions of the RGTK and the PID toolkits, but they do not work with the latest versions.

Ed

Added ver. 3.1 of the Sound and Vibration Toolkit to the document.

Ed

Download File:post-14-1086360927.rtf

This seems like something that should be easy to do.

I just received the latest Control Edition Developer Suite. The normal process for getting the latest versions of the toolkits installed is a real hassle. Most of them won

While checking to see if the 7.0 bug I found with this VI was fixed in 7.1, I ran across an odd behavior that wasn't there in 7.0. (That bug was fixed)

When configuring the VI, if you select either Number or Boolean in the Variable Properties before typing anything the Text with Variables box, the first character you type will switch the Variable Properties back to Text. Subsequent variables entered will not change the Variable Properties back to Text.

I don

I also sent this to NI support and it's a known issue that should be fixed in 7.1.

The current workaround is to do what I described above.

Ed

I've just run across a possible bug in the Build Text Express VI.

Drop the VI and at first configure an input to accept a numeric by selecting Number under the Variables Properties section, and check the