Leaderboard

Well, it depends. At what speed were you, the observer, traveling with respect to the execution speed of the block diagram?

"With over 900 years of motorbike building prowess behind them Triumph have created two wheeled motorbike classics." "Argument juice is added from the argument lobe of the female brain allowing the finished bike to change direction in an instant."

Confirmed. I remember in the past with things like this I've serialized them as strings. In fact I believe a DAQmx Name inherits from the native string type because you can wire up a DAQmx Name to anything that uses strings and vice versa. I believe the logic is Names are system specific so are treated somewhat like refnums? Though it doesn't make much sense why they'd serialize the name to XML but not deserialize it. Who knows. Anyways chances are your real use-case involves a class which hangs onto other state data which also might not need to be serializled, stuff like refnums, cached data, etc. When depending on native LabVIEW serialization-- which is very rare for me-- I often define a private data type/class which I create to hold only the information that needs to be serialized then throw that construct at the LabVIEW primitives. In your case I'd swap out the Name with a string.

Accurate. You keep using that word. I do think it means what you think it means. Precise, sure, but accurate, no. Not yet anyway. Of interest, why do the fractional seconds truncate rather than round? If using the format in your signature (%3u) I get 2013-03-18T20:40:36.8988289833068847Z current time 2013-03-18T20:40:36.898Z formatted time

You should be able to use the "format into string" and "scan from string" functions to store a human readable timestamp in an INI file with considerable accuracy. Try this format string: %^<%Y-%m-%dT%H:%M:%S%16uZ>T modify the 16u portion to set the fractional seconds. ISO-8601 Persistent Timestamp.vi LabVIEW's 128 bit timestamp is accurate to 0.05421010862427522170... attoseconds http://www.ni.com/white-paper/7900/en

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Automated-creation-of-polymorphic-VIs/idi-p/2111968 Make sure to Kudo it ================== Now to the idea of generics, I think one thing that would be help along these lines, would be to be specific of the "Killer App" that's not even possible without generics in LV. One of these things that Brian Powell mentioned recently that made all the difference to me, is that we've got a limited number of things that we can focus on, and those can be the things that are not possible at all, or those things that we can do, but want easier. Sure, life would be grand if we could do everything, but this is a much much harder problem to solve than you might imagine. And when I say 'solve' I mean, do right, not make possible with a Multitude of bugs and limitations and gotchas (including corrupting your codebase) So when it comes to having this feature, it would likely take a huge chunk away from making the impossible, possible. But if you make a case where this is a huge benefit which is completely impossible, things start to get interesting. So if you've got one of those, or even several, Make Them Known. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Provide-a-better-way-to-implement-a-polymorphic-VI/idi-p/920487 http://forums.ni.com/t5/LabVIEW-Idea-Exchange/C-like-Class-templates-for-Labview-classes/idi-p/1714078 Wish I had a better answer, but as an aside, if this is something not going into a product and you'll just use to make your life developing other code possible.....you might want to ping me offline