How do I prevent serial data loss when using a compact fieldpoint (cFP2220)

[Timmar]

Me again with another potential Corner Case....

I am using Labview R/T (2010sp1 x86) on a cFP2220 and am encountering commincations data bye loss on the RS485/422 Port (com 4).

Can anyone point me toward the answers to the following questions:

A: What is the default Buffer size?  (There is a vi to set it but can't find a property node to read it)

B: What thread (if any) UART managed from.

I am finding that as my application becomes busier I start to lose data.

My Code (2 methods) below are in a timed loop with highest priority and should only be trumped by time critical thread,  which I don't have any of.

or

My application periodicaly overloads the CPU so I am using timed loops to manage execution heiarachy for critical tasks, offloading others to be performed in threads of lower priority.

The only explanation that I can think of is that either the buffer is overflowing ( I have seen up to 14, 14 byte message (196) taken from the buffer at a time without problem).

Or the Uart driver/manager is operating in a thread priority below timed structures and hasn't been allowed to run.

Someone posted on another forum topic that the cFP uses all the free processing time to perform DAq Tasks and this is why the CPU usage shows 100% all the time.

Is this correct?, Does it apply to the UART, If so, it implies that I should have most of my code running in background priority to prevent Comms Loss.

Thanks in advance.

[Deborah_B]

Hello iTm,

How often is the communication lost/after how long does the CPU become overloaded? Does it occur after a consistent amount of time or is it fairly random? Are you able to offload some of the non-critical processes or any post-processing back to the host at all? If not, then setting them to background priority would be a good place to start, as well as trying to read from the buffer faster. Is there any improvement in behavior after implementing these two changes individually?

In regards to your questions:

A: What is the default Buffer size?

This Knowledge Base talks about the hardware buffer and this one about setting the buffer in MAX.

B: What thread (if any) is UART managed from?

This Knowledge Base talks about UART FIFOs and the calling thread (check the linked article about UART FIFO sizes at the end as well).

Feel free to post any questions. Also, can you please link the other forum post you reference?

Regards,

Deborah Y.

[Timmar]

Deborah,

Thanks for the response,

After each burst of comminications, the CPU becomes be quite busy as it needs to process the incoming data.

When the errors occur there are less then 512 bytes "supposed" to be in the buffer,  this is well within the allowed 1600.

If it is a hardware process loading this beffer, there is no reason why the data should be lost.

The read from buffer thread is in a timed task and has the highest priority of anything I have running.

I am not sure what thread it is in, I should be whatever is default.

This controller IS the host, so no white horses to the rescue.

I am comfortable with the ammount of processing that it being done, the concept of a realtime system is that it can be overloaded for brief periods, with tasks being executed later based on their priorities.

My expectation is that the serial data is grabbed from the buffer at the expense of any other thread.

Kind regRDS,

Tim L

[Timmar]

Deborah,

I have continued my investigations into this problem with the following setup:

1. Communications handler (consumer) is in a timed structure of the highest priority:

2. I have simulated a loaded processor with the following:

Note, The thread priority is lower than the comms consumer.

The theory is that the communications consumer should take priority of the CPU loader.

---------

My observations are that during times of high CPU load, communications data is lost.  My packets are 14 bytes long and the entire whole packet or packets (as many as 10) appear to intermittently missed.

My conclusion is that the lower level commications driver layer is being serviced at a lower priority (my guess is "normal").

Thanks for your attached links, they were almost helpful.

The performance tweak for the FIFO (change to 14 bytes) provides minor improvement in cpu usage (1 interrupt per packet).

I can change between synchronus and asynchronus modes but since the VI is called after the event trigger, this will have little or no effect on this problem.

There is the reference:

Please see Performance on LabVIEW Real-Time in the NI-Serial Help for more information on configuring the interrupt handling mode.

here

Where is the NI-Serial Help?

I apologise for sounding dumb but I don't have a clue where to look for this one. All my usual searches yielded nothing.

I am hoping that there is a trick to elevate the thread priority for the low level serial controller.

As a clue, I believe that I have observed similar behavior in the DI port of the cFP-2220.

It was possible to get the "on change" acquisition mode confused enough that it fould report an inverted input state.

Any insight is appreciated.

Thanks in advance

Tim L

[Timmar]

Ni Serial Help can be found here - Yay Me!

1. Copy the niserial.dbs file to your host from the /ni-rt/system directory on the RT target.
2. Set the interrupt processing level.
   • To set the interrupt processing level as a systemwide setting, add one of the following code segments to the top of the niserial.dbsfile:
     • To specify primary interrupt handling explicitly:
       
       [System]
       InterruptProcessingLevel = "PrimaryInterrupt"
     • To specify deferred interrupt handling explicitly:
       
       [System]
       InterruptProcessingLevel = "DeferredProcessing"
   • To set the interrupt processing level as a per-device setting, add the InterruptProcessingLevel entry below the UniqueId entry within the desired device section.
3. Download the updated niserial.dbs file to the target, overwriting the existing file in the /ni-rt/system directory.
4. Reboot your RT target.

[Deborah_B]

Hello iTm,

I'm glad you were able to find the NI-Serial help and locate the interrupt processing priority instructions. Were you able to see a marked change in the behavior with the communications handler producer loop after updating the niserial.dbs file on the cFP? Any follow-up questions?

Thank you,

Deborah Y.

[Timmar]

I am getting close, I will post more when I have a complete answer.

At this stage, it appears to be working but I can still knock it out with a timed structure.

My conclustion is that the comms handler is now running somewhere above above high priority but below timed structures.

It would be really nice to get a difinitive statement on this rather than determining it by experimentation.

This has forced a considerable re-structure of my code to remove timed structures - they were used extensively to prioritise execution.

It would be really nice to be able to set the thread priority for the handler,

Kind regards,

Tim L