Triggered streaming stucks after one hour


cromda

Recommended Posts

Hello,

I use a LabJack UE9 connected trough Ethernet to monitor DCF77 signal (a radio atomic clock near Frankfurt in Germania).

The signal consists in one pulse per second (except on the 59th second in a minute) and the width of the puklse is either 100 ms or 200 ms.

In order to record the arriving time of the DCF77 pulses, measured by the UE9 system timer :

- I created two timers (SYSTIMERLOW and SYSTIMERHIGH), through a script in initialization sequence, .

- I connected the DCF77 signal to FIO2.

6 channels are then created in DAQFactory (132 (V supply), 133 (ambiant temperature, 200,224,201 and 225, the 4 words of the system timer @ 750 000 Hz).

Acquisition is then configured to a triggered streaming of those 6 channels (I was guided by the

Link to comment
Share on other sites

1) what is your scan rate? As it says in 9.2.4, in triggered mode the times won't be accurate. Do you get the same time for consecutive reads, or just the same time for the 6 channels in a single scan?

2) I don't know. The LabJack guys would have to address this. They change / improve things rather often and we sometimes can't keep up. I'd certainly like to know, though, so we can update the guide.

3) Again, not sure what is happening, but the LabJack guys might.

That all said, I personally would not do this the way you have done it. I'd instead at least try and use the 32 bit period in timer, reading it in polling mode (not streamed) a few times a second, and then using the result to increment off a base fixed time. The only disadvantage would be if DAQFactory missed a reading, which would only happen if Windows somehow hung (or you wrote an infinite loop in a sequence I suppose). You could also use the Timer Stop mode to count 59 pulses each minute too.

Link to comment
Share on other sites

Thank's for your answer,

1) As mentionned, the scanrate (triggered) is of about one scan per second. The time I get is a few second after the start of the triggered streaming. The time is the same for all conscutives scan and for all channels in a scan.

Off course I red from 9.2.4 that this time is inaccurate with Triggered Streaming. But I think that as the time is the same for all channels and and all scans, it prevent from graphing properely one channel versus another.

If the time values were inaccurate but differents and increasing it would possible to graph properly one channel versus another (?).

2) As mentionned, the

Link to comment
Share on other sites

DAQFactory time should not be affected by the NTP time updates. It only uses the windows system time for the absolute time on boot. After that it counts clock cycles and so isn't affected by time changes. Untriggered stream would work, but would only be precise to about 1/60,000 of a second since that is the max scan rate. You could then use the DAQFactory search() function to find your peaks much more efficiently than you could using Delphi and with minimal overhead.

I'm a little confused why you are doing this. Are you checking the precision of the DCF77 pulses, or the precision of the UE9 clock? My method would work in both cases really. Remember, the Period In timer mode is still using the UE9 time, you are just not getting absolute time.

As for your time stamp issue, try just plotting channel vs. point(channel) instead, setting the bottom axis to Lin. This will at least space your data out on the graph.

Link to comment
Share on other sites

UE9 was connected by Ethernet. I connected it through USB and triggered streming acquisition have been going on now for 3 hours.

Si I think that the problem is due to the Erthernet connection.

About graphing I tried to use point(channel) on X axis, but I just obtain the same result as with Time : an horizontal strait line at the height of the last acquired value.

Link to comment
Share on other sites

The LabJack guys found the solution :

http://www.labjack.com/forums/index.php?sh...c=4244&st=0

The problem was related to a defaut timeout communication wich is quite small (1,5 s).

On LabJack advise, I forced this timeout to 10 s with that instruction in the initialisation sequence :

AddRequest(UE9,LJ_ioPUT_CONFIG,LJ_chSTREAM_COMMUNICATION_TIMEOUT,10000,0,0)

The triggered streaming runs now under ethernet for hours without stopping.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.