How do you time stamp trigger and gate data

[coolmoodster]

I have labview 7, windows xp, pxi6070e, scb-68,PXI-1042 NI-Daq system.

I am using the trigger and gate function to capture events with the start trigger threshold with a pre-data measurement (5 samples) and post datameasurement (5 samples).

The signal input is a 0.25hz (4 second period) signal with a 25% duty cycle. For 75% of the time, the signal is low at 0 volts. For 25% of the time, the signal is high at 1 volt.

My trigger is set on the rising edge with a threshold of 0.5V. As my trigger detects a high, it outputs data to a .lvm write file in increments of rising integers for example (1, 2, 3, 4 ....) instead of the real time of (0, 4, 8, 12, ...) seconds. Is there a way to overcome the increment function of th
e trigger and gate function or assign a time stamp to each triggered occurance? That way my triggered responses will have the time instead of increments in the .lvm file?

[Steven B]

Hello,

If I understand what you are wanting to do, I think the answer is no. There is no way for the hardware to give you that information. It would have to be a software function in order to convert the number of increments into the number of seconds before you write it to the file.

Hope this helps,

Steven

[coolmoodster]

Steven,

The trigger and gate in labview seven has pre/post samples that when tripped is sent to a file with the wrong date and time. In fact, the triggered signal is incremented with the external PFIO trigger system clock. I have it set at 4 seconds with a duty cycle of 25% high, 75% low. So if 20 seconds passes, the trigger and gate function will count 5 times whether a trigger occurred or not. I will get a number that is not associated with the time and date of the occurrance.

To overcome this, I got the computer clock time, formatted it to the style I wanted and then wrote it into the comments portion of the .lvm file. I also used the data valid function of the Trigger and Gate to write to the .lvm file only at specific triggered times.


This approach worked for a single trigger during the occurance. It works partially if there are multiple triggers during the time period.

The time period that I was interested in is the 25% high or 1 second. I would received multiple triggers during the 1 second from time to time. The time that was written for first trigger was correct. The second or third trigger time was incorrect, second trigger being 4 seconds later, third trigger being 8 seconds later (updated with the system clock). Haven't found a way to overcome this yet, will do later.

Derek