I do have a suggestion near the bottom. But, just for the sake of clarifying, I'm reposting your posts (albeit, segmented)
YOUR ORIGINAL POST (segmented for clarity):
1A: One of the inputs, from a 4 pocket section is a jam switch, that turns on a light at the pocket that is jammed up, never comes on but does appear at the main PLC and gives me an error for that pocket.
1B: That tell me that the Profi-Bus is talking
1C: but I'm still not getting an output to turn my jam lights on.
1D: Only one section is doing this, the other 40 pockets and 10 CPU are fine.
1E: When I go on line, the input logic is fine, but no outputs.
1F: I have put 3 new E200 on this circuit and there is no difference.
1G: I have uploaded the program from the other CPU's and downloaded to this section several time.
1H: The only thing I had to change was the Profi-bus address.
1I: I disconected the output wires going to the lights to see if loading would make any difference. It did not.
1J: Now the only thing I have not tried is there are 2 input and 2 output cards bridged to this network, that I have not pulled out. These I/O card ,while in the circuit, work fine and are not part of this logic. Any help?
XXXXXXXXXXXXXXXXXXXXXXXX
YOUR SECOND POST (segmented for clarity):
2A: There are 11 local PLC's talking over Profi-Bus to a main PLC (TI545).
2B: The local PLC provides the jam lights output for the individual pocket but also, through the Profi-Bus provides information data to main PLC on which pockets has an error.
2C: No, I'm not getting any output lights from local PLC which means no jam lights come on to tell the operator which pocket has a problem.
2D: The operator has to go to the main computer screen to find out where his error is at.
2E: I may have mistakenly said that I was getting the outputs from the PLC when I go on line. I am not.
XXXXXXXXXXXXXXXXXXXXXXXX
MY ORIGINAL POST:
Bob,
Is this how it goes?
A Jam-Error occurs at a section.
The Jam is detected by a switch.
The switch sends an Input signal to the Local S7.
The Local S7 reports the jam to the main PLC over Profibus.
The main PLC does indeed receive the Jam Report.
Now what happens????
Q1: Which PLC provides the actual output to the light?
It sounds like the local S7 provides the actual output...
Is that so?
YOUR ANSWER: LOCAL
Q2: Who decides if the light should be ON?
Does the Main PLC determine that the Jam-Light should be ON?
If so, then is it also true that the Main PLC simply sends a C-flag to the local PLC indicating that the light should be ON, at which point, a rung in the local PLC sees the C-flag is ON and therefore, turns ON the output to the light.
-OR-
Does the local PLC decide that the light should be ON? That is, while reporting the Jam to the Main PLC, does the Local PLC turns ON the light?
YOUR ANSWER: LOCAL
Q3a: You say, "When I go On-Line, the input logic is fine, but no outputs."
Are you looking at the Main code or local code?
YOUR ANSWER: LOCAL CODE
Q3b: Does this mean that, while you see all necessary inputs in the code are ON, you still see that the Output in the code is OFF?
-OR-
Does this mean that you see that the Output in the code is ON but the actual output is OFF?
YOUR ANSWER: NO SPECIFIC ANSWER GIVEN.
Q4: Is the Output LED on the PLC ON or OFF?
YOUR ANSWER:
The input PLC lights come on but the output light do not
Also I have not gone back on line to look(monitor) local logic
(I believe by answering question 3+4, I have also answered 5+6
XXXXXXXXXXXXXXXXXXXXXXXX
So, I gather the following...
Point 1: The local PLC is supposed to detect the fault.
Point 2: The local PLC is supposed to turn ON a Fault light indicating the fault location.
Point 3: The local PLC is supposed to report the fault to the Main PLC via Profibus.
Point 4: The fault input IS seen at the local PLC.
Point 5: The fault IS recorded on the Main PLC.
Point 6: The external indicating light at the fault location does NOT go ON.
Point 7: The PLC Output that should turn ON the external indicating light is NOT turning ON.
Point 8: The code in the local PLC is exactly the same as the code in the other "working" PLC's.
Point 9: You have not clearly indicated what the code shows in Status-View.
My Summary:
When you remove all of the impossibilities, what remains is the Truth! or something like that... I hope this is true!
At first I thought that maybe some of your code was "over-stepping" into some of your memory locations.
But, having said that you have downloaded exact copies of the program from working PLC's... I don't think you have an "over-stepping" problem... at least, not within the local program.
What remains? The Main PLC Program!
You might want to check the Main Program to see exactly how it handles these fault conditions.
If the Main Program has a separate section for dealing with each of the S7's, then you should probably do a very careful examination of that code to verify that the code is generically correct in terms of the general functions and then specifically correct in terms of the particular S7.
I suspect that you have a section of code, in the Main Program, that handles this particular S7-Section in a slightly different manner.
If this turns out to be the case, then you should be thoroughly convinced of the value of calling a single, general-purpose, sub-routine to handle this particular activity for all of the S7's.
In that case, the sub-routine works for all or it doesn't. Of course, at that point, the potential problem is passing bad parameters. But at least, if it doesn't work at that point, then you KNOW it's a parameter problem!