Macrocycle

[juangonzalezs]

I would like to know where I could find information about the execution time of function blocks, or where I could find general information about these times.

[Heather Santos]

Hello,
Function Block execution times are dependent on the manufacturer of the device, the algorithm, actual processor time of the hardware. THe good thing is that the execution time for each block in a registered device is listed in the CFF file. The CFF is available on the webpage here: http://www.fieldbus.org/index.php?op...ree&Itemid=324
Just find the device(s) and download the DD and CFF files.

Macrocycle will depend on the function blocks in your control loop, and where they are located (all in the field vs some field and some host). Some host systems that I've seen have an optimized macrocycle time option that calculates the time for you. In general these times are between 500 ms to 1 sec.

[juangonzalezs]

Thank you for your answer, it was very useful. I found the information I needed in the CFF files. Can you tell me the unit those times are in? (msecs-nsecs).

[rezabejd]

Juan - they are in milliseconds, as in 1000 ms = 1 sec

One other factor affecting macrocylce is the degree of interconnection between function blocks. If there are numerous blocks with publish-subscribe relationships (such as an AI connected to a PID) then this will result in a longer macrocycle, compared to one with little or no interconnectoon between blocks.

[hbhullar]

Juan,

The marcocylce is single iteration of the schedule running on the fieldbus segment on a port. The marcocycle as explained before is a combination of function block execution times (ms) as well as publisher-subscriber relationships.(i.e. Control in device vs Control in the field). The execution of single block can be found in CFF file as welll as in some DCS, it will be displayed in diagnostics.

[jberge]

The publication of one link using standard communication settings takes 48 ms, but if the control system and devices permit it, you can tune this faster.

Keep in mind that everything happens in parallel. If your bus has 8 transmitters each having an AI block taking 50 ms to execute, this does not mean total 400 ms because they can all execute at the same time so it is still only a total of 50 ms. However, some blocks must wait for other blocks first before they execute. Communication can happen while blocks execute. In addition to the publication time you also want to leave a slot for non-real-time communication such as diagnostics etc. This is not so easy to do EXACTLY with a pencil and paper. If you want the EXACT number you must enter the configuration into your engineering tool and see what you get because only a computer can pick up all the numbers and put it together. For the purpose of engineering/design consider an estimate such as N*50+200 (ms) where N is the number of devices. If you do a lot of complex control in the field it may end up longer.

Chapter 4 in the below mentioned book has more on this

[juangonzalezs]

Thank you all for your answers.

I have viewed some cff files and the values for the block execution tiemes are in the thousands of ms, a few seconds. I believe that this is too much time to execute a single function block. Thats why I thought that the units were ns.

On the other hand I was trying to make a program that would calculate accurately the macrocyle of a segment, but now I know that it is nearly imposible. I need to know what the devices are transmitting, if the blocks depend on each other, their distances, which blocks are executing in each device, etc.

Is this true?
Am I missing something?

[rezabejd]

Juan,

You are correct those can't be milliseconds. In the CFF, they are recorded as "1/32 ms ticks". So, divide the number by 32 and you will have ms.

So an execution time of 960 translates to 30 ms = 0.03 seconds.

Sorry for the confusion.

I don't believe you need to know "what devices are transmitting". Distances don't matter either - at least with respect to macrocycle time. Well maybe repeaters would factor in . . . but in my experience these are uncommon.

The devices you use do matter, as does where the blocks execute. There are at least two issues here, 1) the same block will execute quicker in device "A" versus device "B", and 2) if you put two or more "consecutive" blocks (PID & associated AO is very common) in the same device, you save the "compel data" or publish time of the transfered parameter (48 ms in Jonas' example).

There are, as you note, many factors and most of us use an estimate like the one Jonas suggests. The instances where cycle time is a huge issue are rare in my applications. I have nearly max'd out several segments (approaching 16 devices, the maximum on my vendor's platform, and as many as three PID loops) and have no segments slower than 1 second. And, I use many old ITK3 devices as well.