Bryan

Is the TVI - Tester Automation Framework an open source alternative? I see you also posted the exact same text here. Is it also a LabVIEW software validation tool?

What are the functions of pins 7, 8, and 9 on the DB-15 controller? Is it possible that you have RX connected to RX and TX connected to TX on both ends? If so, you'll likely need to wire it like a crossover: DB-9 Pin 2 (Rx) to DB-15 Pin ? (Tx) DB-9 Pin 3 (Tx) to DB-15 Pin ? (Rx) DB-9 Pin 5 (GND) to DB-15 Pin ? (GND)

I'm sure others have better suggestions (e.g. a LabVIEW Toolkit or other), but in the past I worked with a system that used PDF995 virtual printer and have LabVIEW set it as the default printer and then print to it. However, It will prompt you for a filename/save location every time you print to it and I wasn't able to figure out how to change the default filename at the time nor have it print without prompting.

I'm in the exact same boat. While I'm not on the cutting edge and doing much of the cool stuff many of you in this forum do, I do entertain the idea in the back of my mind that LabVIEW may one day go away while I'm still in the working world. I'd like to think (realistic or not) that if NI ever decided to completely get rid of LabVIEW, that they would show appreciation to all of we who have made it successful in the past by making it open source.

Thanks for the info! I don't currently work at that company or with iVVivi anymore, so my question was more of a "what became of it" post than anything. While I was there, we had selected it over TestStand because of the built in HAL and simplicity in test development.

At my previous employer, we had updated a couple of our test systems to Calbay Systems' "iVVivi" software. I had spent a lot of time with it and recently got to wondering whatever happened to it. When Calbay Systems was acquired by Averna, iVVivi seemed to disappear. It makes me feel bad for those at my previous employer who are now stuck with using a test executive software for which they may no longer have support. I know that we have some Averna employees in the forum, and I'm hoping someone may be able to shed some light on what became of it - including someone who helped us with our implementation of iVVivi (though I haven't seen him on the forums in many moons).

I'm very interested in the responses to this. We're currently looking into migration of existing TestStand systems either back to pure LabVIEW or to a home-grown or other architecture. TestStand has just become too much of a pain in the butt for us that we're planning on purging it from our test systems. I miss the days of Test Executive (TestStand's predecessor). It was simple and easily customizable for LabVIEW programmers. Even "iVVivi" (created by CalBay - Now Averna??) was better than TestStand for our needs (lacking in some areas), but iVVivi wasn't open source and it seems to have disappeared from existance. It would have been nice if NI would have made the old Test Executive code open source, but I'm sure it would have hurt the sales of TestStand, (although I'm sure TestStand is doing a pretty good job of that by itself). Sorry, I didn't mean to hijack - I'll stop right now as I could easily go on a tirade about my experiences with TestStand.

Did they give a reason? I'm betting has something to do with "Microsoft CE" being a thing, and they don't want to even remotely draw any negative attention from Microshaft.

I had heard that they were entertaining the idea of supporting Discover... but even fewer people use it.

AutoIT is the first tool that comes to mind. I'm not familiar with it personally, but know some people who have used it in the past. I don't know if there are any issues using it with LabVIEW, but I know it has been used to automate control of other types of Windows applications.

Here's an example of converting a text string to bytes to an "ASCII Hex" string.

Another SVN user here (With TortoiseSVN as standalone and also with an SVN server). Was introduced to it years ago and have had no reason yet to move to any others. I like it for its (relative) simplicity when compared with others. For LabVIEW, you can configure it to use the LVCompare and merge tools, (there are some blurbs online you can search for that tell you how to configure it). Drawbacks that I've found (in my current employment) is lack of organization in the repository (poor pre-planning). They use one repository for EVERYTHING and it's gotten huge and didn't plan it for best use of the the branching/tagging functionality. Another one is searching this HUGE repository I have to work with. I've found no easy way to search for files/folders/etc. My workaround for this is to use the TortoiseSVN command line and dump an SVN list to a file - then search the file to get a relative location for what I'm looking for.

You could also create your own VI that establishes a connection to the database where the credentials are stored as constants and remove the block diagram. To do this, you have to create a project, then source distribution with that VI (always included). Then, in the settings for that VI in the distribution, you select the option to remove the block diagram. This is currently the most secure method of hiding LabVIEW source that I'm aware of. The only problem is that if the credentials ever need to be changed, you have to change it in the source VI, re-build the source distribution and then send the new VI to your students.

Sorry, I missed that detail. The LabVIEW program automates the targeting and actuation of firearms. (To the FBI/NSA agent monitoring this post - this is what is known as a joke).

My LabVIEW FPs are color schemed ONLY in red, white, and blue, with animated U.S. Flag GIFs or Bald Eagles used in each custom control. But my BDs are bloated to 3X my monitor size...

Shaddap-a you face!

I agree, I have garnered great disdain for Winblows over the years as far as the negative impacts to our testers from updates mandated by IT departments, obsolescence, the pain to install unsigned drivers, just to name a few. I would hate to see NI stop support for Linux as it has been growing in popularity and getting more user friendly. Linux is a great and stable platform, though not for the faint of heart. It takes more effort and time to build the same thing you could do in shorter time with Windows. However, If LabVIEW were open source and free, you could theoretically build systems for just the cost of time and hardware. I've been wishing over the years that they would support LabVIEW on Debian based systems as well. I've created two Linux/LabVIEW based setups in the past and never had the issues I've run into with Windows. Yes, it took more time and effort, but as far as I know - the one(s) I created (circa 2004-5) have been working reliably without issue or have even required any troubleshooting or support since their release. One is running Mandrake and the other an early version of Fedora.

Very true.

If you're using 32-Bit LabVIEW, you may have to copy it to the "x86" Program Files Directory at: C:\Program Files (x86)\National Instruments\LabVIEW 2015\user.lib

Hopefully this alleviates any concerns about LabVIEW becoming unsupported in the future in favor of NXG.

The checkbox for it is right there in your image, you're looking at the "Report Format:" drop-down. "Generate PDF Report" is on the left side of the dialog window and looks currently un-checked.

I just found out this morning that "Runstate.Execution.TSDatabaseLoggingDatalink{GUID}" isn't a valid location for TestStand 2010 (and not sure what other versions). For 2010 at least, it is "Runstate.Execution.TSDatabaseLoggingDatalink{Database Schema Name}". After a lot of futzing around yesterday, I simply added a statement expression step after "Log to Database" in the "Log to Database" callback sequence. Note: I didn't want to create a new local variable in the sequences of each tester, so I used Step.Result.Status to temporarily hold my value (Probably not a good practice, haha): Expression that works for TestStand 2010 (Not sure about other versions) (Using Parameters.DatabaseOptions.DatabaseSchema.Name and replacing all "\s" with "_": // Assign the GUID value to our step status for temporary local variable (Evaluate won't work unless this is done for some reason) Step.Result.status = Parameters.DatabaseOptions.DatabaseSchema.Name, // Replace all "-" with "_" in the GUID and build path to datalink object... then set it's value to NOTHING (Destroys DB reference forcing TestStand to re-open it next UUT run.) Evaluate("RunState.Execution.TSDatabaseLoggingDatalink" + SearchAndReplace(Step.Result.Status," ","_") + "= Nothing" ), // Update step status to what it would normally be if we hadn't had to use it as a temporary local variable. Step.Result.Status = "Done" Expression that works for at LEAST TestStand 2013 and 2016 (Using Parameters.ModelPlugin.Base.GUID and replacing all "-" with "_"): // Assign the GUID value to our step status for temporary local variable (Evaluate won't work unless this is done for some reason) Step.Result.status = Parameters.ModelPlugin.Base.GUID, // Replace all "\s" with "_" in the GUID and build path to datalink object... then set it's value to NOTHING (Destroys DB reference forcing TestStand to re-open it next UUT run.) Evaluate("RunState.Execution.TSDatabaseLoggingDatalink" + SearchAndReplace(Step.Result.Status,"-","_") + "= Nothing" ), // Update step status to what it would normally be if we hadn't had to use it as a temporary local variable. Step.Result.Status = "Done" Edit: I found today that one of our TS2016 installations used the same method as I had posted in the TS2010 verison above. The DatabaseSchema.Name property had a combination of periods, spaces and dashes. All of these I had to do a "SearchAndReplace" with underscores. I'm not currently sure what's causing the inconsistencies between versions (using the GUID vs Schema Name), but so far I've had to tweak each one on a case by case basis.

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.