AW: Accumulator Block
Hi, suggest using the TIM command which returns the number od seconds since Midnight date Maybe the station block variables CPLBUG_STA:STATION.HOUR and CPLBUG_STA:STATION.MINUTE are of help. Link them to a CALC block and compare if HOUR is 6 and MINUTE is 0. In case this is TRUE generate a 2 Seconds Pulse with OSP and link that to the RESET input of the ACCUM. I think then the time sync problems mentioned by Rick Rys (which are true) should not affect this application. best regards - Marcel Sieling Systems Technologies FOXBORO Deutschland GmbH Heerdter Lohweg 53 - 55 40549 Duesseldorf Tel.:+49 (0)211 5966-171 Fax: +49 (0)211 5966-104 Mobile: +49 (0)172 2673077 E-Mail: [EMAIL PROTECTED] http://www.foxboro-deutschland.de Private Home: http://www.powerslider.de -Ursprüngliche Nachricht- Von: Heath, Graham [SMTP:[EMAIL PROTECTED]] Gesendet am: Freitag, 16. März 2001 09:15 An: 'Foxboro DCS Mail List' Betreff: RE: Accumulator Block suggest using the TIM command which returns the number od seconds since Midnight date I say RTFM. regds -Original Message- From: Loyd Greer [mailto:[EMAIL PROTECTED]] Sent: 15 March 2001 1:31 To: Foxboro DCS Mail List Subject: Accumulator Block Hi to the list. I would like to clear (reset) an accumulator block at 0600 every day with the system clock or TOD. If this can be done, I would appreciate any suggestions on how to do it. Thanks in advance Also thanks to Joe Gale for help on a Weather Station Display. Loyd Greer Great Lakes Chem. --- 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] --- 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] --- 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]
AW: Crontab Log
Hi, For this reason, the lack of cron logging is minor as compared to the possible consequences. Of course you're right. But on the other hand... CRONLOG=NO in /etc/default/cron. ...is some kind like a brute force method, it results in nothing being logged by cron and sometimes for debugging it makes definetely sense to log outputs of cron jobs. So I still recommend using the redirection to /dev/null on each cron entry, in case you need the output it's easy to change the setting for that cron job without having to restart anything. Note: If you place the following lines... EDITOR=vi export EDITOR ...in the file /usr/fox/bin/VT100.script befor the shelltool is invoked, you can very easily edit the cron while it is running using vi with typing the command # crontab -e at the Shell prompt. If you save your changes you can check it's success instantly with # crontab -l Note, that /usr/fox/bin/VT100.script is overwritten by some foxboro installation processes and that changes there maybe have to be re-implemented afterwards. best regards - Marcel Sieling Systems Technologies FOXBORO Deutschland GmbH Heerdter Lohweg 53 - 55 40549 Duesseldorf Tel.:+49 (0)211 5966-171 Fax: +49 (0)211 5966-104 Mobile: +49 (0)172 2673077 E-Mail: [EMAIL PROTECTED] http://www.foxboro-deutschland.de Private Home: http://www.powerslider.de -Ursprüngliche Nachricht- Von: Jack Easley [SMTP:[EMAIL PROTECTED]] Gesendet am: Dienstag, 20. März 2001 15:23 An: [EMAIL PROTECTED] Betreff: Crontab Log I believe recommended procedure to stop cron logging is to change the statement CRONLOG=YES to CRONLOG=NO in /etc/default/cron. You must stop/start the cron process after this to make the changes take effect. From the borne shell, use /etc/init.d /cron stop to stop cron, then /etc/init.d/cron start to start cron.I also make it a rule to append every line I enter into cron with /dev/null 21. The worst mistake I have ever made on the Fox occurred when the cronlog was enabled and a new scheduled cron process errors was not redirected to cron. This particular dwprocess accidently created a large cronlog and filled the /var partition overnite! Your Fox machines will not run with a full /var partition as space is required for a lot of normal Foxboro processes. The result was a lockup of all Foxboro machines. Not Good! For this reason, the lack of cron logging is minor as compared to the possible consequences. --- 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] --- 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: PID equations
Ben, What I need is the exact equation. The section that you mention is only philosophical, I think. Thanks. -Mensaje original- De: Mansfield, Ben [mailto:[EMAIL PROTECTED]] Enviado el: Martes 20 de Marzo de 2001 7:51 AM Para: 'Foxboro DCS Mail List' Asunto: RE: PID equations I believe you'll find what you're looking for in the Foxboro document B0193AX, Integrated Control Block Descriptions in the PID, PIDA, etc. chapter. There is a section towards the end called Detailed Operation that describes how the output is computed based on the controller mode (MODOPT). Ben -Original Message- From: Eudilson Núñez Cossio [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 11:57 AM To: 'Foxboro DCS Mail List' Subject: PID equations Hi list, I looking the equation for PID controllers that exist on I/A Foxboro. Someone can send me this information? Thanks in advanced. --- 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] --- 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] --- 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: PID equations
We had to create it once as the Fox help desk was, well, no help. We used Foxboro's original 1970-something document on PID equations (ancient thing) that the IA stuff was based on. I will try to dig up what we got. It's a coupled equation, which is a big bother from a control theory side, but was apparently the thing to do with the original pneumatic controllers. Also, you have to work in the time domain to get the full effect of what the thing is doing (again, not too elegant). Kirk Kirk Carver ExxonMobil BPEP (409) 860-1314 email: [EMAIL PROTECTED] Eudilson Núñez Cossio [EMAIL PROTECTED] on 03/20/2001 08:40:05 AM Please respond to Foxboro DCS Mail List [EMAIL PROTECTED] To: 'Foxboro DCS Mail List' [EMAIL PROTECTED] cc:(bcc: Kirk D Carver/Beaumont/Mobil-Notes) Subject: RE: PID equations Ben, What I need is the exact equation. The section that you mention is only philosophical, I think. Thanks. -Mensaje original- De: Mansfield, Ben [mailto:[EMAIL PROTECTED]] Enviado el: Martes 20 de Marzo de 2001 7:51 AM Para: 'Foxboro DCS Mail List' Asunto: RE: PID equations I believe you'll find what you're looking for in the Foxboro document B0193AX, Integrated Control Block Descriptions in the PID, PIDA, etc. chapter. There is a section towards the end called Detailed Operation that describes how the output is computed based on the controller mode (MODOPT). Ben -Original Message- From: Eudilson Núñez Cossio [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 11:57 AM To: 'Foxboro DCS Mail List' Subject: PID equations Hi list, I looking the equation for PID controllers that exist on I/A Foxboro. Someone can send me this information? Thanks in advanced. --- 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] --- 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] --- 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] --- 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]
AW: crontab issues and other useful information
Hi Alex, do you have this text on the F10 key? ;-))) best regards - Marcello. -Ursprüngliche Nachricht- Von: Johnson, Alex [SMTP:[EMAIL PROTECTED]] Gesendet am: Dienstag, 20. März 2001 16:50 An: Foxboro DCS Mail List Betreff: RE: crontab issues and other useful information Re: omset should never be used for application purposes One should generally use /opt/fox/bin/tools/omsetimp instead of omset. The caveat with it is that it eliminates broadcasts by placing the compound name and the corresponding address in the IMPORT table. The IMPORT table is 100 entries by default and it can be filled. The IMPORT table usage can be monitored by using 'show_params'. The size of the IMPORT table can be increased by following the procedure described either of the following manuals: * B0193MJ - 50 Series Configurable Operating System and * B0193ND - System Administration Guide for 50 Series Systems (Solaris 2.X) Regards, Alex Johnson 10707 Haddington Houston, TX 77043 713.722.2859 (office) 713.722.2700 (switchboard) 713.932.0222 (fax) [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- From: Sieling, Marcel [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 6:50 AM To: 'Foxboro DCS Mail List' Subject:crontab issues and other useful information Hi, I reset accumulators as follows by adding the following line to the the scheduler cron table 1 6 * * * /opt/fox/bin/tools/omset -v -b T COMPUND_NAME:ACCUM_NAME.RESET You will need to write an application to clean up the cron logs periodically to conserve disk space. Let me make two notes on this statements: 1.) omset should never be used for application purposes, if it can be avoided. The use of omset (omcrt, omdel, omfnd, omget etc.) produces Broadcast Messages on the Nodebus, which can very easily overload the system, especially in large systems, because Broadcasts are sent to all stations. 2.) The cron logs can be kept from growing if output is sent to some device or file or /dev/null in the crontab. Of course then you can't look at them anymore to investigate in case of problems. But often this is a nice solution for every days work and only in case of problems you change the redirection to a file. Since cron is running the cron jobs in a bourne shell, the appropriate statement would look like this: 1 6 * * * /opt/fox/bin/tools/omset -v -b T COMPUND_NAME:ACCUM_NAME.RESET /dev/null 21 In case you want to see only errors and not the regular messages try this: 1 6 * * * /opt/fox/bin/tools/omset -v -b T COMPUND_NAME:ACCUM_NAME.RESET /dev/null 2/usr/tmp/my_phantastic_logfile BTW: Did you know, where the dust in long used computers is coming from? Well, it's pretty simple and obvious: All data being sent to /dev/null ist being transformed into thermal energy, because it can not disappear from the world without being transformed to something else. Now (as every physics student knows) thermal energy corresponds to mass with the famous equation E=mc^2 from Albert Einstein. So all the thermal energy is transformed to mass and that's where the dust in computers comes from. ;-)) Now you know. ;-) PS: Don't tell my boss I'm wasting time writing such emails. ;-)) best regards - Marcel Sieling Systems Technologies FOXBORO Deutschland GmbH Heerdter Lohweg 53 - 55 40549 Duesseldorf Tel.:+49 (0)211 5966-171 Fax: +49 (0)211 5966-104 Mobile: +49 (0)172 2673077 E-Mail: [EMAIL PROTECTED] http://www.foxboro-deutschland.de Private Home: http://www.powerslider.de -Ursprüngliche Nachricht- Von: Freddy Why [SMTP:[EMAIL PROTECTED]] Gesendet am: Freitag, 16. März 2001 10:36 An: Foxboro DCS Mail List Betreff: RE: Accumulator Block Loyd, I reset accumulators as follows by adding the following line to the the scheduler cron table 1 6 * * * /opt/fox/bin/tools/omset -v -b T COMPUND_NAME:ACCUM_NAME.RESET You will need to write an application to clean up the cron logs periodically to conserve disk space. The above works for 50 series server , for 20 series the application 'omset' is in directory /usr/fox/bin/tools Regards, Freddy Why AFH Devers -
RE: Crontab Log
There is actually a job in the standard cron configuration that is supposed
to maintain the cron log within a reasonable size:
0 2 * * 0,4 /etc/cron.d/logchecker
When the cron log (/var/cron/log) reaches a max size, it will be renamed to
olog and an empty running cron log is created. The only problem is that it
is checking the size against the ulimit setting, which is set by default on
AP/W5x systems to 'unlimited' in which case the script simply exits.
We modify logchecker to limit log size as follows:
LIMIT=`ulimit`
if [ ${LIMIT} = unlimited -o ${LIMIT} -gt 1024 ]
then
LIMIT=1024 # better than nothing: 0.5MB file
fi
This gives us a reasonable cron history (2 * 1024 blocks = 2 * 512K), even
in an environment that uses quite a few cron jobs. You can substitute
whatever limit you feel comfortable with on your limited /var partition
(specify the limit as disk blocks).
If you really want to regain some space in /var, schedule a job to reset
/var/adm/wtmp and /var/adm/wtmpx on a regular basis (e.g. weekly) - that
frees up significant space (in some instances 15+MB, depends on age of
system).
Joachim Hirche
CIM Concepts Inc.
200 Continental Drive Ste 112 - Newark DE 19713 USA - 302 368 8982
[EMAIL PROTECTED]
-Original Message-
From: Jack Easley [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 09:23
To: [EMAIL PROTECTED]
Subject: Crontab Log
I believe recommended procedure to stop cron logging is to change the
statement
CRONLOG=YES to CRONLOG=NO in /etc/default/cron. You must stop/start the cron
process after this to make the changes take effect. From the borne shell,
use
/etc/init.d
/cron stop to stop cron, then /etc/init.d/cron start to start cron.I also
make
it a rule to
append every line I enter into cron with /dev/null 21.
The worst mistake I have ever made on the Fox occurred when the cronlog was
enabled
and a new scheduled cron process errors was not redirected to cron. This
particular
dwprocess accidently created a large cronlog and filled the /var partition
overnite! Your
Fox machines will not run with a full /var partition as space is required
for a
lot of normal
Foxboro processes. The result was a lockup of all Foxboro machines. Not
Good!
For
this reason, the lack of cron logging is minor as compared to the possible
consequences.
---
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]
---
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: Crontab Log
--- Hirche, Joachim [EMAIL PROTECTED] wrote: snip If you really want to regain some space in /var, schedule a job to reset /var/adm/wtmp and /var/adm/wtmpx on a regular basis (e.g. weekly) - that frees up significant space (in some instances 15+MB, depends on age of system). Additionally, if you are experiencing growth in these wtmp, wtmpx, utmp and utmpx files such that you need to trim them weekly, consider checking for a corrupted _sactab file: % cd /etc/saf % sacadm -l /etc/saf/_sactab file is corrupt % HH874 has details on this issue. Regards, Kevin FitzGerrell Systems Engineer Foxboro New Zealand Tel: +64 (9) 573 7690 Fax: +64 (9) 573 7691 __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ --- 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]
AIM*AT Messages
Does anybody know how to extract alarm messages (and/or other message types) from AIM*AT (v3.0) running on a AW51E from a shell script? I need to extract the alarm messages to a flat text file. I currently use fh_sacego to extract system monitor messages and point data but do not know how to get any other message types. Under the old historian I had a cron job run every night to extract the alarm messages and highlight problem alarms. This is displayed in a DM display and email to other places. I want to restore this function, but AIM*AT does not seem to have any Unix based tools to do this. Richard Wetton BP Refinery, Bulwer Island Brisbane, Australia. --- 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]
