Hi Jerry, I've been changing some sequence code today, building user labels where possible and using new "local" blocks, connected to the off station CP and declared as variables in case I've used up all the user labels. I'm also paying attention to the wait's, we have quite a few seq's which can do with some extra "wait's" I still have to check a lot of sequences, for most of them we use define files (each unit has it's define file), so we can work with include sequence files, rather than having to write the code for each unit. Unfortunately a #define is nothing but an "alias", the code interpretes this as a C:B (network call)....So I'll probalby use the defines to create variables instead of using the define names in the code directly (except for ain's, cause i need updated values for this, so when possible I'll use labels here) So I'll be seeing a lot of HLBL for the next weeks ;-) We've had to build in "wait" statements also after we changed from CP60's to CP270's. Steps that executed fine before the upgrade were skipped after the CP upgrade, I now use plenty of wait's in the newer stuff. Many thanks to everone who contributed for the good advice Rgds, Dirk Jerry Hidahl <Jerry_Hidahl@xxxxxxxxxxxx> Sent by: foxboro-bounce@xxxxxxxxxxxxx 30/08/2010 15:49 Please respond to foxboro@xxxxxxxxxxxxx To foxboro@xxxxxxxxxxxxx cc Subject Re: [foxboro] system error in sequences 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