-
Posts
259 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Aitor Solar
-
-
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
-
It would be great, but how? OpenOffice has an ActiveX control, but not a server, I believe. So, communication would be a problem.
Saludos,
Aitor
-
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.
-
They work in 7.1, but not in 8.
Saludos,
Aitor
-
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
-
IIRC, reports had a method to print them in the default printer. Not a lot of options, but it worked. VIs can also be printed.
To anything more complex than that, follow jpdrolet recommendation.
Saludos,
Aitor
-
OK, have you tried "TCP Open Connection"? What kind of error do you get?
Saludos,
Aitor
-
Maybe I'm being too obvious, but does the ping work?
Saludos,
Aitor
-
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
-
You can check if the file already exists (in fact, the file dialog tells you), and in that case delete it before proceed.
Saludos,
Aitor
-
Well, I re-installed LabVIEW and I have managed to communicate between exes through a shared variable with no problem at all. I suppose something was bad with the previous installation
Saludos,
Aitor
-
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
-
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
-
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
-
The VI works right for me, provided I change local address to 127.0.0.1. I haven't studied the code, but the basic advice would be to check your net settings and be sure the listener is created and ready before the client connects.
Saludos,
Aitor
-
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
-
That wasn't copied!
No, neither the warning text. I think it wouldn't be difficult, but would add more properties and my aim was a code as simple as could be ;-).
Saludos,
Aitor
-
Here's my code. Probably is not a pure quine, since it copies its own diagram, but I like it as a proof of concept of simple self-reproducing code. Surely it's possible to improve it a lot of ways .
Saludos,
Aitor
-
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?
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
-
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
-
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 .
Saludos,
Aitor
Oh, excuse me for not attaching the code, for obvious reasons
-
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
-
If you are talking about remote panels (i.e.: see and control remotely a LabVIEW program through a web browser), you just need to add some lines of code to the HTML file, you don't need Frontpage or any special program. But, as usually, I'm not sure if that's what you're asking.
Saludos,
Aitor
-
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
Make Window Tranparent
in User Interface
Posted
I have changed it to work with all colors (a tiny modification: RGB goes to BGR).
Saludos,
Aitor
Download File:post-1450-1150103890.vi