Jump to content

Aitor Solar

Members
  • Content Count

    259
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Aitor Solar


  1. Now, what I haven't discovered is how to give control programmatically to a specific client that's viewing the VI.

    This can be done from the client machine (either right-clicking, or from the local LV through the Request Control method). But if the client just has the runtime and it's viewing the RP through a web browser, you can't give him the control from the server machine, just unlock the panel and wait the human user to ask for it :-(.

    Saludos,

    Aitor


  2. How can I trigger event 8 in 'Power Panel.vi' from 'Power Interrupt.vi'?

    I haven't seen your code since I don't have LV8 in this machine, but basically you have two ways, AFAIK, depending on the specifics:

    1) Open a VI reference to "power panel" from "power interrupt" and get a reference to the control you want. Use then the "value (signaling)" property node to trigger a "Value change" event in "power panel".

    2) Register dinamically events from "power interrupt" in "power panel" through a "Register for events" node. But from your description, I think this method is not what you're looking for, because it only registers events, not program actions.

    Saludos,

    Aitor

    P.S.: Or, since you're using LV8, you could use shared variables, a simpler solution that events, maybe. Or other ways of communication between VIs like queues, notifiers, etc.


  3. Probably a port conflict, I'd say. Create a simple html file (called for example "hi.htm") in the web server root directory, let's say something as simple as:

    <HTML>

    <BODY>

    Hi!

    </BODY>

    </HTML>

    Open the browser and go to localhost with the selected port, i.e.: "127.0.0.1:3333/hi.htm" (because, as you have seen, opening directly from windows leads to an error in the remote panel, 'cause you're not entering through the server). You should see the "hi!" message. If not, try using another port. First, check the web server is running, disable proxys, etc.

    Saludos,

    Aitor


  4. My first goal is to be able to change the images associated with a boolean control.

    If you just want to change the images once and forever, you can try the customize advanced option. If dinamically, an Xcontrol could be the answer (or even a picture, controlling its events). Now I can't remember a way of doing it with a script, and even it there's one, using it could be problem-prone, as all copies of that ctl would change, etc.

    Saludos,

    Aitor


  5. Open in Default Browser uses DDE to pass a "WWW_OpenURL" command to the default browser defined in Windows register, and if that fails it uses a System Exec call to the browser executable. Depending on the browser you are using, you can add other parameters to WWW_OpenURL, as WindowID to specify the target window, or use other commands to create a new window and then open an URL in that. Otherwise, you usually (Firefox, Mozilla...) can define the browser behavior referring to urls coming from external applications, so it launches them in a new window / tab.

    Saludos,

    Aitor

    P.S.: Oh, and of course it would be better to use ActiveX, in your browser allows for it.

    Saludos,

    Aitor


  6. I have observed xcontrols lack unit label (or, at least, I haven't be able to find it), so you can not wire the xcontrol to a wire that has units :( .

    OK, the unit is defined in the data type in Data.ctl, but I can't see any way of modifying it programmatically. Opening it from the fa


  7. I would like to know whether I can convert my Matlab script into a Labview program.

    With so much information as you provide, the answer should be "probably not". It depends on what you're doing in that script. But you have the "Matlab script node" in LabVIEW to import it (take note you still need Matlab installed in the machine).

    Saludos,

    Aitor


  8. I don't think it's so hard, in fact. You have an example in LabVIEW (Help -> Find Example -> Communicating with external application -> Excel) and the library it uses. All is based in opening an Excel ActiveX object and operating its methods and properties.

    Saludos,

    Aitor


  9. You're orbiting around the concept of a LabVIEW quine. I've been meaning to raise the same idea in this forum for a few weeks, but I wanted to play around with VI scripting a bit more seriously before bringing it up.

    But what would be considered a quine in LabVIEW? In text languages, usually such a program has a string output that contains its code. But in LV, that's not possible (I think). I have developed a VI who creates a new VI with its same code. Does that count? What's my prize? :D

    And if so, is it really worth the risk that it gets in the wrong hands?

    I'm not sure. It would be a pity some day we should start quarantining all VIs to be sure they have no malign code. On the other hand, the tools are there, easily available to everybody. And when scripting licenses become available, the possibilities will grow much further (documentation, access to all functions and objects...) :ninja:.

    Saludos,

    Aitor


  10. Not sure what the problem would be. I can write a small demo VI that does the equivalent of rm -r / (obviously for unix ;-) and post it and anyone not being smart enough to check the VI diagram before executing it would be deleting his entire harddrive. So what?

    Of course, you can easily destroy almost everything in the computer or even copy a VI a million times. But I think this is more subtly. The code keeps copying itself inside other VIs diagram without destroying their original purpose, and so each infected VI acts as a new propagation point. And you could hide the code, for example, in an invisible (or not immediately visible) zone, such as inside a frame, behind something, etc. So it's possible that, after some time, you discover all the VIs in your application (even most LabVIEW VIs) have been infected, retarding the execution and forcing you to a complex and long cleaning :thumbdown:.

    Saludos,

    Aitor


  11. Hi, people.

    I've been rummaging through this idea and I have managed to create a piece of self-reproducing code (I have to admit it's no difficult). It copies it's own code in other VIs, then when those VIs execute, they copy that code in others, etc. As a concept I find it fascinating, but it's a little nasty if you aren't careful.

    So, does scripting suppose a new danger to free VI sharing, like in forums? What do you think? Probably this is one reason NI doesn't want people playing too much with these new tools. Maybe in a few years we'll need antivirus for LabVIEW :blink: .

    Saludos,

    Aitor

    Oh, excuse me for not attaching the code, for obvious reasons ;)


  12. The vi server use case will not work with shared variables since they are technically external to the LabVIEW executable. And why do the shared variables crash your PC...if I may be so bold.

    I don't understand what do you refer to with "the VI server case with shared variables", I considered them two different ways of transmitting data. Or do you mean affecting shared variables through VI server? I hadn't thought about that, but it would sound interesting (if you hadn't already stated that won't work, of course ;-)).

    About the crash, I really don't know, the laptop just crashed repeatedly when the "deploy" window appeared. I'll try to test it in another machine, if the license allows me to do so.

    Saludos,

    Aitor


  13. Seems to work fine in 7.0.

    Yep, and it's a pretty good system that allows a lot of customization like connecting simultaneously with several instances of the same executable, etc. Another option is to compile the exes as ActiveX servers, then you can communicate between them in a very similar way (in fact you just need one of them to be registered as a server, the other one reads and writes on it). An example is attached. The advantage of this system is you can communicate with the program through another languages, not just LV.

    That been said, I was wondering about the shared variables in two local exes too, 'cause it seems a simpler solution in some cases. My guess is they should be the network type, because for each one the other application is external, even if they are running in the same machine (the same holds true for VI server, when you must use remote access and a valid port number though you never go through the net), but unfortunately I still haven't be able to check it, because the shared variables crash my PC :-(.

    Saludos,

    Aitor

    post-1450-1146036050.jpg?width=400

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.