848t

[Mdm]

Are there any response time issues if we load more than say "25" temperature points on a single H1 segment ?

Any method to calculate screen update time will be helpful.

Thanks in advance

[tibor]

The update time of 848T is approx. 1.5sec. However it is independent of response time, usually the VCR's generate problem based on my experience. The 25pcs temperature points on 1 segment should not be problem.

[Mdm]

Can you explain what problem did you face on the no. of VCR's ?

[tibor]

The project could not be downloaded if we used simple AI blocks for each input. An alert pop-up window appears which tell you that problem is the summ. of used VCR's.

I almost forgot, the HOST was DeltaV. In other HOST's the limit of used VCR's is higher (Yokogawa, Honeywell). In the other hand, generally the DeltaV is one of the best choose for FF application.

All of the above are my personal opininon and based on my personal experiences.
If you need any further feel free to contact me directly or here.

Regards,

Tibor FARKAS
D.E.A.K. Process Control Ltd.
P+F and Metso agent
Hungary
Tel.: +36 25 507 815
Mobile: +36 30 389 87 44
tfarkas@deak.hu
www.deak.hu (http://www.deak.hu/)
our main references: http://www.deak.hu/ref.htm
contact: http://www.deak.hu/kapcsolat.htm
search, download: http://www.deak.hu/keres.htm
news: http://www.deak.hu/ujdonsag.htm

[rezabejd]

I have a segment with three 848T's as well as about 6 other instruments. The macrocycle is set at 1 second. On another segment we hit a VCR limit if "device alerts" was invoked / enabled. Our host is DeltaV also. Total TI's coming on on this segment is 22; we see no issues with update times.

[tibor]

Yes, the temp.variables can be recieved by the host quiet less than 1sec. I mean the process temperature will be updated in the transmitter, when said update time is cca. 1.5sec. Of course, it is independent of macro cycle.

E.g. we have 10 segments with 3 control loops (3 valves with PID function, 3 micro-motion's), 4 pressure transmitters and 2 848T's on each. The macro cycle is 660ms with no communication error. Quiet a stable system is it. However during stage of commissioning I had some issues but those were fixed and now everithing is OK.

If you need any more feel free to contact me!

Regards,

Tibor FARKAS
D.E.A.K. Process Control Ltd.
P+F and Metso agent
Hungary
Tel.: +36 25 507 815
Mobile: +36 30 389 87 44
tfarkas@deak.hu
www.deak.hu (http://www.deak.hu/)

[tibor]

rezabejd,

How many VCR's were used in that project sheet?

[dewey320]

guys, here's an update for you on the vcr thing... just clipped it from the DeltaV website.

Increased Fieldbus Capacity in DeltaV v7.4


To eliminate VCR limits on your H1 segments, the H1 card supports as many as 35 H1 publisher VCRs and 50 fieldbus device subscriber VCRs per port, as long as the total number of VCRs does not exceed 50. Each port on the H1 card can support a maximum of 50 input links and 35 output links, as long as the total number does not exceed 50 VCRs.


btw, you also need to keep in mind that if you're measuring temp then your process time constants are likely to be quite long. This may mean that your longer macrocycle time may not even have an effect on your control performance.


rgds,


dewey

[Georgechu]

My understanding is: If MAI (Multiplexed AI) block is used in 848T, the device uses 1 VCR. If 8 AI blocks are used, the device uses 8 VCR's. I believe that in DeltaV 6.x and 7.2, the max VCR is 21 for each segment.

George

[adrian_williams]

I've been told that the communication time requied to update the 848t is about 480ms. How do you manage to get 3 on a segment, plus 6 other devices, and maintain a macrocycle of 1second?
I've also been told that it is possible to use unscheduled rather than scheduled communication for these devices and the communication time can be quicker (75ms?). Can someone explain? There must be a down side to this.

[Robin Burnikell]

Adrian,

ABSOLUTLEY!

One bad practise which I think people need to be more aware of is as follows;

I know of several installations by a manufacturer who I will not name (but it isn't smar) where customers are unappy because A-Cyclic communication in the Macro-Cycle is being used to communicate control data from the H1 devices to the host (rather than cyclic communication). Obviously this is not something that should be encouraged as the control is no longer deterministic. But once they had run out of VCR's in the host, and their devices do not support function blocks of the right type or quantity for control in the field devices, what other options do they have, other than acknowledge they can't do it?

The problem is most users will be totally unaware this is what they do, they see the macro cycle time and assume everything is as it should be, but this practise could result in loss of control over the plant in many circustances, particularly if hand held configurators or Asset Management systems are latter applied to the H1 segment and therefore soak up A-cyclic supervision time.

Robin

[Hamad_1974]

Dear Robin,

You bring up a very interesting subject which is the ability of using acyclic communication for control as apposed to cyclic one. My question to you is: How do we check that the vendor or the supplier did not use the acyclic communication for control loops using the Host or other configuration tools?

We've just commissioned a very large FF project using the DeltaV control system and we've never run into problems with VCRs. Of course, our Company's specs are very conservative in that we only allow 8 devices (2 final control elements included). In fact, most of the segments used 6 devices on average. For monitoring-only devices, we allow up to 12 devices.

I do hope to know how we could effectively check how many cyclic vs acyclic communication on our configuration tools and whether we maxed out the limits.

Thank you

Hamad Balhareth
Saudi Aramco

[Robin Burnikell]

Hi Hamad,

I regret I do not know an easy way to check on other suppliers systems because I do not know there configuration software well enough. However, a guaranteed way to find out is to use a H1 bus network analyser (e.g. Smar's FBVIEW) so you can see the actual data packets on the H1 bus. However this is a lot of work. I think an easier way is to raise this issue with your system vendor and ask them to prove to you that they have not done this and get it in writing.

The customers in the UK that made me aware of this discovered it after they changed their HMI screens to show more data from their H1 devices. They did not change the control system at all, only the HMI screens.

This obviously increased the load on Acyclic communication. The result was they discovered their process control became unacceptably slow with valves overshooting and parts of the process becoming unstable. They reverted back to the old HMI screens and found the process settled again. Realising this should not be happening becuase it should be deterministic they investigated and discovered the DCS was using A-Cyclic time to get process control data to/from the H1 devices.

Regards,

Robin