Read bytes problem in RS232

[Minions]

How many and different communication busses/ports are you using?  Are the other instruments talking all the time as well as the FADEC, or do they require independent control for requesting the appropriate data responses?

The reason that I am asking, is that each bus communication requires timing overhead.  Additional overhead is required in writing to an instrument requesting it to send data. 

If your overhead timing begins to exceed your instrument packet response times then it is possible that you will get some odd behavior.

[Gilfoyle]

As I said before, There are sensors on FADEC. And also there are sensors on CompactRIO. FADEC has RS232 port. And it sends 47-byte data packet in every 100 mSec without any command.

Now, We connect to FADEC by RS232 cable. We connect that cable to the RS232 port of CompactRIO. And then we communicate CompactRIO and Host PC with Ethernet cable.

This is well-known connection shape. So there should not be a problem here.

I have serial settings for FADEC. I designed the program and CompactRIO according to it. I set baud rate of CompactRIO as 19200 in NI MAX. So both of them run at 19200 baud rate.

I do not know what can I say more or how I can explain my problem. I think it should be clear to understand.

There is no communication problem. Because I can communicate with FADEC on CompactRIO. But when the sensors on CompactRIO active, eventhoght I take sensor datas on CompactRIO regularly, the datas comes from FADEC go crazy. 

That is the problem.

[Minions]

I have been doing this for over 25 years.  Is that clear enough for you?  I am trying to help you here. 

Without seeing your code, I am thinking it is a coding issue.  Are the RS-232 communications in a separate loop from the sensor acquisition?

[Gilfoyle]

I am sorry, I did not mean like that.

Yes, there are two while loops. One of them is for CompactRIO sensor datas.

The other one is only for FADEC.

In CompactRIO loop, there are buttons, indicators, calculations, shared variables etc.

In FADEC loop, there is only VISA read function.

Both of loops run at 100 mSec delay.

To understand problem, I remove FADEC loop from VI. And I made different VI for only FADEC under CompactRIO Target in the project.

But despite of this, there changed nothing.

[Gilfoyle]

My code is something like this

[crossrulz]

As I stated before: DO NOT USING THE BYTES AT PORT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Go back and reread my initial response.

[Gilfoyle]

Sir, when the device starts, it sends four times company name and then starts to send sensor datas. So at first, the packet is not 47-byte. That is why I use Bytes At Port node.

Because This information is not important, I did not tell you. The main problem is to be effected the FADEC datas because of CompactRIO sensors.

[crossrulz]

---

sefaa wrote:

Because This information is not important, I did not tell you.

---

No, that is very important data.  You really need to follow the device's protocol.  You are getting weird race conditions because of the Bytes at Port when the sensor loop is also running.

[Minions]

If you know the size of the message to be received, then set the input to the Visa/GPIB Read to that size.  You can use the bytes at port to indicate that new values are arriving, but avoid using it as the input size when the actual message size is predetermined.  I entered 30 here for the First 4 passes where the device gives its identification not knowing the actual string size.  You can increase the wait time in the bytes at port loop up to 50ms.

[Gilfoyle]

Thanks all of you. 

I decided to take FADEC datas from FADEC to Host PC with RS232-USB directly. And put it in the Host VI. So I will not use RS232 port of CompactRIO.

For now, there is no problem. The program deploys lots of things.Perhaps it happens because of this. But I will call NI Company tomorrow. I wonder what they will tell.

Again thanks for all of valuable knowladges