Thread Content
Urgent help needed: Since 4 days ago, multiple cards in DeltaV have been going offline irregularly. Everything that could be tested has already been tried, but the problem still hasn’t been resolved. Requesting help. Let’s first describe the basic setup of the system: it involves card C28 (16-channel AI), C29/30, C31/32, C33/34, C35/36, C37/38, and C39/40 (all of which are 8-channel redundant AI cards). Starting from C41, there are AO cards, and there are almost no alarms ; Card alarm types: no communication with the card, new active card, card in safety mode, etc., as well as I/O input failures for all channels on such cards ; Alarm interval: as short as 1 second, or as long as 4-5 hours. Multiple instances have occurred where 7-8 cards trigger alarms simultaneously, resulting in continuous redundant switching. Among them, C28 and C39/40 trigger alarms most frequently ; Places that have been processed or inspected so far: 1) The system’s power supply is stable, as is the power supply to the floor (11.5VDC), even during continuous alarms and switching by the card modules; no abnormalities were found in the system’s grounding ; 2) Two new cards have been replaced for each of C28 and C39/40; one redundant terminal was replaced for C39/40 ; 3) C28, C39/40: Disconnect the power supply at the card slot, remove the hardware configuration related to those cards, and delete the C39/40 cards. (Even after disconnecting the power supply and removing the hardware configuration, C39/40 continued to give alarms; therefore, those cards were deleted temporarily.) ; 4) Continuously delete the card-related alarm messages, and reinsert each card ; 5) Switch controller ; 6) Checks were performed on C28 and C39/40; there were no obvious abnormalities in their grounding or insulation conditions (the alarm continued to trigger even with the connectors disconnected, so this was merely a routine check) ; All of the above has been done and checked; 4 days have passed, yet the card continues to trigger alarms and go offline. I’m asking for help from all the experts out there – has anyone encountered a similar situation, or can they suggest other ways to conduct checks? Everything is crashing; in the middle of the night, there’s nothing I can do to deal with those alerts that update 3 or 4 times per second as shown in the diagnostics.
It’s crazy – when I got up this morning, C41 to C50 were all in the wave mode (they weren’t in that mode before); they’re all redundant AO units... I’m still checking to see if the valves on site have moved
It would be best to contact your Delta V agent (who might also be Julu International) and have someone send over to assist with the inspection.
I’ve already contacted them; they went to the site to check things out, but there’s no good solution
The last edit to this post was made by sdlyml on 2020-4-17 at 08:51. 1. When the controllers switch back and forth, communication with the cards connected becomes impossible; we should focus on the issue with the base unit, and it would be best to replace it; Individuals tend to have issues with the base. 2. If it can accept cards, try using various cards. Redundant dual cards maintain consistent versions.
I have also guessed about the problem with the bottom plates; there are now 4 bottom plates that are 8 units wide, but the conditions aren’t available yet to replace them. Regarding the version issue, we have verified that the redundant cards are consistent. Including when testing card replacements, a pair with identical versions is used.
This is a serious risk; it’s recommended to park the vehicle. . . After all, they are all redundant cards that are part of the chain; contact Emerson as soon as possible and try to have Emerson handle it. After all, you’ll get reprimanded for stopping the car due to instrument issues; it’s even more embarrassing if you stop the car without resolving the problem first. I still tend to think it’s a problem with the base plate connection or the base plate itself.
At the moment, the issues related to the fixtures in this cabinet are still within controllable limits. The key problem, as you said, is that we’re worried that when it comes time to stop the machine, we won’t know what to do: Funk:; that would be a disaster
So it’s better to have Emerson come over; if they can’t handle it, it’s easier to shift the blame to them: L
Contact the manufacturer as soon as possible, and be sure to keep evidence of the communication.
I can’t understand it, but it seems very sophisticated