According to the scan time it is possible to use 1 transmitter and 1 valve if you need 250 ms of scan time, isn't it? And things ameliorate only with 1 sec of scan time, don't they? I would like to receive some information and some link where I can read something about it.

Thank you all.

Best Regards,
Lorenzo Cecchini

 

The scan time depends on how fast devices execute function blocks and how many function blocks and function block links you have. Then add a background slot for ad-hoc communication such as operator screens and diagnostics.

For example, if you do control in the field using a Rosemount 3051S pressure transmitter and a Fisher DVC6000 valve positioner you can execute a loop in 105 ms or two loops in 135 ms, because they execute in parallel, but typically the macrocycle is set to 250, 500, or 1000 ms.

To learn more about fieldbus scheduling take a look at the yellow book "Fieldbuses for Process Control: Engineering, Operation, and Maintenance" buy online: http://www.isa.org/fieldbuses

Cheers,
Jonas Berge

 

thank you for the answer but i didn't understand so well:
I found the time specification for the 3051s but not for the fisher valve positioner.
Secondly I don't know how to calculate the loop time that disagree from the time specification of the 3051s.
can you help me please?

Best Regards,
Lorenzo Cecchini

 

Dear Mr. Cecchini,

The Fisher DVC6000f positioner PID takes 30 ms and the AO 25 ms

The 3051S takes 20 ms for the AI. Typically a real-time block link from the AI to the PID takes 30 ms although faster is now possible in many devices. This means the loop itself could be done in 20+30+30+25=105 ms. However, each fieldbus usually has more than one loop. Moreover, there is a time slot allocated for non-real-time communication as well thus ensuring that there are separated "channels" for real-time and non-real-time communication so that the real-time communication remains precisely periodic (isochronous) as required for PID (this is a unique characteristics of FF that makes it the preferred bus for process control loops). Keep in mind that the different loops on the bus execute in parallel - this is possible because they execute in different devices. Calculating the required execution time when a bunch of devices are used is not so easy but is done automatically by the configuration software which tells you the result. Based on this a longer bus macrocycle is then selected. For example, if total execution time becomes 165 ms you may select a 250 ms bus cycle.

To learn more about fieldbus macrocycle take a look at chapter 4 of the yellow book "Fieldbuses for Process Control: Engineering, Operation, and Maintenance" buy online: http://www.isa.org/fieldbuses

Cheers,
Jonas

 

Dear Lorenzo

Is it for Hazardous area application ? eg IIC
xtr response time is typically 100 ms range for
measurment/actuation & additional time for FF
transmission. What is missing in FF communication
is CRC data validation time & interprocess delay
for communication between One node to other Node
& CRC validiation time. Hence you would not logically get correct picture.

If anybody have this figures, please let us know.

250 ms on FF - RS485 BUS WITH only 1 control loop
connected per master card /H1 bus, it sounds good for demonstration purpose only. Commercial application if you give budget to your management
& check the response of your boss, You would never forget this reaction forever.

We use FF only for inherently slow process & non
critical process.

 

Here are some numbers that I hope will bring some clarity.

It does not matter if it is hazardous area or not. The same transmitters and positioners are used regardless of the area being non-classified or hazardous. That is, either way the timing is the same.

In modern devices, measurement takes 20 ms, the output 25 ms, and the PID 30 ms. The transfer time from on device to the next is allocated 30 ms (although many today can go faster). This 30 ms communication time is made up of a moment of silence between messages, the message to trigger the data transfer, response delay, the data transfer itself, and includes the CRC (cyclic redundancy check) generation and verification on these messages. The CRC (which in FF terms is called FCS: Frame Check Sequence) is generated by the dedicated fieldbus chips and is therefore very fast and does not load the CPU.

Note that there are devices available that are significantly slower. Devices can be anywhere between 5 to 50 times slower so in my personal opinion it is important to check the response time before buying a device.

FF is not based on RS485. FF uses a physical layer which is very different from RS485.

20 ms for AI, 25 ms for AO, 30 ms for PID, plus 30 ms for communication adds up to 105 ms. However, the macrocycle will be longer. You need to add a slot for non-real-time communication. For this reason you may set the macrocycle to 250 ms. Keep in mind that if a second loop is added, all the blocks are executed in parallel so we don't get 2*105=210. Instead we only need to add 30 ms for the second communication so we get 135 ms. Thus you can have two loops and still be within 250 ms. This is of course provided that the blocks are this fast. It also requires that control in the field is utilized. If control is done in the central DCS you have three values to communicate per loops so you end up with 90 ms of communication per loop not having counted block time ad non-real-time communication. Note that you can have monitoring devices on the same bus as their outputs are not published but scanned.

250 ms loops are primarily for flow and liquid pressure. Gas pressure maybe 500 ms. Level and temperature maybe 1000 ms. That is, for a fieldbus used for most loops you can allow for more loops and therefore better economy. Modern systems support sub-schedule which means a fast loop can coexist with slow loops i.e. you can mix flow, temperature, pressure, and level loops on the same bus. Note that sub-schedule does not make loops faster - if blocks are slow your loop will be slow so even with sub-schedule it is my opinion you still need fast devices.

I want to highlight here that the past few years have seen tremendous development in the fieldbus arena. Not long ago the FF devices used the same 8-bit microprocessors as their HART counterparts and had a hard time handling the FF protocol and blocks like you implied. But devices have improved a lot and support in the control system cards and configuration tools have made systems much better, including ease of use.

For critical loops you may add some degree of redundancy. Particularly you may wish to consider redundant power conditioners since power supply components are typically a weak link.

To learn more about fieldbus timing take a look at chapter 4 and for FCS/CRC plus other physical layer aspects take a look at chapter 11 of the yellow book "Fieldbuses for Process Control: Engineering, Operation, and Maintenance" buy online: http://www.isa.org/fieldbuses

Cheers,
Jonas