s5 output

N

Thread Starter

Nucciarone, Joe

Hello, I've encountered something funny with a siemens S5 135u cpu928a plc. I have an output at the end of a rung that will not activate when the logic in front of it is true(there is only one contact in front). I've seen this happen when the o/p is used multiple times causing erratic behavior but I've checked the o/p and its only used once in the program. I'm using fas trak software to monitor the program and cannot figure out what is happening. Any ideas? Regards Joe n
 
Hi Joe, even if the output is used many times you should still see the status of the ladder rung when looking at it?...unless you are using direct addressing? If you email me your program I will load it onto my test 928 to try out for you. If you send program also send details of ladder rung where you are having problem? Regards, Steve. [email protected]
 
S

Steve Myres, PE

>>I have an output at the end of a rung that will not activate when the logic in front of it is true(there is only one contact in front). Check if the bit is part of a word which is written elsewhere in a word instruction. Also, I'm not sure about the s5, but you may have instructions that write to multiple words, so that this word is being overwritten without being explicitly coded in the program. Example: the FLL or COP instructions in A-B that write across a group of consecutive values. Try using a different bit address for the output to test this. Last thing I can think of: make sure this segment of code is actually being executed (if in a subroutine, make sure it is being called, also not being jump'ed over, etc.) Suggestion for confirming this: add to the rung a statement to increment another register every scan, then see if that register accumulates. If so, you know the rung is being executed. If none of these work, it's time for the exorcist. ;-) Steve
 
C

Chris - Ceda Automation

Hello, Check if the block with your funny output is being called (ie) ju - fb1), and also check that the output is not part of a word or byte used somewhere in the program, because this may send your single bit low. Chris - [email protected]
 
Even if the output is being written to by BYTE or WORD format, when checking the ladder status online you would still see the output in question being turned on. When the PIQ is updated then the actual status of the output would be "controlled" by whatever is being written to the output last.
 
M

Michael Griffin

You didn't mention whether you are very familiar with the S5 series or not. If you are very familiar with it, you can ignore what I am about to say as you will have tried all the following already. I will also assume that by 'activate', you mean inside the program (I just dealt with a loose DC+ wire on an output card). - First, make sure the block the output is in is actually being scanned. More often than not, this is where the problem is. - Next, make sure the output is not being addressed as a byte or word. Keep in mind that QW2 and QW3 are both addressing QB3. - Next, check that the output is not being addressed as a function block parameter (as bit, byte, or word). - Finally there is indirect addressing using the 'DO' instruction, or even worse, the TIR instruction. If all else fails, and you can play with the program, try programming a dummy rung with the output in it at various strategic points in the program scan to try to isolate the point where the problem is happening. ********************** Michael Griffin London, Ont. Canada [email protected] **********************
 
D

Dittrich, Rodolfo

Joe, Try making that segment with an unconditional jump to test. I encountered a similar problem some time ago, and finally discovered that for some reason the RLO was becoming 0 at that point. Try with JC to a little function were you can activate the output, the JC force the RLO to 1. Hope to be usefull Regards Rodolfo
 
D

Donald Pittendrigh

Hi All Be carefull with Siemens PLC's, the termination of a segment does not remove the dependancy of the following segment, on the preceeding RLO, unless the last statement in the segment was an =, S or R function. This is perhaps a bit of a generalisation but it is well documented in the S5 manuals, if you have a segment which contains a statement which generates an RLO and continue in the next segment with a new RLO dependant rung, the RLO of the previous segment is included in the logic of the second segment. Segment 1 A I 0.0 *** Segment 2 A I 0.1 = Q 0.0 *** The function in segment 2 is that of anding I 0.0 and I 0.1. If you terminate segment 1 with some action such as = F 0.0, then this does not happen. It sounds as if this may have some bearing on your problem. Regards Donald Pittendrigh
 
S

Shahid W Chaudhry

Some of the possible situations could be: 1) The Logic in the segment/rung is being reset before the CPU writes the o/p to the Output Process Image Table at the end of the scan. 2) Is the output a SR (or RS) block. Maybe you are getting a logic=OK for both. By default the SIMATIC Set/Reset block has a higher priority assigned to the Reset Bit. Maybe this is causing the problem. Anyways, happy debugging - Shahid
 
N

Nucciarone, Joe

My problem is definitely within one segment. This segment is ladder represented and therefore RLO independent if the instructions are connected to the power rail. I have one flag bit or'd with another flag bit then my o/p Q7.2. I've checked for QW7 being written by something else and found nothing. The PB is being called in OB1 using JU. I did notice that the segment before is also ladder and it ends with 2 outputs in parallel ! I know this is not allowed in many plc's. Could this be the cause?
 
D

D. C. Pittendrigh

Hi All Please put your programmer in statement list disply, view the program segement on line and do a screen dump and E-Mail it to me, I will tell you what is happening and if it is going wrong in the segment or outside. Cheers Donald Pittendrigh
 
M

Michael Griffin

You checked for QW7, but did you also check for QW6, and QB7? These also address the byte which contains Q7.2. QW6 contains output bytes QB6, and QB7. QB7 of course, addresses this byte alone. To answer your question, there is nothing wrong with addressing multiple output coils in parallel. I will also re-iterate that there are also indirect means of addressing a byte. It can be addressed as part of a function block parameter (not technically indirect addressing - but not obvious none the less). This could be as a bit, byte, or word. It can also be addressed by the 'DO' instruction. This is occasionally done to help create reusable function blocks (the address is calculated by some means). This can be difficult to track down, but is rather rare with outputs. The TIR and TNB instructions are the most difficult to decipher, but they permit addressing any point in memory via machine code addresses (not logical PLC addresses). I've never seen them used to address I/O, although I have seen careless use of them cause programs to erase themselves. These are instructions which should be avoided. You need a PLC memory map and a calculator to figure out what they are addressing. An interesting question though would be what are Q7.1 and Q7.3 doing? Are they behaving normally, or do they have similar problems? If this is a byte or word addressing problem, then they should have the same problem as Q7.2, unless some sort of masking is used. If you want to track down where the problem is occuring, try inserting your test rung at various points in the program. Try it at the end of OB1 (this should work). Next try it half way through, etc. Once you have narrowed down the area, finding the problem should be much easier. ********************** Michael Griffin London, Ont. Canada [email protected] **********************
 
S

Shahid W Chaudhry

Comment on the email from Donald: Another way around the RLO problem (feature?) is by leaving a blank line after the instruction. e.g: A I0.0 A I0.1 = F0.0 // Blank Line - This sets the RLO to 1 for the next line A I1.0 // The new instruction would be executed without the effect of the RLO from the last process A I1.1 = F1.0 Like wise, leave a line before ending a segment. A I0.0 **** - Shahid
 
D
As a quick test, move the whole rung to the END of OB1, as there is no code after it the rung *must* drive the output, if it does, then the fault is software overwriting.
 
Top