Sergey L

Hi Joe, First of all, I would use Task Scheduler to configure your executable to run once at startup, with "highest priority". You can also experiment with the setting "run whether user is logged on or not" and with running it in the account "NT AUTHORITY\SYSTEM": I think that this will allow your task to run before Windows logs you in as a user. You will also want to get rid of most unnecessary tasks in Task Scheduler, disable unnecessary services (including NI services), and minimize the number of logs that Windows creates. Also you'll want to check the configuration of your BIOS/UEFI: minimize startup delays, power-on self-tests, disable unused hardware (e.g. unused COM ports). You mentioned LV runtime engine and VISA. I don't know what hardware you control through VISA, but if it's an RS232 instrument and if you can use a USB/COM adapter, and if your adapter could be built using an FTDI chip, then you don't need VISA: you can use in FTDI driver. I can share a LV wrapper for this driver. No guarantee that this approach is faster than VISA, but it could be worth trying. One more idea: if your application is really light, you may want to consider an older version of LV, maybe as old as LV6 or LV7.11: they can work without runtime engines installed, all you'll need is a few DLLs. Fewer things to load from the drive and fewer services to worry about after your application exits. Finally, you used the word "embedded". I don't know if you just mean a physically embedded PC running regular commercial Windows or a truly customized version of Windows, like Windows 10 Enterprise LTSC. If it's the latter, there are lots of things that you can customize in it, including throwing out most things that you don't need, enabling keyboard filter (e.g. to block Ctrl-Alt-Del), universal write filter (UWF) to block writes to the hard drive (this can also speed up the process, since your disk writes will actually go to a dedicated part of RAM). To learn more about using Windows 10 LTSC for building a "kiosk"-type application, check out https://solidusintegration.com/sikiosk.html. Best, Sergey

Hi James, Thanks for the tool, it's great! A quick question: is it possible to create encrypted DB files (with the password hard-coded in the block diagram)? Thanks, Sergey

Hello, I've been using LVSERIAL library for several years now, and it worked great. The program is a wrapper for communicating with the Windows RS232 port driver; it frees you from using VISA. It written by Martin Henz. Recently we started using LabVIEW and LVSERIAL on Intel Core 2 Duo machines (specifically Dell Latitude D520), and our LabVIEW executable periodically crashes (after anywhere from 2 to 10 hours of operation) indicating an exception in one of the LVSERIAL functions ("comm read.vi"). The very same program running on single-core processors (Pentium M, Celeron M, Pentium III) never show any problems, and they run for many days at a time. If I replace LVSERIAL calls with VISA calls in the same program on the same Dell machine, the program becomes stable. I would still prefer using LVSERIAL over VISA because of simplified installation and support (in particular, not having to deal with the issues of aliases and visaconf.ini), so I would like to resolve the issue of crashes. Does anyone have any ideas as to what may be causing these crashes? Thanks, Sergey

Since my last posting, two things happened: the problem came back and I found the culprit. It was a combination of my sloppy programming and LabVIEW inability to handle it. What actually happened was that in some subVIs I had an event structure within a While loop; after the event structure (still within the loop) I had an IF statement and when this IF was wired for TRUE, I set up a signalling property of one of the controls which had a corresponding event. Unfortunately, when exiting the while loop, I also executed the IF, therefore setting up an event, even as the while loop and the subVI itself were exiting. In most situations, nothing bad happened, but occasionally the calling VI (in which the subVI was embedded into a panel) froze. Now I make sure not to trigger any event upon exit, and everything seems to be stable, so far. I am not sure that what I described is a LV bug, so I don't think I should report it. Thanks for your help, guys. Sergey.

Guys, thanks for your replies! No, I don't use 'DeferPanelUpdates'. Actually it seems to start working now, after I made a change which is in line with PJM's comment: earlier I used to embed a panel of a subVI and then call it (statically). When the call finished (i.e. the subVI stopped), I removed its panel and embedded the panel of the next subVI. It worked most of the time, but after 20-30 calls it failed with the front panel of the main VI (and everything embedded) becoming non-responsive. What I did now is calling my subVI first, and then, within the subVI, embed its panel into the subpanel container of its caller. When the subVI is ready to finish, it removes its panel from the caller's container and then finishes. This seems to work so far, at least it still works after I cycled through various panels more than 50 times!

Hi all, I have a project in which I have a main VI with 3 subpanels; at different times during program execution, different VIs are embedded in these subpanels. What I see is that occasionally the whole user interface get unresponsive (all controls in all subpanels and the main panel), even though all indicators continue updating. The same problem appears when the program is built into an executable. This problem occures in both LV7.1 and LV8. In LV8, I found a strange way to recover from this situation without killing LV: right-clicking on any icon in the PROJECT window, so that the drop-down menu comes up, makes the stuck front panel responsive again (you don't have to select anything in this menu - just let it appear briefly). This applies even to right-clicking on icons of support files. Also any project window menu selection that brings up another window (e.g. About) revives the stuck VI. Not a viable solution for a built application though... Any word of advice? TIA, -- Sergey.