Re: [foxboro] Daily Totalizer Question
- From: kirk.d.carver@xxxxxxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Tue, 16 Jul 2002 12:11:20 -0500
First off, I assume your Toledo, Fairbanks, etc system does not have an
electronic interface to the control system. We had to run that way with
our hopper cars for many years, finally putting in an interface to A-B that
provided a "closure" to the mass balance (or at least closer!)
Perhaps a trigger button toggled by the operator from the input graphic,
leading to a CALC type block would a) make him/her check the number (could
even give smart feedback), and b) provide a deterministic application. We
used that approach several times.
Kirk
----------------------
Kirk Carver
Senior Engineer
ExxonMobil Development
Ph: 281-654-4881
Fax: 281-654-4223
GP6--358
Internet Address: kirk.d.carver@xxxxxxxxxxxxxx
"Angela Gruber"
<aag43220@hotmail. To: foxboro@xxxxxxxxxxxxx
com> cc:
Sent by: Subject: [foxboro] Daily
Totalizer Question
foxboro-bounce@fre
elists.org
07/16/02 11:20 AM
Please respond to
foxboro
Hi list:
This is my first posting so bear with me.
I figured out a simple way to do this temporarily but I am looking for some
thoughts to see if there is something. BTW - we recently upgraded to
version 6.3
-----
We had/have a need to calculate a month-to-date production number utilizing
weigh tickets from railcars. Currently, the operator enters in the daily
railcar loading amount before midnight into a AIN block. Whatever number
is
in the system before midnight is considered to be the final number for the
day.
To get the month-to-date number, I made a simple MATH block that checks to
see if the daily railcar amount (the AIN block pnt value) has changed. If
it hasn't changed, it does nothing (assumes the number is the previous
amount). If it has changed (assumes its a new amount for the current day),
it adds it to the current accumulated value and stores the new number for
the next comparison. I currently have the block set to a period of 8 (60
minutes) to give it the longest time between scans. I have also edited
mastercron to reset the accumulated value at the beginning of the month
back
to 0.
It seems to be working (I have only been running it for 3 weeks now). I
think it could be better. The problem I could run into (but haven't yet)
is
if an operator incorrectly enters in the wrong number before one of the
hourly scans, the MATH calculates (it sees a change), the operator enters
in
the correct number after the scan time. The block would then recalculate
again, only it would be too high - I don't know of a simple way to get it
to
subtract out the error other than having us DCS-folk manually fix it.
But ideally, I would like for the period to be every 24 hours -this would
minimize the error mentioned above because it wouldn't matter much if data
was entered in prior to the scan. At the same time, though, I would like
to
keep it as simple as possible. Perhaps some sort of script that would
toggle the MATH block from MANUAL to AUTO just before midnight, the block
would calculate (put it on a faster period when its configured so it will
scan while in AUTO), then toggle back to MANUAL just after midnight? Or
maye something totally different?
Your feedback is much appreciated
Angie Gruber
OxyVinyls, La Porte, TX
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
_______________________________________________________________________
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: http://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: http://www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts: