D2-250/260 Local Expansion Analog Inputs are not Deterministic

[JimHoward]

We discovered this characteristic of the D2-EM and D2-CM "Local Expansion"� modules design while on a project in which all Analog Input data was being "chart recorded"� or logged to an HMI.

The effected Analog Input modules are located in the "Local Expansion" bases, e.g. base # 1, #2, #3, or base #4; not base #0 (the base with the CPU). Occasionally, some of the analog input data would go "flat-line"�, that is the data would simply freeze and hold at an old value, although it was clear in the process that the analog values (pressures) were changing.

After a series of emails and telephone conversations with both Facts Engineering (the designer/manufacturer of the analog input modules) and Automation Direct; it was finally revealed that "Local Expansion"� Analog Inputs are updated based on the "Active Channel Bits"� of the Analog Input module itself.

Thus, the D2-EM and D2-CM â"Local Expansion"� method is much faster (for example) than the Serial remote I/O method; but it has the same problem as the Serial remote I/O method. The CPU scan time and the Analog Input module update time can develop a "beat frequency"� in which the CPU receives data from only one channel of the Analog Input module for an extended period of time, thus no new data is obtained from the other Analog Input channels.

Although the D2-EM and D2-CM "Local Expansion"� as described in the Automation Direct catalog states, 'All local and expansion I/O points are updated on every CPU scan'�; I feel this statement should be re-written as: 'All local and expansion DISCRETE I/O points are updated on every CPU scan; Analog Input points are updated asynchronously to the CPU scan. It is recommended that critical Analog Input points that must be monitored every scan be placed in the CPU base.'�

[marksji]

What happens if you set a fixed scan time that is 5-10ms longer than your longest scan time? Does that prevent the "beat frequency".

[JimHoward]

Originally posted by marksji:
What happens if you set a fixed scan time that is 5-10ms longer than your longest scan time? Does that prevent the "beat frequency".

Marksji,
I am unaware of being able to fix the scan time of a D2-250 or D2-260. But, for the sake of this discussion, let's say you can set the scan time.

In our system, the problem was most obvious with the F2-08AD-1 (8-Point, 4-20mA Input); which according to its specs, it should update all 8 channels in 24 mSec (3ms/channel x 8). The PLC (with 1096 rungs, 12 PID loops, MODBUS comms on port 2, and ECOM comms to an HMI) was scanning at around 81 mSec.

For example, is 81/24 = 3.375 some "unfriendly" ratio that should be avoided? And if I could add more scan time, what would be safe? I don't know the answer to that question.

I do know the system could run for many hours without the problem occurring, but then some combination of all the PLC's tasks would result in a situation where data would simply not update from the F2-08AD-1 for over 10 seconds. Yes, 10 seconds, which is an eternity in this process!

[InstrTech]

Your saying that it sometimes took over 10 seconds to get updates from the Analog Input cards? wow thats bad.

And this could happen randomly? and your saying Automation Direct knows about this problem?

[JimHoward]

Yes, bad is an understatement.

A PLC is supposed to be predictable in its actions (deterministic). But this problem makes the PLC operate unpredictably, which is unacceptable.

The worst part about this problem is that there is no "work-around"; no amount of clever software/ladder logic written by the user can solve this problem, it is an ingrained design flaw in the D2-EM and D2-CM.

[a agnone]

Jim is this only happening with analog input cards? I am asking because I have an analog output card in an expansion slot using the EM and CM modules. For some strange reason it will not update from a number in v-memory and send out the voltage it is suppose to. I have not figured it out yet. I did work for a short while of about one week. I will try to move it to the main base. Just wondering if the problem you are seeing is for only the input cards. I am using the ibox to run the card. Jim are you using the ibox feature or writing ladder?

[Tech Guy]

Hello JimHoward,

Thank you for your problem report. It had been forwarded to the vendor. They are investing now. Please give us some time to finish the investigation.

Best regards
ADC support

[JimHoward]

a agnone,
As far as I know, this only happens with Analog Input cards.

The Analog Output cards function differently than the Analog Input cards. From my understanding, if the Analog Output card is in base #0 all Analog Output channels are updated every scan; if the Analog Output card is in base #1, #2, #3, or base #4; one Analog Output channel per card is updated each scan.

Thus, if you are having a problem with your Analog Output card, I'd look very carefully at your configuration and your ladder logic.

By the way, I did use the ibox functions ANLGIN and ANLGOUT to configure both the Analog Input cards and the Analog Output cards (these are very nice functions!).

[franji1]

Originally posted by JimHoward:
these are very nice functions!

Thank you!

[InstrTech]

Hey, its been a few months sence this problem was reported. Does anybody have an update? Was the problem with the local expansion analog inputs fixed?

[JimHoward]

I am very excited about the P3-550 (Productivity 3000) system. In careful reading of the published information on the Analog Input modules, it appears as if the P3-series of Analog Input modules are very different in design from their D2-260/250 cousins.

However, nothing in the published literature indicates if a Local Expansion base (using the P3-EX Expansion Module, and USB cables), or a Remote Slave base (using the P3-RS Remote Slave Module, and CAT5 cables) get all analog inputs read by the CPU every scan (or not).

So, if anyone has had a chance to experiment with any Local or Remote P3-Series Analog Inputs, I'd like to hear any of their comments.

[PLC_PM]

Hi Jim,

The analog modules for the P3000 were developed and manufactured by Facts Engineering and were designed with the same intent, but with the latest technology, so there are a few differences (improvements).

However, the P3000 Scan sequence, Expansion update and Remote I/O update are very different from the DirectLogic. Please refer to Topic P190 in the Productivity Suite Software Help file, "Scan Interval and Use of the Maximum Scan Interval Tag". This will explain the basics of the scan sequence, but the analog updates are different from discrete I/O. Let me get more specific details to the analog I/O and I will reply soon.

If you have not downloaded the Productivity Suite Software, you can view the Help file from our Productivity3000 web page. Follow this link and type in P190 in the search field, and select the Scan Interval and Use of the Maximum Scan Interval Tag topic : http://www.aboutplcs.com/P3000/suppo...uitem=5&top=6&

[PLC ENG]

Hello Jim,

The analog interface in Productivity3000 is quite different. First off, having analog inputs in a local expansion bases incurs no update rate penalty. It could even have the opposite effect.

The sequence in which analog input data gets fed back to the CPU is deterministic. In vague terms...

-analog input modules report to the base when the data on an input channel has changed

-the base sequencially scans through the analog cards looking for modules that have reported the availability of fresh input data

-when it finds one, it pulls in all the channel data for the module and moves to the next module that has reported having fresh data ready

-it continually scans the base in this way, only interrupting the process when the CPU requests input data (it's also reading discrete inputs as well, just in a slightly different way since they must always be up to date)

As you can see, with fast scan times, and a base full of analog, you could have a situation where not all the fresh analog data was pulled in during a single scan. For example, assume there were 5 analog inputs cards and modules 1, 2, 4 and 5 have fresh data to hand off to the backplane. After reading modules 1, 2 and 4, the base is interrupted with a request from the CPU for input data. When the base picks up again reading analog inputs, it would start with module 5. It doesn't skip anything.

[JimHoward]

PLC_PM,
Thank you for the link. The Topic 'P190' covering the subject ""Scan Interval and Use of the Maximum Scan Interval Tag" was very informative and is the kind of published data I need.

PLC ENG,
Thank you for your reply. Your answer is encouraging; do you have a link to a published source, or perhaps a 'white paper' that can be referenced?

On a previous project, my client has experienced the unusual behavior of the D2-250/260 local expansion Analog Inputs (as described at the beginning of this thread). He has asked me to find published data on the P3 series confirming that the P3 has deterministic Analog Inputs.

[PLC ENG]

Hello Jim,

The source for my post was discussions with the engineers who designed it. Unfortunately, we do not have published source for this behavior.

We're working on covering it in the documentation. When finished, we'll add it to the software help file, and put a version online and link to it from here.