Serial RS485 RT timing problem

[arieh]

I have problem with RS485 timing using PXI RT computer.

The problem is described in the attached files.

Could you please go through it and let me some ideas how to solve it?

Sincerely,

Arieh Kisos

[DrewPierce]

Hi Arieh-

I opened your attachments and read the problem description, but unfortunately I do not understand the most important part on the second page:

"The problem: When configuring the timed loops to work with a period of 1 or 2 mSec, (when probing the TxD line on scope) block B and C are moving together in a range of about 1mSec, while block A and D are stable.  When configuring the timed loop to work with a period of 100uSec, Block B becomes stable and block C moves in the mentioned range."

I guess the part that's really confusing me is the 'stable' versus 'moving' blocks terminology. What exactly do you mean by that? And what is the expected behavior of your application? Also, what specifically is executing incorrectly? The problem statement above seems to describe what's happening, but doesn't really explain what should happen, or what is failing. Maybe I'm missing something...

So if you could please elaborate as much as possible, that would be wonderful.  I want to help, but I need more information...  Thanks!

[arieh]

Hello

Sorry for the delay.

In fact, I’m receiving the Block A, and have to calculate and transmit Blocks B, and C.

Block B is sent immediately after the calculation, and block C is sent 1mSec after block B.

When looking at blocks B, and C on the scope, it appears to be jittering (moving on the time axis in range of about 1mSec, there is something periodic in their movement. This is when the period of the timed loop is of milliseconds. When changing the period to 100 microseconds, the block B seems to be stable, and block C jitters.)

More over it, as a simulation, I wrote a vi which transmit block A, and D from the second RS485 port (instead of the actual system) and that phenomenon disappeared, and there is no jittering.

It might be that I’m miss-explaining the problem by email, could we speak by phone, just in case that the above description is not adequate.

Thanks,

Arieh Kisos

[DrewPierce]

Hi Arieh-

Keep experimenting with different loop periods until you determine some sort of pattern in the jitter. Then try up-scaling all the timing in your application until you can eliminate any unwanted 'block movement' and start working backwards from there.

And I agree that this issue would be much easier to discuss/troubleshoot over the phone, so if you could please request phone support here and reference this forum, that would be great.  *Please note that a valid service contract is required.

Thanks and good luck!

[JasonSmith]

Hi Arieh,

It is not typically expected that serial will be used inside of timed loops, due to the asynchronous (read non-deterministic) nature of RS-232 and RS-485 communications.

Some issues which I see in your application:

1. Your middle loop, which seems to control all of the timing your are concerned about, is the lowest priority loop (Even your non-deterministic loop is a higher priority!).  In fact, it does not even appear to need to be separate from the first loop at all!  Could not the first two loops be combined into a single linear path, removing the need for you to poll a local variable before transmitting your response?

2. Your non-deterministic loop should probably not be a timed loop at all.  Any timed loop runs at a higher priority than the serial driver (by default), so it could be causing problems in your system (See below for more info about this).

3. Timed loops of any priority run at a higher priority than default priority for the serial driver, so if your timed loops combine to consume the processor it is possible to starve the serial driver, or cause its execution to delay unexpectedly. You can increase the priority of serial actions by disabling Secondary Interrupts for NI-Serial, which will increase serial responsiveness, but also increase system jitter.  If the most time critical use of the controller is serial I/O, then I assume the responsiveness would be more important than the jitter. Modifying this setting is described in the NI-Serial help file, and is a simple change to the niserial.dbs file on your PXI target.

3. If you must use VISA and NI-Serial in a Timed Loop, I would recommend that you switch your writes and reads to synchronous mode instead of asynchronous.  While this will tie up the timed-loop thread until the operation is complete, the overall execution is more efficient, and you should see tighter timing in your application with synchronous communications. You do not appear to be doing anything in parallel with your serial I/O (within the same loop), so it shouldn't be an issue that the thread gets tied up with the synchronous I/O mode.

-Jason S.