S7 CPU Parameterisation problems after loading program

RMA

Member
Join Date
Sep 2004
Location
North of Hamburg, Germany
Posts
2,052
I've suddenly started having problems after uploading new programs to my S7 317-2 DP CPU.

Because of some problems I've had recently, I've taken to creating small test projects and loading them to test new program parts before integrating the new bits in the real program and then uploading the main program to check it out again. Then yesterday I suddenly couldn't restart the CPU and looking in the Diagnostic page it said it had gone into STOP because of parameterisation failure (or mismatch between designated and actual hardware, but that hasn't changed).

I tried everything I could think of, including flushing the memory, power off and on, etc. but nothing worked so eventually I gave up and left it blinking away and went home. I came back in this morning and hey presto everything's running fine - and I've no idea why!

Now it's gone and happened again and this time it seems to be more persistent. If I load the main program I get loads of I/O faults from the bits that aren't there, although the box "Startup anyway even if the configuration is faulty" is checked on the CPU Properties.

If I load the test program where only the CPU is configured, with no I/O, I get only the message above plus two other lines saying:

Non-user relevant (SDB-Nr): 5
Non-user relevant (Z2):8f01 (Z3):0333

(the actual text is in German so the translation may be a bit wonky!)

Does anybody have any idea what the problem might be, and more important, how I can get the CPU running again, so I can get on with my work!

I wondered if the problem might be that the rubbish from all sorts of different programs on the MMC might somehow be getting mixed up, but I can't find any way to delete the MMC so that I can start with an absolutely clean system - the option is always grayed out, regardless of what I do. Does anybody have any idea how this can be done?

Cheers and thanks in advance

Roy
 
I guess you dont have the external prommer. Thats why the function S7 Memory Card ... Delete is grayed out.

(Maybe you have tried this allready):
Create a project that matches the CPU type with no i/o.
Only OB1 with some dummy code.
Download that to the CPU with Download user program to memory card .

Thats the closest you can get to a "clean" memory card.

If that does not get the CPU up and going, then there is something wrong with either CPU or MMC.
 
Roy,
do you mean "startup when expected/actual configuration differ" box by your "Startup anyway even if the configuration is faulty" ?
If so, meaning of this settings is as follows - when checked CPU will start even if configuration of modules in HWConfig doesn't match real configuration in the rack. When unchecked CPU doesn't start at all in such a case. However it doesn't mean that you can access those configured but not existing IO. That's why you get all those I/O faults.
Long startup time can be caused also by configuration mismatch.
 
jacekd has a good point.

Did you set OB85 - Call up at i/o access error:
to At each individual access.
or Only for incoming and outgoing errors.
or No OB85 callup.
If you selected the 2nd, then it can account for the very long time it takes to start up.
edit: If you selected the 1st then you must have the OB80 programmed to keep the CPU running.
 
Last edited:
Thanks Jesper,

it hadn't occurred to me that the "delete" option might only apply to the prommer - and you're right, I don't have one.

In fact, what you describe was effectively what my test programs were - CPU only, no I/O and very short code written only in OB1. However, I was always loading conventionally using the "Laden" ikon with the Station highlighted. I'd forgotten about the "Download user program to memory card" because it was usually grayed out as well, so after reading your posting, I went looking and discovered that you have to highlight the "Bausteine" sub-directory and then it goes OK.

As it turns out, the MMC seems to be damaged in some way, fortunately I have a couple more FM352-5s for the project lying around which have not yet been programmed, so I was able to pinch one their MMCs. Since the 4MB MMC to enable me to upgrade the 317 firmware has been ordered, that will solve the problem of the duff MMC.

Actually, the thought about the FMs occurred to me at about 4:30 this morning, so I would have managed to get myself out of the mess, but I wouldn't really have known why, nor would I have learnt about the "delete" command and the prommer, nor been reminded of the existence of the "Download user program to memory card" menu option.


Ken,

I didn't expect my next stupid question to turn up quite so soon, but this has been a good example of what I meant. Problems that are so basic, that once you've seen it once, you (hopefully!) never forget it. But I hate to think how many hours chasing through the handbooks would have been necessary to find a clue (never mind an answer), if indeed I would have ever found a complete, comprehensible answer there!

Once again many thanks to Jesper for the help, and I hope my next stupid question is a bit longer in coming!

Cheers

Roy
 
Hi guys,

got your other postings in the meantime.

"startup when expected/actual configuration differ"

Yes, that's what I meant, but I've only worked with Siemens since I've been in Germany so I don't know the English messages. On top of that, I've been here for 18 years now, so my English has suffered a bit as well!

Did you set OB85 - Call up at i/o access error:...

I call the OB85 in the real program, in my test programs where there is no I/O I didn't bother.

How it's set up? - No idea, I can't even find where to check it! :oops:

Can you let me know me know where to do that.

Start-up with the real program does take a while, because 20 of the 21 DP modules are missing. (They're all identical so for program development, I don't need them.)

Cheers

Roy
 
Maybe this is relevant.

There was a Siemens technote some time ago about bad MMC cards . A new set of MMC cards with new type numbers was made because of this.
The newer CPUs must have a MMC card of the very latest generation in order to work !

edit: Scratch that !
It was the other way around. The newest MMC's could not be used in the oldest CPUs.
Anyway, if you MMC has a "8Lx11" in it, then it is the latest generation.
 
Last edited:
The newer CPUs must have a MMC card of the very latest generation in order to work

The hardware was all bought last August, when the 317 was still pretty new. This is a pretty big project which won't be finished until the end of 2005, which has been real nice for me - I've learnt more on this project than the half dozen or so I did before it since 2001. They were mostly pretty small, and the one bigger one I was involved in, I was only one of a team of three and spent most of my time on the HMI under WinCC, apart from a little bit of CFC programming (that was nice, suits my IC hardware background!). We should be commisioning the first module in November, so the crunch is coming. I suspect you'll probably hear from me again before then for help with the FM352-5 programming, that's the last bit I've got left to do, and they look as though they might be a little bit weird!

Is there any way to identify which generation MMC cards I've got? Does the problem only affect the CPU, or will the FM352-5s also be affected? If it's only the CPU, that problem will solve itself when the 4MB MMC arrives.

I checked out the OB85 settings and Oooops, it's still set to "No OB85 callup" :oops:

Thanks a lot for the help, until the next time,

Cheers

Roy
 
Re: Maybe this is relevant.

JesperMP said:
edit: Scratch that !
It was the other way around. The newest MMC's could not be used in the oldest CPUs.
Anyway, if you MMC has a "8Lx11" in it, then it is the latest generation.

sorry for the confusion :oops:
 
Hello, guys;
I hope this little bit helps. I've found that one way to "erase" a MMC card when I have problems like Roy's is to open the MMC online (through the Accessible Nodes icon); I select the CPU's MPI number, then Blocks. I then select all program blocks and the SDBs (System data), except for the SFCs and SFBs, and delete them manually.
Once this process has been executed, I go back to offline Blocks and do a complete download (no special menu, just the download icon). Now I am sure that I have the latest version of my blocks on the MMC card, and I have had no further problems.
I can't explain the source of the problem (looks like the CPU reacts
like it sees a timestamp problem), but this a good workaround.
Hope this helps,
Daniel Chartier
 
Daniel,

that sounds interesting, I'll have to have a look next week when I get back. I've got to shoot off home now, I've booked Friday and Monday as holiday, and after this week, I think I need it!

Jesper,

OK, but thanks for the info anyway. My MMCs are 8LJ00, so I suppose that's not quite current, but as I said I only need them for the FM352-5 now, so I hope that's not a problem.

Cheers

Roy
 

Similar Topics

Dear sir, I am using SIMATIC 300, CPU 315-2DP , (6ES7 315-2AF03-0AB0) VIPA 603-1CC21 A1.0 RAM 32KB, Firmware=V4.0.8 The problem Im using MPI...
Replies
1
Views
61
Hello The plant is running and there is no shutdown nowadays therefore I can add 1734- AENTR and its card while PLC is in Run? I do not wanna...
Replies
1
Views
111
We recently purchased a IC693CPU352 module and it appears the internal time clock is static. I can set the time and date but once set it does not...
Replies
5
Views
148
Hey when I turn on my Siemens PLC CPU 216-2 after runing 10 minute it's stop and showing SF indication after I turn off and some time later turn...
Replies
0
Views
92
Hi All, Got a funny issue. I have a 1756-L85EP and a 1756-EN2TR in the same chase. The client asked for the Ferrari and the 3 lane highway!!! We...
Replies
1
Views
125
Back
Top Bottom