Kurt Friday

Congratulations Mike, Tomi and Jim on some truly beautiful work

Nice answer Tomi

One way that I force the front panel to be included in the build without having to manually specify it in the build config is to include a property node in the desired vi to return a control name, take a look at the process code for an active object.

Another way of passing the object arround without having to pass through front panels is to use named object instances, you just get the object by name inside your desired subpanel vi.

Please tell your friend that they are always welcome to contact me for support, I am more than happy to help. It sounds like an interesting application as well.

QUOTE(Thang Nguyen @ May 1 2007, 06:20 AM)

Hi,

Could you please tell me how to work with timer if we use GOOP? For example, I want to run a pump for 5 sec. At the same time I have to do data acquisition. I have a process VI run at the behind to read data already. But I don't know how should I work with the timer, what is the best template for this case?

Should I use the timeloop in this case? This is not a strict real time application.

Thank you so much,

Thang Nguyen

Hi Thang

Have you looked at the pump demo that is included in the GOOP Developer examples, take a look, it is a fairly complete example of a pump driver that can interface to different types of IO.

QUOTE(Thang Nguyen @ Apr 20 2007, 12:12 AM)

Could you tell me about the Data Store and Class store ref in the ObjectRefnums.ctl?

I don't know where you create it.

Thank you,

Thang Nguyen

Open up "Class".New.vi and you will see that a unique instance of the DataStore is created by opening a VI reference to the DataStore as reentrant and then adding the reference to the object cluster. This allows each object instance to have its own unique data store. Class store is called in "Class".ClassStoreGetRef.vi (not reentrant) and returns a reference to the object cluster so that it is available to class. The ClassStore is a repository of all the object instances, this allows the object inspector to get all the instances and to also check if an instance already exists when you are creating objects by name.

QUOTE(Thang Nguyen @ Apr 20 2007, 12:12 AM)

Could you tell me about the Data Store and Class store ref in the ObjectRefnums.ctl?

I don't know where you create it.

Thank you,

Thang Nguyen

Open up "Class".New.vi and you will see that a unique instance of the DataStore is created by opening a VI reference to the DataStore as reentrant and then adding the reference to the object cluster. This allows each object instance to have its own unique data store. Class store is called in "Class".ClassStoreGetRef.vi (not reentrant) and returns a reference to the object cluster so that it is available to class. The ClassStore is a repository of all the object instances, this allows the object inspector to get all the instances and to also check if an instance already exists when you are creating objects by name.

Why don't you make a method which allows you to update the display object and call it within the event structure when you modify the channels to display?

Well I'm happy.

I downloaded the eval 8.2.1, installed it and it was happy with my 8.2 serial. So it looks like your 8.2 serial works to activate the 8.2.1 eval irrespective of you having an SSP or not. This still seems to conflict with the info from NI.

QUOTE(lavezza @ Apr 13 2007, 08:54 AM)

My group switched divisions in our company on January 1st. It looks like one of the things that got screwed up during the transfer was our SSP. It has lapsed. Well, there are bug fixes in 8.2.1 that we really need so I downloaded the installer and installed it. Remember, there is no difference between the evaluation installer and the regular installer now, features activate based on the license.

Basically, as far as NI License Manager is concerned 8.2.1 = 8.2. Which is what we are used to with NI bug fixes. The install went fine (make sure to do the simulation.msi fix if installing over 8.2).

It sounds like your rep is just as confused as the rest of us. You'll need an SSP if you want NI to ship you a CD. But if you have a valid 8.2 license, with or without a valid SSP, you can still get the 8.2.1 bug fixes by running the installer. Now, 8.5 will be another story.

ftp://ftp.ni.com/evaluation/labview/pc/labview_821.exe''>ftp://ftp.ni.com/evaluation/labview/pc/labview_821.exe' target="_blank">ftp://ftp.ni.com/evaluation/labview/pc/labview_821.exe

That's great, just what I wanted I'll give that a blast. I'll bite the SSP bullet with 8.5 but if I can hang that off till then at least the 1 year window doesnt start ticking from now.

I just spoke to my rep, the only way for me to upgrade is to purchase a 1 year SSP. Gone are the days when you just payed 800 bux or so to upgrade your version of LV to the latest, and bug fixes were free. The good side is that within the year 8.5 will be out so I'll automaticaly get that.

I'm just a little sore at NI for forcing me to go with this just for a bug fix.

QUOTE(crelf @ Apr 13 2007, 06:37 AM)

Enjoying a shandy, are we?

I need another shandy to sooth my throat which is sore and calloused from swearing.

QUOTE(TiT @ Apr 12 2007, 08:51 PM)

I thought the update was free... Is it not ?

I don't believe it is, if you take a look at this page which discusses upgrading it states that the update is free to SSP members but those who are not will have to purchase the upgrade. If you then go through the upgrade advisor it forces you to upgrade with a SSP for a total cost of $1999

QUOTE(crelf @ Apr 12 2007, 09:29 PM)

I'm trying to get in touch with my feminine side. :beer:

QUOTE(gleichman @ Apr 12 2007, 09:40 PM)

I'll contact them in the morning, I'll wait till I discuss this with the rep before I download and try my existing serial.

I just used NI's upgrade advisor to check out the cost of upgrading my 8.2.0 to 8.2.1. I was a bit shocked that its going to cost me $1999 to get a bug fix. That's going to tear a big hole in this weeks beer budget.

I noticed that when you upgrade you are forced to go with a 1 year SSP which is probably the bulk of the cost, but hey, I don't want one.

Hi Brian

I hope you didn't spend your holiday playing with this stuff, there are better things to do :beer:

The idea of the dynamic create being able to choose the correct object based on the persist file is in interesting idea, I quite like it, I'm not sure yet how to correctly implement it.

The demos I've put together that implement persistence are proofs of concept at the moment, I think there are better ways of achieving it, I need the time to tinker with some ideas and begin working it into the mechanics of the object. You are right, the persist file path doesn't really belong in the datamembers but probably in the object cluster, but this was the quick fix until I can create a GOOP template that provides it. It would be cool if you would like to participate in this.

I suppose the direction you take with this depends on the time you have to do your project. If you can tolerate having the persist file path in you data members then go with the architecture I've provided, however if you have the time to tinker then carry on, I don't think you are wasting your time, its just a matter of how much time you have, this stuff is fun after all. In the mean time I'll play with some ideas and post them up for discussion.

BTW I posted up a built exe version in 8.2 of the DynamicPersistDemo that you would no doubt be interested in, see the following post.

Question about making the Executable file with GOOP

or download the code from here

QUOTE(Thang Nguyen @ Apr 5 2007, 06:59 AM)

I changed the VI property of the process VI to Open FP, then it's fine with this problem now. Did I do it right?

Hey Thang

I've never had to change the VI property of the process VI to Open FP to get an active object proccess working, either for an object included in an exe or an external plugin. If this has resolved your issue and your are now continuing with your project then go with it. However I'm concerned that something in your code or your build proccess has stripped out the FP of your proccess when it is built into the exe or packaged as a plugin object.

Without seeing your code and reviewing it, it's difficult to diagnose your application, and what you are trying to achieve is non trivial. At this point I can only discuss and provide demonstrations of how I would engineer a similar application. My offer of providing code review is allways open and I think this in the end would be the most effective way for me to help you if you are still experiencing difficulties, hey its free as well.

I've built the DynamicPersistDemo under 8.2 and have created build specifications that create the exe and the plugin library, download the code and exe here

There are two projects, DynamicPersist.lvproj manages the application and contains the build specifications for the exe, the other Plugins.lvproj holds the build settings for creating the Plugin.llb which contains the desired objects that will be called dynamically by the DynamicPersist.exe

Take a close look at the build specifications, check that your additional exclusions in the plugin build is not "Remove as much as possible".

I hope this helps

QUOTE(Thang Nguyen @ Apr 5 2007, 12:29 AM)

I want to know beside the llb from GOOP. Do I have to add another directory when build the .exe file?

It's up to you, I generally create a Bin directory that stores the exe and associated support files, to keep it sepparated from the source.

The Process needs to retain its FP when it is built or placed in an llb as property nodes are used to initialise the object input to the process instance. The code prevents the FP being striped in a build by a control property node being present. Check that in your process a property node for the object control exists that just returns the label text, it should be sitting in the left hand sequence.

Also if you are building your object as a llb then choose not to remove front panels.

I've just done up the DynamicPersist demo under 8.2 that shows how to build your objects as plugins, I'll have it up in about an hour and I'll post a link when its done, I think this will help you out.

I'll have a look at this and get back to you soon with something that will help you out.

Hey Thang

I did the demo and exe under 7.0, so the steps to make the object llb's for say the DataIO.DataSocket.Digital object is as follows.

1) Open the DataIO.DataSocket.Digital.Create.vi

2) Select Save with Options...

3) At the Save with Options dialog select Development Distribution but include vi.lib files then hit Save

4) At the Choose a directory or VI library dialog rename the file names from DataIO.DataSocket.Digital.Create.llb to DataIO.DataSocket.Digital.llb, navigate to the Plugins directory and hit Save.

If you are using 8.2 then you need to:

1) Open the DataIO.DataSocket.Digital.Create.vi

2) select Save As...

3) At the Save dialog select select Duplicate hierachy to new location.

4) Reanme DataIO.DataSocket.Digital.Create Folder to DataIO.DataSocket.Digital.llb, navigate to the Plugins directory and hit Select.

As I've mentioned before if you are experiencing difficulty then I am happy to assist via a code review. You have my details, contact me if you wish to do so.

I've moddified the code to demonstrate how to build such an application as an exe. The Bin folder where the exe resides includes a Plugin directory which contains objects saved as llb's which are then dynamicaly called. Use the same link above to download the new demo.

I moddified the ObjectPersist demo code that implements plugins so it can be built as an exe. To download the code simply go the the following post.

Object Persistence with Open Goop Template

The sorce and a built exe are included in the download, you will see a plugin directory that contains the object llb's that are dynamicaly called.

Hope this helps.

Hi Thang

I think you are using GOOP Developer for this project.

If so then if you are using CreateByRef to dynamicaly call object creators then you need to save the object creators and the dependant code as an llb, simply save the creator as development distribution in the save with options dialog. Note your CreateByRef then has to call the required creator using the llb in the path ie MyProject\Plugins\DataIO.Digital.llb\DataIO.Digital.Create.vi

Let me know how you go, if you need a demo then please let me know.

Awsome

I look forward to seeing it

QUOTE(bbean @ Mar 24 2007, 06:41 AM)

Thanks Kurt. Its going to take me a while to digest this. Unfortunately (or Fortunately) I'm going on vacation tomorrow for a week. I'll take a look in detail when I get back. I like what I see so far. One question:

1) Is there any reason you made the Persist Method private? It seems like it would be a candidate for a virtual function call. I realize its called in the virtual method of Destroy.

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.