Aitor Solar

Well, sorry, from the previous posts I got the impression some people was simply opening the xnode instead using it in a diagram. Ouch, come on... Do you really think I would do something illegal? And even worse, do you really think I'd do something illegal and posting it in a public forum? Creating an xnode is really easy and doesn't need any license. A Xnode is just a type of library and can be open, modified, etc with scripting. And, as Jimi says, a xnode file is just a XML file. You can extract it from the llb, open it in a text editor, change what you want and returning it to the llb. About the abilities... that's even easier . The ability VIs just need to have the correct connector pane, and you can find that connector panes in the xnode example that comes with LV82 (search for *.xnode in your LV82 installation directory). Not everything is exposed, but with some trial-and-error and knowledge of the old External Nodes is not so difficult. So you can create new ability VIs without problems (they are normal reentrant VIs). About linking a VI to a library, it's answered in this same forum, in a question about linking VIs to a Xcontrol, IIRC. You have the library reference and use the "add item from memory" method. So, I ask you, members of the jury, must this man go to jail for all his life? The answer is "probably yes, but not for this" Saludos, Aitor

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

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 Download File:post-1450-1168960151.llb

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

You mean this? Saludos, Aitor Download File:post-1450-1164183183.vi

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

I can't do anything useful in LabVIEW, so I guess LabVIEW is mainstream :headbang:. Saludos, Aitor

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

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

Umm, I can't edit the first post. Is it possible? Sorry for the inconvenience. Somehow, I thought I was trustworthy . Saludos, Aitor

I'm not sure if I understand you, but in the ConPaneData property you have that, isn't it? Saludos, Aitor

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

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

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 Download File:post-1450-1159886824.llb

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 Download File:post-1450-1159532049.llb

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

Is the .NET class "System.Diagnostics.FileVersionInfo". Saludos, Aitor