LabVIEW
Data Types: String vs. SubString
@RavensFan wrote:
But when the help puts parentheses around the "sub" part, that is implying some sort of option to the "sub", like it could be string or it could be substring and it doesn't care. Yet it does care.
I think a sub string can be the entire string while a string can not be a sub string. That doesn't change it's type, it's still a sub string, but when pointing to the entire string the "sub" might be confusing, and was therefore put between parentheses. Definitely confusing as it is...
LV tries to hide the sub strings from the user. Usually it's very successful, and it is very convenient. But here it doesn't work right, and things get confusing.
Same trick is used with arrays (subarrays, or (sub)arrays), although I don't know a situation where the compiler fails to auto-convert.
Not sure if it's a TDMS function problem or a compiler problem...
Search LabVIEW like a graph! 
@CoastalMaineBird wrote:
What exactly is a "(Sub)string"?
I would imagine (I have no inside info) that:
--- a STRING is a self-contained blob - an array of characters with a length word in front. You may use it at will.
--- A SUBSTRING is a reference to ANOTHER string, along with an offset and length word. You may NOT use it at will (otherwise you could destroy the original). It must be "promoted" to a full string before you can use it.
The MATCH PATTERN might produce substring outputs, since it doesn't know which one(s) you're going to use. Rather than create full string objects (allocating memory), it creates a substring. The compiler should "promote" the ones it uses, but fails to do so in this case.
Almost! A substring is perfectly fine to be used read only. The dataflow compiler just has to make sure the original string buffer is not modified before any potential substring read access has finished. LabVIEW has pretty complex algorithmes to allow such optimizations.
Only when the consumer somehow (potentially) may have to modify the buffer does it need to promote it to a full string. That SHOULD happen automatically though.
I would suppose that the quick fix would be simple. Fix whatever messup the TDMS input flag indication for that parameter causes. There might be complications though as that quick fix might disable several potential optimizations. So a true fix is likely a much more complex adventure (with various potential side effects that could cause new problems elsewhere).
