Problem with Reentrant VI using Get Date/Time

[schuller]

Hello,

I've written a library for logging and tracing based on a queue.

Clients can call a reentrant VI by reference (called "trace.vi")  to put trace elements into the queue while a parallel background task is processing the queue.

In order to add a timestamp to each trace element I use a Get Date/Time object in my reentrant "trace.vi" before putting the trace element into the queue

But there's a problem with these timestamps.

I often get a couple of consecutive trace elements with exactly the same timestamp (resolution is milliseconds) and I'd expect to see at least a small difference.

First I thought the poor resolution of the Get Date/Time object might be the cause, but after a few sample VIs I found out this isn't true.

Any ideas what might be the problem here?

Thanks,

Dietmar

[moderator1983]

Resolution of any timing function is in milliseconds, when running on Windows.

---

@schuller wrote:

First I thought the poor resolution of the Get Date/Time object might be the cause, but after a few sample VIs I found out this isn't true.

---

How you concluded that...???

Why exactly are you using reentrant VI and not an 'Action engine', because if the issue is because of poor resolution, there is nothing can be done... Probably along with the timestamp you can also include serial number while adding 'Trace'.

[schuller]

Have a look at the sample VI below, it shows that a resolution of 2msec is possible.

I'm using a reentrant VI and not an 'Action engine', because I have multiple threads in my project that should be able to trace at the same time.
Race conditions are avoided by accessing a queue in a reentrant VI.

[moderator1983]

---

@schuller wrote:

Have a look at the sample VI below, it shows that a resolution of 2msec is possible.

---

Even I had mentioned in my previous reply that:

---

@moderator1983 wrote:

Resolution of any timing function is in milliseconds, when running on Windows. 

---

But the problem that you're facing is because, there could be a possibilty when two or more clones (reentrant VI's instances) were called and the queue were updated within very short duration (within a fraction of millisecond)... Now as LabVIEW timing functions have resolution upto milliseconds and not greater than that, you'll see different traces being inserted at same time.

[Vans]

Hey Dietmar,

how did you configure your VI? If you right-click on the icon of a VI you have access to the "VI Properties". Choosing category "Execution" you have three option to set the reentrancy of your VI. Which one do you use?

Your post is called "Problem with reentrant VI..." if you like to get different time stamps you have to choose non-reentrant execution. Be sure that your VI needs more than one ms to execute. If this is not the case you may also get four idential time stamps.

Perhaps you can post an example code?

Kind Regards,

Vanessa

AE Germany

[DFGray]

If you are getting the same millisecond value, and you really need more resolution, consider using the high resolution timer.  You can find it at <vi.lib>/Utility/High Resolution Relative Seconds.vi.  With some appropriate code, it can be used with the millisecond timer to give absolute times.  As usual, this resolution must be taken with a grain of salt, since modern multitasking operating systems have jitter on the order of milliseconds.

[schuller]

In VI Properties > Execution I tried both "Shared clone reentrant execution" and "Preallocated clone reentrent execution".

As I said, the reentrant execution is required because of multitasking and the VI is called by reference.

As you can see from the snippet below, I add a timestamp to a cluster containg trace information elements and put everything into a queue.

A millisecond resolution is sufficient for our purpose.

I just can't believe that traces with the same timestamp are really happening in a 1msec timeframe.

I rather think the reentrant execution is not working like expected.

[Vans]

Hey,

because of the missing type definitions and VIs I cannot reproduce your problem. Did you measure the execution time of your VI? Simply add a flat sequence around your code and put one frame before and one after your code. Calling the ticker twice you get the execution time within ms accuracy. There is not much code inside your case structure. How long does it take?

How does your caller VI look like? How often do you call this VI? How many cores do you use for the calculation?

Kind Regards,

Vanessa

[PhillipBrooks]

Just a suggestion; rather than calling the "Get Date/Time In Seconds" function for the input to "Format Date/Time String"; leave the input to "Format Date/Time String" unwired; it will default to the current date/time.

Just a guess but maybe LabVIEW is somehow grouping the near simultaneous calls to the "Get Date/Time In Seconds" primative into a single OS call.