String to Path bug (LVRT 8.20 VxWorks)

[gsussman]

This one appears to only apply to the new VxWorks based RT systems (cRIO-9012)

The String to Path function does not operate the same as it does for all other platforms

Correct Behavior:

String in: "calibration\"

Path out: "calibration"

Behavior under VxWorks

String in: "calibration\"

Path out: "calibration\" <---- Note the "\" character is still present

Depending on your code, it can cause double backslash characters "\\" to be inserted into your build path functions.

c:\\calibration\\test

[Mellroth]

QUOTE(gsussman @ Feb 15 2007, 05:50 PM)

Correct Behavior:

String in: "calibration\"

Path out: "calibration"

Behavior under VxWorks

String in: "calibration\"

Path out: "calibration\" <---- Note the "\" character is still present

Depending on your code, it can cause double backslash characters "\\" to be inserted into your build path functions.

c:\\calibration\\test

I too experienced this, on VxWorks it seems like the paths should be given as /c/calibration/test instead of c:\calibration\test.

A bug? I don't think so, since this is a platform different than Windows and paths are platform dependant (Mac, Linux etc.).

I do, however, agree that it is inconvenient to have different paths separators for different cRIO platforms.

/J

[Rolf Kalbermatter]

QUOTE(JFM @ Feb 15 2007, 02:24 PM)

I too experienced this, on VxWorks it seems like the paths should be given as /c/calibration/test instead of c:\calibration\test.

A bug? I don't think so, since this is a platform different than Windows and paths are platform dependant (Mac, Linux etc.).

I do, however, agree that it is inconvenient to have different paths separators for different cRIO platforms.

Edit: I should also add that in development environment, the paths on frontpanels are given in Windows style, but paths read using ini-file primitives must be given in VxWorks style.

/J

INI file paths are always normalized when you use the LabVIEW INI Read/Write Path VIs. And yes the normalized form is basically Unix annotation. Since VxWorks has most likely unix roots I think the actual path string syntax would be correct. One more reason to deal with paths as much as possible using the LabVIEW built in Path data type!

That solves any problems with plattform differences. To assume that CRIO is always one plattform only would be to limitating for sure, and as LabVIEW will get expanded to include more and more distributed technologies this only gets more true in the future.

Soon you might communicate from within your LabVIEW development environment with a LabVIEW programmed fridge on some RT Linux operated 32 bit embedded chip ;-) integrating it into your web service application that runs on another remote system under Apache or something.

Rolf Kalbermatter

[Mellroth]

QUOTE(rolfk @ Feb 16 2007, 01:29 PM)

INI file paths are always normalized when you use the LabVIEW INI Read/Write Path VIs. And yes the normalized form is basically Unix annotation. Since VxWorks has most likely unix roots I think the actual path string syntax would be correct. One more reason to deal with paths as much as possible using the LabVIEW built in Path data type!

Rolf,

I think that a path key in LabVIEW 7.1.1 was given in platform specific format, have this changed in LabVIEW 8.2 (I'm at home and can not check)?

In my opinion the Path data type should display paths in the format specific for the platform that hosts your application. In a cRIO project you are developing on Windows, but deploying to a cRIO, so the question is how a cRIO on a VxWorks platform should handle paths? Either display paths Windows style and accept windows paths in the ini-files, or always use VxWorks path style?

Have a nice weekend

/J