Real World Problem

Vietnam Bob

Guest
V
First let explain the setup:
44 pockets, with each pocket feeding a page to magizine.
11 E200 Sieman's S7 CPU's
Every 4 pockets is controled by 1 CPU (4x11=44)
All CPU's are connected through Phofi-Bus to a main PLC
The main PLC is a Siemans 505 with a 555 CPU
Every input and output controlling the 4 pockets are the same
Now here is the problem:
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.That tell me that the Profi-Bus is talking but I'm still not getting an output to turn my jam lights on. Only one section is doing this, the other 40 pockets and 10 CPU are fine. When I go on line, the input logic is fine, but no outputs. I have put 3 new E200 on this circuit and there is no difference. I have uploaded the program from the other CPU's and downloaded to this section several time. The only thing I had to change was the Profi-bus address. I disconected the output wires going to the lights to see if loading would make any difference. It did not. 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?
 
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????

Which PLC provides the actual output to the light?

It sounds like the local S7 provides the actual output...

Is that so?

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?


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?

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?

Is the Output LED on the PLC ON or OFF?

Sorry if some of the questions sound silly... but, I'd rather have a better understanding of what you have before I start shot-gunning answers at you. I prefer using a Derringer when possible.
 
I hate to state the obvoius but I've been burned by it many times before, did you check that your light is not burned out?

I'm not familiar w/ Sieman's but I would assume there is some sort of forcing capability. Is the local output forced off?

Just a couple suggestions
 
Sorry, I was called out of town to work on another Divisions problem. Thank you for the responds. I will try and answer your questions.

There are 11 local PLC's talking over Profi-Bus to a main PLC (TI545). 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. 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. The operator has to go to the main computer screen to find out where his error is at. I may have mistakenly said that I was getting the outputs from the PLC when I go on line. I am not. I will be returning to my division tomorrow so I can look at this alittle closer. Any suggestions?
 
My first question is...

Do you use CVU?

My next question is...

Can you specifically, answer the 6 questions I asked?

If so, please do so, now.
 
Question #1
The local S7 PLC provides the output to the light

Question #2
The local PLC decides when and which jam light comes on

Question #3
Local Code

Questions #4
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

I not sure what a "CVU" is.

Thanks for your input. Please advise.
 
Has the system with the problem ever worked properly, or is the machine still undergoing startup/debug?

When you monitor the logic in the PLC, is the output being told to turn on? If not, what element in logic is preventing it?

Is the jam switch really being tripped, or is a bogus signal being placed in the packet of information on Profibus?

Do you have power for the outputs?

If you disconnect the Profibus cable from the system with the problem, does the jam detection logic work properly?
 
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!
 
Thanks everyone for your help but I am afraid that this problem will need to go on the back burner. I have to go back out of town next week so I will not be able to get back to this problem till week after next. Please put your thoughts at rest until I get back. I will be bring this subject up again and we will solve it. Thanks again for all the input.
 

Similar Topics

Hello everyone, I am looking to get a job as a junior automation engineer. I know the basics of PLC programming with Rockwell and Siemens PLCs...
Replies
4
Views
1,709
Good afternoon, Last week I had an issue with noise affecting some Kinetix 6500. A new analog drive was installed about 5 feet below these...
Replies
6
Views
1,813
Good Morning Everyone, I am entry level PLC programmer and this is going to be my first PLC project at my company. I would like to thank you for...
Replies
13
Views
4,141
Hi all, [Long message alert!] I’m after some advice on training courses. I’d like to know what the general consensus is regarding the PLC...
Replies
6
Views
3,663
Dear all, I took a PLC course in college. The course was mainly doing basic relay type programming. I did not need to worry about setting up the...
Replies
6
Views
2,669
Back
Top Bottom