how to be a Professional Siemens PLC STL programmer

[Peter Nachtwey]

Any examples of what you can do with stl that you can't do in ladder?

Indirect addressing for starters. There are a lot of examples of tricks that can only be done in STL in my
http://www.plctalk.net/qanda/showthread.php?t=47521
thread.

STL has a JL instruction that allows one to efficiently execute case statements. This is much more efficient that scanning the whole ladder or doing a compare for each case.

The example that L D [AR2,P#0.0] provide can't be done in LAD easily or efficiently.

HelloAll's goal is flawed. He should strive to be a better programmer and strive to learn algorithms, physics and the math required to understand them. The S7 is just a tool. When using another tool the special S7 knowledge will be of no use but the algorithms, phsysics and math will be.

Our second generation controller was programmed mostly in assembly language. Our third generation controller is programmed in C. Few if any tricks I used for the second generation controller are necessary now. Too much mental energy was spent on keeping track of what is in each register and how to address data when programming in assembly language. Now that is no longer important.

 

[Manglemender]

Any examples of what you can do with stl that you can't do in ladder?

Try re-coding this in ladder.

      L     P##pRecipeData
      LAR1  
      L     D [AR1,P#6.0]               //Area pointer
      T     #dwAreaPointer
      L     W [AR1,P#4.0]
      T     #iDataBlockNumber           //DB number
      L     W [AR1,P#2.0]
      T     #iSize                      //Number of bytes

      LAR1  P##pSourcePointer           //set AR1 to the ANY pointer
      L     W#16#1002                   //specify ANY pointer, type 02 = BYTE
      T     LW [AR1,P#0.0]
      L     #iSize                      //number of bytes to transfer
      T     LW [AR1,P#2.0]
      L     #iDataBlockNumber           //DB number
      T     LW [AR1,P#4.0]

      L     #iSize                      //start of read data       ITD   
      L     #iRecipeNumber
      ITD   
      *D    
      SLD   3                           // byte pointer
      L     P#DBX 0.0                   // Point to DBX0.0
      +D                                // Add offset in bytes
      T     LD [AR1,P#6.0]              // store in AR1

Nick

 

[allscott]

I was being somewhat fecisious with my question. I understand that you can't do a lot of things in Siemens ladder.

I can do indirect, indexing, etc... just fine in an AB plc. That little cpt instruction in a AB PLC sure makes life easy.

 

[allscott]

Try re-coding this in ladder.

      L     P##pRecipeData
      LAR1  
      L     D [AR1,P#6.0]               //Area pointer
      T     #dwAreaPointer
      L     W [AR1,P#4.0]
      T     #iDataBlockNumber           //DB number
      L     W [AR1,P#2.0]
      T     #iSize                      //Number of bytes
 
      LAR1  P##pSourcePointer           //set AR1 to the ANY pointer
      L     W#16#1002                   //specify ANY pointer, type 02 = BYTE
      T     LW [AR1,P#0.0]
      L     #iSize                      //number of bytes to transfer
      T     LW [AR1,P#2.0]
      L     #iDataBlockNumber           //DB number
      T     LW [AR1,P#4.0]
 
      L     #iSize                      //start of read data       ITD   
      L     #iRecipeNumber
      ITD   
      *D    
      SLD   3                           // byte pointer
      L     P#DBX 0.0                   // Point to DBX0.0
      +D                                // Add offset in bytes
      T     LD [AR1,P#6.0]              // store in AR1

Nick

If I knew what the heck it did I probably could.

 

[Manglemender]

I was being somewhat fecisious with my question.

I thought perhaps you were serious. Looking back at the comments I wrote for the code they aren't my finest.

The code fragment is part of a PLC based recipe handler that demonstrates the power of pointers in STL. It operates on a datablock filled with multiple recipe UDTs and generates pointers to the recipe in use dynamicaly from the recipe number; these pointers are in turn used for the load/save functions of the recipe handler.

It would be posible to program all those load save transfers individually in ladder; it requires 2*Number of recipes which might be OK if you only needed say 5 recipes but becomes more of a pain when a customer says the want 100 recipes.

Using pointers has some distinct adavantages: Changing the number of recipes in use does not involve changing the code in any way. Because nothing is directly addressed, it is posible to run multiple instances of the recipe manager (I have one control system that uses 4 instances for sub-machines).

I can do indirect, indexing, etc... just fine in an AB plc. That little cpt instruction in a AB PLC sure makes life easy.

I'm hoping to be able to dip my toes in RSLogix5000 next year to see what it can really do.

Best regards and Merry Christmas,

Nick

 

[Peter Nachtwey]

Manglemende, you have been brain washed

It isn't just you but all that think S7-3xx are so cool. S7-3xx provides hurdles you must jump and you think it is great you can jump them but I would rather use a tool that doesn't make up jump the hurdles and simply lets you concentrate on getting to the finish line.

The code fragment is part of a PLC based recipe handler that demonstrates the power of pointers in STL.

yes pointers are powerful. The code I had to write for the x86 in assembly language did the same thing only they had index registers instead of address registers and segment registers instead of data block registers.

All of Manglemender's code just prepares for copying data from one place to another. The code doesn't even do the copy itself. Allscott can do that in one COP, copy, instruction. One specifies the source, destination and length in one block similar to the BLKMOV command in the S7-3xx but Rockwell programmers don't have to mess with pointers. They can use array indexes in a manner similar to what Siemens programmers can in SCL. The last time I looked RS5000 programmers didn't need to manipulate pointers. That saves on mental energy and the opportunity to make big mistakes.

The S7-200 is SO MUCH easier to program than the s7-300 doesn't anybody notice that no one asks questions about how to program it? It has more accumulators and provides a crude indirect addressing in LAD that is similar to what RS500 provides.

Java doesn't have pointers or DB numbers. There are references that are used to pass objects but one doesn't need to manipulate the pointer itself.

I would be embarrassed and consider it a design flaw if there were so many questions about our product about the same thing.

 

[Gnook]

Done the RSLogix 5K thing, bit sketchy, some nice old SLC functions have gone (like really good indirect addressing) but some new nice fearures added in. Another ten years and AB might be on a par with Siemens for functionality and application independant portable code.

 

[manmeetvirdi]

I would be embarrassed and consider it a design flaw if there were so many questions about our product about the same thing.

No I think that objective of providing pointers (and everything else in STL) in 300 is not to create the confusion but just to provide more flexibility to achieve your target.

Everyone knows that all the instructions are executed by processor in assembly language only. Instructions like Addition
subtraction and COP in AB are all broke down into assembly level which is understood by processor and then executed.

So you can make 10000 or more commonly used functions in industries in the form of instructions (which doesn't involve
playing with registers) and come up with a package. But you cant claim that you can do all the things under the sun
with these 10000 instruction, only thing you can do is to increase the number from 10000 to 1000000 but still you
are well short of infinity !!!

Once you understand the things its done,then its no more complex. Have you seen LD asking questions about STL or
yourself asking questions on PID?? Rare, very rare,right?

Only thing which you guys are doing over here on PLCS is to bring we guys to your level, right?

 

[Peter Nachtwey]

No I think that objective of providing pointers (and everything else in STL) in 300 is not to create the confusion but just to provide more flexibility to achieve your target.

Look at allscott's last post. All that code and it doesn't even do the copy. Look at allscott's comment. allscott admitted that code isn't obvious.

One can use a MOV or COP command to use a recipe number to index into an array of UDT ( recipes ) and copy it to another UDT ( recipe ) in one block.

Everyone knows that all the instructions are executed by processor in assembly language only.

Sure but whats the point? My point is that the tools should do the work for you. Mental effort should be applied to the application, not the tool.
Wouldn't you like to do that in one block?

 

[Jeebs]

One can use a MOV or COP command to use a recipe number to index into an array of UDT ( recipes ) and copy it to another UDT ( recipe ) in one block.

This is sadly where STL falls short.
You can't dynamically change the index of an array, you can't do:

      CALL  "BLKMOV"
       SRCBLK :="Recipes".Recipe[#newRecipe]
       RET_VAL:=MW200
       DSTBLK :="Recipes".CurrentRecipe

You can do:

      CALL  "BLKMOV"
       SRCBLK :="Recipes".Recipe[25]
       RET_VAL:=MW200
       DSTBLK :="Recipes".CurrentRecipe

If the first one was possible, most of the need to manually create pointers would vanish.

I do think SCL can do this though.....might be a marketing strategy?

 

[L D[AR2P#0.0]]

It isn't onerous to come up with your own recipe move though.

This, happily, is where STL comes up trumps

 CALL  "RecipeMove"
       SRCBLK :="Recipes".Recipe
       Index :=#newRecipe
       RET_VAL:=MW200
       DSTBLK :="Recipes".CurrentRecipe

 

[allscott]

Sure but whats the point? My point is that the tools should do the work for you. Mental effort should be applied to the application, not the tool.
Wouldn't you like to do that in one block?

Exactly. Not all of us code for a living. I have to decipher STL about once every 6 months when a machine I am working on isn't working. And believe me I swear at the programmer, the Engineer that provided me with 400 pages of drawings, about 20 that of are any use, Siemens, and the dumb *** from my company that bought the machine full of this garbage. And yes its usually something simple that is wrong but I need to figure out the code so I know what that simple thing is.

The most complicated machines I have ever worked on used PLC 5's. And trust me a CCV line in a wire plant is complicated. So when someone says "you can't do that in ladder" I call BS. That something that needs to be done isn't programming, its making a machine or a process do something, so yes it can be done in ladder.

Can it be done more efficiently in STL, probably? Can it be done faster by someone who knows STL, probably again. But at the end of the day who cares.

I once had a Siemens sales Engineer start bashing AB as part of his sales pitch to me. His comment was "You can't even see whats going on in the accumulator of an AB PLC", I fired back with "I have never had to see what is going on in the accumulator of an AB PLC", he kind of shut up after that.

Peter has gone to great lengths to make his product ridiculously intuitive. A high end motion controller is complicated at the gut end. With a delta controller I don't need to see the gut end, nor would I ever be able to begin to understand it, and I really don't care to. I don't think I will ever attempt another motion control project involving hydraulics unless I am using an RMC.

The hardware does the moving of things, the software is the tool to make the things move the way you want to. My kids are busy growing up I don't need to be spending hours of my life fighting with software.

Sorry, bit of a rant there, been a long couple weeks.

 

[L D[AR2P#0.0]]

I wonder if HelloAll is still enthusiatic about STL

 

[metwally.mustafa]

STL example

 

[metwally.mustafa]

STL example


L PIW290
T MW2
LMW2
ITD
DTR
T MD6
L MD6
L 1.0
*R
T MD10
L 200.0
L MW12
>R
S Q50.0