ML1200 error History

[ECSI 17]

Does the ML1200 store the last major fault anywhere? I had a ML1200 go into Major Error Halt (S:1/13=1)today and the maintenance guy went online and couldn't clear the error so he downloaded the program again. The PLC is now running but the guy never did record the error message or code. Is there a place I can find the last error? Thanks

[ECSI 17]

So now I have two identical machines with the same PLC program in each. They have failed 2 times each over the last 2 months. Both had a major error S;1/13=1. The error code on the last failure was S:6=20h. 20h is described in the help file as: Now I don't see any bits set in S:5 in the processor status window. I wonder why. The PLC program compiles without any errors, and it has worked every day for the last two months except for four occasions where the PLC halted and the processor went into error. The only way to get running again has been to download the program again using RS Logix. The program is pretty basic, with mostly digital on/off control. There are two analog inputs. One is a 4-20mA signal for water temperature. The other is a 4-20mA level sensor. I am using the SCP instruction to scale the inputs. I am wondering if the problem lies here, because for input I:3.1 it's possible that the result of this instruction will give me a negative value since the water temp hovers around 0-1 degree C. If it goes to -1 degree will this cause a problem in the logic? I am troubleshooting an intermittent fault from 3000 miles away. Using a ML1200 with a Panelview + 600 connected to one of the ports. Looking for some guidance. Thanks!

[Ken Moore 23]

Go to the status file, and change the display to binary, are any of the bits is S:5 true?

[TConnolly 13]

Try placing an unconditonal unlatch of the overflow bit S:5/0 in your program subroutine containing your math right before the end statement. If you can post the program we could take a look and help identify possible culprits.

[ECSI 17]

The S5 bits are all 0 now. We'll check them again when/if it happens again. Alaric, program attached. Thanks for the help guys. MLP.RSS

[Ken Moore 23]

I think your problem might be the runtime addition. When the runtime minutes exceeds 32767, the processor will fault. In that same ladder you are using N7:80 for two different inputs, is this correct. I recommend you count to 60, then index an hours regisiter. See ladder 6 rung 002 in attached file. Also, you should avoid so many nested branches, they take up more resources, and run slower. ken MLP_km.RSS

[TConnolly 13]

Seconding Ken, don't nest branches, extend them. See http://www.plctalk.net/qanda/showpost.php?...mp;postcount=10 Also seconding his analysis of where the problem is occuring. If you want to count minutes for runtimes then you might want to look at using a 32 bit integer from an L data file. With 16 bit integers you run out of room after 22 days (gaging on the time since the first post, I'd bet that is just what happened) A long integer L data file will accomdate a litle more than 4,000 years - should be long enough. P.S. The RET instruction is not required at the end of a subroutine - its useful for conditionally returning a subroutine early but its extra code when placed at the end. edit: BTW, how accurate are you needing to be on those run times? The reasons I ask is that you might want to take a look at this post: http://forums.mrplc.com/index.php?showtopi...amp;#entry58273 Now all of that may not be necessary, but sometimes it is. Edited 24 Mar 2008 by Alaric

[Ken Moore 23]

I forgot that the ML1200 support Long integers. Alaric's recommendation to use long's if far better. See attached, I changed the N7:80's to L9:80's. You still have I:0/9 and I:0/19 both doing additon on L9:80, might be intended, might be a typo. Ken MLP_KM2.RSS

[TConnolly 13]

I noticed is that your run time minute totals are not synchronous with the actual motors. Timer T4:0 runs continously, resetting automatically once every minute. Now for example, suppose that C1_AUX turns on when T4:0.ACC = 59. One second later L9:80 (formerly N7:80) adds 1 minute to the run time. If C1_AUX turns on/off frequently then you will quickly count lots more minutes than you have actually run. If however this is the kind of a process that turns on and runs for days and the run times are strictly for reference or for periodic maintnenace reminders and are not used for product output tracking or anything needing more critical timing then your method is adequate. Just be aware of the limitations and determine if its OK. Building on Ken's file this example shows independent timers that are synchronous to the motors. Edited 24 Mar 2008 by Alaric

[ECSI 17]

Awesome work guys! I simulated the runtime logic today by setting N7:80 to 32767. Sure enough the processor faulted on the next minute pulse. I took this logic out altogether. I started programming this part in the beginning to keep track of the motor hours but it turned out that the customer didn't need this info, so I left it in the program anyway in case I needed it in future. Big mistake! Yes Ken the N7:80 used twice was a typo. Good to know about extending the branches instead of nesting them. It makes the ladder easier to read too. Alaric, I knew at the time that the way I did the minute pulse wasn't accurate. I was just playing around to see how AB timers and math worked, then it just left alone as it wasn't needed. Much appreciation for the help Ken and Alaric. There's nothing like a processor fault to make you learn more. I hope it doesn't become a habit though...LOL. Thanks Paul PS: On a side note, its kinda cool how when I highlight some text from the RS Logix help file and then Ctrl-C to copy and then Ctrl-V to paste it into my post like I did above, it automatically adds the copyright footnote. I've never seen this before. Edited 25 Mar 2008 by ECSI

[Mickey 71]

Another thing that can cause your error, is if the inputs to your "SCP" instructions ( used to scale your analog out) go to high it will fault the processor. ( see pictures below). This causes the output address to drive above 32767 (fault). Note in pictures a value of 26 is OK but a value of 27 faults. One way to pervent this is to use a limit instruction before the SCP. ( see picture) Or limit the inputs at its source ( HMI, SCADA or) I prefer the limit instruction option.