PDA

View Full Version : Siemens STL Logic to Jump for a Bit !?


cgehlhausen
February 3rd, 2006, 09:00 AM
Need to Jump to different Tasks, based on different Bits.



Need Logic like this in STL: If Bit1 = 1, Jump to Task1

If Bit2 = 1, Jump to Task2
If Bit3 = 1, Jump to Task3
If Bit4 = 1, Jump to Task4
Else Jump to END.

Simple task, but can't seem to get that into Siemens STL (S7). Trying to get the RLO to get Set!


Tried all of these, none work:

Attempt 1
L B#16#0 // Clear Accumulator
A "Bit1" // Load Bit1
JN Task1 // Jump to Task1 if Not Zero

Attempt 2
L B#16#0 // Clear Accumulator
A "Bit1" // Load Bit1
L STW // Load Status Word to ACCU1
SRW // Shift Right Word
JN Task1 // Jump to Task1 if Not Zero

Attempt 3
L B#16#0 // Clear Accumulator
A "Bit1" // Load Bit1
L STW // Load Status Word to ACCU1
LAR1 // Load ACCU1 to ADDR REG1
SRW // Shift Right Word
JN Task1 // Jump to Task1 if Not Zero

rdrast
February 3rd, 2006, 09:15 AM
In attempt #1, shouldn't you be using 'OR' "Bit1" instead of AND?

0 ANDED with anything is still zero.

When in doubt, switch to LAD, code it there, and swtich back to see how Siemens thinks it should be done.

S7Guy
February 3rd, 2006, 09:15 AM
Where are these bits? Just access them directly. You don't need the status word for what you are trying to do.

This would work. Just subsitute your logic for the NOP's:


A #Bit[1]
JC tsk1
A #Bit[2]
JC tsk2
A #Bit[3]
JC tsk3
A #Bit[4]
JC tsk4
A #Bit[5]
JC tsk5
A #Bit[6]
JC tsk6
BEU
tsk1: NOP 0
BEU
tsk2: NOP 0
BEU
tsk3: NOP 0
BEU
tsk4: NOP 0
BEU
tsk5: NOP 0
BEU
tsk6: NOP 0
BEU

SimonGoldsworthy
February 3rd, 2006, 09:16 AM
When using logic and the RLO, use JC or JCN

When doing comparisons use JN, JZ, JP etc.

If the bits to select your task are flag bits then your code should look something like this:

A M0.0
jc Task1

A M0.1
jc Task2

A M0.2
jc Task3

etc...

(simultaneous post with S7Guy)

S7Guy
February 3rd, 2006, 09:20 AM
In attempt #1, shouldn't you be using 'OR' "Bit1" instead of AND?

0 ANDED with anything is still zero.

When in doubt, switch to LAD, code it there, and swtich back to see how Siemens thinks it should be done.

In this case, you don't need an "OR" because there is only one bool instruction. The previous "Load" instruction has no bearing on the RLO.

cgehlhausen
February 3rd, 2006, 11:28 AM
The suggestion of:

A "Bit1"
JC Task1

Is actually the first thing I tried, then found out that JC only works on the accumulator or register, not on bits. RLO remains 0







Siemens DefinitionJC Jump if RLO = 1


After the A "Bit1" code executes, the RLO is still 0, but STA is the bit that changes to 1. That's why I tried loading the Status Word and Shifting it.


But in their ultimate wisdom, Siemens has prevented that as well:






Siemens DefinitionL STW (instruction L with the address STW) loads ACCU 1 with the contents of the status word. The instruction is executed without regard to, and without affecting, the status bits.


Note: For the S7-300 series CPUs, the statement L STW does not load the FC, STA, and OR bits of the status word. Only bits 1, 4, 5, 6, 7, and 8 are loaded into the corresponding bit positions of the low word of accumulator 1.



Since my 4 Bits are in the bottom half of the same Word, I got it to work by using this:





L B#16#0 // Clear Accumulator


L "Word" // Load the Word
L 2#1 // Mask 1st Bit
AW // Compare 1st Bit
JN Task1 // Task1 if Not Zero

L B#16#0 // Clear Accumulator
L "Word" // Load the Word
L 2#10 // Mask 2nd Bit
AW // Compare 2nd Bit
JN Task2 // Task2 if Not Zero

L B#16#0 // Clear Accumulator
L "Word" // Load the Word
L 2#100 // Mask 3rd Bit
AW // Compare 3rd Bit
JN Task3 // Task3 if Not Zero

L B#16#0 // Clear Accumulator
L "Word" // Load the Word
L 2#1000 // Mask 4th Bit
AW // Compare 4th Bit
JN Task4 // Task4 if Not Zero

JU END // Jump Unconditionally to END


PS - The comments keep shifting left, even the Fixed System Font seems to ignore the space characters. Sorry, it's hard to read.

cgehlhausen
February 3rd, 2006, 12:20 PM
How exactly do you write something in LAD and have Siemens convert it to STL?

In attempt #1, shouldn't you be using 'OR' "Bit1" instead of AND?

0 ANDED with anything is still zero.

When in doubt, switch to LAD, code it there, and swtich back to see how Siemens thinks it should be done.

rdrast
February 3rd, 2006, 01:01 PM
It has (thankfully for me) been a while since I've had to program S7's, but in the editor window, you can switch representations with a menu selection, or (I think) with an ALT or CTRL key combination.

S7Guy
February 3rd, 2006, 01:05 PM
I have no idea why the JC didn't work. I have literally thousands of JC and JCN in existing code using bool instructions. Can you post an example of the code that didn't work?

kamenges
February 3rd, 2006, 01:26 PM
One thing that always causes me a problem with the S7 is status of the RLO at any given point.

In your eample you showwed:


A "Bit1"
JC Task1


and said it didn't work. Depending on any logic operations you had done before this the RLO MAY have been zero. In that case ANDing "Bit1" with the RLO would still produce a zero in the RLO and the conditional jump would not have occurred.

After a while I just got in the habit of putting in a 'SET' instruction before I performed an operation like you show. This guaranteed the RLO was in the state I wanted it to bein for a valid compare. I know this is inefficient but it took away some doubt for me.

Keith

S7Guy
February 3rd, 2006, 01:30 PM
Keith, can you show an example? Like I say, I've never had that problem before, and I've written hundreds of thousands of lines of code. I wonder if that condition is specific to certain processors.

cgehlhausen
February 3rd, 2006, 01:41 PM
In case it's processor based, this is an S7 314C-2PtP.

I'll have to re-create the example, but it was just an M-bit in place of "Bit1" and a label to jump to in place of "Task1".

The RLO is definitely staying at 0, so I might try the SET.

kamenges
February 3rd, 2006, 01:47 PM
Here is a snippet of code where I needed to use the SET:


A #Estop_OK
JC ESTP
L 0.000000e+000
T #Line_Speed_Cmd
BEU
ESTP: L #Desired_Speed
L #Line_Speed_Cmd
<>R
JC RUNV
L 0.000000e+000
T #Inst_Accel
SET
R #At_Break_Vel
BEU
RUNV: NOP 0



If I get to the point of comparing the line speeds I need to make sure the #At_Break_Velocity is reset if the comparison is false. I'm not a big S7 user so there is probably a better way of doing this than I did. However, it doesn't change the facts that:
A) Step7 let me enter this
B) If I don't put in the 'SET' the execution of the 'R' is contingent on the result of the '<>' above.

Since I did this, it is possible that cgehlhausen's code is set up similarly.

Keith

S7Guy
February 3rd, 2006, 01:51 PM
I just tried it with a 416, and it worked just as expected. Unfortunately, I don't have a 314 handy. Here is the exact code I tried:



A M 50.0
JC tsk1
A M 50.1
JC tsk2
A M 50.2
JC tsk3
A M 50.3
JC tsk4
A M 50.4
JC tsk5
BEU
tsk1: AN M 60.0
= M 70.0
BEU
tsk2: AN M 60.1
= M 70.1
BEU
tsk3: AN M 60.2
= M 70.2
BEU
tsk4: AN M 60.3
= M 70.3
BEU
tsk5: AN M 60.4
= M 70.4

S7Guy
February 3rd, 2006, 01:55 PM
Here is a snippet of code where I needed to use the SET:


A #Estop_OK
JC ESTP
L 0.000000e+000
T #Line_Speed_Cmd
BEU
ESTP: L #Desired_Speed
L #Line_Speed_Cmd
<>R
JC RUNV
L 0.000000e+000
T #Inst_Accel
SET
R #At_Break_Vel
BEU
RUNV: NOP 0



If I get to the point of comparing the line speeds I need to make sure the #At_Break_Velocity is reset if the comparison is false. I'm not a big S7 user so there is probably a better way of doing this than I did. However, it doesn't change the facts that:
A) Step7 let me enter this
B) If I don't put in the 'SET' the execution of the 'R' is contingent on the result of the '<>' above.

Since I did this, it is possible that cgehlhausen's code is set up similarly.

Keith

Ok, that is a little different than what cgehlhausen is describing. He is having a problem with the JC executing. In your case, whether you need the SET is definitely processor dependent (I think you need it for the 300s, and don't need it for the 400s).

kamenges
February 3rd, 2006, 02:07 PM
But cgehlhausen's case would be the same if you replace the 'R #At_Break_Vel' in my example with 'A "Bit1" JC Task1' from cgehlhausen's example. The 'A "Bit1"' would AND with an RLO of zero and the jump wouldn't occur.

cgehlhausen never said that the logic he is having trouble with was the first thing in a network, in which case the RLO is taken care of. If this JC occurs in the middle of a network with preceeding logic all bets are off, at least in an S7-3152DP.

Keith

kamenges
February 3rd, 2006, 02:12 PM
On a slightly different note, wouldn't cgehlhausen be better off using the JL (jump to labels) instruction? It seems more closely aligned to what he wants to do.


Keith

Peter Nachtwey
February 3rd, 2006, 04:05 PM
This will work of the bits are grouped together.
First you must find the bit index.
( Has anyone figured out to do this efficiently yet? )
Then use the JL instruction to jump to the desired code.

cgehlhausen
February 3rd, 2006, 04:36 PM
It was the SET command that was needed - A lot less code needed now. The 314C-2PtP must be another CPU that has funky commands.

It's a Compact model, meaning it has digital and Analog I/O built in, plus the PtP means it has an extra Serial port.

SimonGoldsworthy
February 4th, 2006, 04:46 AM
Can you please confirm that it was not the code preceding your posted logic that caused your problem ? Can you post this code snippet as well ?

kamenges
February 4th, 2006, 01:03 PM
Originally posted by SimonGoldsworthy:

Can you please confirm that it was not the code preceding your posted logic that caused your problem ? Can you post this code snippet as well ?

I think that is exactly the issue. It IS the code preceeding the logic that is causing the problem.

For those who don't usually work with STL in S7 processors, the idea that logic you placed in a network can still influence you after you have used that logic for it's intended purpose is a bit counter-intuitive. With plcs in ladder logic, as soon as you perform an action and end a rung you move on and start from scratch. This is not necessarily true in STL. The state of the RLO is valid and is used in all logic calculations until a new network is started.

This is really no different than in ControlLogix where you can put an output condition in a rung and then continue with more logic. The difference is that in ladder the visual clues indicate that your logic after the output is contingent on the logic preceeding that output, or more correctly, on the state of the output itself. Without the visual clues in STL is is easy to forget about the RLO if you don't intend to use it.

Keith

WJhsson
February 4th, 2006, 04:11 PM
This will work of the bits are grouped together.
First you must find the bit index.
( Has anyone figured out to do this efficiently yet? )
Then use the JL instruction to jump to the desired code.


I would also use the JL(Jump to List)-instruction combined with some kind of homemade "Bit-to-int"-conversion.

RMA
February 6th, 2006, 07:44 AM
Without seeing what other code is involved, it's difficult to be sure, but this sounds very much like the old problem caused by the different processors used by the 300 and 400 CPUs. Since I believe S7Guy usually works with 400 CPUs, it would explain why he's never seen the problem. Almost everybody who works with 300s on a regular basis has almost certainly had this problem (possibly without necessarily knowing why!).

Here is The Siemens Explanation (http://support.automation.siemens.com/WW/llisapi.dll?query=difference+in+jump+in+300CPU+and +400+CPU&func=cslib.cssearch&content=skm%2Fmain.asp&lang=en&siteid=cseus&objaction=cssearch&searchinprim=&nodeid99=).

Edit:
I tried to bookmark the explanation, but for some reason it doesn't work. The post concerned is the first FAQ in the list - "FAQ Why do STEP 7 programs behave differently with respect to the BR bit with SIMATIC S7-300 and S7-400? ".

SimonGoldsworthy
February 6th, 2006, 08:02 AM
Roy, this is an RLO not a BR issue. We need to see the code that leads up to the problem area.

RMA
February 6th, 2006, 10:43 AM
The problem is that in the 300 series the jump doesn't close off the logic chain and reset the "first query" bit, so that after your jump you are not starting a new evaluation, but instead continuing an existing evaluation chain.

kamenges
February 6th, 2006, 11:22 AM
Roy-

So based on what you and S7Guy are saying, the 400 series processors DO cclose the logic chain at a jump? I've never used the 400 series. I just assumed they would act the same as the 300 series in this case.

Keith

RMA
February 7th, 2006, 01:27 AM
Unfortunately the Siemens explanation is not a miracle of clarity (not helped by the fact that they apparently have a typo in their example: neither
O M0.0
O M0.0
= M0.2
nor
A M0.0
O M0.0
= M0.2
are particularly sensible!), but the one thing that is 100% clear is that the 300s and 400s respond differently under these conditions - the 400 series behaving as one would logically expect.

Kristoffer
May 2nd, 2006, 07:43 AM
I think the only problem here is that you are using more than 4 signs in your labels (task1). You shoult rather call them something like: tsk1, tsk2, etc...

RMA
May 2nd, 2006, 12:50 PM
Well spotted Kristoffer, we all slept through that one!