Kurt Friday
-
Posts
253 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Kurt Friday
-
-
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)
Kurt, I just started checking out the option of making IO classes with some inherited classes and the DataIO class definitely looks like a potential base for examination.:thumbup:
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:
-
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
-
Ok.... attached is my first try at using this OOP stuff.... can some of you look at it and tell me what i am doing wrong , this is based on hardware so you really wont be able to run it , but , you should get the idea.... it still needs lots of work , but , i figured i better stop now before i get too far into it and figure out that its all wrong...
dont be too harsh
Dan
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.
-
Do you include the virtual table for backward compatability (code upgraded from 7.1.1).
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
-
Cute
So when will we see your rendition Mike, or should I say "Ken"?
-
I tried the trick with "Tools -> Update Virtuals" with the result that now ALL virtual methods return Error 1031
EDIT: Just found the problem: on the parent class I modified the error in to "recomended", but not on the child class
.I think there probably should be a warning in the documentation cautioning the user that the interface between parent and child methods must be the same. As the developer who knows it inside and out I can sometimes overlook some of the pitfalls that I naturally assume and take for granted. I am working on making GOOP Developer a more user friendly product and also putting work into the GOOP Template, any feedback or ideas is most welcome.
-
It's more or less what I did, except that I manually click-and-draged each virtual methods conpane to its vi-ref "This VI's Type". But somehow it didn't worked... or should I have dragged highest level conpane to all its children methods "This VI's Type"?
The "Update Virtuals" utility will save you from manually moving the con pane into "This VI's Type" except if you are working in 6.1 where the scripting operations are not available. I wouldn't drag the base class con pane into all children's "This VI's Type", it's too much work and I'm not sure what the consequences may be, I haven't tested that scenario.
-
Hi Didier
At the moment there is no procedure within GOOP Developer that will auto generate the controls and indicators on an existing child to match the parent, however there are a couple of techniques.
When you modify a control on the parent, go through and make the same changes to the children, ie copy the control over and connect it to the con pane to match the parent, then right click on the parent class and select Tools -> Update Virtuals. This will update every virtual methods "This VI's Type" which updates the CBRN in the Descendant implementation so that the interface between parent and child methods are consistent.
Another technique would be to copy the Self implementation code for every child into an empty vi, then delete every child and then re-create them by sending the parent method to all children, and then copy paste the Self implementation code back into every child.
If it's an issue for users then I can look at some scripting voodoo that will update all child virtuals of a parent virtual if it's interface changes, I don't think this will be difficult. GOOP Developer could initiate an integrity check when a virtual method is saved and if there are modifications then it will prompt the user if they want GOOP Developer to automatically propagate the changes to the child methods.
I'm collecting an issues and feature request list to incorporate into the next build, so please let me know if there is anything which is frustrating you or would make life easier, or if you have an idea for a feature.
-
Hey bsvingen
Nice work, very cool. I'll have a play with this and give you some feedback, the drop in execution time is quite impressive.
-
Thanks for the reply.
You're right as to how I was going about it. I got about halfway thorugh this and figured I wasn't going about it the right way. Something just seemed off.
I have been looking at the tutorials, but have been having a hard time absorbing it. I seem to be having a bout of temporary 2-week ADD or something... nothing seems to be sinking in.
I've since deleted this little project and am trying another route. I'm going to look at the DataIO tutorial again. I've actually read the manual (something I never do I might add), but I'll need to go through it again now that I'm fully awake.
If anything is unclear in the tutorials, or you are just saying to yourself "What the hell is he on about" then just let me know, I'll moddify the documentation for the next point release and hopefully explain it better. Also if you feel that something was missed and you would like to see more tutorials or examples then again I'm happy to do so. The best way to tackle the tutorials is to just go through them step by step with GOOP Developer and hopefully it will all start to gel.
Non linear curve fit
in LabVIEW General
Posted
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?