Kurt Friday

Awsome I look forward to seeing it

QUOTE(bbean @ Mar 24 2007, 06:41 AM) I had toyed with a virtual method, and the super messaging examples, however since I used the variant config vi's they initialize all of the data members so I had to call read persist before I set the DataIO object in the Pump object, hence this operation had to be performed even before the object was created, virtuals need the object to be created first. Also in the case of an active object you want the data members initialized before you launch the process. In its present form if you were to make a new child a persist method would be automatically created that will be able to handle the child datamembers, so making it virtual is not neccessary. Enjoy your holiday, I just came back from a couple of days in the sun north of Sydney, was brilliant.

You can download the demo from. http://www.sciware.com.au/goopdeveloper/Dy...PersistDemo.rar The demo dynamically instantiates DataIO and Pump objects and passes the creators a persist file, you simply configure the system from a central ini file describing what type of DataIO child you want and the same with the Pump. This is a really nice demo of persistence and a great way to achieve a plugin architecture, with this kind of architecture you would simply drop your new child objects in, configure your central ini and create default persist files. As I mentioned the persistence uses the OpenG variant config VIs which worked very well and saved a heap of coding, the only issue I came across is that when persisting the Pump object datamembers which contains a DataIO object I had to clear the DataIO obj, I'm not sure why yet and I'll investigate this further. I think persistence should be worked into the template, probably embedded into the mechanics of the object so that it is a native feature that the user can just enable, I'll have to think of a cool way to do it. Have fun

I'm doing up a very interesting demo they implements persistence and allows dynamic loading of children, Its looking good but is a couple of hours away. the persistence is based on the OpenG Variant Configuration File package and works very nicely. I took the forums down for a while until I can protect it from spammers, they make my blood boil.

Hi bbean There are several ways of persisting object data, the super messaging example is a great way for persisting object data where there is an object hierarchy, but its more of an example of super messaging than persisting data. One of the things I really like about ini files is that they are very readable and you can be selective about the attributes that you persist, not every member should be persisted. A couple of alternative methods of persisting data would be. 1) Use the OpenG Variant Configuration File package to write or read your data members, everything will be persisted though. the ini file format is very readable. 2) Write the data member cluster to an XML file, this is readable to a degree but everything will be persisted. 3) Cast the the data member cluster to a string and write to a binary file, non readable form unless you know the type of your data member which could change, ie add an attribute and suddenly you cant read the data members. I would avoid this technique, its quick and dirty To enable initializing your data members from file simply use one of the above inserted in the create between the default members and the Object.New. The file path to the persist file should be added to the data members so that it is available when you persist the data in the Destroy. I'm currently doing up some demo code for you but time hasn't permitted me to get it out today, but stay tuned and I'll pop something up here tomorrow that should help you out.

I took a look at you code but it isn't easy to follow. I ran it and it produced the reported error which is due to the Lev Mar Curve Fit being unable to calculate a covariance, I'm not sure why though. What I would strongly suggest is that you check that your curve fit model is correct and that the data that you are trying to fit it to is appropriate. Generate data that fits your model and see if that works, also check your initial coefficients, are they appropriate?

There are several subvi's missing Spectrum model.vi Quadradic substract.vi Noise figure to V.vi Noise from KeV to V.vi Post them up and we can take a look at it

Oops I didn't update the GOOP Templates in 2.0.4 to Ver1 Rev2, I've updated and re-uploaded, if you have downloaded GOOP Developer 2.0.4 then please re-download it. Apologies for any inconvenience.

Hi Thang You are right it is confusing because I forgot to add the destructors for the Store and DataIO objects in the SimpleLogger.Destroy, I think this must have crept in when I did a major re-write of the examples when the GOOP Template changed significantly. Thanks for finding this and sorry for the confusion, to correct this you just need to edit the SimpleLogger.Destroy to look like the following. Note you need to use the Virtual Destroys. http://forums.lavag.org/index.php?act=attach&type=post&id=5090 Did you get my PM with my e-mail address so I can give you the details of the FTP account I setup for you so I can review code that you need assistance with?

QUOTE(yen @ Mar 2 2007, 02:38 AM) Cool, glad you like it, it's powerful stuff. I used a variant of the DataIO class a while ago to make a logging system for a WW2 era sea plane that was being re-commissioned. By making children of the DataIO class I was able to make a logging system that could acquire data from GPS, the engine management system, gyros, digital inputs, analog inputs etc. All I had to do to get the data was call DataIO.Read on the children. Adding new hardware into the system was easy, all I had to do is make a new child or sibling that could handle it, the application never needed to change.

Hi Thang I think the best way for me to help you is if I were able to view your code and make some suggestions, or even assist you to some degree. From the image you posted it looks like there is some confusion in how to implement inheritance, it appears that you have just created a parent class and then wired an enum into it to tell it what its behavior is. I have set you up with a FTP account on my site so if you wish you can zip up your project and send it up, I'll then take a look at what you have done and help you out. I'll send you a personal message with my e-mail address so you can contact me and I can send you the details of how to access the FTP account.

Actually it looks like code generated from the open source GOOP Template using GOOP Developer, the mention of the DataIO class strongly suggests this. If so then I'm happy to help, looks like you are having some difficulty with inheritance that I may be able to help you with.

The issue may not be your code but the input data, can you post the vi with minimal default data that demonstrates the issue.

Chris I love your sense of humor mate, you help make LAVA not only a source of wisdom but also a fun place. Cheers :beer:

I'm a happy little Vegemite. Vegemite puts hair on your chest, Marmite puts a mince in your step.

Jim, you are a wizard That's really cool, you have solved an issue I hit when I was playing with merging the two, I couldn't run a parent method on a child just to operate on parent data, unless you used dynamic dispatching. I've had an initial play with your solution and it looks elegant, I'm going to have a deeper look this weekend and play with your ideas. This is going to be fun. I'm still investigating what is involved in getting GOOP Developer to work with such a GOOP Template, the only hurdle is that scripting isn't exposed in 8.2, however where there is a will there is a way.

I havent tested that yet, I'll get back to you on that.

Hi Jimi I'm currently working on a GOOP framework that merges the existing Open Source GOOP Template and LVOOP to provide a by ref implementation. You have no doubt seen the code I posted. Merging-LVOOP-and-the-Open-Source-GOOP-Template If you are interested in dynamic destructors then the current model implements them, take a look at the plugin demo, although I haven't placed any cleanup code in the child destructors you can see how it would be done.

Unfortunately my comical existence only extends to 2 dimensions, the real tragedy is that the beer here is a bit flat.

I've done up another demo that incorporates active objects, inheritance and uses a plugin architecture. This demo is again built from one of the GOOP Developer tutorials where a DataSource object and a DataStore object plugin to a Logger active object. The DataSource class has two children, DataSource.Sine and DataSource.Square which simulate Sine and Square waveforms respectively. The DataStore class has two children, DataStore.Spreadsheet, which enables writing data to a spreadsheet file and DataStore.Binary, which enables writing data to a binary file. The Logger class simply reads the DataSource object and sends it to the DataStore object at the desired rate. So far the merging of LVOOP and the Open Source GOOP Template is looking promising, any feedback would be great, hopefully not too far away will be a very cool by reference implementation of LVOOP. The code is 6 Mb so I wont post it up here but you can download it from www.sciware.com.au/LVOOPGOOP/

Hi Dan Just had a quick look and the first issue I noticed is that you need to use a shift register to hold your object ie just like you are using the shift register for the error cluster. LV classes are by value and not by reference, just treat them as you would if you were using an ordinary cluster.

At the moment the demo code is just a proof of concept, in the final GOOP Template for 8.2 that supports LVOOP there will be no virtual table, a lot of the inner mechanics will be stripped away.

Cool, glad you like it. I'll post up a few more demos soon, one demonstrating active objects would be interesting. At the moment I'm manually editing the existing demos described in the GOOP Developer Tutorial, but what I'll be working on very shortly is how to auto generate the code, which will be both challenging and fun. I'll keep everyone updated with how I'm progressing with that.

Hi Everyone I've been tinkering with LVOOP and playing with ways to merge LVOOP and the Open Source GOOP Template. It actually hasn't turned out too difficult to take some existing demo classes built using GOOP Developer and edit them so that they use the LabVIEW class datatype. The immediate benefit of this is that dynamic dispatching (or virtual methods) are automatically handled, no more registering virtual methods. The next step is to start investigating how to get GOOP Developer to auto generate the classes and also build children, I'm just starting to look at the scripting options and I'm sure its possible. Demo code attached Download File:post-1058-1162936616.zip

Cute So when will we see your rendition Mike, or should I say "Ken"?