Leaderboard

Good news! There's a new release available on vipm.io with a fix. https://www.vipm.io/package/oglib_string/#4.1.1.16 The issue We were able to figure out what the issue is. It appears to be caused when using a NI Linux RT target. The problem seems to happen when LabVIEW compiles/saves 1D Array to String for running on an NI Linux RT target. Then, when you open and run 1D Array to String on Windows, it isn't always getting recompiled correctly. More Details The current implementation of 1D Array to String uses an EOL constant () to build a regular expression -- the EOL is platform dependent (it's CRLF "\r\n" on Windows and LF "\n" on Linux and Mac). My guess is that somehow the LabVIEW compiler constant folded the regular expression that is the concatenation of the EOL constant and "$" into "\n$" (match a Line Feed at the end of the string). However, on Windows the EOL character we are looking for is a CRLF ("\r\n") at the end of the string. So, if we were searching for "\n$" at the end, the before string would have a "\r" at the end of it, which is what we're seeing (when the bug is happening). Editing and re-saving this VI on Windows causes it to be recompiled and the regular expression get's correctly compiled and constant folded into "\r\n$" A More Robust Implementation (work-around) Looking at that 1D Array to String code, I don't really love how it's building the regular expression using an EOL constant. I think that a more robust solution would just build the regular expression as "[\r\n]+$" (one or more Carriage Return or Line Feed characters at the end of the string). This would be platform independent and not suffer from the compiler bug we're discussing here. There's a new release available on vipm.io with this fix. https://www.vipm.io/package/oglib_string/#4.1.1.16 [Update] I've opened a service request with NI to dig into it some more. I'll post updates, once I find out more.