Re: [foxboro] system error in sequences

  • From: Terry Doucet <doucet427@xxxxxxxxxxx>
  • To: <foxboro@xxxxxxxxxxxxx>
  • Date: Mon, 30 Aug 2010 11:00:31 -0400

If you already have at least one peer (connection oriented) between two 
stations (confirm who is SINK and who is SOURCE) then it is FAR more efficient 
to add another peer to that connection than to have the sequence block perform 
a C:B.P reference which causes a connectionless data transfer.
Terry

> Subject: Re: [foxboro] system error in sequences
> To: foxboro@xxxxxxxxxxxxx
> From: Jerry_Hidahl@xxxxxxxxxxxx
> Date: Mon, 30 Aug 2010 08:48:09 -0500
> 
> Dirk,
> 
> The next best thing to connecting your off-station references to a
> parameter in your sequence block is to use a parameter in a different block
> in the same compound. The next best thing after that is a parameter in a
> different compound, but in the same station. It could be another sequence
> block or a calc-type block.
> 
> The key factor is when the value is updated within the station where your
> block is running. Connections are updated every time before a block is
> executed, but C:P.B references to different stations are only updated when
> a line of code is executed. Whenever an off station reference occurs, the
> code execution is suspended until the answer returns. If a reference is in
> the same station, the value is just fetched or stored to a memory location,
> and the code drives on.
> 
> When we upgraded our kettles last year to FCP270s and consolidated some CPs
> we had to add a WAIT statement for a sequence to work correctly.
> Previously, a key handshake reference was in a different CP, so the
> execution always suspended. After we consolidated, the handshake stopped
> working until we forced the sequence to wait.
> 
> Adding connections to off station parameters won't always be the best
> solution. You have to weigh the cost of the added overhead of updating
> connections every scan, versus slowing the HLBL execution down with C:P.B
> references.
> 
> Jerry Hidahl
> Process Control Engineer
> Port Neches Performance Products
> Huntsman Corporation
> 
> In reference to:
> 
> Hi Chuck,
> Thanks for the advice, For these (small) sequences I already changed the
> code using user labels, but I have many sequences where there are too many
> C:B.P references to use user labels,  I'll go through the sequences and
> change the network calls using variables where needed.
> 
> Rgds,
> 
> Dirk
> 
>  
>  
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>  
> foxboro mailing list:             //www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>  
                                          
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 

Other related posts: