Funny effects when uploading project to S7 300 CPU

RMA

Member
Join Date
Sep 2004
Location
North of Hamburg, Germany
Posts
2,052
In the course of trying to find out what was wrong with the 4MB MMC for my 317-2 DP CPU (see separate thread), I was repeatedly uploading different projects from different MMC cards to the CPU to see what happened. Somewhere along the line I noticed that I was occasionally getting the CPU into an SF fault condition. Having got the MMC problem out of the way I decided to have a closer look at what exactly was causing the fault.

Having created a completely new project in order to test my FM352-5s, as opposed to the chopped back version of my main project which I had previously been using, I was pretty sure I had a clean piece of S/W with no rubbish lying around in some hidden corner. (I suspect I might be coming back to this in another thread, but that's another story!). I uploaded the project from the Simatic manager by highlighting the "Station" directory and clicking the upload icon. I then powered off and on and everthing came up and ran cleanly.

I then repeated this with the CPU still running and got my error immediately. I then repeated this in several variations - first with the CPU in STOP, then with the CPU in STOP and the memory completely cleared (What's "Urlöschen" called in Engllish, Jesper?). It didn't matter what I did, only when I powered off and on again did I get rid of my fault.

I then tried it by highlighting the "Baustein" (Blocks?) directory and copying only the blocks without the System information - that worked OK. Repeating the action and this time, when asked, saying "Yes", also copy the System Info and now I've got my fault back again. The contents of the diagnostic buffer I've hung on the end of this post.

So the questions are:
1) What exactly am I doing when I upload from station
2) What are the contents of the system information folder - I've been assuming that when moving between my real project with its 20-odd DP stations and my test projects with no I/O, I need to update the System Information so as to avoid faults due to missing H/W. Is this correct?
3) When do I have to cycle the power after changing something.

This problem caught my eye because in my test project, I have no OB100 and no I/O (other than that contained in the FM352-5, of course). I had seen these contents in the diagnostic buffer a few times with my real project and I hate to think how many hours I've wasted trying to track down where I was addressing something wrongly in my OB100!

Final question, is this a normal set of fault messages, or is it another 317-2 DP funny?
 
Last edited:
I then powered off and on and everthing came up and ran cleanly.

Well actually, not quite, even here there were three spurious errors, although I suppose they may have something to do withthe power going down. Just for completeness I'll thta diagnostic buffer entry on as well.
 
1) What exactly am I doing when I upload from station
You upload all blocks (without symbols and comments) as well as the system data. The upload should be so complete that you can download it to another PLC and it must work the same.

2) What are the contents of the system information folder ..
It is the setup you make in the hardware configuration.

2) .. I've been assuming that when moving between my real project with its 20-odd DP stations and my test projects with no I/O, I need to update the System Information so as to avoid faults due to missing H/W. Is this correct?
Yes. Alternatively program the OB86, it will allow the program to continue if DP stations are missing.

3) When do I have to cycle the power after changing something.
This one I dont know about (I use S7-400 only). Maybe it has something to do with that the CPU senses the power down condition and writes the program to the MMC. Thats how I understand it works without battery.

Urlöschen = Reset (to factory defaults).
Well, its my best bet ;)

edit: There is a little confusion about your header "upload to station" and your post "upload from station".
Normally:
upload = load from device to PC.
download = load from PC to device.

Ok, it doesnt help that in german they just say "laden" about everything. It makes for some REALLY bad translations from german to english in some of the help files.
 
Last edited:
There is a little confusion about your header "upload to station" and your post "upload from station".

Actually, that's just me getting confused, I personally would normally regard PC -> Device as downloading and vice versa, but at the last company I worked for, where they had quite a lot to do with PLCs (as opposed to me, who up to that time had spent most of my time on Bailey System 6, Symphony, Foxborough I/A et al), I noticed they used the terminlogy the other way round, so I decided this must be a PLC convention and tried to adapt, but after decades of going in the other direction in ain't easy!

However, in this case the answer is a little different, What I actually meant was:

What exactly am I doing when I upload from the station directory

Other than that, you've pretty well confirmed my suspicions, however, it still leaves the question, what is actually causing the fault, or rather what is its mechanism? I'd be interested to know, even if not knowing won't stop me solving the problem.

By the way, I do have OB86 loaded in my main program (it's going to be Christmas 2005 before the last module gets delivered!) but I wanted to keep my test program as simple as possible.

As I understand it, all the newer 300 CPUs do not have a battery, conversely they all have MMCs. This has the benefit that everything is retentive (Hey, I remembered the English term!) although on some, if not all of them, you can choose whether or not to have the DBs retentive, or to reload the initial values.
 
What exactly am I doing when I upload from the station directory
Do you mean to say: When I use the "Upload station to PG" function, and you have a project open in STEP7 allready.
If you use that function, the blocks and system data from the PLC will overwrite the existing blocks (if any) and system data in the project file.

By the way, the system data will only be filled in to the bare necessities. It means that not all of the type numbers will be filled in in the hardware configuration. The last digits of the type numbers will be cut off.
 
Roy, just a quick note: Be careful with OB86. It's a great function that does exactly what it's supposed to do, but it can have huge effects on the scan time (on one of my systems that has a lot of profibus nodes, the scan goes from 6ms to 55ms on a hardware fault). You have a small project and the increase might not be as drastyic, but you might at least want to change the HW Config and benchmark your scan time without any hardware faults present, since the other card won't be there for a couple of months.
 
Do you mean to say: When I use the "Upload station to PG" function, and you have a project open in STEP7 allready.

No, I mean "Laden". As you say it gets a bit confusing sometimes!

I notice the Icon is only available when you're either on the "Station" or "Blocks" directory (or you've highlighted one or more Blocks inside the "Blocks" directory).

What's not so clear to me is if there is any difference between loading from the "Station" directory and loading from the "Blocks" directory, followed by loading the "System Information" - if there is any difference, that is.
 
Aha, you have a german STEP7.
I think that Download/Laden from the station directory downloads everything defined in the hardware configuration for that station. The difference could mean that it includes panels and maybe drives.
But I am guessing here.
 
Roy, just a quick note: Be careful with OB86.

Thanks for the warning, I'd already noticed that the start-up was quite slow (I initialise everything in sight in OB100!). Since somebody else (with even less experience than me!) is going to have to commission most of the modules (I'm due to disappear off the project in April and return in December to do the final acceptance), I've arranged a DB with a bit which is set or cleared according to whether the module is present or not. All access to the module is ANDed with this Bit.

In the HMI I've a service picture for commissioning and testing the modules (one pic for all modules using ProTool's Multiplex Addressing facility) and I've put a button on there to set the Bit during commissioning, so the Operator doesn't need to know what Bit he's setting, or anything. (Fathoming out how to use the Multiplex Addressing was an interesting exercise in it's own right!!).

So all in all, it shouldn't be a problem, but it's nice to have it quantified. As they say, forewarned is forearmed.
 

Similar Topics

Happy Turkey day. Post your favorite funny comments. // Dear programmer: // When I wrote this code, only god and // I knew how it worked. // Now...
Replies
11
Views
3,150
I have been developing a program on studio 5000 in function block. I exported the program section from one computer to another. The function block...
Replies
2
Views
2,211
Being an Automation Engineer for quiet long time, what will be some funny phrases you want to wear on a T-shirt? I recently developed a hobby to...
Replies
67
Views
19,273
I spent two hours on a very simple question: I have 4 flashing icons (PLC variable) on the screen of a C-more panel showing the communication...
Replies
4
Views
2,114
Studying a PLC program from a conveyor system I across these lines of code. I laughed but realised, I knew what it meant. The inputs are...
Replies
0
Views
1,429
Back
Top Bottom