I see a significant amount of discussion on here regarding use of these blocks and sequence code. Not wanting to ignore a potential tool in my toolbox....OK, really I'm just lazy* and do not want to pass up an opportunity to get a computer to do something instead of me. Some background: my plants are continuous processes. I inherited systems in both plants. Neither system had any sequence code in it - nada. I had heard all the horror stories about sequence code loading CPs, issues with memory fragmentation, etc. etc., so I never took a big interest in learning it. I then had an application, non-control, where a large number of complex calculations were being performed. I felt it was a good application for sequence code, so I built an IND block and got after it. It worked fine, but at the default BPCSTM of 100, it caused a CP30A's idle time to drop by over 30% (it was about 50 lines of code, with a WAIT loop back to the beginning). I set BPCSTM to about 10, and the idle time problem went away, but I only got away with it because this application did not need anywhere near real-time performance. I sgain shied away for using it do do anything that did have such requirements. Which is a shame, really. I used the sequence equivalent fairly frequently in my Brand H days, partly because they did not really have a CALC* equivalent (you had logic, or math, but not both in one block), partly because some flavors of their sequence-equivalent had wide system access that I needed. I don't think I'd go crazy with it on I/A, but there are 2 or 3 applications where it would be nice to have if it didn't have the issues I saw. So how do others use sequence on I/A? Batch only? How do you get around the CP loading issues? What other issues do you have? How do you get good performance and reesponsive interaction with a human operator? Vi or emacs? :) Thanks, Corey Clingo BASF Corporation _______________________________________________________________________ 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