Logging Teststand steps actions and status

[aSquared]

Hi,

I am using Teststand 2014 and LabVIEW 2013 SP1 as the module adapter.

My Teststand sequence file includes communication with 3-5 different instruments via TCP/IP.

Such as Spectrum analyzer, generator and other RF measurement devices.

Since I am performing many configurations of the instruments and fetching measurements I would like to have a log of the status of every command sent to any instrument.

for example - if I send an Auto Range command to a spectrum analyzer, I would like to log that it was sent and also log the respond from the instrument that the action is done.

This log will be visible to the user and he could scroll and see what commands has been sent to the instruments and their status.

I believe that this log should be a part of the UI that I will create for the Teststand Seq, is that correct? or should I create a different Window for it ?

There are many other questions that I am thinking -

1. Where should I store this log ? in a spreadsheet file ? in a database ?

2. What is the best way to pass the information (what resource, what command, status) to the log ?

Using a Queue implemented in LabVIEW ? or maybe pass the This.Context Reference to every Step so that every step will update a Teststand Queue that will that will write the log to a database?

or maybe Writing in every step to the log (file or DB) and using the UI messages to write to the Teststand UI 

[GovBob]

Are you strictly using LabVIEW drivers (NI VISA) to talk to these instruments? 

This could be a lot of data to log...to get an idea of how much just look at MAX (Measurement and Automation Explorer) and open NI I/O Trace. After you configure NI I/O trace run your sequence with the capture on and you will see what I mean. 

In LabVIEW under Measurement I/O there are subvi's to invoke NI I/O trace which might be the easiest way to do this if you want to show that window to your operators all the time. 

For my purposed I just post messages to the TS UI on where it is in the sequence and not show the nitty gritty details that most of my operators wouldn't understand. If I think there is a problem I'll open NI I/O trace manually and check it myself or have an advanced user (technician) do the same. 

Hope this helps.

[Dennis_Knutson]

Yes, I/O Trace is the correct tool but I can't imagine anything more useless for the typical operator to have access to. My typical operator didn't even speak English let alone be familiar with the SCPI commands of an instrument. I/O Trace is a debug tool when you are writing a new sequence with an existing driver or writing a new instrument driver. Once debugged, your instrument is not going to suddenly stop responding to the commands being sent unless someone starts fiddling with its front panel or the sequence of commands and errors is not correctly handled in your code.