LabVIEW
Knowlege Nuggett - End of Line means different things in different operating systems, Vx Works vs Phar Lap
I have been chasing a code bug for a long while and thought I should share my maladays with the room:
Labview's end of line Constant means different things on different platforms.
For a text file, this can be mildly annoying. I create them on a VX Works device and read them on Dos or Phar-Lap Devices.
For serial Communications to a device using ASCII strings, this is a showstopper.
Don't do what Tim Did!
The Kicker is that it appaers thet when I run in development mode from a windows PC it seems to be O.K.
it fails at .RTEXE (Needs more investigation to confirm)
Hope this helps someone.
@Timmar wrote:
I have been chasing a code bug for a long while and thought I should share my maladays with the room:
Labview's end of line Constant means different things on different platforms.
For a text file, this can be mildly annoying. I create them on a VX Works device and read them on Dos or Phar-Lap Devices.
For serial Communications to a device using ASCII strings, this is a showstopper.
Don't do what Tim Did!
The Kicker is that it appaers thet when I run in development mode from a windows PC it seems to be O.K.
it fails at .RTEXE (Needs more investigation to confirm)
Hope this helps someone.
I believe this is documented in context help. I know it is documented here though. I wonder if the discrepancy between dev and RTEXE has something to do with the dev environment being "displayed" on windows. I put displayed in quotes, becuase I don't really know exactly what RT code running in the dev environment is doing behind the scenes. This is pure speculation. With regards to communication, I air on the side of caution and always explicitly put the \ code character that a device expects. I assume you will too from now on 
slash codes in LabVIEW are consistent and I never had any problems with them.
The end of line behaviour is pretty well documented in LabVIEW and has been so since the early days of LabVIEW (this constant existed in LabVIEW 2.2 already although there it was always a \r only since 2.2 was Mac only). But when they introduced LabVIEW 2.5 for Windows it clearly stated the difference between the two and recommended slash codes instead if you needed to make sure that the same eol was used independent of the LabVIEW platform.
As to the difference between RTEXE und debugging on the host: Welcome to the world of crosscompiling which LabVIEW in fact does when you work with deployed targets. The code is written and tested on the host and uses whatever platform specific details apply to the host platform and is then crosscompiled for the target and the platform specific details of the target apply for that. For paths this means that you suddenly have \ on Windows, / on Unix and : on Mac and eol is \r\n, \n and \r respectively. VxWorks being in principle Unix based inherits the Unix specific settings. Pharlap being a Windows compatible platform inherits the Windows settings.
For a long time x86 CPUs were not a good option for embedded systems and Pharlap only being available for x86 based systems they had to find a different more suitable CPU (PPC) and an embedded OS that was ported to that architecture, which got VxWorks.
@Timmar wrote:
The answer is of course obvious, after the fact We all have 20-20 hindsight.
I guess it pays to read.
The context help (Which I rarely turn on) is clear as to what it is.
In my defence, the icon does show a picture of a line feed followed by a carriage return.
Not using the context help much clearly is a shortcoming. I couldn't wirework without although I frequently switch it on and off to get a better overview in between.
As to the icon: the slash can be interpreted as "either or both", a notation I sometimes use in normal written text too.
