View Full Version : MTT With other device on the same segment
Tarun
November 9th, 2010, 12:19 AM
What are the limitation of Using MTT(multi input temperature transmitter) along with other open loop in the same segment.
Feedback from system supplier is that MAI block cannot be utilized because of system limitation and hence individual AI Block has to be utilized.
In such case the publication time would exceed the allowable schedule time and hence no other device can be connected in the same segment.
Awaiting ur response on how to overcome the above limitation !
jcpilman
November 10th, 2010, 08:34 AM
When we brought in a large number of temperatures, we increased the macro cycle. In our case, we used a macro cycle of four seconds, which was faster than required by the process by at least a factor of ten times; however, after the schedule was built, we saw that we could have used a macro cycle of two seconds.
...John
JR.Zonderman
November 10th, 2010, 02:01 PM
Not sure what function block execution time of the AI-blocks are.
Lets assume 40 ms, 8 x 40 ms = 320 ms --> 400 ms needed to execute all AI blocks.
If you only use the temperatures as monitoring points (open loop), most control systems will use client server communication. This gives less strain on the communication. No fixed/deterministic communication, communication done in available/remaining time of the macro cycle. In 1 s macro cycle this should fit.
agupta
November 11th, 2010, 08:10 AM
If you only use the temperatures as monitoring points (open loop), most control systems will use client server communication. This gives less strain on the communication. No fixed/deterministic communication, communication done in available/remaining time of the macro cycle. In 1 s macro cycle this should fit.
For parameters that are read / written periodically, the publishing should be used. It requires only one message with less overhead. The client-server requires four messages - request, ACK, response and ACK. The overhead in request and response message is larger than the overhead in publishing message.
It is not necessary that every parameter has to be published at the identical rate. It is possible to construct a schedule for publishing (CD from LAS) such that some of the parameters are published once per second and some others only once every 10 (for example) seconds. Make sure that the configuring host is capable of constructing such schedule.
shankar_u45
November 15th, 2010, 05:27 AM
Refer http://forums.fieldbus.org/showthread.php?t=3200 for over view on MTT
jberge
December 6th, 2010, 12:57 PM
Publisher-subscriber should be used for closed loop control: both to reduce communication overhead and to ensure control is precisly periodic (no jitter, constant sampling time "dt") and that the control response period is as short as possible. Just the way the PID algorithm wants it. This is one of the greatest advantages of digital control with FF.
However, in this case it is open loop monitoring so client-server makes sense. It allows macrocycle to run faster for control loops sharing the same bus. The system may only request the temperature value every couple of seconds for log in the historian or display on the screen. It may read it as part of a "view" (together with other stuff) which is quite efficient.
Users need not worry about client-server or publisher-subscriber jargon. If a PV is used in a control loop the system would normally pick publisher-subscriber automatically, and if it is not part of a loop the system will give you client-server by default. Easy.
vBulletin® v3.8.7, Copyright ©2000-2012, vBulletin Solutions, Inc.