Kurt Friday

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.

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.

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.

Hi Bryan From what you have described about your VME system your object hierachy looks correct, you are allowing the ability to branch out with different cards and different modules, quite a deep and interesting hierarchy, but nonetheless easily handled. I'm not quite sure you are on the right track with your object creation, my impression is that you are calling the VME base object Create which calls a card Create which calls a module Create and so on. If so this is not the way to create your object. The base or parent Create is never called, it is really only there to be used as a template for the object Create. When you want to use a VME.Card.Module.Type1 then call that classes creator, place whatever code that is required inside its Create to initialize the HW or get HW references to channels. What you are doing is very similar to the DataIO class that ships with the examples, take a look in there and that should guide you. Also the tutorials provide an excellent guide and go into how to architect the type of class that you are looking to develop.

Hi Chris First, I admire how you have asked for help and you have had a really good shot at solving your problem. I can provide a little hint here. You are using express vi's, however you can convert an express vi into a regular vi by simply right clicking on the express vi and selecting "Open Front Panel", the express vi will then be converted, take a look inside, you will then see subSignalProcessin.vi, take a look in there that will help you. Also if you want to attach an image into your post simply attach the image file and then you will be given a reference which you can insert in your post. Good luck with it.

Ha, well done Chris I havent see Pat for a while but he is indeed a top bloke. Whenever I'm next in Melbourne I'm going to pop my head in the door for a yack.

How can I not respond :laugh: All this talk of Aussie slang reminds me of the warmest welcome I have ever received. The MD of one of the Alliance members from Melbourne had just come over for a visit to our office, and as I got out of my chair to shake his hand he said with a big grin, "G'day you old bastard" BTW, my favorite beer is someone else’s

Hi Mohammed You are on the right track, your vi is producing the correct result but you need to clean your code up a bit by using shift registers to carry the sum and don't use constants on the count terminal of your for loops, pick the appropriate values from your 2D array using the Array Size function, it looks like you started to do that. Also there is no reason for the single for loop up the top that that iterates once. Since you have attempted the problem and had a go I have attached my solution. Download File:post-1058-1148056804.vi

Absolutely, and when it

Hi Mohammed What you are asking is quite a trivial problem. However we are a bit like your maths teacher, we want to see that you have had a go at the problem yourself before we throw you the solution. Also what is this in relation to, if it's your homework then this is the wrong forum.

An even more efficient method of the shuffle, just randomly select two elements and swap their locations. Download File:post-1058-1145537823.vi

Hi Greg Perhaps a better way may be to shuffle your array. Download File:post-1058-1145521987.vi

Bad 3D code would probably look like this

At least I could practice alternative dance and get my work done. I thought this demo on Augmented Reality was very cool, imagine having your team in the same space and being able to see them and work on the 3D Code together.

Hi Vnn The best way to distribute your application with the Run-Time Engine is to create an installer. Take a look at the following Distributing Applications with the LabVIEW Application Builder I hope this helps

Except the morning after eh alfa :beer:

Hi Mike I think you are trying to access a file relative to your main vi using the file constant "Current Vi's Path" and then striping it back one level to get the directory that your main vi resides and then building your file path from there. This is a problem when you build your application as the path that is returned by Current Vi's Path will be for example. C:\MyApp\MyApplication.exe\Main.vi What you need to do is detect your application kind ie Runtime or Development and handle the path stripping appropriately. You will find more information on it here and here I hope this helps

I recommend that every post by Alpha be turned into a post about drinking and bawdy behaviour. Here

Hi I just replicated your code and I see the same error. The problem is that the path that you are setting as the replacement control is not valid, try pointing the path at the absolute control path, ie c:\temp\temp.ctl I tested this in 7.1 and works fine

Wow, that's lightspeed, great support Thanks for that Darren :thumbup: :beer:

I'm witnessing a peculiar behaviour when reading the callees of a vi if the vi contains either vi's which do not have their required inputs wired or if the vi is inserted as a static vi ref. Under 7.1 these vi's are returned as callees but under 8.0.1 they are not. For example, 1) Create two vi's A and B, make B have a required input 2) Place B on block diagram of A, save and read the callees of A and notice that B does not appear as a callee of A. 3) Wire a constant into the required input of B , save and notice B appears as a callee of A. 4) Remove constant input from B and save, notice that B still remains in the list of callees of A. 5) Try placing B as a static vi reference, notice that B does not appear as a callee. I've attached a demo which demonstrates this behaviour. Is this a bug or a feature? Download File:post-1058-1142740240.zip

Hi Chris Try the solution attached. It is written for LV 6.1 which requires the BD of the target be open for the operation, so for 7.0 and up just remove the open and close FP property nodes. Download File:post-1058-1141083489.vi

Hi Brian Take a look at the example LabVIEW user interfaces included with TestStand, just go to TestStand\Operator Interfaces\NI\Simple\LabVIEW The Simple user interface will help you get started and its easy to modify to suit your needs. Hope this helps