MP270 no source files

[JasonWade]

Hi,

I have an MP270 with an existing configuration that needs lots of modifications. The source files are unavailable. So I must start from scratch.

My idea is to stop the PLC (S7-315 2DP) so that no data values are changing (Except the clock byte I think?) and then look for changing values in the PLC when I manipulate HMI objects.

What would be the easiest way to do this?

The PLC code is largely un-annotated, and I know that the HMI tags are spread across lots of DBs and M memory.

I know I can monitor each DB in turn and create VAT tables to look at the M area, I know that it will be usefull to annotate the PLC code to aid the detective process, but I am looking for any shortcuts, i.e. Maybe I could write some PLC code to inform me what DB and DBD/DBW/DBB/DBX has changed its value (I feel another thread starting!)

Another idea is to delete DBs one by one and see if the HMI complains, and so determine which DBs have HMI tags. (Will the HMI complain immediately when a tag becomes unavailable in the PLC, or only when it tries to write/read it, or only if ths currect screen contains an unavailable tag.?)

Any suggestions or advice much appreciated. Someone must have done this before?

 

[JesperMP]

Ouch, tough one.

Yes your idea of manipulating input fields and then observe changes sounds feasible, but hard work.
For DBs, you could upload everything to the STEP7, change a value on the HMI, and then do an offline/online compare.
For Merkers, you would have to setup a couple of VATs.
edit: Actually, any non-brain-dead HMI programmer will have setup all input fields as input/output fields. So if you manipluate the PLC adresses as suggested below, you should also be able to locate the connected PLC tag addresses.

Your other idea of deleting DBs to locate addresses assigned to output fields could also be possible. The panel will complain about the missing tag address, depending on if the tag is scanned cyclically always, or if it is scanned on use and is currently displayed on a screen.
When you have figured out which DBs are relevant you can then begin to put them back in, but starting with a small DB, and then constantly downloading it again with more and more bytes allocated until the error disappears.

Or .. you could have some PLC code write values to DB adresses so that they are filled with all the same numbers for the DB number. "1" for DB1, "2" for DB2 etc. and "0" for merker addresses. You can then see on the screen if an output field is connected to a DB (and which DB) or Merkers.
When you know which output fields are connected to what DBs or to Merkers, you can make another code that writes all "0" to byte 0 in all DBs and MB0, "1" to byte 1, "2" to byte 2 etc. up to 255.
From that you get the byte number.
Then write some code that writes "255" to all bytes in all DBs and all Merker adresses. On the screen you can then see the formatting and how big a variable is (byte="255", integer="32676", hex="FFFF").

For alarm and event messages, you would have to do some detective work to figure out what Merker or DB address they are located in.
Then you set one alarm or event message bit at a time, and take note of what alarm or event message text that appear.

Phew, you need a lot of patience for this one.

 

[L D[AR2P#0.0]]

You could also use the xref facility for DB's and M's to see which variables are only written to (chances are it is displayed on the HMI) and only read from (chances are it is written by the HMI).

 

[JasonWade]

You could also use the xref facility for DB's and M's to see which variables are only written to (chances are it is displayed on the HMI) and only read from (chances are it is written by the HMI).

Thanks LD, but I know that the PLC code has lots of redundant addresses and unused junk, so I could be chasing my tail around with this method. The sheer volume of DBs means it's worth the time to write some code to do the work for me, as Jespers suggestion.