Leaderboard

OK, here's a game plan I think will work to fix the issue, yet without changing the behavior of the code. Since LV2009 (the version of LabVIEW the package is currently developed in) doesn't have the "Separate compiled code" feature), we'll implement a work-around by creating a special subVI to get the EOL that is not affected by the bug (Note: ignore the fact that the screenshot shows this VI open in LV2020). We'll do this by calling the Array to Spreadsheet string function with empty string inputs. It appears from testing that this does not get constant folded (or at least is not impacted by the bug). And, we'll cache this value for performance on subsequent calls. It'll all be packaged into a tidy little sub-VI, so that it's obvious what we're doing and why. I've released this as version 4.1.2.18. Moving forward, we'll upgrade the sources for this package to LV2013 and mark all the VIs for "Separate from compiled code". We would have done that sooner, but there was a build issue in 2013, due to the fact that NI introduced a VI called "Trim Whitespace.vi" that shares the same filename and thus collides with the OpenG VI (in source code form before it's name mangled in the build process). But, that's a different story (and I think we can work around it during the build process)...

Here's another potential "fix" that simply aims to work around the compiler bug and doesn't deviate from the original implementation (which helps avoid any unintended changes in behavior that might be caused by a new implementation).

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.

Shameless plug: Proper Way to Communicate Over Serial