Slot 4 is an input card, the IQ16 feeding the infeed photo eyes, and with it faulted the packer won't index. I pulled it and reseated it twice, then pulled it out and dropped it in slot 6 with the tree changed to match, and it faults in slot 6 as well. Put the old spare from the crib in slot 4 instead and that faults too.

Two different cards faulting the same way in two different slots has me thinking the backplane, but the rack's only eighteen months old. Is that where you'd look next?

The MSG sets .ER on the first scan it runs and .ERR sits at 16#0005. Not intermittent, every single time. I gave it its own MESSAGE tag at controller scope in case the old one was shared, put a one shot ahead of the rung so it can't retrigger, and downloaded twice. Still 0005.

Am I right that 0005 is the class or the instance, or can the path throw that as well?

Steam went down for about two hours on Tuesday for a boiler trip. CV sat at 100% the whole time, which makes sense with PV falling. But when steam came back the CV stayed at 100 for another eleven minutes after PV crossed SP, and the temperature overshot by 9 degrees C before it came down. Nearly tripped the high temp alarm. I checked the valve and it strokes fine, and the operator on site says it does this after every steam outage.

Is this a tuning problem? The gains haven't changed in years. Or does something happen inside the PIDE when CV sits at 100 for two hours, could someone explain why it takes eleven minutes to come off?

Drive powers up, display says STO, and the axis in Studio sits at Inhibited. MSO errors straight away with a code I'd have to look up again, 60 something. We recreated the axis with defaults and reflashed the drive to the version Studio wanted, no change either way. Motor and feedback cables are fine and the drive sees the motor.

Is there an axis parameter I'm missing for STO on the 5500? Or is it something to do with there being no safety circuit on the rig yet, I'm not sure what else to look at.

second time this has happened. first time we figured somebody downloaded the old file by accident, but nobody did tonight, i was standing there. went online and compared and it's definitely the march version, and downloading my file again fixes it until the next power cycle i guess.

is the controller memory going bad? i don't want to redownload this every time a breaker trips. what am i missing

Online the rung is true and Local:5:O.Data.12 is 1, but the electrician put a meter on the terminal and reads 0V to common. Module OK green, no yellow triangle, no fault in the tree. I checked it with a force on the output and it's still 0V, and when we moved the solenoid wire over to point 3 the gate fires fine. Back on 12, nothing.

There's a red LED on the front of the module I've never seen lit before. Can we get by on point 3 until a new module comes in, or is that a bad idea? And that red LED, I guess that's telling me something I ought to sort out before I leave it sat on point 3?

Major Faults says Type 06 Code 01, Task watchdog expired, and names the task, T_Weigh. That one is 10ms periodic with the watchdog at 20ms, which somebody set in 2017. My new routine takes an array of 500 REALs and does a running average in a FOR loop. I cleared it and it faulted again about three minutes later, and with the JSR pulled back out it ran all weekend with nothing.

Am I looking at raising the watchdog, or is the L73 just slow for this? Pretty sure 500 REALs in a FOR loop isn't a lot of work, so is it the loop, or has that 20ms been getting away with it since 2017?

Controller Properties, Major Faults says Type 03 Code 16, I/O connection failure, and it names the AENTR. We tried a bigger 24V supply and a shorter run, no change, and it isn't really a power thing anyway, the rack is off on purpose when they lock out.

Is the L36ERM faulty? Other lines here drop remote racks all the time and just get a yellow triangle. Could someone explain what's set differently on this one that turns a rack going dark into a major fault?

The MSG errors straight away, .ER set with 16#0005, and the Communication tab says Path destination unknown. Chassis B pings fine and RSWho sees it with the controller in slot 3. The path I typed is 1,1,2,192.168.10.12,1,0. I retyped it and swapped the target tag for a single DINT, same 0005 both times.

In TIA I'd point a PUT at the partner's IP and rack/slot and it just goes, so I assume I've got a rack/slot thing wrong here too. Is 0005 telling me the path is wrong, or that chassis B won't take the read at all, I'm not sure which end to blame.

The channel shows underrange, Ch3Underrange is 1 and Ch3Data sits at 0. Module's OK green, no fault in the tree, and the old transmitter read fine on that channel the day before. I put the two new wires where the old signal pair was, checked the scaling in module properties, and moved it over to channel 5, same underrange. Meter on the transmitter terminals reads 0V, and in series I get 0mA.

Is the module input dead on that half, or is the new transmitter DOA? Before I send the new transmitter back as faulty, is there something about a 2-wire one I should have checked at the terminals?