Errors Using LabVIEW Timestamps in TestStand

[djdewitt]

LabVIEW Timestamps are presented in TestStand as Strings. It seems as if TestStand will output a LabVIEW created "Timestamp" using the same format that it was created in. However, I've noticed one issue and one outright bug with the conversion process:

1) TestStand doesn't seem to like to use any more than 3 digits of precision on fractions of a second in the String representation of the Timestamp. Therefore, any Timestamp that is more accurate than this will get rounded not just in the TestStand output, but also in any LabVIEW module that uses the TestStand output as an input parameter. Is there any way to increase the precision of the TestStand representation (preferably to 6 digits)?

2) If a LabVIEW Timestamp has leading zeroes in the fractional seconds, these leading zeroes will be removed from the TestStand string. For example, a timestamp of 01:35:45.005 will be displayed in TestStand as 1:35:45.5 - this also extends to when these values are used in LabVIEW adapters after the fact. TestStand legitimately believes that 45.005 seconds is 45.5 seconds. Is there a patch coming to address this?

Thanks for looking at these issues,

Darryl

[djdewitt]

---

@djdewitt wrote:

For example, a timestamp of 01:35:45.005 will be displayed in TestStand as 1:35:45.5 - this also extends to when these values are used in LabVIEW adapters after the fact. TestStand legitimately believes that 45.005 seconds is 45.5 seconds.

---

I did some more testing and it turns out that while TestStand shows the Timestamp as 45.5, if you insert the String back into LabVIEW as a Timestamp it will appear as 45.005. So TestStand is only displaying 45.5 but storing 45.005. This is still an issue as anyone reading the test report would see this mistake and assume the test case was faulty.

[Al.B]

Hi Darryl,
 
Thanks for providing this feedback.  Both of these issues have been reported to R&D:
 
1. millisecond precision of timestamps - This is currently the designed behavior, but I have created a Bug Report under ID 363434 to note that this precision is less than desired.
2. loss of leading zeroes - This issue has been reported to R&D as Bug Report ID 363405 and is currently under investigation.  Please let me know how severe this is for you to help us prioritize it appropriately.

[djdewitt]

The issue with the zeros being incorrectly displayed could be difficult to explain to customers who read our test reports. The inconsistency may result in problems during our review processes. It would be nice to keep the precision as accurate as it is defined but our current application doesn't currently need microsecond precision. Future applications will need to consider microsecond precision, however.

[Al.B]

Hi Darryl,

You may already be aware, but I also want to note that you can work around these issues by using a string rather than a timestamp to pass the data between LabVIEW and TestStand, performing the conversion in LabVIEW.  You can convert the timestamp to a string with the desired format using the Format Date/Time String VI in the timing palette.  (to get more precise seconds, you can use something like "%S%6u" in your format specifier).

[Al.B]

The second issue addressed in this thread (loss of leading zeroes ni timestamps) has been addressed in a recent set of TestStand patches for TestStand 2010, 2010 SP1, and 2012.  These patches are available through update service and online.  For more information, see the thread below:

New Patches available for TestStand 2010, 2010 SP1, and 2012