LabVIEW
Trigger an event from software
We probably would need to see some code, but a VI with e.g. "mouse down" events does not seem reasonable. Why can't you just use a simple polling loop? No need for event structures.
("Mouse down" is typically a poor choice for buttons, because it fires even if the button is disabled. More typical are "value change" events.)
@altenbach wrote:
We probably would need to see some code, but a VI with e.g. "mouse down" events does not seem reasonable. Why can't you just use a simple polling loop? No need for event structures.
("Mouse down" is typically a poor choice for buttons, because it fires even if the button is disabled. More typical are "value change" events.)
"Value change is the best option, like you said. Only poorly designed UIs (IMO) use "mouse down" because it doesn't give you a chance to "take it back". On an value change, you can still slide off the button without a mouse up and not trigger the event. (Probably all the apps everyone is familiar with work this way.) I guess "value change" for Boolean would behave like "mouse up" but it is much cleaner to act on a button event than a mouse event.
I didn't know "mouse down" fired even if the button is disabled!!! 😮 Edit: Is this because disabling the control disables it against that button's event and not a mouse event?
@maurimonti wrote:I have a problem: our lab bought a detector which comes with a LV software..
It almost looks like you are using some (potentially poorly written?) LabVIEW demo program that came with the unit. Most likely inside that VI you have the "communication/driver" subVIs that do the actual legwork. These are all you need, so write your own LabVIEW code and we can probably help you with that. I also assume there is good documentation how to communicate with the external device, so it could be implemented in your preferred language if you chose to do so.
@billko wrote:
I didn't know "mouse down" fired even if the button is disabled!!! 😮 Edit: Is this because disabling the control disables it against that button's event and not a mouse event?
Similarly, it even works on indicators. Can sometimes be useful as a way to avoid local variables if it "mostly" an indicator. (e.g. to click on it to acknowledge and reset an error condition LED using an event)
Thanks for your replies, I don't know the reason why the VI was written that way, I was hoping to make things work without having to substantially rewrite the vi, at least as a temporary measure until I write something that blends better with the rest of our equipment (being that Labview or python or C or whatever). Here's a couple of screenshots. I am also uploading the main vi itself but it is a bit complex (20+ sub-VIs in the folder) so it may take a long time to figure out every nook and cranny.
@Mark_Yedinak wrote:
If you have the source code for the application (which it sounds like you do) it may be easier to simply add a small TCP task which would generate user events into the existing code. However, without seeing the code it is impossible to say how feasible this would be. My thought would be that you simply create the necessary commands that you need to control and translate those to the appropriate events of the current application. It would most likely involve creating some user events which mirror specific events such as the mouse down.
This sounds more or less what I was thinking of doing I have uploaded some code. do you know where I can find information on this? As in there is a specific manual section I should look at? Thank you
@altenbach wrote:
It almost looks like you are using some (potentially poorly written?) LabVIEW demo program that came with the unit. Most likely inside that VI you have the "communication/driver" subVIs that do the actual legwork. These are all you need, so write your own LabVIEW code and we can probably help you with that. I also assume there is good documentation how to communicate with the external device, so it could be implemented in your preferred language if you chose to do so.
The Vi Is a bit complex (many sub-VIs) and I am not qualified to comment on the quality, however the actual leg-work is done by a .dll file which I have started to write a Python wrapper to, but it is also not the easiest thing to do and will take some time.
Thanks for the VI. From the style of the front panel control and the overall program architecture, it seems like this was originally written 25+ years ago! Most likely whoever wrote this is long retired! 😄
Front panel: Almost everything from the classic palette, but there are a few modern element, most likely added during maintenance years later.
Block diagram: Topelevel stacked sequence structures with 16 frames is not somebody would even consider in modern times. Glaring race conditions! Are all these globals really used globally or just locally? What about all these inner greedy loops? Value property nodes?
Yes, there is a lot of unmaintainable code out there. Sometimes companies hired summer interns or high school students to write a "LabVIEW driver" or demo code for their products and it shows. calling the dll in a reasonably simple program is all you need.
