MikaelH

GOOD NEWS this feature works on normal LVClasses made without the GDS tool. (Of cause I can't understand how you can work with classes without this tool ;-) The function also supports cloning one base class method to several child classes at once. So install the GDS tool, and just right click on the VI, and select GOOP->Clone VI... Cheers, Mikael

Your are right, and it's sooo annoying. I've talk to a NI guy about this and he recommended to use the auto tool selection. But I haven't become of friend of that yet. This is especially bad when my front panel is covered by a tab control, then I can't find an "empty" front panel place to do my shift-right click combination. This is something that really bugs me. :headbang: Do anybody know if there is a tweak to fix this? Cheers, Mikael

QUOTE (Aristos Queue @ Feb 3 2009, 12:08 PM) Hi I came across a new (for me) English word a couple or month ago when we went for a bush walk. It's "unCLAD", so after a 30 minutes walk we came to a beach with naked people then we understood the meaning of the new word. http://lavag.org/old_files/monthly_02_2009/post-941-1233637029.jpg' target="_blank"> Cheers, Mikael

HI Chris You can use the scripting function Select object and the Copy it and then past in a new CTL file. But the problem is that you are not allowed to copy an object from a running VI, so you have to first take that VI and do a file-copy/"save as" of it to a new name, open that VI and then you can Copy and Past in to a typedef CTL file. //Mikael

QUOTE (crelf @ Jan 24 2009, 01:28 AM) No, I don't know what the numbers are, but a single array could not be larger than 0.8G that's for sure. Regarding switch to a 64 bit Beta, I don't think I dare. Cheers, Mikael

I’ve gotten some answers from NI regarding my problem. First there is a known bug in LabVIEW that prevents the runtime engine to allocate as much memory as the development environment. Second problem is that I tried to allocate a big chuck of memory at once. If Windows can’t give LabVIEW a continuous bit of memory from the RAM with this size you get the “Out Of Memory” message. There are memory defragment program that can make it better. I tried to allocate many small chucks of memory than it works better, but still an executable can’t allocate as much as I can from the development environment. //Mikael

4G of RAM when running Vista 64 bit Everywhere you read it tells you that you can allocate 4G of RAM when running LabVIEW on Vista 64 bit OS. But I can’t get it working, on my VISTA-64 machine that has 8G of RAM installed. First thing I found is that when running a small memory hungry application in LV8.6 development environment it can allocate more memory compared when I run it as an executable. The “Size” value could be 32767 on Vista-64 in when running it from the development environment, but only 28623 when running it as an exe. Maybe why “Size” only could 32767 (2^16)/2 is a limitation of how big LabVIEW allows arrays to be. When using the value 32767, LabVIEW allocated 1.07 G of RAM, I can see this in the task Manager also. The Value 28623 corresponds to only 0.82G. Why can I only allocate 0.8 in one array in an executable? So if there where a limit of how big one Array could be, I copied the code above so 2 arrays of the same size should be allocated, that means 2.14 G of RAM. (I could actually only set the Size to 32729. before I got Out Of Memory) So I could only allocate 2G of RAM. So what am I doing wrong? The scariest thing is when I convert this second application into an executable. The application gets limited to 0.8G of RAM. I could only get the Size value up to 20300 which is 0.82G. Cheers, Mikael

QUOTE (crelf @ Jan 21 2009, 11:34 AM) NI Labs, that would be great. I believe it's stabile enough, I’ve used it for years without any major problems. Cheers, Mikael

Thanks, I'll try with some extra "Mass-Compile all". See if that does the trick. //Mikael

Hi I’ve created and Executable in 8.6 using lvlibs, and lots and classes. The executable works as it should. Then when I create an installer and run it after that, it complains that some VIs aren’t of the right version and can’t be loaded. (I need to run the installer to get the RunTime-engine installed on these computers). So what I have to do then is to copy all the files under the Build/EXE-file folder and paste them on the target PC’s c:\Program Files\MyApp folder. Have anybody exercised the same problem? I know there were a patch I had to use to get this working in 8.5, I had to update some VIs in the build-folder to get it working. It had some problems with lvlibs containing lvclasses. Cheers, Mikael

QUOTE (Jeff @ Dec 20 2008, 10:39 AM) Hi Jeff FYI the "cast to more specific" don't work in LVCLasses, it does work in the GOOP2 version of classes and is still in there to be backwards campatible. I used this function in the UML modeller when I cloned an object. I copied a Java design where you first call the Super.clone method that goes all the way down to the "root" Object-class that everything inherits from in Java. Then when that method return a new cloned object, I type cast it to more specific and then add "my stuff to it" and then let the sub classes do the same thing. Cheers, Mikael

When saving to file I normally save it as binary, like this. If I stick to SGL it takes less then 500ms on my computer, for DBL it takes a minute. When I need to save this is a database, I first ask my self do I need to search through the data or use any powerful calculations functions the database can offer. If you need these functions, you have to save it as normal float values. But if you only need to store it somewhere I would suggest only save the path in the database and then place the binary file on a file server. Otherwise you can use a binary column type. Cheers, Mikael

Try this example: C:\Program Files\National Instruments\LabVIEW 8.5\examples\picture3d\robot arm\RobotArm.llb\RobotArm.vi //Mikael

...but which implementation executes fastest?!? I just had to try this. So I made a quick calculation VI with 3 different implementations, as show in the picture. You would think that LabVIEW would optimize the code and execute in almost the same way, but there is a time difference in all three implementations. The answer was the Formula Node :-) Cheers, Mikael

I use Class Attributes from time to time. The definition if of cause that this data is shared between all objects of the same type. If you e.g. have a common TCP/IP server all objects should communicate with, it's good to save the IP-address here. If you need to change the IP-address in the middle of the execution you just change it in one place instead of changing all objects. On thing I often use it for, is to save a references of all created objects in. Then I can create a ClassMethod (Static) that can return reference to a particular object type. Static Method: GetInstrumentByType Statis Attributes: InstrumentsName & InstrumentsRef But to get this working you have to use the Class Attributes in a special way. The class attribute of a VdLabelPrinter objects will not have anything in common a VdDigitalContoler object. So I can't really use a Static method GetInstrumentByType, from the Base class VdTestInstrument to get these objects. So I have to store the references to all objects in a Class Attribute that is Common for all created objects that is derived from the VdTestInstrument base class. If you lock and unlock the class attributes without wiring a reference in to the VI (Reference value=0), you can save class attributes in a memory that isn't aware of any derived classes. So you actually have 2 different class attributes to store data in. 1) If you wire the lvclass wire into the lock attribute, you will get a unique shared memory for a objects of that type. 2) If you don't wire the reference into the lock attribute, you will get a unique shared memory that you can access between all classes that derives from this class. Cheers, Mikael

QUOTE (Nanxiong Zhang @ Nov 20 2008, 11:53 AM) 8.5 //mikael

Try this: Cheers, Mikael

QUOTE (pikro @ Nov 11 2008, 10:43 PM) The Alt+F4 will close/hide the front panel, and that should normally unload the VI from memory, but as you say Aristos Queue, the VI must have an open reference to itself. I always use the filter "Panel Close?" event, and always discard this event, and then gracfully close down everything. The last thing I do is to call the EXIT LabVIEW function (only if the App.kind=RunTime), this will close and unload all runing VIs. Cheers, Mikael

What Reentrant settings are you using for the VI? Also try to remove the Allow debugging. //Mikael

When comparing two float values you have to use this VI: ... but unfortunate this VI don't exists ;-) I have a VI looking like this to solve the problem: Cheers, Mikael

QUOTE (Norm Kirchner @ Oct 14 2008, 05:50 AM) ...and then this "Reentrant FP Window Holder" -VI only contains one big SubPanel, that is set to "Fit control to Pane". //Mikael

QUOTE (Norm Kirchner @ Oct 14 2008, 04:07 AM) Awesome pictures, Norm! Take care, Mikael

I normally just use a Tab control and ONE Next button and ONE Back button that I place on top of the Tab control, not inside any page. Like this. Cheers, Mikael

Try something like this. Cheers, Mikael

Hi Niklas This is a perfect opportunity to use an OO approach. I did a simple "Creature in a maze" solution that you can download from here if you are interested. http://goop.endevo.net/GDS/MaceGame.zip (These classes needs a class template that you can get by running the installer below) http://goop.endevo.net/GDS/OpenGoop_Installer_03.zipThere is also a debug video that shows how to debug the objects using GDS here: http://goop.endevo.net/GDS/videos/GDS_Debug.swf.html Lycka till, Cheers, Mikael