Maybe I don't get outside my Region here in the SouthEast much, but I have never heard this "UNIX bigot" term until seeing it posted here. I think long-time Foxboro employees take pride in the UNIX offering we have provided over the years. Andrew W. Carter Invensys Process Systems 235 Quail Ridge Road Helena, AL 35080 Office: (205) 428-9242 Cell: (205) 215-9440 Fax: (205) 428-9223 -----Original Message----- From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of Johnson, Alex (Foxboro) Sent: Friday, February 04, 2005 2:19 PM To: foxboro@xxxxxxxxxxxxx Subject: Re: [foxboro] Super Duper Tools, was: IACC Product and Integratio n with existin g I/A tool s Re: the term "UNIX bigots" Personally, I find the term offensive. I think it denigrates those of our customers who find that part of our offering to be the one that best meets their needs and it de-humanizes our customers and their needs. I implies that the speaker thinks the user of that technology doesn't understand their own needs. I will not tolerate the usage of the term by Invensys folks. Re: I believe he (Alex) thinks the "UNIX Bigots", (and I mean that in the nicest possible way everyone), should be more accepting of the new Windows based apps. I stated in front of several hundred users in San Antonio that our (IPS') goal is to make our applications so valuable that you want to upgrade your systems to use them. I strongly believe this. If we don't make our offering compelling we aren't succeeding. Re: IACC The current IACC is the first step. We are actively working the next generation and we hope it will be even more compelling. Regards, Alex Johnson Invensys Process Systems Invensys Systems, Inc. 10707 Haddington Houston, TX 77043 713.722.2859 (voice) 713.722.2700 (switchboard) 713.932.0222 (fax) ajohnson@xxxxxxxxxxx -----Original Message----- From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of tom.vandewater@xxxxxxxxxxxxxx Sent: Friday, February 04, 2005 1:00 PM To: foxboro@xxxxxxxxxxxxx Subject: Re: [foxboro] Super Duper Tools, was: IACC Product and Integratio n with existin g I/A tool s Thanks for the feedback Marcel. You are obviously quite knowledgeable about IACC and I appreciate the time you have taken to share your experiences. We have used the Exception Handler in our code where it is appropriate. In most instances our sequences are ("sequential" ;) and we don't want them to proceed unless the previous step has been properly executed. We use the sequence alarm capability, (OP_OPT), to notify the appropriate operating technician of problems with sequences so they can contact us. As far as using grep, we have over 50 CP's running our processes which work together in a continuous train. There are significant interactions between the CP's across both the nodebus and the sitewide CBLAN. To insure we catch all of those potential interactions we would have to grep all of the .s files in all of the compounds on all of the AW's. It could definitely be done with an automated script but it would take a little longer than searching our database with the Super Duper IA Browser. IACC definitely sounds like a better tool to consider if a user is starting out from scratch, but it still doesn't address all of the problems that users have. Because of this, users have created scripts and databases to meet their needs. Most of the people on this list have used UNIX as their building block and are used to using commands like grep, awk, sed, and a host of other command line tools to get what they want from the object manager or text based configuration files. That is at the root of Fox IA's appeal to many of the users and it creates problems for those users when new applications are developed, especially on a different OS that is GUI based, if those applications don't eliminate the need for all of the UNIX/Command Line based applications. I have had this discussion personally with Alex. I believe he thinks the "UNIX Bigots", (and I mean that in the nicest possible way everyone), should be more accepting of the new Windows based apps. I say they will be accepted when those applications make conversion from the old to the new relatively painless and they offer more functionality and possibilities than the old stuff. So far there is enough advantages for us to do it. I keep asking questions to try and make sure I understand the new capabilities. Besides the CSD capability, another initial attraction to using IACC for me was the ability to create consistent graphical conventions for the depiction of common block types, but we would have to use Foxview/Foxdraw and we currently use the Display Manager. Considering the 50 CP's, you can imagine that we have several hundred megabytes of DM graphics. I have heard people say that they had no problems converting DM graphics to Foxview but when I tried it with ours, the conversion was far from satisfactory. The problems were especially noticeable with the font conversions, but there are also problems with line sizing and aspect ratios. That meant we would have to go into FoxDraw and fix all of the graphics just to get them to look like they did in the DM. I worked on a moderate sized file to see how long that would take and it took me about 30 minutes to re-adjust. That calculates into man-months of effort for all of our graphics. We have already created globally generic overlays for each block type that we use in the DM environment. That allows us to define the Compound and Block so the DM can build and call up a faceplate on the fly, eliminating our need to build individual faceplates for each loop created in the ICC. We call user generated library elements that are already configured onto a base graphic. They "know" how to invoke the generic overlay when clicked on by a mouse. So, for me, I can't justify the time, expense, and training it would take for us to move our applications from the old to the new. I wish the applications were compelling enough for me to want to transition to them regardless of whether I could justify it, but that is not yet the case for me and I think many others on this list. Tom VandeWater Control Systems Developer/Analyst Dow Corning Corporation Carrollton, KY USA -----Original Message----- From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Sieling, Marcel Sent: Friday, February 04, 2005 5:12 AM To: 'foxboro@xxxxxxxxxxxxx' Subject: [foxboro] Super Duper Tools, was: IACC Product and Integration with existin g I/A tool s Tom wrote: > This type of information is most important when=20 > deleting existing blocks because a sequence trying to get or=20 > set a variable that no longer exists will cause the sequence=20 > to hang up. =20 And I'd like to add [I take the risk to repeat myself in this issue]: ...if you don't use Standard Block Exceptions. If you do (TO_SYS_ERROR = in this case) it's easy to issue a well defined error message, where the = line number of the source code and the error number (OP_ERR -1 or -45, = depends upon read or write has performed) is printed and the block does NOT = hang up. However, the Super Duper I/A Browser is a great idea and for sure = extremely useful. > My question to IACC users is: > Is there any way in IACC to see if a block is being=20 > manipulated by a sequence get or set? No way, sorry. > How do other users address this situation? my personal Super Duper I/A Browser for omsets and gets in Sequence = Code is called "grep", preferably executed in = /opt/fox/ciocfg/<COMPOUNDNAME>/*.s. ;-))) Best regards - Marcel Sieling Systems Technologies Invensys Systems GmbH Emanuel-Leutze-Str. 11 40547 Duesseldorf Germany Tel.: +49-211-5966-302 Fax: +49-163-99-5966302=20 Mobile: +49-163-5966302 Email: mailto:marcel.sieling@xxxxxxxxxxxxxxxx Homepage: http://www.foxboro-deutschland.de _______________________________________________________________________ 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 _______________________________________________________________________ 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