Leaderboard

I figured I would post a resolution to my own problem for anyone who may run into the same thing. While searching for something unrelated today, I stumbled across my answer. TestStand creates a connection to the configured database with the first UUT that is tested and maintains that connection while UUTs are continuously tested. Only when the sequence is stopped is when the database connection is released. I was able to come up with my solution by essentially compiling what I found in my searches. In my situation - "hiccups" in network connectivity or with the SQL server cause that connection to become invalid. This is why we get our database logging errors and lose logged data. I had read about the offline processing utility, but I wanted something simpler such as a LabVIEW test step that I could drop into a sequence that would handle things gracefully instead of setting up offline processing configurations on all of the testers. After the first time the "Log to Database" callback is run, the datalink object becomes available at: "Runstate.Execution.TSDatabaseLoggingDatalink{GUID}". (GUID will vary). My solution (in my testbed so far) is that I created a VI that locates that object and writes a null value to it. (Empty variant constant). This appears to force TestStand to re-establish the database connection when each subsequent UUT is tested. This makes sure that when the test sequence sits in limbo for hours or days (plenty of time for DB/Network "hiccups"), that the next time a UUT is run, the data will be logged - assuming the DB and Network are up and running when called. I have yet to put this method to the test on one of the actual testers to validate it, but it seems promising in my "simulated environment", (we all know how that sometimes goes). I should also mention that this should go at the end of the "Log To Database" sequence callback. I wish I could share the VI that I created, but I'm not sure of my company's policy in doing so, but my description above should be enough to get people on the right path.

Right now you just see the name and icon of the package, and a short description of what it does. I would like to see some small icons or text at the top next to the icon of each package for example. That list of compact of information should tell me things like the price / type of license, minimum required LabVIEW version, whether the package is part of a larger set (OpenG-tools for example are easier to download by grabbing the all-in-one package), when it was introduced and last updated, project link, category....(and let us filter the list based on these parameters as well). Much of this additional information is currently available if you click in the tool, but that is a huge waste of time when you are browsing hundreds of items. Pack the main screen tighter. The current design is far far away from information overload.

I'm kind of unsure whether this could be accomplished with a common File Dialog or an underlying yellow File Dialog and its ExtFileDialog internal function. But you could switch to .NET and use some third party libraries available. One of those is BetterFolderBrowser proposed here. I have just tested it on both 32- and 64-bit LabVIEW 2019/2020 and it works great. Here's the basic example: Untitled 1.vi