PJM_labview
-
Posts
784 -
Joined
-
Last visited
-
Days Won
10
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by PJM_labview
-
-
Hi Mike
It seem that you need to initialize the parent first (outside the loop). By doing so I got the following:
a
|_3
|_2
|_1
Cheers
PJM
-
-
Hi Everyone,
as a follow up to this post:
Set alternating diagram colors
I made a utility that will generate Labview 7.0 Familiy Tree.
It is not optimized for speed, but one does need to run it only once
(and the result is saved to a file that is included in the zip file).Caution: the resulting tree seem accurate but it might have errors.
PJM
-
Michael
Here is how I do it (In that case it is linked to a Class Specifier Constant)
PJM
-
One caveat... when you do the object typecast test you must be referring to a valid VI Server object, not just a null object that flows out of a Class Specifier Constant.
Jim,
Actually I just remember that the "to more generic class" has broken wire if one does not wire the appropriate class (in the appropriate "order"). So this way it should not be necessary to get a reference to the a valid VI server Object. To find out if a wire is broken or no, one just have to invoke the run method and a broken wire should return an error (Wire conflict probably).
PJM
-
Hi Jim,
One, "next step", that I suggest is a VI that outputs the inheritance hierarchy of a specific class. This can be represented as a path or and array of strings. The inheritance hierarchy of all VI Server objects could be stored (inside the VI) in a linked list. From this, one could populate a Tree Control with the structure of the VI Server inheritance hierarchy as well as doing more functional programming tasks.
Hmm, I dont see any elegant way to do that. The only approach I can imagine is brute force (meaning create a class specifier constant, then create the "to more specific" primitive then create another class specifier constant wire everything (all using scripting of course) and see if the first class specifier constant can be downcast (to more generic) to the second class specifier constant without error then repeat this process for all classes). Well someone might have a better idea (or inspiration might struck me 
) ...I propose that these utilities and type definitions be organized in an OpenG package so that we can more easily collaborate and use the utilities. For example, I would like to create an OpenG package that puts the "New VI Object" and "Open VI Object Reference" (as well as some other recently discovered tools) into the palettes for easy access.Sure, I am willing to donate what I have wrote so far to the OpenG community.
PJM
-
Hi Michael
That utility was far on my todo list but it was there. Thanks for shorting my list !
You are welcome. This scripting is indeed extremely usefull.Well, a very BIG thank you to PJM for this post! He's opened up a whole can of worms. I immediately started diving into the different classes and tried to figure out the hierarchy. Now I can finally get the feature I knew NI would never add to LabVIEW. I think our wish list will slowly disappear since if we need something we can just program it ourselves.It turns out that the VI diagram reference is only useful for listing diagram objects outside of structures. If you want to explore objects inside of structures then you must get a diagram reference to each structure. In addition, each frame of a structure requires another diagram reference. A simple comparison can be made between this and nested clusters in controls on the front panel.This was indeed what did stop me initially, but once I recognize (like you did) that a diagram is very similar to a giant cluster, I went on writing my own recursive VI to get different type of objects on the diagrams (such as Functions, SubVi, Diagram, Wire, Decoration, All Objects ). Since my grasp of recursion using Call by ref is weak, I wrote a recursive VI using a while loop (see Attached image).
Also, I notice the following class hierarchy (can simplify the recursion):
Structure [downcast to = (-->) ]
-->MultiFramStructure
------>EventStructure
------>CaseSelector
------>Sequence
Loop
-->WhileLoop
------>TimedLoop (Whatever it is)
-->ForLoop
FlatSequence is alone (downcast to nothing)
So really, when trying to get for example "All Objects" one does have to recursively check only for Structure, Loop and FlatSequence.
Hmmm.... what should I create next.There are actually so many things that can be done with it, that it is quite hard to select what to try next
. I have made tools like VI inspectors that look for certain type of objects (it did actually help me to uncover more exposed srcipting features 
among other things ). Another one that I made is called "Relink SubVI by Name". The possibilities are endless.
-
Hi everyone
Attached is a tool that demonstrated how to generated private class controls (and constants).
It does used the technique described in the following post: Public And Private Classid Names
Enjoy
PJM
-
This bug has been reported and confirmed by NI
Following is part of NI Response:
Thank you for contacting National Instruments.I looked at the llb you sent me and I was able to reproduce the behavior
you were seeing. I quickly checked if any such behavior was already
documented and I found that it was recently documented. This means that
our R&D engineers are already aware of this bug and are working on a fix.
According to the behavior, it looks like the abort VI method generates the
'mouse leave' event. After executing the 'mouse leave' event, 'mouse
enter' event is executed because the mouse is on the VI (since it never
left the VI in the first place). Mouse enter event is not generated by the
abort VI method. The only reason 'mouse enter' is called is because the VI
thinks that mouse had left the VI due to the faulty event caused by the
abort VI method ...
Feroz Patwa
Applications Engineer
National Instruments
-
David,
Usefull indeed !
That one was on my todo list
PJM
-
The following is a repost (with a bonus) of a post I made on the following developer exchange discussion forum:
Discussion Forums:Where can i find the classID list for Labview 7.0
>Where did you get that from?I did not get it from anywhere or anybody, I built it.
One way to do that is to put on a Front Panel all the objects you want to get info about then with VI server you can get access to all of them(Open VI Ref->VI:Front Panel->Panel:AllObjects->Forloop->GObject:ClassID and ClassName) and get their CID and Class Name.
The problem with this is that it only work with object you know about; for the others I used another method.
There is a locked VI in LV7.0 that allows dynamic instanciation of controls. The name of the VI is "Get Contorl From Type Descriptor.vi" and it is located in LVRoot\project\_NewProbeWizard.llb\Get Contorl From Type Descriptor.vi. If you look at the type descriptor (of unnamed controls) you will see that the third number in the array is the CID. So it is possible to create a VI that generate all the objects refnums (to get their name, manually change them to a constant). I will caution anyone who wants to play with that VI, you WILL (<-no may, but will) crash labview by generating these refnums (so better save your stuff before hand).
Now for the bonus. This is possible to do the same thing with private class refnums (you can see some of them in LabVIEWroot\vi.lib\Utility\XNodeSupport.llb\XNodeParts.vi)
Since getting these ClassID (between labview crashes) is time consuming, check the attachement for both (public and private) ClassID Name.
-
njkirchner
You should register with info-labview :thumbup: as I posted an email about it at the end of last year
Check it out as there are some extra stuff that your are not mentioning
:arrow: http://messages.info-labview.org/2003/12/25/01.html
PJM
-
Craig,It's not the abort, I think- it's the "Open". The window temporarily loses focus when opening the sub VI, then regains focus. This is what triggers the mouse leave and mouse enter events. I fixed it by only opening the VI once at the start and not autodisposing the reference.I am spawing VIs. If I understand what you say, you are opening the reference only once. I need to open a new one for every new spawn.
Well, you may have already solved the real problem, which is how to exit the spawned VI. In this case a Notifier works very well. Attached is an example that shows how to do this.Jim,
Yes, I had to use a notifier. I did not want to do it because I though that's an overkill for what I want to do, but it has the GREAT advantage of working
Philippe
-
Hi everyone
I have a main VI that start a spawn which mission is to execute code after a some delay :clock: (ex:2s). The spawn is start when the "VI:Mouse leave" is triggered.
Now, if the user re enter the VI before the delay :clock: expire (ex: before 2s has elapsed), I do no longer wish to execute the code, so I kill my spawn using VI:Abort.VI method.
As long as I do not kill my spawn, everything work like a charm, but as soon as I kill my spawn, "VI:Mouse leave" and "VI:Mouse enter" events are generated (?!?!!?) :thumbdown: and I am entering an infinite loop because in "VI:Mouse leave" I generate the spawn and in "VI:Mouse enter" I kill it which generate VI:Mouse leave ....
If someone could confirm this (or even better prove me wrong) that will be great.
System: Win2k with LV7.0
Attached is some code that will demonstrate the issue
-
Michael,
I believe this property has been available since Labview 6.1.
PJM
-
For what you are describing a subpanel will do just fine.
Put a subpanel control (from the container palette) inside you 2nd tab and then you can run your SubVI and display its front panel in the subpanel.
For more info on subpanels and how they work, search LV7.0 examples
PJM
-
1) Drop an intensity chart (or an intensity graph) on the front panel (make sure Z axes and ramp are visible)
2) right click the intensity chart and select Properties
3) go to scale tab, select z axes and set it to autoscale and click ok
4) now right click on the ramp and notice that the autoscale Z is not check (alternatively read the property node "Z Scale.Scale Fit")
Has been confirmed on Mac as well as on PC
PJM
-
Bug Decription (tried on 2 machine running W2k):
Go to user.lib, create a copy of you original dir.mnu ( :arrow: "Copy of dir.mnu") and try to restart labview :? .
I got that one while installing my user.lib vis FROM lv6.1 and it took me a while to figure out what was going on.
PJM
Static VI reference
in Application Design & Architecture
Posted
This is true, but it introduce a little annoying (for me at least) side effect when you do that. The reentrant VI appears to be linked to the VI where the static VI reference is. So if for example you are dynamically instanciating that reentrant VI and you are expecting it to show up in the VI Hierearchy (when is sucessfully instanciate), it will never happens because it is "linked" to the VI where the static VI reference is. It does make debugging, in this particular case, a little more difficult (like reentrant VI need to be made more difficult to debug !
).
PJM