Booleans can have a "value" which is True or False. They also have a "colors" property so you can change what the False and True colors actually are. If you only want 2 different colors, you will probably just want to change the value.
How you implement the timing is up to you. You can set the value to True, add a "Wait (ms)" VI with a value of something like 750ms, and then set the value to False.
Yes, I tryed out again like in the picture posted. The paralel loop speeds up things x8. With the files closes I take 20us/file. With opened files it takes 0.013seg/file (wich is due tu the x8 speed of the parallel loop, removing paralelism makes it go back to 100ms) wich again seems like a timeout in order to give the actual file opened error. cos thers no way the same open operation takes infintly longer to check that indded the file is beeing used.
At a guess I would think that since the default behavior of a control when written is to not fire an event that the "Value (signaling)" property node is a special case of sorts. I'm guessing there's not much you can do about it.
What if you created user events, register them in the event structure, store the event reference in a global, then create VIs that fire those user events, then have your 3rd party program run those VIs?
Where I gave to put this "Wait (ms)" VI?
?
Here is a quick example for you:
You can drag the snippet into LabVIEW and run it.
That is funny, I couldn't find a simple way to do it either!
You can try this snippet. Please back up your control before running it. Just browse the path constant to the location of your control and then run.
Hee is a 2013 and 2014 version. What version do you need?
I think this is the kind of thing you wanted from the description. Remember there is always a hundred ways or more to program the same thing.
Yes, each operation takes 100ms, but several instances can be run in parallel, giving a proportional speedup, so that is a partial solution if many files need to be checked. The individual operation still has a fixed duration.
I was under the impression that it was the responsibility of the client app (the VB.NET one, in this case) to connect to the server app. I'm fairly certain that if the LabVIEW ActiveX server is running on the remote PC, with the DCOM service enabled and the firewall open, the PC is ready to receive. You just need to set up the client to point towards it, which has nothing to do with LabVIEW.
I could be wrong though... I've never actually tried this in practice.
Thanks for the suggestion. I created a new control saved it to my desktop, closed the control, used your code to point to the control, ran your code, re-opened my ctl file and the scroll bars remain unseen. Did you successfully use this to restore the scroll bars on a ctl file?
Hi Chulito,
Would you mind taking a look at Steps 7-9 in the document linked below? I am hoping that clears up the issue.
Instrument Driver Troubleshooting Guide
Bug in NI MAXs interaction with the NI PXI Resource Manager.
To check it out, disable NI PXI Resource Manager, reboot, then run NI-MAX.
No need to click on anything and a few socket connections to port 3580 should be there in TIME_WAIT state, for ever.
NI R&D acknowledged the bug and a Corrective Action Report (CAR) has been filed.
It works, but you need to leave the .ctl file open and then resave it. You might note that there's no "Save" method called in his snippet, so it just opens the file, changes it, the immediately closes it without saving.
altenbach wrote:
BowenM wrote:I did a test on my machine out of curiosity. 100ms seemed like a long time to just open / close a file.
The way I understand the problem, the 100ms delay occurs if we try to open a file that has already been opened elsewhere.
I missed that part of it. I had a couple open files to make sure that it detected them as open but most were closed.
Just FYI I also tested this with a call to the System.FileIO .NET and it was slightly slower. I think hoovah's suggestion is your best bet.
Of course. I should have noticed that. Thanks for clarifying.
Are you using native serial ports or USB-to-serial adapters? The USB adapters often behave badly with LabVIEW in certain circumstances.
While it may be a bit of a workaround, is it possible you can close the reference in LabVIEW right after the visa write to "force" the message across, then re-open the serial port reference again?
Kyle97330 wrote:Are you using native serial ports or USB-to-serial adapters? The USB adapters often behave badly with LabVIEW in certain circumstances.
While it may be a bit of a workaround, is it possible you can close the reference in LabVIEW right after the visa write to "force" the message across, then re-open the serial port reference again?
Hi kyle,
Youre absolutely correct, im using FTDI USB to RS232 converters and im using the FTDI chipset because ive had terrible experience with other converters and labview, but i havent seen a problem in labview with these converters and i have used them often. But i did take the brute force method and i close and reopen the port every time, seems to be working for now. The software on the device seems a bit shaky.
Thank you,
Matt
I filed CAR 560087, "Compiler Changes Waveform Y Array Data Type Unnecessarily" to describe this behavior. I wasn't sure exactly how to express this CAR so I will show how I explained it in the report. Please reply if this is incorrect so I can fix it on our end.
1. Delete U32 WFM In and clear broken wires. Notice how the Y Array representation has changed to DBL and there is a coercion dot on the U32 WFM Out
2. Undo all actions.
3. Delete the input to the Build Waveform function.
4. Delete U32 WFM In and clear all broken wires. Now notice how there are no coercion dots and the Y Array representation is still U32.
If there is information I left out of if I am missing the point please correct me.
Created CAR 560091 "Mark Existing Items..." Project Property Fails if VI from a Newer LabVIEW Version is in Project for this behavior
altenbach wrote:(A fraction of users thought that it should instead be used by NI to post new CARs, but that is not the correct usage and pretty useless.).
I am really not sure what should be posted there. I usually reply with CARs that I create from forum posts but if that is unncessary I will stop (I've been making it up as I go on the forums here).
