Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: TheGreatMarklar on October 07, 2021, 01:23:46 PM
-
I have a tab-delimited CSV file from a Cmore chart. I've used FTP to copy it to the BRX file system so I can rename it and add several strings to the end. How do I format the string for the FILEWRITE command? The command succeeds, but all it does is add a string of gibberish to the CSV, so I assume the string is formatted incorrectly.
String programmed in STRPRINT: SS50 "$T" SS51 "$T" SS52 "$T" SS53 "$T" SS54 "$T" SS55 "$T" SS56 "$T" "$T" "$T" "$T" "$T" "$T" "$T" "$T" "$T"
writes to SL1: SS50 "$09" SS51 "$09" SS52 "$09" SS53 "$09" SS54 "$09" SS55 "$09" SS56 "$09" "$09" "$09" "$09" "$09" "$09" "$09" "$09" "$09"
There are 16 fields in the CSV, so this string needs 15 <TAB> characters, right?
-
I used your string in a STRPRINT. I set the short strings (SS50-SS56) to "A", "B", etc. Then I used a FILEOPEN with the Mode as "Write (Create/Append if exists)." In this case I chose the RAM file system (not the SD card). I called the file MyLog.txt and created a File Handle Struct called FILE_0. Then I used the FILEWRITE of SL1. Then I used a FILECLOSE. All completed with success.
Then I used PLC --> Browse PLC File Systems... chose the RamFS, browsed to root, copied the file to my PC, and opened it in NotePad. The result:
A B C D E F
Each character is separated by a horizontal tab as expected, with 9 tabs appended to the end.
I did this multiple times and never ended with "gibberish".
Can you post the CSV file you started with? Or email it to support@hosteng.com?
-
Forum won't let me attach the file; I'll email. It is a Chart Log generated by a Cmore.
-
Forum won't let me attach the file; I'll email. It is a Chart Log generated by a Cmore.
The issue here is that the C-more generated file is in Unicode ASCII, which Do-more doesn't support. If you open up your file in a hex editor, you can see that after each ASCII byte, there is another byte. In this case, that added byte is an ASCII null character. So, instead of ASCII for "ABCD" being 41 42 43 44, it is actually 41 00 42 00 43 00 44 00. The text editor that you observe the file in comprehends this Unicode and displays merely, "ABCD." So, when you created your string using the STRING print, your string has single-byte ASCII, not double-byte Unicode. And when you append this record to your Unicoded file, the text editor you are using, tries to interpret that string as Unicode (16-bit) when it is actually only 8-bit. That's why it looks like gobbly goop at the end.
Here's what I did to make it work:
- Started with your original file, which is in Unicode (i.e. ASCII + code). If you view this file in a hex-editor, you can see that after each ASCII byte, there is another byte, a null (0x00). So, the issue is we need to add a "$0" after every ASCII in the string you want to write.
- Since in your original file (Data_S6_original_211006.txt), there is a time/date stamp, I prepended that in the same format: STRPRINT, using FmtTime($Now,24h) " " FmtDate($Now,us).
- Then I used the same STRPRINT you said you were using and prepended that time/date stamp to it. But, I also added, "$0D$0A" which is the carriage return/line feed that your original file also shows is there.
- I wrote a Task that copies that string to another working string (e.g. SL1 --> SL2).
- This Task has a FOR/NEXT loop, Index: V0, From:0, To: SL1.Length, By Step 1.
- If V0 has reached the last character, I don't have to process, so it has a BREAK
- Normal procedure is to use STRINSERT to put the ("$0") after every character. After this TASK runs, the final string (e.g. SL2) now has "Unicoded" ASCII (essentially the ASCII byte + null byte)
- After we have the string (e.g. SL2) formatted correctly, do the normal FILEOPEN, FILEWRITE, FILECLOSE.
This, or something similar, should make it work properly. I don't pretend to be a super-programmer, but the above code worked for me using your original file. NotePad (which obviously recognized Unicode), now shows the appended record properly instead of the gobbly goop it was previously showing.
-
Thanks again, Greg! Works great!