Running LV 2013 on windows 7 and a 9074 cRIO target. I need to bring in new instrument data on 232 port, sort / parse / select from String and turn into separate values for the 20 variables I am getting in. when it is parsed properly for a short time then I can see I have the rest of the data processing working fine. I have the serial data coming in and can view the "raw data" it consists of 4 data groups each ending in a \r and starting with t. headers for each are, t1848, t2848, t3848, t4846 the ascii data after the header is hex, the first three are 8 byte and t4 is 6 byte. I have looked at a lot of examples and discussions but nothing is covering my issue. which is....when I think I have the string format set properly and data coming in its looking fairly good for a bit. Eventually it starts shifting around and the string data starts jumping one to the other and is very messed up. typically the first string of data will stay solid, sometimes has no data. the known issue with the data is that the rate is not the same for each of the 4 groups, t3 comes in slower. t1, t2 and t4 data rates change when a alarm limit is reached. they go from 500ms to 100ms. when this happens then the parsed strings go crazy, data is jumping all over the place. even the headers are not being parsed correctly. clearly t4 string will be placed in the t3string and t1 will be displayed in t4 string as well
at my wits end, have tried a lot of string format options. the snipet shown is working the best. have tried reading bytes at port as opposed to a fixed number. changing loop speeds. some serial port instruction changes and I find it easy to not bring in any data at all. played a little with termination of read on \r but then I only get the first string. not sure if a feedback node for t3 is necessary or helpful. I am still pretty new with LV and the more detailed the answer will be most appreciated. not reading between the lines very well here yet.
a little more to the hardware catagory. the insturment device comm port is actually CAN. I have a CAN232 converter its talking through. The raw data looks stable with the understanding that t3 transmits less often. Why am i doing this. I already have this hardware, we have used sucessfully on DOS systems in the past and CAN modules are stupid expensive for the cRIO. besides, why not. It looks like Scan from String is broken to me. I am still certain I am messing up somewhere. Help will be very much appreciated.
Is 500ms long enough wait between commands? I can't see part of the program before you read the string from the port. Do you have a delay in there? Is it long enough?
You have the byte count set to 84? Are you cutting the data off prematurely? Set it to 200 and see what happens.
You have termination character set to true but if your device doesn't output one, what's the point?
Should the device always return T1-T4 (in that order)? If so, it's just a matter of getting the data from your device and Scan from String should work. If there is no guaranteed order of the data returned, you'll need to use a different method (split string, etc).
Thanks for a quick reply, I believe the 500ms is long enough because the input data is coming in as expected. Longer times didn't show anything different. I have tried different byte sizes. a larger byte size actually makes it worse. The device does send the \r. I think what you mentioned that is most important is if the data isn't always in order. that is exactly what I know is true. The t3 string isn't always transmitted. and the data rate changes too. I expected the scan from string would still parse them appropriately but it clearly doesn't. so you say "split string" I tried working with that and actually can't get it to display anything, not sure if my formatting is way off or what but I tried everything I could think of. I did have some luck with "pick line". that has at least cleared up some of my grey area in proper terminology. so what I didn't say before is I have a text string with multiple lines....That the amount of lines in each transmission is not the same. this now still creates a problem for me. I now can properly acquire lines one and two. but the data I want out of line 4 sometimes comes in as line 3 and sometimes 4. I am still working at this so if any other ideas come up please let me know.