Jump to content

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


Recommended Posts

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

post-143-0-44403300-1305664256_thumb.png

Link to post
Share on other sites

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

Link to post
Share on other sites

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

post-9586-0-11015500-1306166396_thumb.pn

Link to post
Share on other sites

<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

post-9586-0-50410200-1306178623_thumb.pnpost-9586-0-39643600-1306178624_thumb.pn

  • Like 1
Link to post
Share on other sites

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.

Link to post
Share on other sites

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?

Link to post
Share on other sites

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:

post-11742-0-98711700-1306263023_thumb.p

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:

post-11742-0-70467300-1306263434_thumb.p

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

Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 4 weeks later...

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Jim Kring
      [Update: NI Bug 974336]
      There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here).
      Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet.
      Coerce to Variant Fail (LV2019).vi


       
      Note that adding another element to the outer cluster causes the problem to go away.


    • By Bas de Jong
      Hello, I'm trying to display an animated GIF on the front panel. This gif should be loaded programmatically based on some user event. My google search led me to use the OpenG Read GIF File (Animated)__ogtk.vi file. However, loading a GIF is extremely slow. It takes almost 20 seconds to execute the vi when I load the attached GIF (I found randomly on the internet). Is this normal? And if so, is there a way to load a gif faster? Because I need to load several and I cannot afford to load maybe 2 minutes only for the gifs.

    • By ShaunR
      Maybe others have seen this but I only became aware of it recently so I apologise if there is already a CAR for it.
      The following demonstrates a difference in behaviour between LabVIEW 2017 and previous versions (back as far as 2009, maybe further).
      The VI registers an event when it starts (in the timeout case) and generates a user event when the Increment button is pressed.
      The expected behaviour is that the counter will increment by one every time the button is pressed. This is the case for LabVIEW versions prior to 2017. In 2017, the user event is never fired, nor is there an error emitted by the generate user event.
      To get the VI to operate as expected in 2017; change the event refnum tunnel to a shift register. This seems to indicate that the refnum prototype is stomping on the dynamically allocated reference whereas in previous LabVIEW versions it would not. Note also, that when using the shift register, the cases do not need to be "wired through" as would be expected with similar functionality in a normal case statement.
      evnt.vi
    • By A Scottish moose
      Hey everyone,
       
      I am working on a backup function for a test executive.  The backup uses the 'class to XML' vi to create an XML string and then save it to a file to be reloaded later. All of my test specific information lives in the class (or one of it's children).  I like this functionality because it makes backup and reload brainless.  It just works.... until now... I've got a test class for my current tester that's grown rather large.  Everything works fine, until the tester loads some waveform data into either of the waveform arrays.  Without data in this field the class reloads just fine, otherwise if fails and says the XML is corrupted.
       
      As you can see in my backup vi I have built in a work around that flattens the waveform arrays to strings, drops them back into the class private data, deletes the waveform arrays and then writes the class.  This works! Much to my surprise both waveform data and the rest of the class data are written to file and reloaded without error.  
       
      Does anyone have any knowledge or experience with this? 
       
      Cheers,
       
      Tim


    • By fennectp
      Hi all,
       
      I've got a customer that wants to zip/unzip files on their cRIO-9035, so I had them playing with the OpenG Zip tools to see if it would fit their needs. Although they've found that they can zip files on their cRIO just fine, they find that they get disconnected from their RT target and the shell shows the following error message:
      LabVIEW caught a fatal signal 15.0 - Recieved SIGSEGV Reason: address not mapped to object Attempt to reference address: 0x0x10000000 stdin: is not a tty  
      The zip file they're testing with includes two simple .txt files with short strings in them ("booya" and "booya2"). This file unzips just fine on the host PC with the "ZLIB Extract All Files To Dir" VI, but when copied over to the cRIO and unzipped via the same VI, it only unzips the first text file and the resulting file doesn't have any text in it.
      I've attached a copy of the project and the zip file I used to reproduce this behavior using a cRIO-9033 that I had on hand. (The only thing I can't provide is the cRIO >_<)
      Could anybody tell me what I'm doing wrong? Any suggestions as to what other workarounds I could take to zip/unzip files on a LinuxRT target would also be very much appreciated!
       
      Regards,

      Tamon
      Unzip on cRIO-9033.zip
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.