06-29-2010 06:32 AM
Hi,
I am sending values of 6 channels on serial link of 9012 crio which works fine. On the receiver end,sometimes
1)Space is received
2)Two characters are received together.
11:53:05 | D0.00 |
11:53:05 | E-0.01 |
11:53:06 | F0.01 |
11:53:06 | G1.00 |
11:53:06 | |
11:53:06 | B7.50C4.23 |
11:53:06 | D0.00 |
11:53:07 | E0.01 |
11:53:07 | F-0.01 |
11:53:07 | G1.00 |
See there is one space received and moreover B and C are received together. I have tried to change the delay in both TX and RX but didn't worked. Infact I can handle two characters together but I have no idea what to do with space. Because if there is no link between TX and RX, LED goes red and if link is fine LED goes green. In this scenario, as soon as space is received Led goes red which is false because there is a valid working link between RX & TX. Any suggestion how I can improve my code either for RX or TX.
Thanks
06-29-2010 01:28 PM
Where is the space coming from? I don't see anywhere in your transmitting code where you are sending a space.
I wouldn't flush the buffer on every loop iteration on the receiving side. Suppose a byte comes in right after you read the buffer, you flush and that byte is lost.
You really should set it up so that each piece of data is sent with a line feed (ascii 10) sent at the end of the data as a termination character. You do have the termination character enabled on the receiving end. That way you can read a larger number of bytes, and the read will end when you get the line feed character. Now you know you have a complete data packet. Relying on number of bytes at port is kind of arbitrary and just means you got lucky that all the bytes came in while you are waiting, and the next group of bytes hadn't started. I imagine the 202 msec wait was a part of that which is a really odd number for a wait. If you read 3 bytes, but the packet was incomplete and the 4th , 5th or more hadn't arrived, then you wind up with incomplete data.
06-29-2010 03:10 PM - edited 06-29-2010 03:12 PM
In both of your vi's, you have a false constant wired to the loop stop sign. The program runs until you hit the abort button. Then there is an abrupt stop and the VISA session never gets closed and you don't get error messages. Luckily Labview takes care of closing the VISA automatically. But you should NEVER use the abort button to stop a vi unless it is hung up accidentally. Instead put a stop button. Let your vi finish its code.
The only thing that would transmit a space is if one of the numeric variables could not be converted to a string properly. Then you might get a letter followed by a space. Not sure about this though.
To make your code better, eliminate all the repeated stuff, like the VISA write followed by a delay. First convert all your numerics and concatenate the letters, then make an array of all the commands to be sent. Wire in the array to a For Loop with indexing enabled. Inside the loop, put one VISA write followed by a delay. TADA... much simpler code performing the same function. It will run once then stop. If you need continuous running, put it all in a while loop like you have it now, and put a stop button.
In your first post, why is the A never received? You list B through G but never an A.
06-30-2010 04:08 AM - edited 06-30-2010 04:13 AM
Hi
I have managed to overcome the two characters received together by reducing the delay from 200 to 75 in both RX and TX. Infact, I am constantly checking serial port and if space is received LED goes off whereas on receving characters LED goes On. Now I am having blinking LED. Is there any function which can diffrentiate between space and serial port not connected.
Thanks
06-30-2010 09:11 AM
I still don't understand your "receiving a space" problem. You never send a space. The only thing that kind of makes sense is TBob's comment that a space gets generated when the numeric data is not converted properly.
Why do you still have a False constant wired to your stop terminal thus making an infinite while loop that you have to abort the program?
Why don't you do what I said and stop using the bytes at port and start relying on the termination character to determine when to end a read? End each piece of data with a \n new line/line feed character in the sending program. When you read in you receiving program, tell it to read 100 bytes. When you get A0.00/n (which is only 6 bytes) the VISA read will terminate, you'll have a complete pack of data that you can than proceed to decode. As it is now, you are relying on an arbitrary time delay, and then telling the serial port to "give me what you got right now". If you get out of synch, then you wind up getting A0. on one read, because the 00 that would come immediately after just hasn't arrived yet.
When you do this right, you won't need to do 200 msec delays between each packet of data in your transmitting program. You could put all data together in one message and just throttle the loop at whatever rate you want.
06-30-2010 12:50 PM
Space is generated due to constantly polling on the receiver side. If I increase the delay greater then the delay of transmitter side,than space is received very rarely.
The reason why i am not concatenating strings and send them through one single write in a while. My first attempt was this technique but I always got buffer overflow error. Due to which I changed my mind to transmit separtely each channel with an identifer an front line A or B or C or D or...
As I am constantly polling so I'm receving space.
Infact I have got an indicator on front panel which lits if serial link is fine and vice versa.So when I receive space, indicator goes off and lits back again when character is received. So my indicator is constantly blinking. I dont know how to change this blinking to constant lit now?
06-30-2010 02:21 PM
I think you will always have problems unless you do it the way I tell you relying on the termination character. To give you a push in the right direction, try these modified versions of your files.
06-30-2010 03:38 PM
Thanks Raven for you help and support. I will try this code tomorrow and will let you know the outcome.