write time info to text file

[eesen]

Hi,
I am triying to write time information to a text file. I trie it in my computer. I run file.vi and a write the result to file record.txt (see the attachments) Results are nonsense.
I can not find the reason.
In second version, ı run Network Interrupt time measure file.vi in my RT target and ı record the result Network Interrupt time measure record.txt (see the attachments)
(Note that in order to run Network Interrupt time measure file.vi VMIC driver is needed) . When every interrupt comes , ı want to record that instant's time info. But
it records every loop count. There is case structure there and so it shoul not make a record at every loop count but only when an interrupt comes. What is the wrong
with these configuration

[Nadim R]

Hi,

I looked at your VI, file.vi and made some modifications.  I noticed that you have two while loops, the second of which is not needed.  I presume that you wanted to do a carrage return on each iteration, but why not include that onto the first while loop and remove the second.  I have attached the modified VI to this forum.  I believe it should work now 🙂

I hope this helps,


Regards,

Nadim
Applications Engineering
National Instruments

[eesen]

I use two while loop since writing file takes long time. So ı prefer to write firstly to RAM, then ın another loop ı read to file.Is this apporch wrong?

Another point, can you give a comment for real time part? (Network Interrupt time measure file.vi )

[Nadim R]

Hi,

Unfortunately I do not have your specific driver that is needed for your RT vi (Network Interrupt time measure file.vi).  What is the specific problem regarding this vi?  Regarding your file[1].vi, I believe a better approach would be to directly write to the file instead of writing to a memory location and then writing to the file.  If you leave the file reference opened and write point by point, I believe it will take a shorter time than to build an array or some sort of memory location and then write to the file.

I hope this helps.


Regards,

Nadim
Applications Engineering
National Instruments

[eesen]

The file[1] vi that you send does not work poperly either.Basically what i need is that i need time information. If you run file[1] vi with different loop rate yot see that time information is affected which should not. Get time vi does not work properly.

I need a way to get absolute time info in RT target.

(I am using  labview 8.2)

[NIJanell]

Hello Eesen,

I've looked at the file VI that you and Nadim have been discussing and made some minor changes in regards to error handling.  In this VI, you are asking for LabVIEW to take a time stamp each time the loop iterates, which is exactly what it is doing.  If you only want to take a time stamp when a certain event occurs, you will need to use an event structure, much like the other VI that you posted.  Unfortunately, we do not have access to the hardware that this other VI needs to run properly but it looks like it should work properly.

As far as the loop rate affecting the time stamp, that also seems like expected behavior.  You see, if the loop is not running fast enough, it may miss some interrupts causing longer amounts of time to pass between each recorded time stamp.

Have a great day!

Janell R | Applications Engineer

Message Edited by NIJanell on 01-30-2007 11:51 AM

[eesen]

Just forget about interrupts:)

Main point is that I need to record time information in my computer (OS=Wİndows XP) and in my real time target. Get time vi seems to not work properly.

Say that now time is:31.01.2007 12:13:45:,413  (year,month,day,hour,minute,second,milisecond)

And say that my loop is a timed loop and its period is 1msec. Then ı think that ı should record something as follow:

31.01.2007 12:13:45:,414

31.01.2007 12:13:45:,415

31.01.2007 12:13:45:,416

31.01.2007 12:13:45:,417

31.01.2007 12:13:45:,418

31.01.2007 12:13:45:,419

Am i wrong?  But ı record

31.01.2007 12:13:45:,413
31.01.2007 12:13:45:,413
31.01.2007 12:13:45:,413
31.01.2007 12:13:45:,413
31.01.2007 12:13:45:,413
31.01.2007 12:13:45:,413
31.01.2007 12:13:45:,413
31.01.2007 12:13:45:,413
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,429
31.01.2007 12:13:45:,445
31.01.2007 12:13:45:,445
31.01.2007 12:13:45:,445
31.01.2007 12:13:45:,445
31.01.2007 12:13:45:,445
31.01.2007 12:13:45:,445

I read a message about my problem:

Hi,
I was able to investigate this further. As it turns out, LabVIEW RT's "Get Date/Time in Seconds" function does not keep real-time in the RTOS - it falls behind. Format Date/Time String, and Get Date/Time String are also affected. The problem is that when the real-time OS runs code, it gives higher priority to this code, and the real-time OS prioritizes its bookkeeping routines lower. One of the bookkeeping tasks of the real-time OS (or any OS for that matter) is to keep system time. In LabVIEW RT, this is done with interrupt service requests, which get ignored when the real-time OS is busy running real-time code. However, note that when a system is rebooted, the system time is reset to be correct again.

The Tick Count function however does not display this behavior. This is because it gets its value directly from the hardware register and not via a service request. So one solution for your case it to use the Get Date/Time function to get the initial timestamp. Then use the Tick Count function to get subsequent timestamps by using the initial time as an offset.

Another solution is to use the timestamp VIs that use values directly from the hardware register, as the Tick Count function does. These VIs use low register-level functions to ensure the most accurate timing. In LabVIEW, go to File » New... » VI from Template » RT » NI Timestamp Code Timer.vit and open that template. This template uses the timestamp VIs I'm talking about. They are locate in C:\Program Files\National Instruments\LabVIEW 7.1\vi.lib\addons\rt\_RTUtility.llb if you want to access them directly. But the template will show you a good use-case.

So you can either use the Tick Count function as I described above, or you can use the timestamp VIs. Both will provide you with a valid work around. Please let me know if you need more help with this.

Have a great day!

Anu Saha
Academic Product Marketing Engineer

I trie first solution mentioned above but it does not work. I can not find the template vi which is stated in second solution. (Perhapse because of the ver of LabView) Can you support another solution for me?

I write many time about my problem but still i can not get an answer:(

[GerdW]

Hi eesen,

at least for Windows OS the 'Get Time' is limited to 16ms resolution! That's why you get those 'interesting' 🙂 timestamp values...
There are other threads discussion this 'feature'...

[eesen]

Thank you for your explanation about Windows. I did not now about 16msec resolution .What about RT?

I read messages about this subject. I can not find a satisfactory answer:(

[beavercreek]

Eesen, I had similar issues, but assumed it was because my loop time was faster than 1msec.  (ie I thought I was gettting something like 12 loops per msec).  If you don't need the speed, you could drop in a "wait for next msec multiple" vi, feed it a 1 as a constant, and that will slow your loop down to around one per five msec.  But I digress, My work around is currently the attached PNG file.  Do you have a card with a counter?  if so you can use the 20Mhz system clock as a source for edge counting and use your counter to keep track of time (note that in my case the counter is only 24 bit, so the output of the DAQmx read was overflowing and thus the need for the case structure in the middle to handle the overflows).  This code did not slow down my while loop appreciably.  I store the cumulative time (in µs) to my data array (its the blue wire going up out of the PNG). 

Issues with this method:  1)20MHz clock has a quality of 100ppm there for the actual clock speed could typically vary between 19998000 and 20002000.  2) I could be accumulating round off error from the use of a real data type after the divide by 20

Anybody spot more issues with my method?