Leaderboard

For me the simplest reason I don't use TestStand for my sequencer, is that it doesn't run on real-time. I want to tell an RT target to run a sequence and have it run deterministically (mostly) and headless. No more worrying about Windows restarting on an update, blue screening, how to handle PC upgrades and the down time with it, etc. I just want an embedded device to run my sequence talking to network devices, serial, DAQ, and other IO. And have the Windows computer just get the data and do report generation. When RT is not a hard requirement, or in cases when there is an RT target but the sequence itself can be non-deterministic (steps ran on Windows), TS is a fine option. Just not one I've used often enough to be comfortable with it on large projects. When a small project does come I just use our sequencer anyway because eating your own dog food is good for other projects when issues are found.

I usually don't recommend using the first token unless you are trying to capture a specific crash. Full crash dumps can be very large and not only will crashes generate full dumps but all DWarns will create full memory dumps so the LVInternalReports folder will get pretty enormous in most cases. I'm not 100% certain but doesn't the DWarnDialog token just show a modal dialog window on any DWarn? I remember doing something like that at one point and just found it very annoying personally.

Which is a big point to why we didn't use TestStand in that there is a cost in learning the system which has to be able to fit in budget and schedule of a project.

From my experiences, TS seemed to be overkill for a lot of applications with which I have been involved, like "trying to swat a fly with a Buick" (to quote a friend). Add to that the additional cost of deployment/debug licenses for multiple test stations, the bill goes up quickly. Learning curve also comes into play as TS has seemed to become its own programming language and is not as easy to learn as LabVIEW for those without the budget or time to take the training classes. With a "roll your own", after the initial time investment of creating a test sequencer in LabVIEW, you can deploy to as many stations as you want without the cost of additional deployment licenses by just building EXEs. Where I'm currently working, TestStand is just starting to gain a foothold, but ease of deployment and cost of deployment licensing has been a source of contention. Now, my opinions are based solely on my experience with using TS on and off for several years without formal TS training. Ironically, a couple of my coworkers and myself are going to be taking a TestStand classes within the coming weeks, and I'm interested in whether my personal opinion (and those of my coworkers) will change. At my previous employer, we still had a system running the precursor to TS: Test Executive. We had kept updating it until we ran into an incompatible version of LabVIEW, then just "froze it in time". Nobody there was very familiar with TestStand and how much it would take to do a migration as the station tested a large variety of boards. Because there was only one operating station, the risk of downtime for migration was considered too great, so it was never done. Test Executive seemed so much simpler and a better match for the needs at the time. A second station was created to do the same as the one running Test Executive. Test Executive wasn't compatible with the newer version of Windows, and they still didn't want to go the TS route, so we ended up going with a LabVIEW-based test sequencer from CalBay (now Averna) called "iVVivi". I became very well versed in iVVivi and it was definitely simpler than TS. It also had an integrated LabVIEW OOP-based HAL, which was very attractive. However, in some respects it was TOO simple and required some creative LabVIEW routines to mimic some functionality available with Test Executive. I don't believe iVVivi is even supported anymore, so they may eventually be forced to go the route of TS. Or, beg NI for the password to access/update the protected VIs to recompile in later LV versions. EDIT (3/2020): After having had the training and applying what I've learned over the past year, I can say that I understand TestStand much more, including its quirks. I still think that it could be suited for some applications, but still way too overly-complicated for the majority of applications that I deal with on the day-to-day and the additional costs per seat/deployment are still a deterrent. It still fits the "swatting a fly with a Buick" analogy I used before.

My only TestStand roadblock so far (and has not been nearly as big of one as I expected) is the deployment license cost. Though, put that cost against a VST and it is a small drop in the bucket. (The VST is literally half of the cost of my current project's entire test rack.) As far as going away from TestStand, I have ran into a couple situations where I was told to use TestStand and I convinced the customer/management that the project really just needed a decent State Machine with a few other loops for logging and instrumentation. Sorry, no real ammo coming from me. But I am very curious about other people's reasons.

Mwuhahahahaha! Three config tokens have escaped your grasp! I modified them specifically for folks like Flarn! They don't appear as plain text anywhere in the EXE (or in any VI for that matter). Do they guard any great secret of LabVIEW? I'm not telling! But you can have fun pouring through the code and looking for interesting bits and trying to figure out what you need to put in your config file. LabVIEW 2013 or later. Good luck.