Why doesn't my compact field point file handle files as expected

Question

Before I add this to my LV2011 Whinge Thread I thought I would give the forum a go at this one.
This is a 3 step challenge:
Challenge 1, Spot the difference in the 2 pieces of code
Challenge #2 Explain why this is happening
Challenge #3 Find me a workaround.
Challenge #4, Give me a good reason to continue to use Labview......
Background:
This code is tested and works on a PXI-8108
This code Does Not work on a cFP-2220
iTm - Senior Systems Engineer
uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT
Attachments:
mytest.vi ‏12 KB

Answer 1

Timmar wrote:
Jarrod,
First let me thank you for the late night post, This way this "behaviour" will ony destroy a small ammount of my Sunday.
My Code is part of a much, Much bigger codebase that is used in multiple programs on multiple  platforms (Windows included)
Based on your advice, I should make the change below:
*Yes I know the folder names are differernt, I have corrected this already.
I will check it out tomorrow morning (Sunday) and see if it works.
This code has migrated from 8.5, I am not sure if it supported Path data types in config files.
/* Start Rant
1. My included block diagrams show the "appended array" indicator with identical data for both metheds.
I consider myself to be an experienced programmer and logic would say that I should expect the same result with the same data. They both should either be bad or good, not one of each.
The config file contains the text c:\\meridian\\holding which should be cFP friendly.
2. Why are the 2 platforms different?  I don't believe that I should have to change my config files as I move between platforms. (Looks like a Linux Base vs DOS Base) - Very confusing
1) Path differences between platforms is probably one of the single most reasons multiplatform libraries fail in one way or the other. A large part of cygwin and even larger part of MSYS are dedicated to trying to make those differences invisible for the tools that work inside their environment yet they all have the problem that they run sooner or later into contradicting requirements and can't make it fully seemless. LabVIEWs approach is one of the better approaches in that respect.
2) The Path control stores the paths in a platform independant format, but displays them in the format of the host system it runs on. Since your front panel is running on your Windows host, it shows the path as Windows path eventhough the code runs in fact on vxworks, which is for the most part to be considered Unix. The INI file functions store the path also in a platform indepenanden format but that still does not mean that path "/c/meridian/holding" is a valid path on the VxWork system, unless you have created this directory specifically. Because of this it is usually better to not work with absolute paths but instead use relative paths to a known location. Known starting path locations could be the various path constants that are available in the file palette.
And of course if you invent some path location you should also always make sure that the entire path to the directory containing your files does exist, so an execution of the Create Directory Recursively function is always a good idea before trying to create a file someplace.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions