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

[Timmar]

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

[Jarrod_S.]

The cFP-2220 runs the VxWorks OS, which handles paths in a different format than windows or PharLap (your PXI). Paths generally look like //folder/file.txt on VxWorks. LabVIEW can automatically translate paths into the correct format for the target if the path data is stored as a path. But it has no control if the data is a string.

The best advice is to always use the path data type for paths and avoid using strings.

[Jarrod_S.]

So to answer your challenges!

1. The difference is using a string to store a path instead of the path data type.
2. Paths contain more info than just the path string, and can automatically convert themselves to the target platform.
3. Always use path data types for paths.
4. Because people will help you out at midnight on a Friday 🙂

[Timmar]

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

I have lost weeks finding workarounds for LABview Bugs and "Behavior"

Over the last 2 months.I estimate I have spent more than 1/2 of my time chasing down unexpected behaviour due to labview quirks.

Here is another one, I have been using the event model for reading the port in my serial driver,

On PXI, it works fine, on cFP I lose 25% of my CPU for each port.  I started a 3 port program and lost neary 80% of my CPU, and that's without plugging in a device.

I went back to a polled method (25ms) and lost 3% (22% better).  My latency is longer but it I no longer have to wait 1.5 seconds for the swamped CPU to process the read data. It now only takes 50 msec

End Rant */

[Timmar]

Didn't Fix it.

[rolfk]

---

@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.

[Timmar]

Rolf,

Thanks for the post,

This is quite informative.

so:

1. It is possible that the Path works but I am using the wrong format.

2. I have no chance of seeing this as Labview has Obfusicated it from me.

Whist I appreciate your use relative path comments, (We do this for all of our internal files, we use a fixed "Base" path with relative offsets)

This paticular Path is read from a .ini file and is supposed to be customer configurable, Relative Path is not a very nice option.

A suggestion:

Sting controls allow you to show '\' codes.

I think Path controls should allow us to see the "native path" - at least then I would have a fighting chance at seeing and debugging the errors

[rolfk]

---

@Timmar wrote:

2. I have no chance of seeing this as Labview has Obfusicated it from me.

I think Path controls should allow us to see the "native path" - at least then I would have a fighting chance at seeing and debugging the errors

---

As to 2) there is no problem in using a Path to String function in your diagram and wire the resulting string to an indicator of some sort. Since the Conversion is executed on the target then, the resulting string is in the targets native format. This is after all why your initial approach couldn't work since you defined a string constant in Windows format but tried to convert it on the Unix target.

As to additional show mode for path controls, while it could sometimes be handy, it complicates the path control even more. As it is now, the path control has no knowledge of the native format of the location where it was created on. And if it has you run into a difficult problem. Since in most situations you end up defining the path in your host system, which would be Windows, then transfer it to the target which is VxWorks and then back to the host to be displaye. Which is the origin of this path? Still your Windows system so the idea is much more tricky and worrysome than you have imagined.