PLC register snapshot

[trikemailer 0]

Hi, I'm looking for advice, is there any way to take a snapshot of all the registers, inputs, outputs etc. of a plc? It would be a great help for fault finding to be able to identify what contact was not made which caused a machine to stop. Generally we need to keep production running so it's a case of a quick check then hit reset and away we go, we don't have the luxury of being able to stop in the vfault condition and investigate. All suggestions welcome (Running Mitsubishi) Thanks

[Crossbow 295]

Nope. In the programming software, you can upload and select the 'Device Data' option to save it all into the project. That's about the best you can get. If you don't need all the data, just some, the PLCs have a fairly good data tracing function built in, depending on which Mitsubishi PLC you use.

[panic mode 246]

PLC memory available to user is organized into areas like X, Y, M, D, W, etc.to make a snapshot of everything, you need additional memory (a new PLC). obviously this is not practical, you need to be far more selective and decide on what you want saved and on what event. in my opinion, decent troubleshooting starts with decent diagnostics (alarms etc.) and robust program. to get there it may take a while and lots of snooping in other people's code then making decisions on what general program structure should look like. it does not matter (much) what machine does, all of the projects will eventually have same elements and one should take a good look what each of them should look like. if this is executed well enough, troubleshooting is usually very straight forward. if the program is already written (by someone who was not organized) then ... it may be better to start fresh than trying to patch up what is there. for example my programs contain sections like: - signal conditioning: mapping, debouncing, scaling, whatever... - sequence(s): some sort of FSM, i prefer counter based because it has some (to me) important advantages. - permissives/interlocks: this is what ensures that nothing bad happens regardless what operator (using HMI and manual controls) or your sequence(s) do - alarms: every I/O should have at least one corresponding alarm (shotgun approach) plus whatever else is program generated. if i see PLC with ten IO cards (some 100-160 IO points) and only 50 alarms, job is not nearly complete and someone has to go back to the drawing board. merely displaying alarms on HMI is very least one can do, any HMI today will also have alarm history, alarm counting etc. - mode control: at least auto & manual , in auto there i always add step mode (program stops in every state), in manual HMI has full control over all outputs, usually i add additional modes (semiauto, debug, whatever) which is machine specific. another thing important to me is quick and simple way to bring machine to specific initial state (note this is NOT just bringing program to particular state of FSM). this is kind of easy-button which allows quick restart from known state. etc. now there are many types of state machines, most are counter based but they are not equal. for example one can simply create series of rungs such as: "if StepNr is ## and <condition> then StepNr = Value" this is simple to use, allows looping, there is no need for particular organizing of sequence (equivalent to bunch of GOTO statements) so it is easy to add any number of new states etc. one disadvantage is that this makes tracking of state changes difficult. easy way to track state changes is to only change them in one place (one rung for example). then it is impossible to change state and not know about it. basically you would write: "if state changed, save current state in the log" if your sequence is table driven, then using simple XOR function you can generate list of conditions that are preventing sequence from continuing and if you need to log, it is easy to log both state and conditions to a certain depth (number of states) depending on available memory. some of my own personal 'rules' (just an example): - keep program structure simple, nobody has time or energy to dig through miles of spaghetti - be thorough and plan before programming (and use plenty of comments) - avoid fancy instructions and where needed, add plenty of comments, using 5-10 instructions instead of one may be longer but ... it may also be more readable. - never use any instruction that was not thoroughly tested by me (regardless how tempting it is to "get the job done"). only when i know every aspect of it, this can be used in my program. can't afford to have production stop because i was too lazy to evaluate behaviour of an instruction. most of my programs use surprisingly few instructions (and this is why they are easily ported to any brand PLC). - declare block of PLC memory as "debug" with sole purpose for debugging. add line of code that clears entire block on plc power up (in case left the plant and forgot to take it out or turn off). - look through other people programs, you can learn from every one (even from terrible ones - how NOT to do things) - any HMI message and alarm must have index number such as "203 : servo drive overvoltage" (i would much rather hear "we have seen alarm 203" than "there was a fault, it was something about servo drive". with a number, i can quickly find the EXACT message or alarm, much better than relaying on language, communication skill and attention to detail of those that happen to be around the machine when problem was encountered)

[me_maikey 0]

If the programming port is open you can hook up the PLC to your programming environment and track the inner workings. This will allow for at least some chance to track the program (I don't know the speed, complexity etc so I have no idea how viable this is). Most HMI's also give the possibility to enter monitor mode.