RE: Legacy Historian Upgrade
I am familiar with the Legacy Historian but I was recently at a plant where they had the new AIM* Historian. It was installed on a Sun machine. I really like the fact that you can change its configuration without shutting it down. This allowed us to tighten many deadbands specifically for the tests we were running without impacting their normal data collection. There is a GUI configuration program for Solaris and it is not too bad. We had a strange problem trying to enter new deadband number for a few points. For some reason it would not accept the number we wanted to enter. So instead we ended up entering 0.0 which worked. The main thing I didn't like was the data extraction capabilities. It may be that there is a better tool, but the only one I could find was the Data Display function. This is much improved over the same program for the Legacy Historian but it is still a pain to use for extracting a large amount of data. I ended up having to extract 63 separate files to get all the data we needed. It then took me about 6 hours to merge all that data into a single Excel file. On our Legacy system we use a program called ProcIns_extract to extract data and it is much easier to use. I am always amazed that Historian developers and vendors don't include a simple program to extract data to a text file in their base system. Westinghouse has the same problem as Foxboro in this area. Cyrus Taft Chief Engineer EPRI IC Center Harriman, TN --- This list is neither sponsored nor endorsed by the Foxboro Company. All postings from this list are the work of list subscribers and no warranty is made or implied as to the accuracy of any information disseminated through this medium. By subscribing to this list you agree to hold the list sponsor(s) blameless for any and all mishaps which might occur due to your application of information received from this mailing list. To be removed from this list, send mail to [EMAIL PROTECTED] with unsubscribe foxboro in the Subject. Or, send any mail to [EMAIL PROTECTED]
What the future holds.
David, I like the way you translated the last paragraph. Unfortunately you have to do that with all news these days to get around the spin. It sounds like Solaris is out. Too bad. Cyrus Taft Message text written by Foxboro DCS Mail List Let us dissect the last sentence. The common architecture, (we're putting all of our development effort into one platform) which will run on Microsoft technology(no surprise here), will offer a migration path for customers(Solaris users are in trouble), greater ease of use (always promised, seldom delivered), scalability (You can mix and match NT, 2000 and XP), and more functionality(comes with Excel plug-ins). --- This list is neither sponsored nor endorsed by the Foxboro Company. All postings from this list are the work of list subscribers and no warranty is made or implied as to the accuracy of any information disseminated through this medium. By subscribing to this list you agree to hold the list sponsor(s) blameless for any and all mishaps which might occur due to your application of information received from this mailing list. To be removed from this list, send mail to [EMAIL PROTECTED] with unsubscribe foxboro in the Subject. Or, send any mail to [EMAIL PROTECTED]
Re: Bcalci and switch blocks
Message text written by Foxboro DCS Mail List I checked my SELECT page display and mine does not show a BCALCO parameter, just the BCALCI, BCALC1 and BCALC2 parameters. I am using version 4.3, which version are you on? Kevin, I'm at version 6.1. It sounds like they lost a fix when they went to 6.1. Cyrus --- This list is neither sponsored nor endorsed by the Foxboro Company. All postings from this list are the work of list subscribers and no warranty is made or implied as to the accuracy of any information disseminated through this medium. By subscribing to this list you agree to hold the list sponsor(s) blameless for any and all mishaps which might occur due to your application of information received from this mailing list. To be removed from this list, send mail to [EMAIL PROTECTED] with unsubscribe foxboro in the Subject. Or, send any mail to [EMAIL PROTECTED]
Re: FoxAPI programming problems on AW70
Sascha, We really had 2 problems. One was with the sxopen utility for creating the sets. It gave inconsistent results when trying to create a set for read/write access. Sometimes it would not create a set at all and other times it would create the set but the returned status on the entries was -1. When the set was created our routine would still not write to it. We use the wrtval call. I have since learned that there are several write related problems with FOXAPI version 4.2.0 and you should get quickfix 990084 to upgrade to version 4.2.2. I have the quickfix now but have not installed it yet. Cyrus --- This list is neither sponsored nor endorsed by the Foxboro Company. All postings from this list are the work of list subscribers and no warranty is made or implied as to the accuracy of any information disseminated through this medium. By subscribing to this list you agree to hold the list sponsor(s) blameless for any and all mishaps which might occur due to your application of information received from this mailing list. To be removed from this list, send mail to [EMAIL PROTECTED] with unsubscribe foxboro in the Subject. Or, send any mail to [EMAIL PROTECTED]
FoxAPI programming problems on AW70
Message text written by Foxboro DCS Mail List has anyone succeeded in adding objects with read/write access to an application's CDX on the AW70 using the FoxAPI function an_add_objects()? Adding read only objects works fine, but read/write access fails although FoxDoc describes it and even gives an example program (which fails, too). So I'm wondering who is wrong, the function's documentation or the example program. I have a small test program here which tries to add two RI parameters of a CALC block to the CDX. I could send it to anyone interested. We've tried this program on virtually every FoxAPI version we could find and it always failed with return code 76 which is not mentioned by FoxDoc as a possible return code for an_add_objects(). foxapi.h defines it but the description there doesn't tell much since I don't pass any NULL pointers. If you change 'rdwrit' to 'rdonly' (for access type) in the program, it works fine. I could of course open a data set instead for writing but I'm reluctant because doing so gives me those annoying command prompt windows flickering up briefly upon set opening and closing. Data sets also stay open if someone kills the application with the task manager. Sascha, This won't exactly address your question but we have also noticed a change in the behavior of the foxapi on Solaris when writing to block parameters. On version 4.0.1, we had a C program which wrote values to the INP2 parameter of 2 SWCH blocks and it worked fine. We upgraded to version 6.1 for Y2K and now the same program won't work. Both versions used a set for the 2 INP2 parameter points and I think there is a problem creating the sets for write access. We use the sxopen utility to create the sets. We have another application which writes data into shared variables in a set and it still works. So I created two new shared variables, put them in a set and linked them to the INP2 parameters and used the C program to write to the shared variables. It now works fine but I don't know why it would not work the old way. It seems that something has changed in the API. Cyrus Taft EPRI IC Center --- This list is neither sponsored nor endorsed by the Foxboro Company. All postings from this list are the work of list subscribers and no warranty is made or implied as to the accuracy of any information disseminated through this medium. By subscribing to this list you agree to hold the list sponsor(s) blameless for any and all mishaps which might occur due to your application of information received from this mailing list. To be removed from this list, send mail to [EMAIL PROTECTED] with unsubscribe foxboro in the Subject. Or, send any mail to [EMAIL PROTECTED]
