bug Bug: Format Variant Into String__ogtk.vi doesn't handle Timestamps

[jed]

Format Variant Into String__ogtk.vi doesn't handle timestamps, you get an "Unexpected Datatype" error, as the TDEnum reports it as a Waveform.

I have put in place a fix that seems to work without issue, but I can't be sure that it doesn't falsely detect timestamps when processing other types of data. Is this something that can be integrated into the release? Up to this point I just have to remember to copy my version over the OpenG version. It would be nice to not forget and break my code every time I move to a new machine!

-jed

[jgcode]

  On 5/17/2011 at 8:33 PM, jed said:

Format Variant Into String__ogtk.vi doesn't handle timestamps, you get an "Unexpected Datatype" error, as the TDEnum reports it as a Waveform.

I have put in place a fix that seems to work without issue, but I can't be sure that it doesn't falsely detect timestamps when processing other types of data. Is this something that can be integrated into the release? Up to this point I just have to remember to copy my version over the OpenG version. It would be nice to not forget and break my code every time I move to a new machine!

-jed

Thanks for posting this bug and your code update jed.

This issue will have to be further investigated however,

You can track this bug here: ID: 3303663

Cheers

-JG

[Bob Schor]

I have found a "variant" of this bug myself, and was about to post it (I have not yet figured out a solution ...). I was using Get Array Element Default Data and passed in an array of clusters. If the cluster included a TimeStamp, the OpenG routine would fail (actually, the failure was in the sub-VI Get Default Data from TD), also indicating "(Unexpected Datatype <Waveform>) Get Default Data from TD_ogtk.vi:2 in Get Default Data from TD_ogtk:vi:1->Get Array Element Default Data_ogtk.vi->TEST OpenG Problem.vi" (the last was my test routine). If I eliminated the timestamp from the cluster, the error disappeared.

I think this is a "bug", not a "feature" (or if it is a feature, it is certainly an un-documented one). The problem seems to be the TimeStamp not being handled/recognized by the OpenG routine.

Bob Schor

[Bob Schor]

<Admin>Post Merged into this Topic</Admin>

I recently tried the OpenG routine "Get Default Data from TD", hoping to be able to parse a cluster all of whose elements were "simple types" (numerics, strings, paths, booleans, timestamps). I discovered that presenting a timestamp to this routine resulted in an error 1, with the message complaining about a "waveform type". I originally thought this was a "bug", but now realize that it is a "missing feature".

I had considered a Timestamp as a simple type, not realizing that LabVIEW considered it as a sub-type of Waveform. While I didn't want to implement code to handle "real" Waveforms (which are definitely composite types), I decided to add an "exception" to properly handle Timestamps. The fix is simple -- add a "Timestamp" case, test the cluster element "# Elements" (which is really "Sub-Type") for 6 = Timestamp. If it is a Timestamp, handle it as with any of the other simple types. If not, generate an error message (I changed the message to refer to "Unsupported Waveform").

My code now works with this modified version of the OpenG routine.

Bob Schor

[mje]

I believe all of these issues arise from the OpenG library not being able to distinguish between timestamp and waveform types. In my opinion the legacy OpenG VIs which now have NI equivalents should be retired to avoid errors like this.

[jdunham]

  On 5/24/2011 at 1:07 AM, mje said:

I believe all of these issues arise from the OpenG library not being able to distinguish between timestamp and waveform types. In my opinion the legacy OpenG VIs which now have NI equivalents should be retired to avoid errors like this.

What's the NI Equivalent for Format Variant Into String__ogtk.vi?

[mje]

  On 5/24/2011 at 5:32 PM, jdunham said:

What's the NI Equivalent for Format Variant Into String__ogtk.vi?

There isn't one. But the bug in Format Variant Into String__ogtk.vi arises from the use of a legacy VI in which gives rise to the error. Sorry, haven't used the OpenG libraries in a while and don't have them currently installed, but the offending VI is the one circled below:

I believe the NI replacement would be VariantType.lvlib:GetTypeInfo.vi and its associated typedef control.

I'll also point out that it is pretty trivial to implement your own Format Anything method once you start using the GetTypeInfo call. A simple case structure on the returned type and you're off to the races. Here's some code I've been using for the last year or so:

Wouldn't be too hard to extend that to duplicate all the functionality of the OpenG VI.

[jdunham]

  On 5/24/2011 at 6:58 PM, mje said:

I believe the NI replacement would be VariantType.lvlib:GetTypeInfo.vi and its associated typedef control.

I'll also point out that it is pretty trivial to implement your own Format Anything method once you start using the GetTypeInfo call. A simple case structure on the returned type and you're off to the races. Here's some code I've been using for the last year or so:

Wouldn't be too hard to extend that to duplicate all the functionality of the OpenG VI.

Thanks! We use some other custom "format anything" VIs and we were handling the timestamps with custom code. Thanks for pointing me at the new VI.

[jed]

  On 5/24/2011 at 7:12 PM, jdunham said:

Thanks! We use some other custom "format anything" VIs and we were handling the timestamps with custom code. Thanks for pointing me at the new VI.

Hi Jason,

Is there some way that I can contribute to a new release? If I moved through the code and replaced the lagacy with the new function, could I then submit the code for you guys for a release? Seriously, I do a LOT of work with TS and these formatting tools, and if I forget to overwrite this library Iget phone calls late at night!

Jed

[jdunham]

  On 6/20/2011 at 5:24 PM, jed said:

Hi Jason,

Is there some way that I can contribute to a new release? If I moved through the code and replaced the lagacy with the new function, could I then submit the code for you guys for a release? Seriously, I do a LOT of work with TS and these formatting tools, and if I forget to overwrite this library Iget phone calls late at night!

Jed

I was actually talking about my own code, but I'd be glad to contribute it to the OpenG too. This code handles the Waveform data type, checks if it is a timestamp, and formats it in an ODBC-complaint string. The other thing I would say is that it's important to store the string in UTC rather than the local time zone,. My code doesn't do by default, but it could be fixed, though if I remember correctly this was harder to do in previous versions of LabVIEW and the toolkit probably needs to be 8.0 compatible. I'll try to get my code together later today.

Jason

[Bob Schor]

I posted a variant of this bug a month ago (I found it in "Get Default Data from TD"). As has been noted above here, the underlying problem is that the OpenG "Get Header from TD" returns a Waveform Type for both Waveforms and TimeStamps. The OpenG Type Definition Enum doesn't seem to include TimeStamps (as LabVIEW now does), so the "patch" is to add code specificly for Waveforms, then test to see if the number of elements is 6, whence you treat it as a TimeStamp.

It would be really nice to have these fixes added to the current OpenG Variant library, so they would be "automatically pushed" to those of us using OpenG. If the patch was to simply recognize the "special case" of a Waveform that really is a TimeStamp, then it shouldn't "break" existing code (since anyone who used it with a TimeStamp type would have already gotten an error, hence if you didn't have an error before, you shouldn't have one now). Alternatively, coming out with "Version 2" of these routines that use a Type Definition Enum that is consistent with the current LabVIEW enum (which has a separate entry for Waveform and TimeStamp), and making the OpenG code return the "correct" value, would also be a way to go, though this would potentially be a "bigger" change, and could potentially "break" existing code. Maybe rename the VIs and use slightly different icons?

Bob Schor

[jgcode]

Please continue discussion on this issue so as I would like to add support for timestamp and release an iteration in the near future.

Cheers

-JG