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 th

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

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 eve

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 t

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.

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