Macrocycle and block execution time

[CHRISC1024]

Morning All,
For a project we are working on we are trying to figure out if the macrocycle is causing some communication issues. They are using all CIC for every segment. We have already been told that the preset macrocycle that is calculated by the linking device/software is usually too short. The following calculation has been provided:

(NDEV*50 + NPUBLINKS*30 + NDTWDTRS*30)*1.2
NDEV = Number of Devices on the H1 segment (doesn't matter whether or not they are in
the configuration)
NPUBLINKS = Total Number of Published Links on the H1 Segment (count all links,
including between devices, in the configuration for this H1 segment)
NDTWDTRS = Total Number for device values accessed via class 3 messages (or data
table reads/data table writes). It does not matter how many are accessed simultaneously or
the number of times they are accessed. Any value accessed even one time needs to be
counted.
For example, for the 64 Node Test Bed, there are 16 devices per an H1 segment (plus 1 for
the bridge) and 128 published links on the H1 segment.
(17*50 + 128*30)*1.2 = (850 + 3840)*1.2 = 5628 macrocycle value

I know every vendor has specific execution times for thier function blocks so I was wondering if I should also do a therorecitcal calculation based on the vendor's information for thier function blocks. What would be the easiest way to look these values up? Would I need to go to each vendor to get this information or is it available in the DD/CF files? I am not onsite so I don't have access to the files or software. The client is looking up the information to do the above calculation but I'd like to check that against the real numbers from the manufactuer to see if it is correct.

I have also seen conflicting theories on the amount of background time for a macrocycle. I've seen anywhere from 30-50%. I'm assuming that since the calaulation is giving 30ms VCR, the 50ms for each device would be calcualting the background?

Any insight on this would be appreciated. From what we've seen it looks like the macrocycles are too tight and as soon as they go "live" with the software to look at the strategy, they bog down the H1 side and cuase communication issues to devices and entire segments.

[agupta]

The shortest macrocycle time in a link depends upon:
1. The maximum execution period (not the time it takes to execute the block) of any function block in one macrocycle,
2. Number of publish links in one macrocycle, and
3. percentage of time reserved for unscheduled data transfer.

It does not depend upon the number of devices in the link.

It takes less than 10 msecs to send CD and DT i.e. publish one data.
Thus for 128 publish data, the time used is 1280 msecs. This should not be more than 40% of total macrocycle time (period).
Therefore the shortest macrocycle should be 1280/.4 = 3200 msecs.
When the schedule is constructed, it is necessary to have at least one gap of 75 msecs, so that the longest data link PDU (approx. 270 bytes) can be sent.

The FB execution time and the time when it is executed is used to construct the schedule, so that the CD for publishing the output of a FB is sent only after it has been executed.

You can find the FB execution time of a device in the Common File for that device.

Now it is up to the host to figure out proper schedule.

If you want to discuss it further, you can send me email (agupta@aniotek.com) or call me at 732 274 2648. I edited and contributed to the FF Data Link layer specifications.

[rezabejd]

For example, for the 64 Node Test Bed, there are 16 devices per an H1 segment (plus 1 for the bridge) and 128 published links on the H1 segment

Are you saying 128 "compel data" events per segment? That would have to be some kind of record. 8 compel data per device if I understand correctly?

I'd guess you'd have a real mess on the macrocycle - surprised it runs at all. My system starts at 30 ms per compel data, which would demand a macrocycle in excess of five minutes. I have never run with "compel data" time slots less than 20 ms.

This is real?? It worries me - sounds like a recipe for disaster, mis-application of the technology, after which FF will get a bad rap. Is this user a novice or have they done this before?

Any chance there's a way to use MAI / MDI (8 I/O or so per block)?

As for unscheduled time for asynchronous communications, more is better if your process control needs can tolerate it. A minimum of 30% sounds about right. How much utilization of device diagnostics and how much on-line downloading will increase one's desire / wish for increased "down" time in the macrocycle.

[IanVerhappen]

Don't forget the ExecutionTime shown for each Function Block in the CFF file is shown as milliseconds*32 so if the CFF file says Executiontime = 3200 it really means 100 milliseconds.

[jberge]

I agree with John. 128 published values on the same bus does not sound right. Normally there is no more than a dozen publication.

In a worst case senario with 8 loops on the same bus and using control in the controller you would only get 24 publications.

Normally I just leave the macrocycle to whatever the control system automatically sets it to. I just verify that it meets the customer requirements. The system automatically assign appropriate background time so I need not worry about it.

Cheers,
Jonas

[CHRISC1024]

The equation I posted above is from a manufactuer's test bed setup not one of our segmetns at the plant. The segments at the plant have no more than 9-10 devices per H1 segment. No segment has no more than 2 control valves and 8 transmitters. The key is they use a fair amount of FIT's and AIT's, and from experience we have seen that these devices require more time than recommended. I was wondering it the gerneral rule in the manufactuer's equation of 30ms per VCR would be sufficient.

The Linking Device/Software vendor has stated that thier "preset calcuated macrocycle" is too short and must be adjusted. I don't know if I should use thier caculation and run with it or actually take the segments and perform a true calculation. I did thier calculation on 4 segments and according to that calc, 3 out of 4 are acceptable to the current configuration. However, we have seen if we take that macrocycle and then add say an extra 100-250ms to it, the problems are not present.

I know that if a macrocycle is too short if can cause disruptions and momentary "loss of signal". This fault clears up and even though the device shows up in the live list for the segment, the linking device does not re-establish communication with the device.

I have a feeling that the last statment is due to the configuration and that the alarm is latching and not allowing the linking device from re-establishing communication with the device. When this happens, should we drill into the linking device and field device to see if the init value is 1?

I'm very fustrated that it's a known issue that the software calculates an incorrect macrocycle and that we now need to go back and verify/adjust this setting. On top of that, there is a communication setting in the ethernet adapter in the control rack that also needs to be set manually based on the macrocycle to make it syncronized with the linking device.

Thanks for the responses and I wanted to give you all a little more insight into the project.

[rezabejd]

I was wondering it the general rule in the manufacturer's equation of 30ms per VCR would be sufficient.

The Linking Device/Software vendor has stated that their "preset calculated macrocycle" is too short and must be adjusted.< . . .> However, we have seen if we take that macrocycle and then add say an extra 100-250ms to it, the problems are not present.


Sorry to hear your systems supplier is making you work so hard. Counting VCR's AND doing arithmetic . . . = less time spent solving process control issues. Do you know if this system appears as a "registered host (http://www.fieldbus.org/index.php?option=com_mtree&task=search&Itemid=324&ffbstatus=Registered&ffbmfg=&ffbcategory=Host)"? Hopefully the Foundation is testing to make sure registered systems have better support than what you are experiencing. If not, we should improve the test . . .

Jonas may recall a user from a couple years ago who complained his valve positioner calibrations were taking 15 minutes. His issues were probably like yours - macrocycle too cram-jammed with FB and compel data events, leaving no time for asynchronous communication (diagnostics, calibration, etc.)

Do you have to prove to your client that his / her macrocycles are too short? I would say, the evidence says they are and if adding 200 ms solves the problems, you're good. Be generous with macrocycle time. If you need speedy loops you want to do control-in-the field anyhow, which will do a lot to optimize the segment communication efficacy.

[CHRISC1024]

Thanks for the response. The linking device is a registered product. However, they have stated thier calculated macrocycle is often too short and needs to be increased. Without increasing the macrocycle, they had a horrible time actually configuring the system in the first place as there was NO room for the unscheduled traffic for downloads. At one point, they though all of thier FIT's were not working correctly and changed them to a different vendor, same issues. We noticed a TON of retransmits from the devices and recommended increasing the macrocycle.... the retransmitts stopped and the segment/device was working correctly.

To me, if the calculated macrocycle is 1000ms and your process can handle 3000ms, why not set the macrocycle to 1500-2000,s and check for improvements. If this corrects the issues, then you know it's the too short.

We have seen that thier FIT's and AIT seems to require much more overhead then what the calculation/documentation says. I don't know if it's the devices or the overall macrocycle is too short, but those are the 2 types of devices that seem to show the most problems. Many of the basic pressure/temp devices have either shown no issue or 1/2 device alarms over 6 months. I believe they are only looking at the device fault bit to trigger thier alarm and this bit can be set by more than a communication issue.

[Heather Santos]

We have seen that thier FIT's and AIT seems to require much more overhead then what the calculation/documentation says.


Curious to know what you meant by this statement. Are the FIT and AIT's registered (http://fieldbus.org/registered)field devices? If so, are they not performing as per the CFF stated block execution times?

[CHRISC1024]

Yes they are registered products. I think the main issue is with the pre-caclulated macrocycle by the host. When they were first hooked up they had a horrible time keeping them online as they would have constant retransmitt errors. Once I had them increase the macrocycle, they seemed to work fine. Whenever they had a segment with either FIT's or AIT's on them, I would have them increase the macrocycle and they would actually work and stay online.

It could also be a device configuration issue too? No segment would have more than 8-10 device and no segment with more than 2 CV/TV. The FIT/AIT have the most alarms in the alarm log thus they believe that them. However, I think it's the configuration not the segment. All of the contol is in the host so wouldn't an FIT/AIT only be using the AO block to send values from the device to the host?

[agupta]

Only the FB outputs can be published. Therefore, the max number of Publish messages is limited by the number of FBs. The AI block has only one output. The AO block also uses only one output that can be linked (published) - BKCAL_OUT.
The alarms are sent using unscheduled messages. If the alarm is not acknowledged then the device keeps sending the alarm. If the alarms are enabled and if the alarm limits are narrow, then the device can try to send several alarms.

[Heather Santos]

Even if the FIT/AIT have the most alarms in the log, the devices can only transmit alerts during unscheduled periods of the macrocycle. The amount of alarms would not bog down a segment, the CD's (compel data) and DT's (published data) will always occur.

[rezabejd]

The FIT/AIT have the most alarms in the alarm log thus they believe that them.
Maybe we need to understand what you mean by alarms. My host has a diagnostic called something like "MissedViewListScan" which can increment rapidly on busy segments. However it is not a "fatal" error - just an indication that all of the "requested" asynchronous data wasn't transmitted when the token was passed. Not a cause for great concern. Are your alarms something akin to that?

All of the contol is in the host so wouldn't an FIT/AIT only be using the AO block to send values from the device to the host?
PID in the host will have one compel data for AI > host PID, one compel data for host PID > AO block (valve) and one CD for AO BK_CAL > host PID, three total (minimum). CIF with control in the positioner consumes 1.

[CHRISC1024]

I'm not the system engineer and what we are being told is they are getting "Comm Alarms". No one has beena ble to define what triggers this alarm. I am trying to getan explaination on what triggers this alarm in the device and the linking device. I have a feeling that most of the "Comm Alarms" are actually for bad device condtions and not an actually communication fault. I've told them to check the live list to see if the device is showing up. If it is, they are not losing communication to the device. I beleive they are only looking at the main device fault bit to trigger this alarm, which can be triggered by a device for a ton of reasons.

[WHodson]

The alarm “MissedViewListScan” is generated by the DCS, not by the Fieldbus network or any fieldbus device on the network. It is most likely on systems whose design calls for reading all dynamic block views all the time regardless of whether the values of the parameters within the view are being used or not (by displays or by other applications). These systems typically run through a list of all dynamic views and update a cache (for fast response) periodically. If the next periodic run through the list is due before the last one completes, the alarm is generated.

Other system designs keep track of usage of Fieldbus parameters within the DCS and stop updating caches of parameters that are no longer being used within the DCS. This greatly reduces the load on the network because only a small percentage of parameters are actually being viewed at a time. When a cache “miss” occurs, the network is usually lightly loaded enough to respond very quickly, and the data typically has less “age” to it than the periodically updated cache approach.

Bus priorities are (1) bus management, (2) scheduled data publications, (3) alarms, and then (4) other client-server communications such as demand reads or writes of parameters. It is almost impossible for a device to generate enough device alarms to bog down the link. Process alarms and diagnostic alarms use the same mechanism.

Bill Hodson
Hodson Consulting, LLC