LabVIEW
How to convert long hex string to individual decimal values..??
Solved!
@Tusharvp4 wrote:
Error-1073807253 (Hex 0xBFFF006B) A framing error occurred during transfer...
That normally points to an incorrect setting on your serial port (baud rate, number of bytes, number of start or stop bytes, handshaking, etc.). It could also be from getting extremely unlucky and you initialized your port when a message was going out and what was actually data was interpreted at a start bit, which can cause all kinds of errors. This is at the UART level. If you want to be really sure, you could use a FOR loop before everything to try to read a byte until this error does not occur. I say FOR loop so you can limit the attempts. I have seen this when dealing with an instrument that just constantly sent out data and I had to jump through some weird hoops to get it to sync up right. But you do have a gap between whole messages that the UART will use to sync up at the bit level.
@Tusharvp4 wrote:
In this case...If i use little time delay and flash buffer between configure port & read serial loop..
is it good to use or not..??
You will still have the race condition. Again, we are talking about at the UART level. The buffer is after the UART found data. So flushing will do nothing. But I got thinking about this and came to the conclusion that you could just simply not stop your loop on an error. Then you, as a user, can just ignore the error until it syncs up and goes along its merry way. So if you are using my example, remove the OR and have only the Stop button wired up to the stop conditional terminal. In theory, it should sync up when the next message comes around (ie during the gap between messages).
@crossrulz wrote:
@Tusharvp4 wrote:
In this case...If i use little time delay and flash buffer between configure port & read serial loop..
is it good to use or not..??
You will still have the race condition. Again, we are talking about at the UART level. The buffer is after the UART found data. So flushing will do nothing. But I got thinking about this and came to the conclusion that you could just simply not stop your loop on an error. Then you, as a user, can just ignore the error until it syncs up and goes along its merry way. So if you are using my example, remove the OR and have only the Stop button wired up to the stop conditional terminal. In theory, it should sync up when the next message comes around (ie during the gap between messages).
I've done this before. Additionally, I grab the VISA timeout value just before the loop. Then I start a timer inside the loop. If the timer >= the timeout value and I haven't sync'd up, I manually throw a VISA timeout error and force an exit. That way you can fake a timeout, even though you are actually constantly resetting the timeout flag.
Hi Tusharvp,
@Tusharvp4 wrote:
Can you please verify both case structures.I did something wrong from yours posted image....!!
Why do you OR with a TRUE before the stop condition of the while loop? I used a stop button…
Why do you use InsertIntoArray? I didn't use this function…
Why is the conversion still so crowded?
Why don't you read the parameter number from the received message? Why don't you use it to replace the corresponding element in the array holding all parameter values (as shown in my image)?
Why don't you show the display style indicator at the string constant? It always helps to document your code when "non standard" display modes are recognizable right from the beginning!
What's the point of this sequence frame? Does it serve any purpose?
Why do you need to use so many constants to call SerialPortInit? You don't need to wire/set default values of that function!
@Tusharvp4 wrote:
@Crossrulz..
Can you please convert yours posted code in Labview 17.0..??
Here you go.
