LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Extra characters when writing to file

Hello,
I'm currently working on a datalogging system using XP and 8.2. Our program monitors CAN messages, saves values to local variables, and records to a text file based on several inputs from the front panel (file location, ms delay, and write ratio of fast update to slow update parameters). In the interest of saving disk space some variable are only written every "Write Ratio" times the fast variables are recorded.


The file creation works fine, and the write to file works fairly well, but I get garbage characters at the beginning of most lines. You can see in the attached text file there is an extra "J" before my header (not a big deal) but there is also an extra character at the beginning of each line. Usually it's a square, but on lines which will eventually write all the variables it fluctuates between a space, ", or !. I've also gotten files with a * or ). Any idea why I'm getting these? My gut instinct says it's caused by the Write Counter >= Write Ratio Case structure or the EOL constant in the main concatenate strings. I've tried changing both the EOL constant and the false case write string with the same problems.

While I've got the sample posted, is there a better way to implement my traveled distance function? The sequence structure seems...inelegant in this case. I could post my entire prototype VI if that would help, but I'm a bit secretive of its contents and simultaneously ashamed at its ham-handedness.

Thanks
Mark
Download All
0 Kudos
Message 1 of 11
(4,120 Views)

Your text file attachment did not show up when I tried to open it.  However, you have a race condition in your code.  You are using local variables for Write Counter.  The part that increments the variable may or may not happen before the variable is read in the other two places that you are using this variable.  You also write 0 to the Write Counter in one of your case statements.  You need to learn about proper data flow.  I'm not sure if this is causing your problem (I doubt it), but I thought you should know about race conditions.

You are writing a binary file.  How do you translate to text file for viewing?  Maybe your extra characters are coming from translation errors.

- tbob

Inventor of the WORM Global
0 Kudos
Message 2 of 11
(4,105 Views)
Hi tbob, thanks for the quick reply,
I very well may be an idiot. I was busy troubleshooting the concatenate strings and EOL characters I didn't doublecheck the write file. I can't try the write text now, but will soon. Good call.

As for race conditions, I'm partially aware of what they are and what to look for, thus the flat sequence for my elapsed KM total. the 0->Write Counter is intentional, to reset the counter after it writes the high and low priority values to text. Hadn't noticed the race between increment and case execution however. The Write Counter >= Write Ratio probably disguised the race condition unless I went through the elapsed ms values very carefully. I'm slowly learning Verilog HDL in conjunction with LV, so the nebulous execution order oftentimes trips me up.

I'll reattach the text file so you can hopefully see how it looks.

Mark

0 Kudos
Message 3 of 11
(4,095 Views)
Try this thing again.
Download All
0 Kudos
Message 4 of 11
(4,094 Views)
Have you considered a while loop with shift registers?  Then you wouldn't need to have a Last Millisecond indicator.
 

[link removed]

 
The shift registers store value between iterations of a while loop, so you can dump data in there from one cycle and carry it through to the next phase.  They can be blanked if you leave them unwired, though.
0 Kudos
Message 5 of 11
(4,080 Views)
Mark.  Still can't read your txt files.  They show up as a blank page.
- tbob

Inventor of the WORM Global
0 Kudos
Message 6 of 11
(4,075 Views)
Tbob,
 
Did you try saving the .txt file to your hard drive then opening from there in notepad?  Doing a open in new window from the browser gave me a blank screen, but saving the file and opening in notepad worked and looked like the attached.
 
Mark,
I don't know about the J.  But at the beginning of most lines in the .txt file I see a square.  Doing a copy and paste into a string constant in labview, then converting it from normal display to hex display,  it is the Hex character 13 which is decimal 19 or a Ctrl-S or DC3.  Maybe that will help you find the problem.
 
One thing that is kind of odd about your write VI is that you are converting all the numbers to strings, but you are feeding that into a Write to Binary file VI rather than to a Write to Text file VI.  I bet that may be the source of the problem.
 
Edit:  This may also explain why your "text" files are quite showing up in the browser.


Message Edited by Ravens Fan on 02-25-2008 06:13 PM
0 Kudos
Message 7 of 11
(4,065 Views)
I knew he was saving text in a binary format, but I thought it was for a reason.  I still don't know how that extra character is getting to the beginning of each line.
- tbob

Inventor of the WORM Global
0 Kudos
Message 8 of 11
(4,052 Views)

Mark, I am only able to generate the header row when I run your code. Here are some suggestions:

  • You seem to want to write to a text file so you can simply view it as a text file later, so simply do a replace to both Write Binary File VIs with the Write Text File VI. Because you were writing in binary format, and then viewing as text you may be seeing these odd characters. I could only verify that with the "J" that appears at the beginning of the header row.
  • Put a while loop around the bulk of your code and use shift registers as others have mentioned, instead of using local variables.
  • Place an Open File and Close file before and after your while loop, respectively. As it is now, the files you generate remain open when you stop the VI.

I would see if writing and viewing as a text file takes away those characters.

0 Kudos
Message 9 of 11
(4,046 Views)
The Binary Write has the prepend array size input unwired.  Its default is True.  So every time the string is written, the length of the string is being written to the file.  For the short lines, it is 19 characters.  For the header,  it is the ASCII equivalent for J, 74.
 
So Mark, please tell us why you used the binary file VI rather than the text file VI???Smiley Wink
0 Kudos
Message 10 of 11
(4,039 Views)