Kurt Friday

I remember a few years ago the DSC shipped with a cute example called Chemical Reactor which had peristaltic pump indicators that were pic rings. I've scrounged through some old code and found the control. [Moderator Note] This post contained a broken link to an attachment. Best effort was made to find the attachment and fix the link. Unfortunately, the missing attachment could not be found. (ID 6360)

QUOTE(Sparc @ Jul 10 2007, 07:37 AM) You can access the properties of a decoration, the following example shows how to change the visibility of a label decoration. http://forums.lavag.org/index.php?act=attach&type=post&id=6333''>http://forums.lavag.org/index.php?act=attach&type=post&id=6333'>http://forums.lavag.org/index.php?act=attach&type=post&id=6333

QUOTE(yen @ Jun 28 2007, 01:37 AM) Hi Yen There was never a version of GOOP Developer that was free to use for commercial use. There are three versions of GOOP Developer, Evaluation, Full, and recently Academic. There is an open source GOOP Wizard that can handle creation of classes using the open source GOOP Templates, but it is nowhere as featured and user friendly as GOOP Developer. Evaluation means exactly that, you are evaluating GOOP Developer, it even nags the user that they are using evaluation software and prompts them to purchase, I don't know how users can be confused about this.

Lately I have come across several users who have used the evaluation version of GOOP Developer to build commercial systems, which is a violation of the evaluation license. These encounters have been mostly by chance and suggests that the number of violations are quite large. GOOP Developer cost me a lot of time and money to develop and supporting it is a continuing expense, I have to purchase my own LabVIEW licenses so I can maintain compatibility. I really hate having to bring this up, but please, if you have used or are continuing to use the evaluation version to build classes for commercial use, then you need to purchase the full version.

QUOTE(yen @ Jun 14 2007, 01:50 AM) I really like the new datatype, G-Strings

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 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) 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) 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) 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) I need another shandy to sooth my throat which is sore and calloused from swearing.

QUOTE(TiT @ Apr 12 2007, 08:51 PM) 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) Only if you're a shelia... I'm trying to get in touch with my feminine side. :beer: QUOTE(gleichman @ Apr 12 2007, 09:40 PM) Have you checked with your local sales rep? This is probably just a bug with update advisor. Download the new version and see if your serial number works with it. 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) 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) 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.