VCR's - Archive

[Stephen Mitschke]

Raj, We've been assuming that segment communication loading is handled bythe DeltaV inherently by limiting H1 cards to 64 function blocks and how itcalcs the macrocycle time. Is there something else we should be watching,e.g. VCR calculations? Can you educate us what to calculate and why?A Fieldbus device is divided into two or more Logical Field devices:A Management Virtual Field Device (Management VFD)One or more Function Block Application Processes (FBAP VFD). The Management VFD contains the device's Physical and Resource dataResource data includes the virtual communications resources (VCR's).Each device has a set number of available VCRs and each host system has aset number of available VCRs. Depending on your individual fieldbus controlstrategy each strategy will utilize a set number of VCRs. Each publish andsubscribe link to another device consumes one VCR.Determine your control strategies, determine how many VCRs those controlstrategies will consume on the segment. There is a limit on the number ofallowable VCRs per segment, get that specification from your controlmanufacturer. Now compare the two numbers, if your control strategies consume 88 VCRs andthe controller has only 50 VCRs allowed per segment then you have a problem.Either reduce the number of devices or the number of publish/subscribesbetween devices to reduce the VCR count.I compare VCR calculations to the segment bandwidth calculation. Essentiallythat is one reason why you try to limit the number of connections betweendevices by reducing the bandwidth or the number of VCRs. Cheers!Raj K P.S if someone has a better explanation I would appreciate some feedback.- - - - - - - -Hi All,This might start a nice discussion... There is a bit more to VCR's thanwhat Raj has given you. Every device will need at least the followingand then depending on the number of Function Blocks (FB) you will needadditional VCR's.Every device needs the following VCR's:1) Client/Server connection to the SM/NM MIB. Every device has this VCR.It is used to configure the device.2) At least 1, preferably 2 (3 would be even better), more Client/ServerVCR's to connect to the FB VFD. This VCR is used to get the Read/Writedata to the HMI.3) If the host supports FF device alerts (FRSI DeltaV does not currentlysupport device alerts) you will need 1 Sink/Source VCR. The device usesthis VCR to send out alerts. There are other ways to get some alert datafrom a device (using 2 above), but Sink/Source is THE most reliable.4) You will need 1 Publisher/Subscriber VCR for EVERY Input and Outputavailable on a FB. If the device is using internal connections toconnect the Input/Output data (called Link Objects), a VCR is NOTneeded. But if you want to conect ANY Input or Output to ANOTHER deviceon the bus you WILL need a VCR for EACH Input/Output.During Interoperability testing ALL VCR's are tested in the device!EVERY registered device supports the following VCR types:Publisher/Subscriber - Input and Output connectionsSink/Source - Alerts, Alarms and TrendsClient/Server - Read, Write, etc.The fact that a host may not currently support Sink/Source is NOT alimitation of the device! ALL REGISTERED DEVICES SUPPORT ALERTS AND ITIS TESTED.So for example (I love picking on these guys)...An existing registered device contains 12 VCR's, it has AI, PID, ARTH,ISEL, and CHAR Fucntion Blocks. 12 VCR's are not enough to support all external connections. It isextremely limiting to your application.Let's assume the following (very realistic and conservative):- 1 Client/Server VCR, reserved for NM/SM (used to configure the device)all devices must have this VCR.- 3 Client/Server VCR's needed. 1 for host, 1 for temporary device, 1for maintenace/configuration tool. Some hosts may limit you to only 1C/S VCR. Forget about future expansion...- 1 Sink/Source VCR needed for alarming (SOME hosts don't support itNOW, but they will in the future. You had better have it available)- 1 Pub/Sub VCR needed for AI block- 5 Pub/Sub VCR's needed for ISEL block (assumes 1 local connection forAI)- 2 PUB/SUB VCR's for the PID (1 local for the Input, PUB for output,SUB for BCKAL)------Total = 13 VCR'sThere is no way you can use all of these FB's with external connections.Basically, you have just been limited to using only 2 blocks (maybe 3)in this device. Thesame goes for using the ARITHMETIC block. Forget about ever using boththe ISEL and ARTH blocks at the same time. The question really gets tohow much are you paying for this functionality? If the price is the samefor JUST an AI block, good deal. If they are charging you more for theadditional blocks, I would have to ask why? You could probably live with just 12 VCR's in this device, but you willbe VERY limited on the application(s) the device can support. With 12VCR'sthis device can NOT realistically support all of the FB's available init.-Kurt------- ------ ------I think this is going to get published somewhere... this is thepre-marketing version...-K-------- Original Message --------Hi Dave,By locating function blocks in the field, you can reduce the loading andresources used by a host. For example:You have a host, flow device and valve on a segment. You put the PID inthe host you will need the following VCR's in each location:1) Flow device will need; 1 Server VCR for configuration. 1 Server VCRfor FB access. 1 Publisher VCR for PID. Total = 3 VCR's2) Valve needs; 1 Server VCR for configuration. 1 Server VCR for FBaccess. 1 Subscriber VCR for PID Input. 1 Publisher for BackCalculation. 1 Subscriber for the Input of the AO. Total = 5 VCR's3) The host needs: 1 Client VCR for configuration. 2 Client VCR's for FBaccess for each device. 1 Subscriber VCR for AI Input. 1 Publisher forOutput of PID. 1 Subscriber for the Back Calculation of the AO. Total =6 VCR'sTotal for all = 14 VCR'sIf we move the PID to the valve:1) Flow device will need; 1 Server VCR for configuration. 1 Server VCRfor FB access. 1 Publisher VCR for PID. Total = 3 VCR's2) Valve needs; 1 Server VCR for configuration. 1 Server VCR for FBaccess. 1 Subscriber VCR for PID Input. Total = 3 VCR's3) The host needs: 1 Client VCR for configuration. 2 Client VCR's for FBaccess for each device. Total = 3 VCR'sTotal for all = 9 VCR'sYou can see that it is much more efficient regarding bandwidth and VCRusage to keep control in the field.- -- - - - - - I fully agree that having the function blocks in the field devices improveefficiency and control performance. Determinism and short macrocycle timereduce variability, bringing considerable savings to the user andimprovement in product quality. Macrocycle time reduction is achievedthrough the right selection of fast executing blocks and reduction ofconnections through the bus. The PID in the transmitter takes twoconnections whereas in the valve it takes one, but sometimes the PIDexecution in the transmitter is faster, making the macrocycle shorter. I would like also to clarify that in this string of emails there are somepoints that require a certain reality check.Fully configurable VCRs "eat" a lot of memory. Memory is gold in fielddevices. Unnecessary VCRs lock capacity that could be used in importantfunctions such as, for example, diagnostics.A large number of function blocks in a device does not imply in a largenumber of VCRs, as it was mentioned in a past email.Lets first talk about overhead VCRs. A permanent VCR for configuration isonly needed if you use a configuration tool that can not intelligentlydisconnect itself when not needed. Typically, this configuration tool isonly needed during device commissioning and not during operation. The hostconnection is what is used for operational configuration of the device, e.g.mode changes, setpoint changes, gain changes, etc. An analysis of practical process control applications demonstrate that atransmitter requires a maximum of 4 to 5 publisher/subscriber connections.Other block connections are internal to the device.Here is what is needed:1 host1 temporary configuration tool1 network management,1 permanent maintenance tool2 alerts and trend5 pub/subTotal: 11 VCRsPeople spend a fortune in optimization programs, but sometimes adeterministic, fast executing and well tuned loop can operate miracles. regards,Marcos------ ------ ------The number of P/S VCR's is ENTIRELY dependent on the function blocks beingused and the application applied.As more hosts become available, manufacturers are going to be under a lot ofpressure to add more VCRs with the blocks they are putting in theirdevices... As long as they only sell their devices with their host nottoo many problems...-Kurt----- ------Some comments on Marcos reaction on this subject:We find that reduction of macrocycle time by selection of fast PID executionis in practise overruled by other constraints: End users are in the first place interested in cost savings of FF comparedto other options. Cost savings (by now a well known list) are indeedachieved by e.g. the FF infrastucture, better control performance, etc. Thefirst interest in a project is to optimise the number of devices persegment. This has consequences on the macrocycle. Our experience is that amacrocycle of 1 sec is a realistic figure with typical 10 devices and somecontrol loops on the wire. With the present PID execution times we end upwith a fast loop execution (even a cascading one is about 400 msec) which isonly performed once every second. I therefore don't see much in selection offast PIDs unless for a nice application with a dedicated small segment.With fixed VCRs one will indeed less memory, but we have seen that theninteroperability issues surface with hosts of different vendors. Fixed VCRstherefore will promote a single vendor approach. The same holds at presentfor advanced diagnostics: also a single vendor approach will enable full useof such features. The single vendor approach is not preferred and we shouldfind ways to standardise more than what is done now. Futhermore there isneed for more FF tic-marked function blocks and hence more VCR capability inthe devices (is this feasible or are we already at the limits of FFtechnology?). Maybe at this stage we should not worry about efficiency too much and makeFF happen first by sufficient VCRs, power, memory, whatever, and later onimprove the efficiency of the devices and reduce the macrocycle.Regards Bindert Douma