[Bug?] DSC - Returned Timestamp from 'Read Alarms.vi' Query is Corrupt

[jgcode]

[LV 2009]

Howdy!

I have a returned timestamp from a DSC query using Read Alarms.vi that came back "empty"

On comparison to an "empty" timestamp (default value) taken from the Control Palette - they do not match.

Further formatting to a DBL and a string shows that the DSC timestamp is misleading and corrupt.

Additionally when you click on the Set Time and Data calender-glyph button for a default timestamp from the Control Palette you get the following: 

Doing this from the DSC constant made into a control gives this:

So the timestamp from the DSC seems corrupt and I can't test if its empty like I normally would.

Don't know if its the case for other VIs returned data, as haven't checked.

Is this a bug?

[Ben_S]

jgcode,

Thanks for the info and example VI to run! Upon running your VI I see the same behavior that you do, however, I am unable to recreate it on my own.

1. What DSC function are you using to get the Timestamp Constant?
2. What steps can I use to create the situation that you are showing in your VI?

[Ben_S]

jgcode,

Also, What OS are you using?

[jgcode]

Hi Ben 

Thanks for your reply.

As per the thread title I was running the Read Alarms.vi.

The platform is Windows 7 Pro.

I didn't stick the code up that generated the Query with but it was a simple: Read Alarms from these Shared Variables. 

But if it helps let me know and I will post it.

My workaround at the mo is to compare the corrupt timestamp OR an empty standard one (just to be safe).

However, its seems like a bug to me??

Cheers

-JG

[RavensFan]

I decided to create the subVI.  I backsaved it all the way to LV 8.0 in case any older versions have a problem.

One other discrepancy I found in the clusters besides the swapped elements is that the refnum in the Historical palette uses a U32 long integer, while the functions in the Alarms and Events palette use a U64 quad integer for the refnum.

[RavensFan]

I'm sorry.  I replied into the wrong thread.

See here for a better version of the VI in the correct thread.

[Ben_S]

jgcode,

I figured you were using the "Read Alarms.vi", but I wasn't able to get the funky timestamp from it, that's why I asked what DSC function you were using. I was creating constants/controls from the terminals of all the VI and wasn't having any luck, I'll see If I can get the bad timestamp by doing what you said, "Read Alarms from  Shared Variables."

Can you check the shared variable properties to ensure that timestamping is enabled for them and any other variable they may be bound to?

[jgcode]

Hi Ben

The funky timestamp is from a Query performed:

I registered for alarms using the User Event functions (via shared variables)

When an User Event occurred I called Read Alarms.vi and checked if any alarms in the returned query were Ack'd or not (I wanted to filter out the Ack'd alarms).

I did this by comparing the timestamp - if the alarm was not Ack'd then it has an empty timestamp - or in this case the funky one.

Does that help?

Cheers

-JG

[Ben_S]

jgcode,

Yes! that does help. I am able to replicate the issue now. I will let you know what I find out by further investigating this issue.

[jgcode]

Cool, look forward to your reply.