Indirect adressing oh no

dwoodlock · Aug 3, 2018

Gents,

I've not had much dealings with indirect addressing, but I'm troubleshooting a program now, and I just wanted to verify that I've come to some level of understanding.

Code:

      L     3
      L     1
      -I    //3-1= 2
      L     416
      *I    //2*416 = 832
      LAR1  //load 832 into AR1                          

      L     DBW [AR1,P#22.0 //load the value found in DBW832 with a 22byte offset, which would be dbw854???

thanks for your help

thingstodo · Aug 3, 2018

dwoodlock said:
Gents,

I've not had much dealings with indirect addressing, but I'm troubleshooting a program now, and I just wanted to verify that I've come to some level of understanding.

Code:

L 3 L 1 -I //3-1= 2 L 416 *I //2*416 = 832 LAR1 //load 832 into AR1 L DBW [AR1,P#22.0 //load the value found in DBW832 with a 22byte offset, which would be dbw854???

thanks for your help

That looks like assembly language to me.

Code:

L 3	load (push to stack) the constant value 3
L 1	load (push to stack) the constant value 1
-I 	subtract the first number popped off the stack from the second number popped off the stack and push the result to the stack
L 416	load (push to stack) the constant value 416
*I 	multiply the first number popped off the stack with the second number popped off the stack and push the result to the stack
LAR1 	pop the result from the stack and store into AR1 register
L DBW [AR1,P#22.0 //load the value found in DBW832 with a 22byte offset, which would be dbw854???

- this syntax looks a bit funny. But I agree with your comment. I am not familiar with this instruction set - I don't know what offset the DBW starts with, whether it starts at 0 in memory, or in data memory, or whatever. But adding 22 double words (not bytes) to AR1 is what i would expect this code to do.

Is this code from a PLC?

mk42 · Aug 4, 2018

dwoodlock said:

I think you more or less have the idea down, although I'm not sure about the offset. It's been a while, but I THINK the value in AR1 is shifted over three bits to account for the bits after the byte. I think it would actually be DBW126 (22+ 832/8).

thingstodo said:
That looks like assembly language to me.
Is this code from a PLC?

This is STL in the Siemens world, or IL in IEC parlance. It is commonly used by the brave, foolhardy, or European to program s7 300s and 400s.

thingstodo · Aug 4, 2018

mk42 said:
This is STL in the Siemens world, or IL in IEC parlance. It is commonly used by the brave, foolhardy, or European to program s7 300s and 400s.

I knew that structured text could be .. would somewhat obtuse be polite? ... but this appears to have none of the positives of other PLC languages

I guess it's what you get used to ...

L D[AR2P#0.0] · Aug 4, 2018

If you are trouble shooting then when you monitor you can show the contents of the accumulators and address register to confirm your understanding. AR1 is (as already pointed out by mk42) pointing to DBW104 so the load is from DBW126

mk42 · Aug 6, 2018

thingstodo said:
I knew that structured text could be .. would somewhat obtuse be polite? ... but this appears to have none of the positives of other PLC languages

I guess it's what you get used to ...

So, strictly speaking Structured Text (ST) is SCL in the Siemens world. It's based on Pascal, a PC language that was popular in the 80's when PLC stuff got standardized. It is fairly straightforward for people who are used to pretty much any text based programming language, and scary to people who only know ladder and refuse to learn anything else. If they want to at least TRY, SCL is fairly easy to read, even by people who wouldn't have the first clue how to write more.

STL is Statement list or Instruction List (IL), which is more or less straight up assembly code. Obtuse is a very polite description. It was more or less what the PLC was directly executing. For advanced programmers, it was useful to know how the PLC thought, so you could get the most out of it. For medium programmers, sometimes you had to use STL because there was no other way to do what you wanted. For beginning programmers, STL was a horror that you prayed you didn't have to deal with.

dwoodlock · Aug 6, 2018

Thanks for the info everyone. This is some cam/tool protection logic, and it seems that some of the addressing may have gotten entered incorrectly.

Will continue working on it today.

I guess I was oblivious to the part where 832 is divided by 8.

thingstodo · Aug 6, 2018

mk42 said:
So, strictly speaking Structured Text (ST) is SCL in the Siemens world. It's based on Pascal, a PC language that was popular in the 80's when PLC stuff got standardized. It is fairly straightforward for people who are used to pretty much any text based programming language, and scary to people who only know ladder and refuse to learn anything else. If they want to at least TRY, SCL is fairly easy to read, even by people who wouldn't have the first clue how to write more.

STL is Statement list or Instruction List (IL), which is more or less straight up assembly code. Obtuse is a very polite description. It was more or less what the PLC was directly executing. For advanced programmers, it was useful to know how the PLC thought, so you could get the most out of it. For medium programmers, sometimes you had to use STL because there was no other way to do what you wanted. For beginning programmers, STL was a horror that you prayed you didn't have to deal with.

Thanks for the info! ST = SCL, and mere humans can likely read and troubleshoot the Pascual-like code. STL or IL is assembly and would require serious investigation and documentation before messing with it.

Back in university (in the 80's) Turbo Pascal was one of my first programming languages. Along with 6502/6510 assembly, for the Commodore 64 and Vic 20, PDP 11 assembly, for the Digital Equipment Corp VAX/VMS 11/780 mainframe. And of course some variant of BSD C.

I've never dealt with Siemens PLCs, in 25 years of PLC programming. In the mid 80's I worked with a tech that used an older CPM-based prorgramming package for Siemens that ran on top of DOS, using a CP/M emulator. It did not sound like he had a good time.

mk42 · Aug 6, 2018

dwoodlock said:
I guess I was oblivious to the part where 832 is divided by 8.

Yeah, the divide by 8 is, AT BEST, implied. If you don't know how pointers are structured in memory, it makes no sense what so ever, and it isn't trivial to realize which specific help page is the one causing your issue.

It's very common to see people calculate their pointer and then multiply by 8, so that it actually works. Sometimes they are polite, and insert a comment explaining why. Sometimes.

thingstodo said:
Thanks for the info! ST = SCL, and mere humans can likely read and troubleshoot the Pascual-like code. STL or IL is assembly and would require serious investigation and documentation before messing with it.

Back in university (in the 80's) Turbo Pascal was one of my first programming languages. Along with 6502/6510 assembly, for the Commodore 64 and Vic 20, PDP 11 assembly, for the Digital Equipment Corp VAX/VMS 11/780 mainframe. And of course some variant of BSD C.

I've never dealt with Siemens PLCs, in 25 years of PLC programming. In the mid 80's I worked with a tech that used an older CPM-based prorgramming package for Siemens that ran on top of DOS, using a CP/M emulator. It did not sound like he had a good time.

I know a lot of programmers that are very familiar with STL and program in it exclusively. Its very common in Europe. If you work with it you understand how it works quickly, but it makes it very very easy to make stupid code that is hard to follow without detailed comments you never quite found the time to include.

C64 was where I started in programming. No assembly, but elementary school me was quite proud of what it could do in Basic. Yeah, I know, dating myself.

These days with newer Siemens PLCs, STL is mostly just there for backwards compatibility/migration purposes. Or if the previous programmer wants to make you suffer.

dwoodlock · Aug 6, 2018

Thanks for all the tips.

I came to the conclusion that the pointer offset was off by 22, so where it was 22 it should have been 44 and so on.

The 22 lead to it at some piece of the characters from the cam description instead of the cam start point.

This machine was coded in Deutschland so as is typical its in STL

Indirect adressing oh no

dwoodlock

Lifetime Supporting Member

thingstodo

Member

mk42

Lifetime Supporting Member

thingstodo

Member

L D[AR2P#0.0]

Lifetime Supporting Member

mk42

Lifetime Supporting Member

dwoodlock

Lifetime Supporting Member

thingstodo

Member

mk42

Lifetime Supporting Member

dwoodlock

Lifetime Supporting Member

Similar Topics