Aitor Solar
-
Posts
259 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Aitor Solar
-
-
This is my first Xnode (not an External Node, but a true LV8 Xnode). I don't know how "revolutionary" is this, I suppose not much. I haven't found info about new Xnodes, but sure a lot of you are playing with this technique and are more advanced than myself. In fact, a couple of days have been enough to grasp the basics, so my first impression is Xnodes are far better "thought" than old External Nodes :thumbup: .
The purpose of this Xnode is simple, it just returns the selected string value from an enum. This was already easily done, for example with the "Format into String" function or with the "Get Strings from Enum" VI from OpenG (impressive by its own), but I think it can be an useful proof-of-concept for people who want a VI that accepts all kind of enumerations as inputs without using variants (something I've found desirable from time to time).
The function accepts all enumeration types and representations (even typedefs), or at least it should. If you find any error please tell me, I've tried to make the Xnode as light as possible.
Obviously, Xnodes can do a lot more things, but unfortunately just one example comes with LV82, so if anybody knows better, please share your wisdom
.Saludos,
Aitor
-
Of course, since you probably don't want to disable everything, you'll need some logic around when to write a "2" and when to write a "0".
For this logic, I've found useful to group the controls that must be enabled / disabled and apply the changes to the whole group elements. This way is not necessary to check all the front panel objects and it doesn't depend on the labels either.
Saludos,
Aitor
-
-
Yes, I think I'll go for the "all events in one registration" approach. But I'll explain my case further. I have several VIs that must monitor a series of dynamic events. And one additional VI that, apart from that events, has to monitor some more. So, I just see two possibilities:
1) As you say, register all the events once and pass that reference to all the VIs, keeping null references for the events a specific VI has not to control. But I don't really like this, because is not very elegant to have a VI with dynamic events it won't use ever, and furthermore, if I change my mind about an event, I must readapt manually all the controls and indicators in the subVIs, even if those VIs will not use the changed event
.2) Keep the references to the controls and create two event refnums, one "basic" and one "extended". I even like it less, because changes in the type of the registered events must be replicated in all the registrations.
I hadn't thought about using a typedef, maybe is an improvement when rewiring
.I hope to have explained it better
.Saludos,
Aitor
-
I need to add new events to a previously defined event registration refnum, a task that's starting to seem impossible
. Well, in fact I've managed to add two event refnums (from their typedesc, plus some scripting, etc). It works, but... the new event registration refnum, though it has the correct structure, it doesn't have specific controls registered on it (of course), so the events never trigger.
I'm running out of ideas, so if anybody has one to offer...
Saludos,
Aitor
-
Have you tried invoking the server object with the desired version? For example, "LabVIEW.Application.7.1" instead of just "LabVIEW.Application".
Saludos,
Aitor
-
Well, I don't know what you were expecting, nor I have promised anything other than a VI who adapts to the input type at develop time.
Recently this issue was discussed and it was said a polymorphic VI would be the answer, but making a poly subVI for every possible input type is unaffordable. So you need a VI that, somehow, runs some code when a terminal is connected. That would be, of course, a XNode, but Xnodes are difficult to implement, specially in LV8+, and usually you don't need all the capabilities they offer, but just a way to change some code in that subVI.
So I've come to what I thought it was a simpler way. It is, of course, an Express VI, where the configuration VI is used to change what you need of the original VI (by scripting) without a dialog. Is not a perfect solution, since it doesn't update automatically when you connect something (you have to double-click it), but I've found it surprisingly easy. LV passes the config VI all the references you need, from the subVI an its parent VI, to change them the way you like (be it really simple, like this example, or as complex as you could make it). And every instance works indepently, so you can use them in different VIs, or several times in the same VI, without fear.
Not that I have presented it as a solution to anything, just a "Hey, I think this is nice, look if it works for you". No doubt a lot of people can make it better. But it's never late to learn, and for sure I have learned a lot from this thread for future participations.
Saludos,
Aitor
-
LV8.2 version, non-protected
Download File:post-1450-1159950912.llb
1) Copy adaptation_8_2.llb in a directory LabVIEW looks for files, like user.lib.
2) Compile all the llb files. Locate get contorl from type descriptor.vi in your LV installation directory.
3) Use same.vi in a block diagram, connect anything and double click.
Saludos,
Aitor
-
A C programmer, by contrast, can't do anything useful except as a member of a team.
I can't do anything useful in LabVIEW, so I guess LabVIEW is mainstream :headbang:.
Saludos,
Aitor
-
:laugh:
Hmmm - maybe it's been there too long for you to be able to edit it? That's okay - just post the new version.
There'll have to be tomorrow, I don't have LV here.
If after all this fuss you don't tell me is a great idea, I won't post more code ever :laugh:.
...
No, wait, it's not a joke
.Saludos,
Aitor
-
In 7.1.1 I do
Yes, sorry. Is in the VIs properties, you have "Connector pane" and then "Connector pane data", and there you have the permutation and more things.
Saludos,
Aitor
-
There are more properties than that. Do you have the private stuff activated?
Saludos,
Aitor
-
I'd prefer it if you edited your original post and replaced the old one with the fully-open version
Umm, I can't edit the first post. Is it possible?
Sorry for the inconvenience. Somehow, I thought I was trustworthy
.Saludos,
Aitor
-
Sure, it's easy to make the rotation, but how do we determine orientation after the fact and re-intepret the connector order/traversal.
I'm not sure if I understand you, but in the ConPaneData property you have that, isn't it?
Saludos,
Aitor
-
I download it, then I noticed some VIs (that I believe you made) were password protected. My interest pretty much dropped at that point.
Oh, I had to make them protected since I tested them in a shared computer. Password is "expreso". I'll put a non-protected version if you like.
Saludos,
Entro
-
That's pretty neat, but I've always (since scripting )wondered how to handle the rotation of the connector pane.
How to handle it? Well, you have the rotation methods for the connector pane:
We can do it all, but adding new patterns. It would be necessary a xnode for that, and is not so simple
Saludos,
Aitor
-
So speaking for myself, your posting looks very interesting and I am planning to learn something from it as soon as I can.
Oh, well, then I hope your computer get repaired fast
I have now the LV8.x version, it wasn't that difficult. As previously, compile the whole llb and run relink.vi before using same.vi in a block diagram.
LV8 version:
Saludos,
Aitor
-
Well, I guess it hasn't worked for anybody
. Maybe in the future I'll come to an easier way of doing the same.Saludos,
Aitor
-
Hi, people.
I would be very grateful if you test this simple program and give me some feedback. Surely the technique is not revolutionary, but I find it useful as a proof of concept.
Basically, same.vi gets an input and returns it in the output. So it does nothing, but it adapts to anything you connect to the input.
Some instructions to make sure it works (let's hope!):
1) Re-compile all the VIs in the llb. If you get asked for Get Contorl From Type Descriptor.vi, it is usually located in your <LabVIEW directory>/project/_NewProbeWizard.llb.
2) Run relink.vi.
3) Now, drop same.vi in another block diagram and test different inputs.
Caveats:
a) I've checked it also works with customized controls, but it loses the type definition link. I'll work on that.
b) To make it work in LV8+. you'll need the Get Contorl From Type Descriptor.vi from LV7.1, since the modern version has no type descriptor input. Strange.
Saludos,
Aitor
-
Alternatively, try to register the ActiveX dlls and call them from Labview, creating an automation refnum and selecting the correct ActiveX class. Then, you'll be able to use the public properties and methods.
Saludos,
Aitor
-
Remote Panels use now the web server, not the G web server. In the Web Server configuration tab, you can allow or disallow access to specific VIs and from specific IPs, but not password protect them, as far as I know.
Now, I don't know if there's any way of retrieving a FP through the G server, without calling the Web Server. It seems this was possible back before the web server existed, so maybe is still there.
Saludos,
Aitor
-
I connect at work, but doesn't mind if you tell my boss, I consider it part of my job: looking for solutions and upgrading my knowledge
Saludos,
Aitor
-
I mean what class is that?
Is the .NET class "System.Diagnostics.FileVersionInfo".
Saludos,
Aitor
-
jopp, I did this - 2 or 3 years ago, and I called that "dynamic cluster" - a cluster which existed only by reference. You have to figure out how the type descriptor array works, then you can create clusters in a way you want. the only drawback is - if you want to access them, you can do this only if you convert them into a variant. You cant create any bundle or unbundle nodes on the BD with this cluster.
But you can create an object if you have the type descriptor... Anyway, the problem is always the output type. You need a VI that executes when put in the BD, and that's a Xnode (a solution I don't like either).
Wait a minute, what about this: have a running VI in memory that checks what you're doing in another VIs BD (easy). When you connect a wire to the "variant VI" input, this daemon reads what type of wire it is and modifies the "variant VI" output indicator to be the same as the input. That would work, but the "variant VI" should be constructed to allow its output manipullation.
Do I have explained mayself?
Saludos,
Aitor
My first Xnode
in VI Scripting
Posted
Xnodes are used as a subVI, not opened directly. From another VI's diagram -> right click -> Select a VI -> Go to "EnumToString.xnode.llb" -> Select "View all" in the bottom options -> Select "EnumToString.xnode"
I attach an example of use (put it in the same directory the EnumToString.xnode.llb is). Connect any of the enums (or other ones you create) to the input, it should adapt to it; run and get the selected string.
Tell me if it works for you
.
Saludos,
Aitor
Download File:post-1450-1169019643.vi