Siemens/OP15C communication problems

  • Thread starter Mols, Jo [JanBe]
  • Start date
M

Thread Starter

Mols, Jo [JanBe]

Hi all,

Who can help us to solve the communication problems with our OP15 panels. They give the message : "303 AG Verbindung gestort" (=303 PLC connection disturbed/interupted).
The panels are connected via AS511 to 943b PLC's, all points have poll time of 1000 ms ; we already 've checked the power supply and earthing. After release of power, the panels restart and the message is gone ! (but the
problem always comes back ...)

Greetings JomO - Belgium
Email : [email protected]
 
M

Michael Griffin

My manual lists the 303 error as being:

Message: "$ 303 "
Cause: "PLC did not invert life flag. Data have not been requested or are no longer valid."
Action: "Check PLC status."

It sounds as if there is a software problem in the PLC. There is a FB (FB fifty-something) used for communications which needs to be constantly scanned. I believe the "life flag" is a bit which is toggled to let the OP know the PLC is still alive. There is also a data block used for theinterface which you are not supposed to play with, except to initialise it on power up.

How often is this message re-appearing? What is the typical time between re-initialising the OP and the message appearing? Were these
machines running reliably with the current hardware and program for some time before this problem appeared?


**********************
Michael Griffin
London, Ont. Canada
**********************
 
D

Donald Pittendrigh

Hi All

I know this is not the answer you are looking for, but I refuse point blank to work on any OP which is plugged into a programmer port and vice versa. This connection is a disaster, it is slow, unreliable and damn difficult to commission as you cannot have the OP and programmer on line at the same time, my message to my customers...... "If you want a budget solution, find yourselves a budget engineer".

Regards
D.P.
 
Z

Zan Von Flue

hi
I prefer a op. I can develope it quicker then a scada and is less complicated. I haven't had any problems with a op/plc connection and i can program with the op still connected, on both s5 and s7.
So with your problem I can't relate.
zan
 
M

Michael Griffin

I have used it quite a bit with the smaller S5 series, and it really isn't that bad, compared to the alternatives. If you can't use a Profibus
connection (not an option with many smaller CPU models), then your alternatives are via a CP521 card (too slow to be useful) or the second
serial port S5-95U (which may not be the hardware you are using), or to use the programming port connection (a common choice).

It also isn't true that you cannot have the OP and programmer on line at the same time, at least not for the OP15 (or OP20 or OP17). You can use "loop-through" mode in the OP to share the com link. You can't do this with the OP5 or OP7, because they don't have this feature. The OP5 and OP7 though are bottom end OPs which are not intended for use with complicated machines.

I don't know what particular problems you experienced with this method, but I've seen at least a hundred machines configured this way with
no real problems. If anything, I've had more problems when sharing an S7 MPI or PPI link with an OP than I've had with the S5 front port.


**********************
Michael Griffin
London, Ont. Canada
**********************
 
D

Donald Pittendrigh

Hi All

Zan you have not read the original posting, you really must try and be more carefull. For your information :

I also have a great love of OP's for the same reason, however the original respondant refered to an OP connected to a 511 port, neither you nor anyone else I know can plug a programmer and an OP in on an RS232 link simultaneously. The second port on a CPU is not an AS511 port. The original query also did not refer to an S7 which is a totally different kettle of fish. On S7 an OP plugged into the MPI port works fine and a Programmer can be plugged in, it is still too slow for my liking I prefer to see it run at 12 meg on Profibus DP where it is fast enough to catch an alarm generated in a normal PLC program on every cycle of therogram, which not every scada is capable of doing.

The Verbindung gesoert message means connection disturbance, usually a transitional error as when a permanent error occurs the OP reports verbindung
aufgebaut or in english I think it says cannot connect to PC or connection restarting, I am a little grey in this area I set up about 12 container cranes with 2 OP's on each at one stage of my life, but haven't worked much on S5 or
its OP connections since then.

Regards
Donald Pittendrigh
 
M

Michael Griffin

Donald Pittendrigh wrote:
<clip>
>however the original
>respondant refered to an OP connected to a 511 port, neither you nor
>anyone else I know can plug a programmer and an OP in on an RS232 link
>simultaneously. The second port on a CPU is not an AS511 port.
<clip>
You simply use "loop through" mode on the OP15C and you can have the OP and programming PC both talking to the S5 PLC through the same port. This is done all the time. There is no need to unplug the OP unless the PLC is in stop mode (i.e., you are loading a complete new program), or unless you want to do a compress. You can do this with an OP20, OP15, and OP17, but not an OP5 or OP7.
The programming port, by the way, is TTY rather than RS-232C (not that this is relevant to "loop-through").

>On S7 an OP plugged into the MPI port works fine and a Programmer can
>be plugged in, it is still too slow for my liking I prefer to see it
>run at 12 meg on Profibus DP where it is fast enough to catch an alarm >generated in a normal PLC program on every cycle of therogram, which
>not every scada is capable of doing.
<clip>

What is the operational advantage of the higher speed? I'm not sure I see the advantage of getting the alarm to the OP a few hundred milliseconds faster. The alarm flag isn't going away until you acknowledge it. Does it matter if it takes 10 msec or 500 msec to make it from the PLC to the OP?
I also don't think the firmware in the OP has a cycle time which is fast enough to take advantage of that. Even if it did, is the operator going to react that fast? We should remember that we are reporting alarm messages to
humans, who have a reaction time which is orders of magnitude slower than the PLC-OP communications.

**********************
Michael Griffin
London, Ont. Canada
**********************
 
D

Donald Pittendrigh

Hi All

Responding to the battle cry again.......

> You simply use "loop through" mode on the OP15C and you can have the
> OP and programming PC both talking to the S5 PLC through the same
> port. This is done all the time. There is no need to unplug the OP
> unless the PLC is in stop mode (i.e., you are loading a complete new
> program), or unless you want to do a compress. You can do this with an
> OP20, OP15, and OP17, but not an OP5 or OP7.

I would like to know what exactly you mean by loop through mode and also just hoiw simple you mean by simple. The protocol used for AS511 reserves the first 4 bytes for a partner address, this function was never used in the RK511 protocol although the adresses are still reserved for this purpose, in short who knows which messge is for the OP and which is used for the programmer. I would like to know if you are theorising or quoting your pratical experience of what works in this instance. I suspect your argument to be argumentative rather than practical.

Theory is clear this can be done. but in pratice, I dont think so......


> The programming port, by the way, is TTY rather than RS-232C
> (not that this is relevant to "loop-through").

This is quite correct, if you use a current to voltage converter or a Siemens FOX-PG which is the same thing, you will find that the data being transferred on the line is quite understandable in terms of an RS232 protocol analyser. It is in fact a simple aberration of the RS232 specification. I think you may be getting confused between communications protocol and hardwire medium.


> >On S7 an OP plugged into the MPI port works fine and a Programmer can
> >be plugged in, it is still too slow for my liking I prefer to see it
> >run at 12 meg on Profibus DP where it is fast enough to catch an
> >alarm generated in a normal PLC program on every cycle of therogram,
> >which not every scada is capable of doing.
> <clip>
>
> What is the operational advantage of the higher speed? I'm not
> sure I see the advantage of getting the alarm to the OP a few hundred
> milliseconds faster. The alarm flag isn't going away until you
> acknowledge it. Does it matter if it takes 10 msec or 500 msec to make
> it from the PLC to the OP?

Higher speed means that fleeting alarms can be captured by reading the status of a single bit, it is not neccessary to latch alarms nor to get involved in complex fault reset procedures, which if you have much experience of this type of problem, you must know for yourself are seldom foolproof and always prone to generation of false alarm texts. If you have ever made any research into the matter you puport to offer advice on, then you will know the difference between the high speed comms links and the alternative running on programmer ports on low budget projects.

In short let me propose the following, the OP generates... let us say 5 faults in the period of 500 ms which it takes for the OP to implent a new update.... let us say in practical terms that on a travelling machine, someone pushes the estop while the machine is moving, assuming the estop is hardwired, and I hope in your case it is, this switches off the control voltage to the travel contactor and the cable reel contactor..... this can result in several faults being generated simultaneously. All these fault would normally be detected by the OP in the same cycle on a slow system. Consider the following possibilities when the estop is puished while the machine is moving

Travel drive contractor feedback error
Cable reel slack tension
cable reel contactor feedback error
Travel brake failed
Cable reel brake failed

WHICH ONE DOE THE OP REPORT AS BEING THE CAUSE OF THE PROBLEM What we who are active in the industry know as the first up alarm.

Shall I go on...... On the system which updates every 1/2 second, which fault was recorded as being the first problem report, in the case of the slow update, they will all be seen in the same cycle, the machine operator will be trying to repair a cable reel fault instead of trying to find out who pushed the estop. Personally I find this to be a rather poor engineering solution but if your clients are happy with this.... then go for it my friend. I personally don't have much time for this kind of rubbish. If you want to then I guess you can design a PLC program to communicate the fault sequence correctly to the OP but God help you if you need to add an extra contactor or overload into the equation, you will suddenly find yourself losing a great deal of money trying to get to grips with the new requirements, on my 12 meg system, I will be in the pub spending the cheque before you even get off site.

> I also don't think the firmware in the OP has a cycle time
> which
is fast enough to take advantage of that. Even if it did, is the operator going to react that fast? We should remember that we are reporting alarm messages to humans, who have a reaction time which is orders of magnitude slower than the PLC-OP communications.

Simple answers are a) it does and b) it is of no consequence

The issue is objectionable, the OP updates as fast as the comms link allows and if it runs a faster cyle time IT IS capable of discrectionery speeds of 10's of milliseconds which is quite adequate to distinguish between the cause of the problem, and a secondary fault. The reaction time of the operator has absolutely nothing to do with the issue, what we are trying to do is show him the correct cause of the failure and not indicate some secondary fault as the root cause. I suggest an apprenticeship and a whole lot more experience in the field of HMI are indicated to relieve your limited understanding of this problem. I will be happy to indenture any serious learners for a large financial consideration.

Bye
Donald Pittendrigh

 
Z

Zan Von Flue

Hi
About the S5-TTY programming connection.
It's true the S5 has only one connection, I use at work a mux. from IBH (forgotten information)- the OP and PG can be connected or OP and
L1. In either case it's slow and because of S5 (any size), compressing the memory should not be done with the OP connected!
About speed to the PG/OP. Higher speed means convenience only (i.e. a 586/90MHZ and 586/1.2GHZ). I save Time critical parallel information
in the PLC. When the OP has time it can display the information. Alarms must be given the correct priority. E-stop of course the highest.
Actually, I don't use the alarm function on OP's. Because of the E-stop example. I would (did) make a seperate screen with all the possible
alarms. The PLC latches the alarm, then the op displays it(display and scada are not time critical). This same alarm bit is also used in the
Scada, this means the Scada and OP have the same alarms.
Later
zan
 
D

Donald Pittendrigh

Hi Michael and Others

Hmm..... I suppose I did come across as being too agressive, I cannot remember the circumstances when I typed the reply to the reply to the reply, however on re-reading my words I gather I must have had a bit of a rough day, and for that I apologise.

My original reply to this thread was intended to be a little lighthearted, and having digested your last e-mail perhaps mis-informed. There are
however some things which after the period of time I have worked with Siemens PLC's which irritate me immensely and one of them is "substitute engineering" where a cheap and nasty solution is put in place of something
which costs a bit more and therefore doesn't quite foot the bill. I am inclined to categorise this CPU/OP connection along these lines. Possibly
the worst of this type of setup that was ever inflicted on me was a loop to an OP (I seem to remember it was an OP35 but am not sure as it was a while ago), over the "second interface" on a 928B CPU, so unfortunately I am biased. The reason why I am unaware of the loop through mode is that I have subsequently only used Profibus connections to the OP/TD's on my projects, and I try to run the connections at 12meg. There is for obvious reasons no need for a loop through mode on a DP interface. I cannot claim to have set up 100's of OP/TD devices but the machines where I used TD20 displays most effectively were container cranes which I designed for several harbours in South Africa, while I still worked for Siemens. These machines are a good deal larger than the type of project you have
described and the interlocking and interrelation of various motions can get fairly complex. The problem with large material handling machines is
that one fault often causes other secondary faults to occur, This is where the importance of the high speed connections plays a role. There is
nothing worse than a client reporting repeated failures based on the error log on his text display, causing hours of wasted time, looking for a problem which doesn't exist as it was incorrectly reported.

I have a very high regard for the Siemens OP/TD range and have used them often and with great success, especially in the days prior to hi speed
ehternet scada interfaces when it just wasn't possible to get a scada system to be as responsive as a Profibus OP link.

Setting up error texts and linking them to the PLC program is a simple matter and simply acknowledgeing a text message does not cause much difficulty. The complexity I referred to relates back to the "chained faults" as described above, where tripping a circuit breaker would for
example have to be used to interlock a brake failure detection circuit so that the brake failed fault does not indicate when the cause is in fact removal of power from the brake supply and not a malfunction of the brake itself. The fact that the brake is tripped and closes could then possibly cause the machine to travel slower than the setpoint to the drive, this then could cause the drive to detect a discrepancy between the speed setpoint and the speed actual feedback, and report a third fault, this would subsequently have to be bridged out or blocked by the original
errant circuit breaker. With a bit more imagination, I could probably dream up even longer "chain reaction" however I think the point is well illustrated by the danger of reporting a brake failure when in fact the circuit breaker has tripped. Spending the extra bucks to get the OP link speed to acheive an update time of one PLC cycle, and setting the display to show the first fault at the top of the buffer, alleviates the need to get into the complex interlocking of the "fault chain" in other words, although the PLC may detect the secondary faults, the display will always show the one which occured first and is rightfully identified as the cause of the problem.

Lately we have been building machines which have sophisticated HMI systems on board, this results in a very attractive presentation of important
machine information, and affords the operator access to information that just isn't possible to handle on a td/op, and by using these fancy hi
speed ehernet interfaces in the PLC and the HMI PC, we can acheive great trends and fault logging and statistical information, however even so the
HMI update time is typically 100 - 150ms for 2 - 3000 tags, this is impressive considering that not very far back in time it was a challenge to do better than a 2 second update on HMI, but even then, with a typical hi speed S7 PLC, we can expect a cycle time of the PLC program of around
15 to 20 msecs, this means the PLC can do 5 cycles in the time the HMI updates only once and the above chain of faults still leads to (somewhat
less frequent) erroneous error reports. By using a text display this 100ms update time can be significantly reduced and so we still have better
accuracy from the Siemens OP/TD for a great deal less cost.

I hope I have now presented my case a little more clearly and that I have been able to shed some light on a slightly different concept of alarming
to the one you have described. I reitterate my apology for a somewhat irritated reply and thank you for a clear and informative description
of your side of the matter.

Regards
Donald Pittendrigh
 
Top