DSC: Programmatically change the name of a DataSet?

[David Moerman]

I want to use a "Data Set Marking I/O Server" for my batch-oriented application, however in the logging database it would be useful if the DataSet name were meaningful.  The DataSet name seems to be tied to the name of the IO Server, but there seems to be no way to change the name of the IO Server (i.e. Data Set name) while the process is running.  Therefore I was considering starting and stopping the DSC process for each batch, changing the IO Server name, and then re-deploying the process.  So I attempted using a "template" .lvlib file, changing the name of the IO Server item, and then restarting the process.  It turns out that won't work either, because the ProjectItem.Name property is read-only.

Does anyone know of some way to programmatically change an IO Server name, either while the process is running, or in a project library when the process is offline?

Thanks,
--David Moerman

[nickf]

Hi David,

 I typically just change the "Run ID" at run-time.  The data set example (<lv>\examples\lvdsc\dataset\DataSet Marking Demo\DataSet Marking Demo.lvproj) shows how to do this.  Can you provide some more explanation why you would like to change the data set name between batches?

-Nick

[David Moerman]

I am using the RunID to represent the Batch_ID.  I want to use the DataSet Name to represent the material_ID that the batch is making.  Thus, a set of batches that make the same material will then be grouped under the DataSet Name... to me, this seems like a natural use of the DataSet paradigm, and it would certainly make it more intuitive to a user that happens to be browsing the Citadel database.  They find their material of interest, and voila, it lists all the relevant batches.  That would be nice.

My workaround at this point consists of renaming the process for each batch instead.  However, because I have multiple batches (i.e. multiple processes) running simultaneously, I have to create a process name like "{process_name}_{material_ID}".  Not as tidy, but workable.

--Dave

[nickf]

Hi David,

   Yes, I must agree. That is a good use case.  It looks like your work-around is the best option for now.  --An alternative, albeit more complex, solution would be to store the extra level of detail in a relational database (or perhaps even a file).  You would also need to write your own GUI instead of using Citadel.  I recommend submitting a feature request here:  http://sine.ni.com/apps/utf8/nicc.call_me. 

  TDMS files in LabVIEW allow you to write arbitrary key information along with data, but without the data finder you'd still need to write your own indexer and GUI.

-Nick

[unclebump]

With the old tag engine format, I would bundle all of the data into a cluster, flatten it into a binary string, then write that to a memory tag in the DSC engine. Could you write a cluster of info into your dataset? Unfortunately this requires you to decode when reading history data.

[David Moerman]

Of course, it is very easy to set up a "Material_ID" string tag (shared variable), and I am doing so; and also (as you suggest) anyone creating a custom GUI could easily flatten a cluster of meta-data and write it to a string tag as well.  However, I was just looking for a way to use the DataSet idea to make it even more useful when browsing logging results in MAX.

Thanks for your help,

--Dave