PJM_labview
-
Posts
784 -
Joined
-
Last visited
-
Days Won
10
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by PJM_labview
-
-
-
hi
1st of all, thx for the precious support
I think that building your own ".bld" file, is very useful, because "application builder" lacks for many aspects.
For example, in the "Source Tab" you can "Add Support File..."--> "Add Directory Contents..."
but this not include subdirs....etc.
I am using a PXI MXI3 with lots of NIcards
My main 'always growing' application is a test manager that call the appropriate test using
a "call by reference node". The Vi name & the proper subPaths loaded from a configuration file .ini.
Don't tell me to use TestStand
Thanks again for the help
bye
Hi
As previously mentioned, you might want to check out the OpenG Commander (OpenG.org). This is a free package manager. A lot of package are already freely available. One of them is the OpenG builder which does extend the application builder capabilities siginifcantly. Give it a try.
PJM
-
Hi all
I forgot about that thread, but since it resurfaced I realized I made such a tool.
The Attached tool will allow you to get 90% there. At the end, you just have to add the polymorphic instances to the polymorphic VI.
Enjoy
PJM
Note: I forgot to mentioned, attached file is in LV7.1
-
Therefore, to share this technology is to break the licensing and/or Nondisclosure agreements.
This is quite a "weird" statement that we got there.
Using code left exposed by NI cannot be consider a breach of the license agreement or even a breach of an NDA, since NI left the foundation of scripting functionalities exposed in shipping products. These exposed functions allow access to a lot (all?) of the scripting API. Therefore, the scripting capabilities are cover by the license agreement in the product which they are exposed.
Personnaly I more than once though that the exposed scripting functions were left there on purpose (there was so many of them) for us to experiment with and I was not surprised reading some posting from NI in info labview that were encouraging us to explore the scripting functionalities.
Just my 2 cents
PJM
-
Ed,
This is indeed very annoying. I notice, that going to "file">"new vi" will sometimes help restoring the handles.
PJM
-
Paul Sullivan already made a tool that does that.
Check it out at http://www.sullutions.com/LabVIEW.html (look for Edit Panel Elements).
PJM
-
I enable/disable blinking of a listbox via property node. This should let the selected item(s) in the listbox blink.
When I run the vi floating, it's working fine, but when I have it as a subpanel the listbox doesn't blink.
Is this behaviour normal and a limitation of the subpanel?
Didier
This is a bug (confirmed by Stephen Mercer in that post) that I reported in 2003 for LV7.0 and it has not been fixed in LV 7.1.
PJM
-
Paul,
Ultimately I am planning to make a package of these VIs (along with more from other developpers may be ?).
I already posted about 20%-30% of these in different LAVA forums through examples. Another 10%-20% are just wrapper around exposed private properties. The more usefull (in my opinion) is the recursive VIs that look for Diagram object (such as the one seen on the above image you mentioned), and I think its accessible through relink all vi by name example or clean all wire (which are part of the palette as well) .
Happy digging.
PJM
-
Now that you mentioned it, I realized this is quite eazy to program and does not need scripting (see attached VI). It would probably be usefull to run this VI during the class creation.
Programatically changing the image in the enum... That would be nice if it could be done with scripting (I have not tried it, but I have a feeling it might not be possible).
PJM
-
This is what I do when using it. I make a new class, decide what data type I'll use, and then change the VI reference as noted above. Then I make two directories in the parent class directory, named Public and Private. I then copy the four template .vit's from the Templates directory to the public directory, renaming them as .vi's. (I have no idea if this is how one is supposed to use them, but that's what I do). I try to keep my design such that I'll only call routines in the Public directory from outside the class. Private are just for bookkeeping and calculations within the class. I put all cluster and enum typedefs into the Data Structures directory. Lately I've been using a bunch of pop-up windows for configuring constructors in various ways, so I've tended to put these into a Utilities directory.
Keeping the private and public data separated is a very good practise. :thumbup:
You can usually keep the templates in the template directory and just double click on them to instanciate it when you need to create a new vis that read/write the data (then you save the instance under which ever name you which).
I then work on making the constructor and destructor first, and then eventually add the various other routines to add/read/modify data of the class. All public routines are based on those four template vi's.Good
One annoying thing is that if one of my external VI's receives the reference to a class, the control always says "Template", so if I have two different OpenGOOP classes, I cannot tell which is which (except through the label).You should actually edit the enum (that say template) to replace the text by your class name (ex:my class).
You can also edit the control to replace it by a nice picture (look at the configuration file VIs palette and its refnum to see what I mean).
I also haven't found out how to do inheritence, and instead I've had to do a bunch of programming gymnastics to get around this. For example, the motivation to use OpenGOOP was for the device drivers of my Test Executive. Each driver will have associated with it a enum indicating what device it is (GPIB, Serial, VISA), configuration data for the appropriate communication channel (eg Address and Mode for GPIB), a reference to vi file that gives the actual calls, etc. This would be the perfect opportunity for subclassing. For example, GPIB instruments would use different communicating VI's than RS232 instruments, so there would be alot of common methods but a few specific methods between the instrumetns. I wanted to have a GPIB and Serial subclass that would inherent from my Instrument class, but never figured out how to make this work. So instead I keep various other definitions and handle the class differently depending on how it's defined.There is an OpenGoop which has inheritance and virtual method on the OpenG.org (old tiki website), but if you think the doc is bad on the "regular" toolkit I will advise no trying it.
Basically, to be more user friendly, the OpenGoop need a better doc and more wizards to make managing classes easier.
Attached is an utility that add a banner on selected VIs in a class; it's a modify version of one that is found on the old Openg.or website.
PJM
-
Hello,
Although I've programmed in LabVIEW for some time now, I never had the chance to try the GOOP way of programming.
In the beginning, my applications were quite small, so the "normal" way of programming was enough to make them and keep them structured and maintainable.
With time they are becoming bigger, more complicated, and I think that now is time to dedicate some time to this approach. I heard some goop things about it and having some knowledge of OOP languages, I believe that this is realy the way I want to go, at least for big projects from now on.
I downloaded the OPEN GOOP wizard and installed it.
What I want to know is if there is documentation explaining the concept - how to do OOP in LabVIEW!!! Design good practices... In some words - Where/How to start.
Thanks for the help,
Ragards,
Paulo
Hi Paulo,
There are some documents and examples on the old Old OpenG website. Search the OpenG meeting Archive for more docs.
Also, there is one example in this forum using OpenGoop (look for Didierj posting).
Cheers
PJM
-
I believe this this what you are looking for.
Note: this is for labview 7.0.
New classes have been introduced in 7.1, but the end result is similar. If people are interested, I can post the code for 7.1.
PJM
-
...
Enums don't support the property "Strings[]" to be written...
Not quite, You can use the "strings[]" property on an enum in and idle (non running) VI.
PJM
-
Attached is a "merged" version of both context menu tools.
I kept the architecture developed by didierj because it was the more advanced (covering mouse and key events) and I integrate a lot of code from hfettig for using standard separators, symbols, disabled items, multi list column, side behaviors ...
Everything is in LV7.0.
Now, who is feeling like writing a LV6.1 version ?
Note: the menu builder GUI remains to be done.
Also, for Michael only
, I fix a bunch of cosmetic issues.PJM
-
-
While I dont have an answer to your question, would you be so kind as to stop using caps when you are typing ? using capital letters "LIKE THIS" is considering shouting.
Thank you
PJM
-
This is an intentional duplicate post from the Poll: NI Software Licensing thread
Following is another official answer by NI:
I -
Following is another official answer by NI:
I -
-
NI has had this ability for years, so they DID do a utility. You can see it in LabVIEW, under:
Menu: Tools > Instrumentation > Import CVI Instrument Driver...
If you point this to a CVI Function Panel file (*.fp) which lists all the functions in the driver, it will then create wrapper LabVIEW VIs for all of the functions, 2, 10 or 100. It was beautiful to watch the first time I saw it work. It did in less than a minute what would have taken me over a week on one driver.
This is really neat. I did not know about this.
Now, we just need one that will do the same thing out c/cpp.h file :thumbup:
Please, let us know when you are done "hacking" it
PJM
-
I used this to hack together a little utility that writes the function prototype and parameters to a Call Library Node. The next step is to add a parser for a c/cpp.h file and make a utility that will auto generate wrapper VIs for DLLs, something I have wanted for years. I'll post when I get it finished.
:thumbup: This one has been on my "wanted" list too for years!
Everyone that had to interface with a dll and manually enter all the datatype knows what a pain in the b...ehind it is :thumbdown: !
I am really looking forward to see your implementation.
Why NI did not do such an utility, I really wonder...
PJM
-
Didier pretty much sum it up for you guys, but if you do no wish to reinstall labview 7.0 to get at these primitives, check this post:
Creating Property Nodes, How can I link them to controls?PJM
-
-
Where i can see the codes of colores??
Right click on the u32 (in the color array) and replace it by a color constant
PJM
Auto Sizing FP Controls and Indicators
in User Interface
Posted
Bryan,
Actually Michael (Aivaliotis) came up with this idea. If you select the table and go to edit (menu), you will noticed that the "scale object with panel is checked". This is basically how it works.
Note: NI is doing something similar in the VI Metrics llb (LVRoot\project\prometrics.llb\VI Metrics.vi)
PJM