I hate to sound freshman but have you tried omget to see if anything can get
the value, no cyan in the Select Display, etc. This would at least narrow down
if it's a block or AIM* problem.
Sent from my iPhone
On Mar 23, 2016, at 5:33 PM, Burks, Ashley <Ashley.Burks@xxxxxxxxxx> wrote:
One thing that I also noticed today with the points David mentioned below is
that not only has Aim stopped collecting this data, but my off platform PI
historian has also stopped collecting this data. Do that help to understand
the issue anymore?
Also, the CP that contains the CALC block is the same CP which contains the
sequence code block where the division by zero is taking place.
Thanks,
Ashley
Sent using OWA for iPhone
________________________________________
From: foxboro-bounce@xxxxxxxxxxxxx <foxboro-bounce@xxxxxxxxxxxxx> on behalf
of Tom Vandewater <tjvandew@xxxxxxxxx>
Sent: Tuesday, March 22, 2016 9:00:16 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] AIM* Collection fails after divide by 0
It sounds like your Station Object Manager tables could be messed up David.
If you know how to run RSOM on the CP containing the CALC.RI04 value you
should be able to see the status of the OM peer to peer connection being
sourced from the CP to the station hosting the AIM historian. If it is not
scanning, the problem could be in the CP OM table. You can also use SOM on
the station hosting AIM historian to see the sink status it is receiving from
the remote CP. Just stopping and restarting AIM historian may not clear the
OM table error but rebooting the AIM host box will definitely cause it to
remake all remote connections.
Tom VandeWater
Control Conversions, Inc.
On Mar 22, 2016, at 8:56 AM, "Johnson, David" <dmarc-noreply@xxxxxxxxxxxxx>
(Redacted sender "David.Johnson" for DMARC) wrote:
All knowing list,
HELP!
If we could do this without the freshman lecture on bounds checking, error
checking, and knowing that a divide by zero error was a possibility, that
would be great.
I did it, I divided by 0, the result was NaN and now the data that was being
collected by the AIM* historian has a 1.#QNB showing on the trend, and it is
NOT collecting historical data.
The value is a IND .RO0001, the number goes to a lead/lag LLAG block, the
resulting .OUT of the LLAG goes to a CALC block .RI004 and that is the item
that is trended. (Don't ask...)
The number being calculated by the IND block is now acceptable, all the
numbers are ok, but the AIM* historian will not collect the data.
We have transitioned the LLAG block from Auto to Man and back. We have
DELETE/UNDELETE the CALC block. We did an upload/done on the IND block. We
have stopped and restarted the historian instance that contains the point.
I'm at a loss.
Any help would be appreciated.
Thanks,
David
________________________________
Confidentiality Notice:
The information contained in this message is private and confidential. This
information is intended only for the individual or entity named above. If
the reader of this message is not the intended recipient, you are hereby
notified that any use, review, dissemination, distribution, copying or
action taken based on this message or its attachments, if any, is strictly
prohibited. If you are not the intended recipient, please contact the sender
by reply email and delete or destroy all copies of this message and any
attachments. Thank you.
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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 Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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 Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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
