字串保存中的換行問題
請問各位大俠，
自己做了個實驗的ad采集卡
數據通過串口發到pc
用serial read讀入為string
因為數據每三個（%02x格式）為一組
想在文件中打印三個後自動換行
請問可能實現
yiyi38817.6837037037謝謝
我再寫詳細點，從串口收到的數據已經通過Spreadsheet String To Array轉成一位數組，數據形式是%02x，並用tab間隔。想實現在 Write File 的時候每打印三個就自動換行。
我想了一個解決的辦法
有些麻煩
利用了N迴圈的自動索
引功能來進行自動換行
你原本用「Array To Spreadsheet String.vi」就可以很順利地完成
需求了，只不過要在輸入資料時，就將資料先行整理過：
要注意 Row 及 Column 的配置。
你可以試著將這兩組值對配看看。
謝謝您的關注和指導
您的例子讓我了解到Array To Spreadsheet String處理兩位數組的效果
相信這種模式能在處理兩維位置數據時發揮它作用
可能是我以前的描述並不是很清晰
也沒能夠上載我的vi
所以您所給的方法並不是很適合我正在處理的情況
我的數據是從串口通過RS 232 協議傳進PC的
通過labview的VISA read模塊取到的數據格式爲string,
我不是很明白它底層的協議
但能看出這個放在while循環中的VISA read每次讀出的數據數並不相同
所以並不能通過這個while循環來構建規則的數組
你可以看一下我的vi
我在while循環上對這個讀出的string進行shift register的累加也是無奈之舉
但這種方法最終還是成功的實現了串口數據保存中的換行問題
我發問前也曾搜索過解決方法
無果而終
希望這個並不很優化的方案能給別人一點啓發
上次貼的圖有些錯
我貼個改好的
現在新的問題是在最外層的while循環結束時
引到它外面來的string堆棧很深
當我采集的事例數很大的時候
labview會不響應
我在想辦法把write file搬到這個while裏面
用了CINs
所以把整個文件夾打包上傳了
嗯 .... 同樣的功能可以用很多種不同的方法來完成，
只是提供了其中一種方法給你參考，
當然這得將輸入值以 3 x N 的 2D Numeric Array 方可行。
目前你的需求可能會發生多次資料的型態轉換，
可以的話，想辦法讓轉換次數愈少愈好，因為這會佔用掉系統資源。
我按師兄的思路改寫了陣列換行的部分
但是仍然用了Decimate 1D Array
這樣導致的問題是當我從串口中讀出的資料特別多（>65536）的時候
Array會用64位元的int來索引
這段換行的Labview程式運行的效率就會很低
<?:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
附上兩種寫法的範例：
你可以用 Tool -> Advanced -> Profile VIs 及
Tool -> Advanced -> Show Buffer Allocations 來檢驗該用什麼方法讓程式的執行效率最高。
謝謝師兄教我這個比較VI效率的方法
確實師兄的換行方案比起我原先的在時間上要省很多
<?:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
但是我上面回帖是說另一種情況
由於這些換行保存的操作我都是留到程式結束時進行
所以string中的保存的資料量極大
String-〉U8後形成的陣列也極大
如果用C來比方的話
相當於一個
Char[size]的陣列
其中size >65535
也就是需要__INT64的值來對這個陣列進行索引
這對於32位元的cpu和系統是個沉重的負擔
計算的速度在我眼裏就和蝸牛爬一樣
所以我改寫了我的資料保存方式
利用pos mode 和 pos offset端空接, write file 模組的續寫模式對串口的資料進行即時的保存
（If you do not wire pos mode or pos offset, the functions reads or writes the data following the most recently read or written data. ）
底下是 NI 網頁上所提供的 String to Hex 及 Hex to String 的做法：
How Can I Convert ASCII Characters to ASCII Codes and Vice-Versa?
我想應該適用在你 case 中，或許效率會更高。
給你一個小小課題，如果適用的話，
試著將上述方法修改、並整合進你的程式裡。
可能師兄錯會我的意思了
在我的設計裏並沒有涉及到ASCII碼
不過我還是很受益的看了一下這些常式
<?:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
現在我嘗試去做的是將資料再採集過程中就進行處理保存
避免累積到最後出現超大陣列的情況
新的問題出現了
在我Vi中極為關鍵的一個Pallete “Decimate 1D Array” 的表現與自己原本設想的不同
它很傾向於將傳給它的1D U8 陣列中第一次出現的”0x00 0x0A”忽略
而且僅僅是最前面出現的”0x00 0x0A”
我在測試時同時保存了Vi列印的檔和顯示在接受資料區中的數值
不用 “Decimate 1D Array”的換行保存方法
但是第一對0x00 0x0A還是丟
這個不會出錯的
底下是引述自 yiyi 的心得，謝謝他能夠最後找到問題點並且
將之與大家分享：
===============================================
討論一個labview的bug<?:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
調試串口通訊時出現的問題，有關VISA Read。由於VISA read涉及比較底層的硬體介面操作，開始時一直以為是自己硬體系統的問題，困擾了很久。這裏post出來，也是為了讓大家遇到同樣的問題的時候能少走些彎路。
先描述一下我的具體情況。自己做的採集卡，通過告訴串列口給PC送資料，每個資料事例包括三個位元組的內容。由於串口資料是串列進入的，這樣，在讀串口資料後，就需要用Decimate 1D Array 進行整理。但是Decimate 1D Array有個缺點是當其收到的一維陣列不為需要拆分段數的整數倍時（在我的情況下是3的整數倍），Decimate 1D Array會將多餘不足的部分拋棄掉。這是串列資料最忌諱的事，整個資料鏈後面的部分就會亂掉，必須在將資料送到Decimate 1D Array前就進行處理，使其適合。當時最先想到的方法是每次在VISA Read時從buff中讀取整數倍位元組數的資料。結果問題就出來，在資料傳輸中會遺失掉第一次傳送的值為0x00和0x0A的數據。具體情況是VISA read 時這兩個資料不計已讀取位元組數，但還在read buff的string裏，接著用string 2 U8的節點轉換後再送到Decimate 1D Array就徹底沒有了。
<?:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />
後來我用一個放在迴圈中的陣列變數儲存和組合每次多餘的資料解決了這個問題。
