shift time in citadel

[craige]

Does anyone know if you can perminantly shift the time of a trace within the Citadel database?

Here's why: I have a remote device which acquires data at and ships this data (with a timestamp) over a serial connection. The timestamp is manully set using a HMI to the device so I already the timestamp is a little off due to human error. However at the begining of a test there is a digital pulse which lasts for 1 second which is used by all my devices as a reference.

After I run my test I'd like to line this pulse up againt other traces with the same pulse but more accurate timestamps thus shifting the timestamp of the serial device trace perminantly within the database.

Sorry for the lengthy description,

Craig

[NAKeel]

Hi Craig,

You can modify the timestamps of the traces by reading the traces, unbundling the timestamps, replacing the time stamps, and then writing the traces back to the database.  You can do this all programmatically.  I would use a timestamp associated with the pulse and write that value to the database.  All of the functions that you will need for this are in the  DSC»Historical palette. 

[craige]

Right. Using the DSC toolkit to manipulate each trace individually is fine but I want to perminantly effect the database. Here's another example....

Lets say I run a test and log data using the citidel. Unfortunately my system clock was incorrect. It was set for 2:30pm instead of the actual time which was 2pm. I'd like to go into the Citadel and push the timestamps back 30 minutes to correct this so in the future when a call a Read Trace VI  I don't have to offset the data manually. I'm looking for a way to correct time in the data set itself not the queried result of a trace.

[NAKeel · Accepted solution]

Hi Craig,

Thanks for clarifying.  Unfortunately, there is no way to offset the Citadel database clock.  If you know that that your clock is going to be off by a specific amount you will need to offset the timestamps manually when you write them.  For your first question, I would write the timestamp for the serial line based on a time stamp generated with the pulse.  For your second question, you would need to update the traces manually.

[craige]

That answered my question. Just wanted to make sure I wasn't overlooking something. I understand that this is probably no small feat but it would be a nice feature for the future of DSC. Thank You!

[unclebump]

Are you saving all of the traces individually for a test?? Might be worth doing the alignment of all the traces to start, using some of the waveform tools, then combine the traces, and write all of the traces to a single Results memory variable. Is the exact timing of the tests really that important, or just the relationship of all of them to the start pulse??

That is kind of my one flaw with the DSC system, it is based on time only. Sometimes in manufacturing it might be better to be based on cycles or tests. Could be a use for the dataset run feature, but I haven't used the DSC modules since the labview 7.0 days.

[Ben]

---

craige wrote:

That answered my question. Just wanted to make sure I wasn't overlooking something. I understand that this is probably no small feat but it would be a nice feature for the future of DSC. Thank You!

---

THe DSC DB is 21-CFR-11 compliant so fudging the time stamps is bad bad bad.

Imagine if the the system was monitoring the storage conditions of the kidney you are about to recieve. Would you fell better knowing it was stored correclty and there is a legal paper trail to document it, or would you be happy knowing the storage was tracked in a spreadsheet that the person who gets fired if the kidney goes bad can edit after they get back from that two hour lunch break?

If you want to fudge the number the DSC DB is not the right tool.

Ben

[craige]

To clarify, DSC is only 21-CFR-11 IF you configure it as such (at least according to NI). I'm not performing a medical human use study so I have no responsibility to governmental authorities regarding datarecords or security. My question has been answered. I just don't think the Part 11 explaination justifies why i cannot change the dataset how I see fit.

[Ben]

---

craige wrote:
To clarify, DSC is only 21-CFR-11 IF you configure it as such (at least according to NI). I'm not performing a medical human use study so I have no responsibility to governmental authorities regarding datarecords or security. My question has been answered. I just don't think the Part 11 explaination justifies why i cannot change the dataset how I see fit.

---

Fair enough.

Ben