Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Read bytes problem in RS232

Hi everybody

 

I have a device. This device has been designed to send a data stream which is 47-byte in every 100 mSec without any command.

 

When I begin to read the datas, I read 47-bytes data stream at the bytes read terminal of VISA Read function. But a few seconds or minutes later, it goes crazy. I mean it is raising up to for example 230 byte or falling to 17 byte.

 

Any idea or help please??   (By the way, I am using "Bytes at port" proporty node before read function)

 

0 Kudos
Message 1 of 20
(5,142 Views)

sefaa wrote: (By the way, I am using "Bytes at port" proporty node before read function)

THEN STOP IT!!!!!!!!  If your message is always 47 bytes, then just tell VISA Read to read 47 bytes.

 

But could you tell us more about the message format?  A quick rundown of trains of thought:

1. The device is sending ASCII characters for the message:

    a) The message have a termination character:

        Enable the termination character with the Configure Serial Port and tell VISA Read to read something like 100 bytes.  This will take care of situations where the message is longer or shorter due to many possible reasons

    b) The message does not have a termination character, but is always the same length

        Just tell the VISA Read to read that length of bytes.  Make sure the termination character is disabled with the Configure Serial Port

2. The device is sending binary/hex/raw data

    a) The message is always 47 bytes

        Just tell VISA Read to read the 47 bytes.  Also make sure the termination character is disabled since it could stop the read prematurely due to the data just happen to have a 0xA in it.

    b) There is a sync byte and message length, etc to the message.

        This can be a little more complicated, but not much.  Definitely need more information on the protocol.  But make sure the termination character is disabled.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 20
(5,127 Views)

Thanks for information, sir.

 

My data packet starts with 2-byte packet header (FFFE). I tell the program that if the data came starts with FFFE, and if the length of the data is 47, then do these.

 

But I am not sure whether there is termination character in the packet. I do not see this on the data-link specification of the device.

 

First of all, I will remove bytes at port node and I will write directly 47 to the byte terminal of Read function. And then I will try what you said for termination character.

 

I just wonder that why the byte is changing with respect to time?? I am sure that the device flushes its buffer after every message. It makes no sense 😕

0 Kudos
Message 3 of 20
(5,120 Views)

@sefaa wrote:

My data packet starts with 2-byte packet header (FFFE). I tell the program that if the data came starts with FFFE, and if the length of the data is 47, then do these.


This tells me a few things:

1. Your data is binary

2. There is a protocol to the data.

 

What device are you trying to communicate with?  Where is the full protocol?

But based only on what little information you have given, I would read 1 byte until I get an 0xFF and then read another byte and verify it is 0xFE.  Once you get that, now you can assume you have the start of a message.  So now read 45 more bytes to get the rest of your message and decode as necessary.

 


sefaa wrote:

I just wonder that why the byte is changing with respect to time?? I am sure that the device flushes its buffer after every message. It makes no sense 😕


Maybe the device is sending another message in there that is shorter, like an error message.  Maybe you are doing too much in your loop and you start reading multiple messages in a single read (one of the issues with the Bytes At Port).  Need a lot more information to give any more advice (like the full protocol and your code).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 20
(5,114 Views)

The name of device is FADEC. It has RS232 port. I take the datas from FADEC to CompactRIO with RS232 cable. And then from CompactRIO to my computer with Ethernet cable.

 

The device sends hex stream. According to specification, it sends informations in every 100 mSec. So I run my while loop in 100 mSec.

 

This problem can be because of time? I have two while loops in my Target VI. One of them is for the sensors on CompactRIO and has shared variables for Host VI. The other loop is only to read datas from FADEC. And there is only read function in second while loop.

 

So it seems not be because of time. But I do not understand. I will try what you said. I hope I take the 47-bytes data stream regularly.

0 Kudos
Message 5 of 20
(5,102 Views)

Can you provide your vi for how you are trying to acquire this data?

 

If your system is running under Windows, it will be at the mercy of Windows scheduling.  While you may expect to read data every 100ms, your actual times reading data may vary somewhat.  If your code is set properly, then you can mitigate this issue.

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 6 of 20
(5,047 Views)

Do you know the breakdown of the packet you are reading from the FADEC?  As the Full Authority Digital Engine Control is capable of independent operations and only tends to generate packets for other channels and engines across a standard data link.  Do you know if this is for the cross-engine data link or the cross-channel data link?

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 7 of 20
(5,043 Views)

Let me tell you what I noticed today;

 

I created a simple serial VI under CompactRIO target and observed what happens.

 

There was no problem, I was taking the 47-byte data packet regularly. It did not change with time.

 

But!! When I active the VI which collect sensor datas on CompactRIO, the other VI that was running regularly went crazy again.

 

So the problem is absolutely because of CompactRIO. The sensor on CompactRIO effect the data packet and cause distortions or delays.

 

Any idea?? (Baud rates are the same as 19200) (sampling rate for both VI are the same as 100 mSec)  so I set the cRIO's baud rate as 19200 from NI MAX. And in simple serial VI as 19200 as well.

 

0 Kudos
Message 8 of 20
(5,039 Views)

1. What cRIO are you using?

2. You really need to share code for us to help you troubleshoot any further.

 

But it does sound like you other loops are using too much of your CPU.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 9 of 20
(5,026 Views)

I am using NI CompactRIO 9025. There are 8 modules. Totally, there are 64 pressure sensors, 32 thermocouples and RPM sensors. 

 

I can not share the program because it is forbidden. But I explained all necessary informations.

 

Ofcourse there are calculations, buttons or indicators or shared variables for raw sensor datas in Main VI.

 

They must be. And I have to use all of the modules.

 

So, I need your help. Any idea??

 

0 Kudos
Message 10 of 20
(5,024 Views)