Stephen Mitschke
August 12th, 2003, 12:37 PM
I think this will be a good learning exercise/example for everyone and hencethe reason I am posting it to the list.1. I think it will take 2 VCR's, 1 publish/subscribe for each of thefollowing: AI_OUT, PID_OUT, and PID_BKCAL_IN2. That is correct, internal links are 'free'.3. Yes, 1 VCR will be required for each Publisher/Subscriber.I think the easiest way to remember and represent the use of VCR's is thatif you are using the configurator like interface, each interconnecting'virtual wire' requires a VCR for its associated publisher/subscriberrelationship.Ian-----Original Message-----Can we clarify how to count publisher/subscriber VCRs? So far I'vegot 2different answers from two different sources.Could we have the following questions answered:1) Does link between, for example, AI block output and PID blockinputlocated in DIFFERENT FF devices cost 2 VCRs?2) Links between blocks within the same FF device do not cost anyPublisher/Subscriber VCRs. (?)3) Does link between, for example, PID block SP, located in FFdevice, andPID block output, located in host, cost 2 VCRs?(Under links I understand permanent connections between blockparameters.)Thanks,- - - Hi Ian,Why don't you send him my "VCR" guide...Answers below..."Verhappen, Ian" wrote:> > I think this will be a good learning exercise/example for everyone andhence> the reason I am posting it to the list.> > 1. I think it will take 2 VCR's, 1 publish/subscribe for each of the> following: AI_OUT, PID_OUT, and PID_BKCAL_IN> 2. That is correct, internal links are 'free'.> 3. Yes, 1 VCR will be required for each Publisher/Subscriber.> > I think the easiest way to remember and represent the use of VCR's is that> if you are using the configurator like interface, each interconnecting> 'virtual wire' requires a VCR for its associated publisher/subscriber> relationship.> > Ian> -----Original Message-----> > Can we clarify how to count publisher/subscriber VCRs? So far I've> got 2> different answers from two different sources.> Could we have the following questions answered:> > 1) Does link between, for example, AI block output and PID block> input> located in DIFFERENT FF devices cost 2 VCRs?Yes, 1 VCR in each device = 2 VCR's. The way to think about it:Every Input and Output that needs to communicate BETWEEN devices willrequire a VCR. Every Publisher VCR requires at least one Subscriber VCR.If you have an AI in one device and a PID/AO in another device you willneed two VCR's (one in each device):1) A VCR to Publish the OUT of the AI2) A VCR to Subscribe the OUT info and place it in the IN of the PIDIf the PID is located ANYWHERE else you will need more VCR's.> > 2) Links between blocks within the same FF device do not cost any> Publisher/Subscriber VCRs. (?)Correct. Internal In/Out communications between blocks use what arecalled Link Objects. Link Objects are local to the device only.> 3) Does link between, for example, PID block SP, located in FF> device, and> PID block output, located in host, cost 2 VCRs?Do you mean 2 VCR's in the Host? No. You need 3. Assuming the host usesa FF block; Subscriber for IN, Publisher for OUT (assuming Out goes tofinal control AO), Subscriber for Bkcal_In.Again, the way to think about it, every FOUNDATION fieldbus functionblock Input and Output (including Back Calculations) parameter will needa VCR. In a Cascade the best place to have the PID Function Blocks would be inthe final control element (For example the valve, 2 PIDs and the AO) Youwould then still only need 2 VCR's: 1) The OUT of the AI2) The IN of the outer PIDIf you move the outer or inner PID anywhere else (AI transmitter, host,etc.) you will need more VCR's... Give me a specific example and I cantell you how many VCR's will be needed.Keep another thing in mind, some hosts may not use VCR's for functionblocks in the host! Things get really messy then... -Kurt - - - - - Ian,I think that confusion was caused by the fact that in DeltaV documentation,when they speak about VCRs they say that LINE, connecting input and outputcosts ONE VCR. One port of DeltaV H1 card can handle 25 VCRs, and if youcount them as lines, connecting blocks in different devices - it is OK - youcan build pretty complex control strategy, but if you count VCRs as Kurtdescribed, i.e. each line costs you 2 VCRs - limit of 25 does not seem veryhigh. It looks like they use term VCR too loosely.Regards,Oleg- - - - - Hi,I think the original questions came from a concern of limited amount ofresources in a field device. Some devices in the marketplace have manyFunction Blocks but do not have resources many enough to give users afree hand in designing field measurement/control applications fullydistributed among devices. Let me explain. There are two fact groups which confuse users.A fieldbus device has two kinds of communication resources. One isVCR (Virtual Communication Relationship) and the other is Link Object.VCR is a communication resource to send/receive data through it. Acommunication takes place between/among VCRs, which could cause a"Group 1 (relationship or resource)" confusion. For example, Client-Server communication involves two VCRs, one for Client and the other for Server. When you are counting VCRs IN A DEVICE, it is ONE becauseanother VCR resides in another device (communication partner). Thereforecount the number of communications running in a device which are one of:o a Client (send requests to Server and receive responses)o a Server (receive requests from Client and send responseso a Publisher (send an output parameter of a block to other devices)o a Subscriber (receive an input parameter from another device)o a Source (send an alarm or trend to other devices), ando a Sink (receive alarms or tends from other devices).The number you get is the number of necessary VCRs in that device.Link Object is a resource to "link" Function Blocks. If you want tolink Function Blocks in the same device, you need an Link Object butno VCR. You need one VCR to link a block to another block outsidethe device. A Link Object identifies the link is internal or external.Therefore, a link from an output of a block to an input of another block consumes following resources:A Link Object and no VCR in a device, if the link is internal, andA Link Object and a VCR in each device, if the link is external.Function Block applications shed another light to the resources. A controlblock needs bi-directional communication for tracking and bumpless control.Usually a PID block needs OUT and BKCAL_IN connected to the downstreamblock,which requires two Link Objects and no/two VCRs for a device containing thePID block depending on where the downstream block is. The "Group 2 (uni-directional or bi-directional)" confusion comes out when you are mixing upthe communication and application. I would suggest to "draw" a pictureconnecting parameters, which helps you a lot in figuring out the necessaryresources.My answers are:1) A device containing the AI block needs one VCR, while the PID deviceneedsone VCR to get measured value from AI. (Answer requiring TWO VCRs countsVCRs in both devices.)2) No, an internal link consumes no VCR but a Link Object.3) I understand your example is a cascade control where one PID is sittingin a device and another PID in another device. This cascade schemerequires bi-directional communication (PID1.OUT -> PID2.CAS_IN andPID2.BKCAL_OUT -> PID1.BKCAL_IN) and two VCRs in each device (again,the answer of 4 VCRs counts both devices).Please remind above cases do not describe a complete application. Yourapplication consists of more blocks and links. I believe one of "configuration softwares" is very much helful for you to understand this.Simply pick necessary Function Blocks and connect them, then you willbe told the number of consumed VCRs and Link Objects. That would helpyou a lot.I hope this removes the fog around you,Chuji Akiyama- - - - Even counting every input and output parameter is not sufficient. Don'tforget to include alerts/trends, as each one will also require a VCR.+Sean VincentFieldbus Inc.- - - - Hi Folks,There are two seperate and distinct set's of VCR's:1) Those VCR's used by the host2) Those VCR's used by the deviceYou do NOT count VCR's used in the device when refering to the host andyou do NOT count VCR's in a host when refering to a device.The way a host "counts" VCR's is by only counting those used by theHOST. For example (I wrote this up here before) let's say you have 1host and 3 devices (a Temperature, Flow and Valve) using a simple PIDlocated in the valve. This assumes there is no alarming being done bythe host (if alarming is being done by the host add 1 SINK VCR for eachdevice)The _HOST_ will NEED the following VCR's:1) Client VCR for configuration of all devices (used to build the VCR'sin the devices!)3) 3 Client VCR's, one for each device. This is used to get the datafrom the Function Blocks.A total of 4 VCR's are ACTUALLY needed by the host (7 if usingalarming). But, the host may use more than these, the host may set upseperate VCR's for configuration of each device. When counting VCR's for a host DO NOT COUNT VCR's USED IN THE DEVICES!Each device will need the following:Temperature: One Server VCR for configuration, One Server VCR forFunction Block access (One VCR for the Source if alarming is used) 2VCR's total in this device.Flow: One Server VCR for configuration, One Server VCR for FunctionBlock access (One VCR for the Source if alarming is used), One Publisherused for the Flow AI OUT. 3 total VCR's used in this device.Valve: One Server VCR for configuration, One Server VCR for FunctionBlock access (One VCR for the Source if alarming is used), OneSubscriber VCR for the PID IN. 3 total VCR's used in this device.So our total is:4 VCR's needed for the Host (for Delta V with 25 VCR's, 21 VCR's arestill available for other devices, additonal blocks in the host,alarming, etc.)2 VCR's needed in the Temperature Device3 VCR's needed in the Flow device3 VCR's needed in the ValveThis issue of counting VCR's would go away if the host/devicemanufacturers would supply more VCR's. Unfortunately, with some vendorssupplying far too few VCR's, the user is FORCED into counting VCR's. If the users want this problem to go away, talk to your vendors andDEMAND MORE VCR's! The user should NEVER EVER have to worry aboutcounting VCR's! Vendors should supply you with more VCR's in the deviceand host than you would ever use in most applications!Fortunately, there are some vendors that have already addressed thisissue... Other's need to be persuaded a bit more...-Kurt