Placing ML1200 in RUN from HMI

I'm trying to program the HMI to switch a ML1200 back into RUN mode after a fault. The idea is for the customer to be able to handle problems without a laptop or need for RSLogix500.

I used
S:1 := S:1 & 0x5FFF
to clear the error halt bit S:1/13 and that worked successfully.

However
S:1 := (S:1 & 0x5FE0) | 0x0006
would not work for placing the controller back in run mode.

I could swear I did this once before with a SLC500 from RSView, but it doesn't seem to be working for the ML1200. The manual seems to indicate that S:1/0 thru S:1/4 are read only, however I do seem to be able to write to at least part of it.

Am I missing something or forgotten something?

I do have the S:1/8 and S:1/12 bits set to clear fault and go to run on power up, however I was hoping to avoid the need for the customer to cycle power.

I personally would fix the problem that causes the PLC to fault.

I presume you know what fault(s) occur(s)....

I did some research into this once upon a time and I don't think you can do exactly this.

The old DH485 PanelView Standard terminals had a special feature where you could write to Status bits that were addressed as the Run Mode status bits for the controller.

But the PanelView didn't really write to the Status file; instead, it sent the SLC-specific "Go to Run Mode" command.

I messed with this on a system where we got the PCCC Execute object inside a Net-DNI to send that command. It was tricky. We could also make the Net-DNI send other mode-change type commands.

But I also found that non-DH485 PanelViews and RSView/PV+ didn't have the same feature.

If you clear the fault and cycle power, does the controller come up in RUN mode or in PROG ?

I think this is exactly why the MicroLogix 1500 got a toggle switch and the MicroLogix 1100 and 1400 got a multifunction LCD panel. I like the absence of a key in the new 1769-L1x controllers too, in favor of a protected toggle switch.

Ken
Thanks for the memory jog. It was the old panel view that did that. I found a tech note (19471) about the PV faking the PCCC commands when writing to S:1, however I didn't realize it wasn't writing directly to S:1 until I read that tech note.

The clear fault on power up and run on power up bits are set so cycling power will reset any error if possible and put the PLC back in run. I was hoping to avoid the need to cycle power.

Daba,
There isn't a problem with faults. This is a feature I was hoping to implement for the customer so that IF there was a fault he could correct the problem and bring the system back online without the need for him to have Logix500 and without the need to cycle power. The customer can't have the system down. It has backup controls that keep the system alive in a limp mode if the PLC drops out. Cycling system power is undesirable due to the back up controls and the enterprise critical nature of the process.

Unfortunately the knucklehead who designed it didn't have the foresight to put the PLC on a different fuse from the backup controls. I'm going to have to have a talk with that guy and do something about that.

TConnolly said:

Ken
Thanks for the memory jog. It was the old panel view that did that. I found a tech note (19471) about the PV faking the PCCC commands when writing to S:1, however I didn't realize it wasn't writing directly to S:1 until I read that tech note.

The clear fault on power up and run on power up bits are set so cycling power will reset any error if possible and put the PLC back in run. I was hoping to avoid the need to cycle power.

Daba,
There isn't a problem with faults. This is a feature I was hoping to implement for the customer so that IF there was a fault he could correct the problem and bring the system back online without the need for him to have Logix500 and without the need to cycle power. The customer can't have the system down. It has backup controls that keep the system alive in a limp mode if the PLC drops out. Cycling system power is undesirable due to the back up controls and the enterprise critical nature of the process.

Unfortunately the knucklehead who designed it didn't have the foresight to put the PLC on a different fuse from the backup controls. I'm going to have to have a talk with that guy and do something about that.

Click to expand...

Cycling power to reset a fault isn't the answer.

Something must be causing the fault in the first instance, so you should really investigate what faults you think cycling power could reset.

In general, there are 4 types of fault...

1. A hardware fault - the PLC is no longer functional - replace it.

2. The PLC detects a Major Fault condition that cannot be recovered from, and enters into the Fault state regardless.

3. The PLC detects a Major Fault condition that can be recovered from, and enters into the Fault state if the fault is not cleared by a Fault Routine.

4. The PLC detects a Minor Fault, flags it up in the status area, and carries on scanning the user code.

It is unlikely that you will recover from type 2 faults, they will just come back at you, repeatedly. It seems to me that you are investing effort into being able to recover from only type 3 faults, and these faults are nearly always user-code generated.

The processor can deal with these itself in a fault routine, but in the vast majority of cases these type of faults are caused by errors in the program, e.g. indirection errors, negative timer values, etc.

Resetting faults and carrying on with the process, with the existing (buggy) code could, in many instances, be the worst thing to do, it obviously depends on what fault existed.....

But you also said "There isn't a problem with faults." : Are you trying to "fix" an issue that doesn't exist ?

He's trying to set it up such that he doesn't have to code for every possible failure and allow a quick return to run mode.

If it could be done, it would make any type of fault recovery possible with one simple arrangement from the HMI, potentially saving lots of time following a hardware failure, for example.

OkiePC said:

He's trying to set it up such that he doesn't have to code for every possible failure and allow a quick return to run mode.

If it could be done, it would make any type of fault recovery possible with one simple arrangement from the HMI, potentially saving lots of time following a hardware failure, for example.

Click to expand...

I rest my case - there should be NO faults that an operator can "override" ....

It's not about overriding faults, it's about recovering (after correcting a problem) without having to break out a laptop.

On a cooling tower system that was recently expanded the customer asked me to add an HMI where one didn't exist before. The PLC fault reset is a feature I thought I would add as a last minute bonus (extra customer service is good for happy customers) as I had done something similar years ago with a PV. On this one I'm using a Redlion G3. After it didn't work and Ken jogged my memory on the PV I found the technote I mentioned earlier.

The system has been running for a number of years and has never faulted. To date limp mode has only been used when downloading new programs to the PLC (this thing was first commissioned before the ML1400 came out and the ML1100 IO limitation excluded it).

All the math faults are trapped and corrected. But as so many have found the ML family is notorious for loose connections that can lead to an IO mismatch fault. It hasn't happened yet on this unit but its one possibility I had in mind. The customer could re-seat the cables and clear the fault.

daba said:

I rest my case - there should be NO faults that an operator can "override" ....

Click to expand...

I'm going to have to disagree. I was only hoping to deliver an extra goodie to the customer, not get into a debate over giving a customer the tools to service his own equipment.