pointer and array in STL Step7

Hi,

I mostly program in LAD, because I think electrically. Calculations in STL, but real simple, I don't do complex things in STL.

But, many programmers write in STL.

I see pointers and arrays sometimes...

can anyone explain this a little with an example ?


Thanks very much

Combo said:

Hi,

I mostly program in LAD, because I think electrically. Calculations in STL, but real simple, I don't do complex things in STL.

But, many programmers write in STL.

I see pointers and arrays sometimes...

can anyone explain this a little with an example ?


Thanks very much

Click to expand...

Often use for "catching" multiple values sent continuously, Arrays are almost the only way to go when you need to "file" and access some pieces of Data.

Say for instacne that a device sends to your listenning serial port, a string composed of 32 Bytes.

The next string could arrive soon or not and could be of a different number of Bytes.

You would use an array to parse and move all them seperate Bytes into an Array of "registers" or memory allocations.

The pointer has a value representing the amount of Bytes you receive. So your pointer would have the value of 32.(Its often built with a LENGTH function applyed on the incoming string)

The pointer gives you the "spot" where to start writing the next incoming Bytes.

On the oposite direction a pointer will give you the position where you will start to "read" them memory allocations.

So the array is a reserved group of continuous memory areas and the pointer is "from where" in this group, an action will take place.

Its often use with a "Ring-buffer".

This applies to PLCs, not specifically Siemens.

Hi Combo

I regard STL, LAD, FBD and all the other PLC languages as just different tools to solve different problems. Some are better at some tasks but no one is best of all.

With this type of thinking I could re-phrase your question as "At work I mainly use a hammer, but I know some other guys use screwdrivers. I've used little screwdrivers, but I've never tried a ratchet screwdriver or an electric. Can you give me an example of when or why I should these?"

Well if you can already satisfactorily solve all your problems using a hammer then they must all be nails. And learning to use a ratchet screwdriver is a big backward step in the nail department. On the other hand, are there things you find you can't do that you would like to do, or where ladder is really messy and awkward? Well maybe some of these are screws in disguise and this is where an extra tool in the box is worth its weight in gold. ( (C) Ken M Analogies Ltd. Mixed metaphors a speciality.)

It's not always easy to explain when to use a particular tool - if you've never seen the extent of the problem you won't appreciate the value of the solution. However, here goes -

One application I saw which used a 3-dimensional array really neatly was a automated warehouse storage system. There were a number of aisles (about 40-50), each aisle had a number of columns of shelving units (about 15-20), and each column had a vertical stack of 12 shelves. Products with specific codes were placed or removed by automated machines at each shelf position. To identify the shelf position you had to know the aisle number, column number and shelf number. In the PLC an array was set up in memory which had 12000 memory locations. In each of these a single product code would be stored. Why 12000? Well 50 aisles x 20 columns x 12 shelves = 12000. But to read or write these memory locations it didn't make sense to use address 6127 or 9186 - where the hell were they in the warehouse? What was used was an array so the memory was addressed as Store[AisleNo, ColumnNo, ShelfNo] or Store[3, 12, 10] Much easier to design, code and debug.

Pointers were also used in this application. Occasionally a check had to be run on whether a particular product was anywhere in the warehouse (the SCADA was supposed to keep track of this, but some times there were disagreements and corrections had to be made.) So, armed with a product code you could either write 12000 comparisons "is the product in location 1 equal to ...", followed by "is the product in location 2 equal to ..." followed by.. etc Or you could use another piece of memory as a pointer. That didn't hold the value to be compared. What it did was to hold the address where the value would be found. That's the big difference with pointers - they don't contain values, they contain addresses. So a single comparison could be written saying "is the value in location {pointer address} equal to ...' and then run this multiple times, changing the contents of the pointer each time so you scanned through the locations until you got a hit.

This application actually used 3 tools : ladder, STL and Structured Text (ST). I guess they reckoned they had nails, screws and bolts!

Regards

Ken

ok

ok

tnx

Sorry, know this is old, but do you have that program would like to take a look at it, sounds very helpful for future use. Thanks, mike.

Ken M said:

Hi Combo

I regard STL, LAD, FBD and all the other PLC languages as just different tools to solve different problems. Some are better at some tasks but no one is best of all.

With this type of thinking I could re-phrase your question as "At work I mainly use a hammer, but I know some other guys use screwdrivers. I've used little screwdrivers, but I've never tried a ratchet screwdriver or an electric. Can you give me an example of when or why I should these?"

Well if you can already satisfactorily solve all your problems using a hammer then they must all be nails. And learning to use a ratchet screwdriver is a big backward step in the nail department. On the other hand, are there things you find you can't do that you would like to do, or where ladder is really messy and awkward? Well maybe some of these are screws in disguise and this is where an extra tool in the box is worth its weight in gold. ( (C) Ken M Analogies Ltd. Mixed metaphors a speciality.)

It's not always easy to explain when to use a particular tool - if you've never seen the extent of the problem you won't appreciate the value of the solution. However, here goes -

One application I saw which used a 3-dimensional array really neatly was a automated warehouse storage system. There were a number of aisles (about 40-50), each aisle had a number of columns of shelving units (about 15-20), and each column had a vertical stack of 12 shelves. Products with specific codes were placed or removed by automated machines at each shelf position. To identify the shelf position you had to know the aisle number, column number and shelf number. In the PLC an array was set up in memory which had 12000 memory locations. In each of these a single product code would be stored. Why 12000? Well 50 aisles x 20 columns x 12 shelves = 12000. But to read or write these memory locations it didn't make sense to use address 6127 or 9186 - where the hell were they in the warehouse? What was used was an array so the memory was addressed as Store[AisleNo, ColumnNo, ShelfNo] or Store[3, 12, 10] Much easier to design, code and debug.

Pointers were also used in this application. Occasionally a check had to be run on whether a particular product was anywhere in the warehouse (the SCADA was supposed to keep track of this, but some times there were disagreements and corrections had to be made.) So, armed with a product code you could either write 12000 comparisons "is the product in location 1 equal to ...", followed by "is the product in location 2 equal to ..." followed by.. etc Or you could use another piece of memory as a pointer. That didn't hold the value to be compared. What it did was to hold the address where the value would be found. That's the big difference with pointers - they don't contain values, they contain addresses. So a single comparison could be written saying "is the value in location {pointer address} equal to ...' and then run this multiple times, changing the contents of the pointer each time so you scanned through the locations until you got a hit.

This application actually used 3 tools : ladder, STL and Structured Text (ST). I guess they reckoned they had nails, screws and bolts!

Regards

Ken

Click to expand...

I know this is an old thread that's been resurrected but I've just read the reply from Ken and its brilliant!! Really enjoyed the read.

Well done that man!!

;-)