MikaelH

I compared my project file after first save, and after opening it again (LabVIEW says "An attribute of the project was changed"),and resaving it.

But the lvproject files are identical. LabVIEW removes the start in the project tree window title, but no changes were made to the project file. I guess that means it has some stuff only in memory and not saved in the file. But what?

-Mikael

The only comment I have to the picture is:

"And NI says it's easy to customize a userinterface in LabVIEW for TestStand".

//Mikael

Hi Jim

I saw the same problem yesterday (using 8.5).

No VI had any changes, only the project-file.

I saved it closed and reopened it and the project had changes in it again.

It said property in lvproj-file had been modified.

But I didn't to a diff on the xml file, I might do that to investigate a bit more why it occurred.

When I check out a project from Version Control, the fist thing I check is that there are no changes in any VIs/project before I start, so I don't like this behavior at all.

//Mikael

This is not a bug, just a change of how the Copy function works.

The Copy function don't support files in the LLB any more.

Does that mean that LLB's soon are unsupported

I got quite when my application stopped working when I recompiled it to 8.5

//Mikael

And don't forget to close the Event with "Unregister for Events" outside the lower while loop

//Mikael

What I can see, is that your STOP-function could run before you "Write To Measurement File" node has been executed.

Place the 2 actions in e.g. Flat Sequence structure.

Or as I would do it, through out all Express VIs and create a nice state machine

Cheers,

Mikael

QUOTE(Paul_at_Lowell @ Sep 22 2007, 03:41 AM)

By the way, I don't really need the child classes at this point, since the functionality is the same for each door. (This may change.) For the moment I just have to create multiple instantiations of the VentilationDoor class, where each instantiation has a path to its own shared variable library, etc.

I often use an Abstract Base Class and almost always implement a Simulated_X Child, I.e. SimulatedDoor.

This class could have a UI to show the door status. You could have one UI per object or one UI for all Simulated Door objects.

//Mikael

I don't realy understand how you want the toggle switch to work.

But you can always customize a Slide control like this:

Download File:post-941-1190687238.vi

//Mikael

Hi

We've done some updates that will be released in the next version, which is going through the last tests right now.

I suggest you try to run it again and wait a loooooong time for it to finish.

When a child class method, gets updated with a "Call Parent Method", LabVIEW some how takes looooong time to do this.

I ran a major application through this conversion and it took 63 hours to complete.

This VI was one of the hardest to create in GDS since LabVIEW crashed so many time, just by doing things in the wrong order.

Regarding the Save and Close-state, it just runs through a large array of VI refs and class refs and saves them and then closes them.

This could take some time for LabVIEW also, but the application don't have a while loop or simulare where it could get caught.

Cheers,

Mikael

QUOTE(Jim Kring @ Sep 20 2007, 09:29 AM)

It would be GREAT if the Endevo GDS had an option similar to the "Override" option (when creating a new method), but was able to copy from siblings, as opposed to just the ancestor classes.

I know exactly what you mean, since I've needed that function as well. And if I need it I add IT, so just give me some time....

Right now I'm finishing up the 2.0 version and had a release candiadate 2 days ago, but when testing a function in 8.5 it didn't work...

So upgrading from 821 to 85 isn't always a simple mass compile action

I hope we can open a "New features" forum were we can rate them, so I know what features to start with.

//Mikael

I have always wondered about this behavior, but just accepted it.

If you do this by the invoke nodes VI:Save.Instrument and select “Save a Copy=True” the master VI don’t get changed.

Nice thing is that the new cloned VI gets disconnected from the class. So it will not modify your class automatically, instead you have to add it as a second step where ever you want it.

You're using the right property node!

Try taking the working graph in your Toy Example, and copy the graph and replace it with the one in your main application.

//Mikael

Hi

I got the same bug in one of mine VIs.

See VI Property: Allow debugging, My VI don't work if I turn off the debug option

Check for data coercion dots in your sub VI, and typecast them manually, that might do the trick.

//Mikael

QUOTE(crelf @ Sep 12 2007, 07:58 AM)

Winters are a little milder in Sydney as opposed to Sweden

Yes your absolutely right there !!

Finally the spring is here, we had 28°C a couple of weeks ago, and the week after we experienced -2 and snow.

(It might be because we went 5 hours South-West from Sydney up to the snowy mountains)

QUOTE(Harish @ Sep 5 2007, 09:55 PM)

Hi,

Can some one help me with some examples of performing serial communication classes using GOOP?

I am new to GOOP, and want to perform some basic read / write functions using classes and objects.

Thanks in advance!

Harish K

Here's an undocumented GOOP class I've used in the past (just upgraded it to 821-lvoop style, and haven't tested it).

You need the _goop3.llb in your addons-folder.

(you can get it through the GDS tool).

Download File:post-941-1189566714.zip

Cheers,

Mikael

Welcome Colleague

I guess you won't see me at the office that much since I took Chris Relfs position at NVSI in Sydney.

But I still work for Endevo in the evenings, nights and weekends

Cheers,

Mikael

Thanks,

//Mikael

I have an old VI I haven't touched for ages, but suddenly it gave me wrong result.

Try the attached VI, and run it and look at the PictureOut indicator.

Now change the VI property: Allow debugging to OFF, and run it again.

The PictureOut's result changes.

Have I done something wrong?!?

You have to excuse me for the nasty code behind this VI, it's an old one.

Download File:post-941-1189392546.vi

The behavior is the same in 8.2.1

Cheers,

Mikael

Funny you should mention this, because I was just thinking of creating an application like that, and then do the "tray icon" part as a .net Class library.

You can then create the "Icon tray" object set its properties/icons and then when a user interacts with the system tray icon the .net part fires call backs to LabVIEW.

I've done a similar project before and the callback works great.

If I have time to finish the code I'll post it here.

//Mikael

The front panel grid works fine but I would like to see the Microsofts Visual Studio approach some day.

It shows you help lines when you reached edges of other objects like this picture.

http://forums.lavag.org/index.php?act=attach&type=post&id=6808

--Mikael--

But if you place the List Box Value event after the Numeric Value event it should probably work?!?!

I guess it's depending on the speed of your computer if it has time to do the event numeric change before the list box value change.

I put a small timeout in the example and got the "wrong" behaviour, and then I just rearranged the events and it worked again.

Cheers,

Mikael

This is a known problem in LabVIEW 82(1).

I've had to live with it until NOW when 8.5 is out.

You can ignore the rename problem unless you try to load these VIs/Controls dynamically.

But you have to build it in debug mode.

What happens in the process is that some VIs have been saved without block diagram, and then a VI needs to be renamed, that works fine, but now a VI that already was saved without block diagram has to be recompiled, and it can't handle that.

There are still issues with one of my large projects that I have had these problems in, even for LabVIEW 8.5 but it works better.

If you still like to use 821, build it with debug-flag on, and then manually remove the block diagram of all class VIs and VIs inside the exe-file.

You can extract the llb from the exe file by removing the header in the exe-file until you get to the word "RSRC", this is where the llb starts.

Extract it, remove the block diagrams and then put it back in the exe file.

-Mikael

QUOTE(Aristos Queue @ Aug 23 2007, 11:38 PM)

http://en.wikipedia.org/wiki/AVL_tree''>http://en.wikipedia.org/wiki/AVL_tree' target="_blank">http://en.wikipedia.org/wiki/AVL_tree

PS: This may be a situation that your UML tool should be aware of ... Class A may have a control of class Parent in its private data, but it may use an even lower Child class as the default value of that control. I don't know if you care to highlight such a situation in the UML, but it is a relationship that LV has to track in order to know to load the child class into memory whenever Class A loads.

The default values is visualized like this:

MyAttribut:int=23

MyObject:BaseClass=LeafClass

But the UML modeller don't look at the default values right now.

When it comes to the default values for a referenced based class, these default values should be wired up in the Create/Constuct-method.

You could still add the equal sign in your design when generating code, but when you do a reverse engineering those will be overwritten.

-Mikael

QUOTE(Aristos Queue @ Aug 23 2007, 01:56 PM)

why the *empty* Sequence Structure is labeled "Do not delete". ;-)

http://forums.lavag.org/index.php?act=attach&type=post&id=6723

That's a tricky one, I guess it has to do something with garbage collection.

Here is how it looks if you analyse it with a LabVIEW based UML Modeller ;-)

http://forums.lavag.org/index.php?act=attach&type=post&id=6725

BTW, how do you set the default data to a leaf Node in the Map class attribute named Root which is a Map Node Object?

Cheers, Mikael

QUOTE(Jim Kring @ Aug 23 2007, 08:19 AM)

Is there an equivalent to "<LabVIEW 8.5>\vi.lib\utility\LVClass\Get LV Class Default Value.vi" in 8.2?

I tried down-saving this VI from 8.5 to 8.2 and it complains that the function doesn't exist in the shared library (LabVIEW.exe).

I have tried using the "LVClass.Open" function, in conjunction with the LVClassLibrary.DefaultInstance() method, but the "LVClass.Open" function fails (error 53: Manager call not supported) in a built executable (dispite the fact that the help docs claim that this method works in the run-time engine).

Thanks,

What I thought was that the new 8.5 VI "Get LV Class Default Value.vi" is just the 2 VIs you mentioned wired together.

I use it like that in 821, but haven't tried it in an executable.

BTW I like the new "Get LV Class Path.vi" found in 8.5 in the same folder :thumbup:

//Mikael