Dump Status of PLC

welby

Member
Join Date
Jan 2008
Location
Indianapolis
Posts
6
I am currently monitoring the status bit of an AB PLC for math overflow. What I would like to do is to dump every variable/item within the plc to a text file for analysis to show our PLC programmers what variable is overflowing.

The part I need help with is the best way to dump the current memmory of a plc vie VB and Linx with OPC. I could get the source from them and add each item into a groupd and dump that way, but I am looking for a more generic method so that the program could be used without change in the future.

Thanks

Welby
 
It would be much easier to identify the math error, dump only that memory location (if desired), then correct the program error so that it does not occur again.
 
Let's simplify this....

1.) I cannot dictate the terms of how this is done..it was a programing assignment given to me by my superiors..I can't change it.
2.) I cannot change the ladder logic..I have only vb acess.

What I simply need is a way to easily dump the entire contents of all the variables. They want it as generic as possible, so that precludes loading up known adresses as items in a group.

I do appreciate the ideas and other approaches to solving this issue, but I am stuck with the job assignment as is.
 
Sooooooo.... Somehow, your superiors expect that simply from looking at a raw dump of all data in a PLC, you will be able to determine the root cause of an overflow?

That is incredibly optimistic, as often, the same points are used in many different calculations. It might also be impossible. What platform is this ? PLC/SLC or Logix?
 
Mickey said:
Exactly as Lancie1 has said. See link below for one method to do just that.

http://forums.mrplc.com/index.php?showtopic=13151

Heres another:

http://www.plctalk.net/qanda/showthread.php?p=14307&postcount=4

You may want to take a look at the second thread Mickey posted. Ron explains so elequently how just looking at the data may not give you the source of the math error. Not trying to rain on your parade here but I have run into the exact problem that Ron is refering to. In fact that very problem caused me to create the first thread Mickey has attached.
Dumping a block of registers to a PC is not really a major issue. As Alaric stated you can find plenty of examples in the help files. I just hope you understand that this a maybe result. You may see your problem you may not.
 
No, not a school project. A work asssignment.

One of those nice projects where my boss has been told by the plc programers that I should be able to do this easier than it would be to change their programs. Yes, I did look at the links that were sent.

I've been all over the Linx help and SDK. You should be able to come close with the linx sdk and the browser object, but it's not working properly (as well as a few mistakes in their source code).

I understand there are other approaches, but that doesn't help me in this situation.
 
welby said:
... my boss has been told by the plc programers that I should be able to do this easier than it would be to change their programs.

Welby, I hate to be a bearer of bad news, but you are on the sharp end of a short stick over hot coals. The PLC programmer lied to your boss, and your boss, probably not being PLC savy, believed them. The programmer is either incompetent and unable to find the cause of the overflow himself, or lazy and doesn't want to do what is actually very simple to do. Either way, he managed to manipulate the job into your lap. Your best bet at this point is to understand why a memory dump probably won't help, show how memory will change while you are in the very process of downloading the data tables, and then educate your boss.
 
Welby,

I agree with Alaric. You CAN probably find a way to dump the memory, but that will be very little help in finding a math overflow. As others have said, the memory storage gets changed constantly, and for a memory dump to mean anything, you would have to be able to dump it exactly on the same scan as the math overflow occurs.

How to do that? Oh, you just have to find the places where a math overflow might happen, then add some rungs (modify the PLC program) to capture the data. If you have to do that it is not much more trouble to go ahead and fix the problem, once it is found. The best troubleshooting tool to find a problem in a PLC program.... is the plc program itself!

That is what I meant by it will be much easier just to fix the program so that it works correctly. I understand that you are not able to do that, but there are those who can. Simply tell your boss that if the in-house gurus do not know how to do it, then he needs to bring in an outside contractor.

You can probably find someone here that is close enough to Indianapolis do the job for you. You might even get some trouble-shooting done right here online, depending on the complexity of the PLC program.

If we knew what you have (PLC, SLC, Micrologix, and so on) then someone might suggest some memory locations to look at. For example, if it is an SLC, then I think the Overflow Status bit S:0/1, the Overflow Trap bit S:5/0, and the Math Register S:13 and S:14, would all be important to dump.

32-Bit Math Special Considerations
If you are using a Series C or later 5/02, or a 5/03, 5/04, 5/05 or MicroLogix processor (capable of 32-bit addition and subtraction), you can set the math overflow bit (S:2/14) in the status file. This causes the unsigned, truncated, least significant 16 bits to remain in the destination.

If this bit is not set and an underflow or overflow conditions occurs, the operation will be the same as with a Series B processor. The destination address will contain a 32767 (if the result is positive) or -32768 (if the result is negative).

Arithmetic Status Bits
After an instruction is executed, the arithmetic status bits in the status file are updated. The arithmetic status bits are in word 0 bits 0-3 in the processor status file (S2).
This bit Description
S:0/0 Carry (C)
S:0/1 Overflow (O)
S:0/2 Zero (Z)
S:0/3 Sign (S)

Other Status Bits/Words You May Want to Monitor
This bit Description
S:5/0 Overflow Trap Bit (Minor Error Bit) If this bit is
ever set on execution of the END, TND, or REF
instruction, a major error (0020) is declared.
S:13 Math Register (Least significant word of 32-bit value)
S:14 Math Register (Most significant word of 32-bit value)

Rockwell Software 2000
 
Last edited:
Greetings welby ...

I'm expecting a "no way" reply - but I'm going to ask anyway ...

is there any chance that you can post the PLC's program file and let us take a look at it for you? ...

also ... you haven't answered a perfectly valid question from rdrast ... specifically, what platform is this? ... it DOES make a difference in some cases ...

another question has just popped into my feeble mind ...



when (at what point in time) do you intend to “dump” all of the PLC’s data into this text file? ...



(1) if the answer is: “as soon as a MATH OVERFLOW FAULT occurs” then why bother to “dump” the data at all? ... why not just use the RSLogix “Save As” operation to store a copy of the PLC program file instead? ... all of the data that you were going to “dump” is already right there ... and in many ways, the information will be MUCH easier for your PLC programmer friends to search through and interpret than it would be in a plain vanilla text file of “data only” values - without the accompanying ladder logic code ...



(2) if the answer is: “during each and every scan of the program” then you might want to consider how much this project is going to co$t in terms of data storage space ... and who the heck is going to ever look at all of that stored data anyway? ... the only collection of “dumped” data that anyone is ever going to examine will be the very last one - which is where the FAULT occurred ... so that brings us right back to answer (1) again ...



actually I know that all of this is meaningless - because you’ve already explained that your course has been charted by circumstances beyond your control ... I’m just joining my distinguished colleagues in adding some more “common sense” material for anyone who might come across this thread in the future ...



we wish you the best of luck with your project ...
 
Last edited:
One way would to let the PLC fault instead of clearing the math over flow before the end of the scan. then the last values would still be in the registers.
This may not be an option depending of what it used for. but you would have plenty of time to log all the data then.
It would only require 1 line PLC program change unless it is faulting now.
 

Similar Topics

I have a micro1400 processor running two routines (transfer compression/compression molding press). Recipe parameters are stored from job to job...
Replies
0
Views
43
Good evening, I'll start by explaining what i want to do and then what I've tried. We have an excel document at work that contains our material...
Replies
4
Views
2,279
Any ideas using"Shift Registers"for Vision Failures on long conveyors for Dump Gate? Good Morning , We are starting a quality program...
Replies
15
Views
3,831
Hi everyone! I'm working on the controls design of a semi-automatic pneumatic vertical press. The machine will consist of two double-acting...
Replies
5
Views
1,920
Hey ya'll and Ken if you're out there, I've encountered one of the strangest dnet issues I've ever come across. I have a Rockwell estop box...
Replies
0
Views
1,667
Back
Top Bottom