High Speed RS422

[edinsofty1]

Hi,

I am trying to develop a test program to test an RS422 link recieving a 24 byte message every 2.5ms (on average) and responding to it. I always had concerns about the timing of the messages, and latest testing shows that the software only sees every 11 messages (on average) using a COM CALLBACK to do this. Is this going to be possible in a CVI environment?

Cheers

Stuart

[RobertoBozzolo]

Hi Stuart,

which speed are you using in COM communications?

By a rough calculation you cannot satisfy that timing below 115 kbaud, supposing your responding task is very fast.

Additionally, how have you structured your application? Single thread or multithread? Which sleep policy have you set for CVI / the spawned thread, if any?

[edinsofty1]

The link is running at 460.8 kbaud.

I was using a COM Callback which carries out the initial checks and responds with a message. Am I right in saying that another message cannot be received by the COM Callback until the COM buffer falls below the number of bytes it is set to Rx? (3 in this case). It is currently running on a single thread, but I have been trying think of other was to do this. I have not changed the sleep policy from the default.

[RobertoBozzolo]

Changing the sleep policy may improve system performances.

You're right: once entered the callback, the buffer must fall below the threshold value and then raise over it again for the callback to fire; that is, you must remain in the callback processing all characters until the queue is empty. When I attempted to develop some software this way I hardly succeeded in designing an efficient callback function with consistent behaviour so I abandoned this approach moving to waiting for a termination character (LWRS_RXFLAG) when I have one.

[ebalci]

In a recent application we have written we used the following approach:

- create a struct that fits the incoming data package

- use bit fields in the struct (if necessary) to be able to access each component easily

- create a thread-safe variable (or queue) that is able to store package data

- create a thread and loop on the number of bytes in queue

- when available read bytes directly into the struct variable [ComRd (port, &struct_ptr, bytes)], process (header bytes, data id's, checksums) if required, put valuable data into the thread-safe variable (or queue)

- keep the thread running as long as you need it

- test code accesses the thread-safe variable (or queue) when it needs any data from the incoming stream

This has been extremely useful. We completely separated "communication code" from the rest of the "test code" and avoided confusing bit operations within the test related part and used more intuitive struct fields.

The thread became sufficiently fast. We had baud rates of 1,500,000 and packages of different size.

We never missed any data. I know it from the incoming time tags.

Hope this helps,

[edinsofty1]

Thanks for the reply.

I have a requirement to respond to the Rx messages (every 2.5ms) within 2ms of them arriving, so I really need to act on the message straight away. Could your process work for this?

Cheers

Stuart

[ebalci]

Sure,

If it does not depend on the incoming data, you can (in a separate thread) prepare your reply and put it into a thread-safe variable/queue.

Your RS-422 thread will call GetInQueueLen repeatedly. When you get a positive value, you can immediately ComWrite your reply and then read the rest of the incoming data.

If you have a fast enough computer and when running in Relase mode, I believe it will be much less than 2 ms.

You can see it on a 2-channel oscilloscope if you like.

[edinsofty1]

Thanks for the reply.

If I had a TSQ holding the incoming data every 2.5ms, would this not fill the queue very quickly?

Cheers

[ebalci]

If you don't have to get "all" the arriving data, but just the most recent data then you don't need a large TSQ.

You can overwrite.

If you don't have the luxury of missing some incoming data, then you should create a sufficiently large TSQ to buffer the data while you are busy emptying it.

You can continiously read the number of occupied locations in the queue and determine if your size is enough.

Hope this helps,