S7 any pointer using struct in TEMP area

[L D[AR2P#0.0]]

... and here is the code generated by the editor but shown to you as a block call in ladder. As you can see, for the first call the editor has filled in the any pointer with the DB data specifed and then passed an area pointer to that data.
In the second call, the editor just passes the area pointer. The editor detects the ANY in the Temp area as a special case to allow you to build your own any pointer.

 

[dahnuguy]

I think he is just hard headed, and when he got this nice idea, he tries to ram it trough, even if it is not possible.

[CRYSTALBALL]
He will hit his head on the wall few times and then constructs his anypointers with pointers.
[/CRYSTALLBALL]

What? I acknowledged that I understand several accepted methods from the beginning, even listed several.

I want to make a STRUCT in a TEMP area that works as an ANY. How is that hard headed or a bad thing? If no one ever tried anything in S7 you wouldn't have any of the neat tricks you rely on daily.

It is a nice idea, and I am trying to find a solution, and it is somewhat academic, but if it works, it will be very nice. Thus my inquiry and effort.

For example:

Everyone at work said you need an MPI or pfoi cable to first load the IP address of the PLC before you can use the ethernet connection to communicate. I did it with only an ethernet cable. Even the documentation says you can't do it. But I did, and I cleared it and did it again just for fun.

Now isn't that helpful when your out with only an ethernet cable and a new PLC?

That's why I do this.

And my current project would benefit from this TEMP STRUCT ANY experiment and it would make my future projects better.

I don't see any down side here.

How is any of that bad?

 

[TurpoUrpo]

Sorry, you took it more personally than I tought you would. I apologise. I am hard headed and do it all the time, hit few times on the wall before im trough with it

None the less, you cant do struct that acts like any, I said that in Post #2. Rest was trying to explain why, Kalle started that in post #3.

 

[dahnuguy]

... and here is the code generated by the editor but shown to you as a block call in ladder. As you can see, for the first call the editor has filled in the any pointer with the DB data specifed and then passed an area pointer to that data.
In the second call, the editor just passes the area pointer. The editor detects the ANY in the Temp area as a special case to allow you to build your own any pointer.

This is one of the methods I have been using as you describe.

I wanted to go one step further by isolating the ANY inside a STRUCT so changing the TEMP area would not upset the ANY pointer.

OR

"something else" that might work just as well. I am familiar with using L ADR1 [p 0.0] etc.

I will probably end up making a small block that does just this one small thing so it doesn't need to be edited.

 

[L D[AR2P#0.0]]

Yes, the "something else" is the way to go, e.g.

 

[dahnuguy]

Sorry, you took it more personally than I tought you would. I apologise. I am hard headed and do it all the time, hit few times on the wall before im trough with it

None the less, you cant do struct that acts like any, I said that in Post #2. Rest was trying to explain why, Kalle started that in post #3.

I wasn't terribly upset, just confused. So I explained more.

I assume everyone is trying help in their own way most of the time.

Thanks for the feedback.

This is one of those times S7 bugs me, so much is documented and is so vague or even wrong, I often wonder what to believe. So I have to try anyway to find out. You can do so much with S7 that isn't documented, it is difficult to know where the limits are. With other PLCs the limits are clear and well defined.

S7 5.5 has SCL included in the basic package, that is new. And it is compatible with Win7.

Maybe I can upgrade to 5.5 or use the trial install to play with SCL.

 

[dahnuguy]

Yes, the "something else" is the way to go, e.g.

this what I have been using INTs input to BLKMOV

 

[L D[AR2P#0.0]]

I wanted to go one step further by isolating the ANY inside a STRUCT so changing the TEMP area would not upset the ANY pointer.

Having re-read this post, I have now realised that you have been accessing local data by referencing the absolute address. If you declare the any pointer as the first variable in the temp area, you can fill it in using LW0 etc. but if someone then adds an entry prior to the any the code is toast.

Do not refer to local data data by it's absolute address, use an address register instead. That way if more entries are added, the address register will still point to the correct address in temp.

 

[dahnuguy]

Having re-read this post, I have now realised that you have been accessing local data by referencing the absolute address. If you declare the any pointer as the first variable in the temp area, you can fill it in using LW0 etc. but if someone then adds an entry prior to the any the code is toast.

Do not refer to local data data by it's absolute address, use an address register instead. That way if more entries are added, the address register will still point to the correct address in temp.

yeah that was the whole idea.

I don't have any issues with direct addressing the TEMP area.

Especially in a small dedicated FC.

Thanks again.

 

[Manglemender]

yeah that was the whole idea.

I don't have any issues with direct addressing the TEMP area.

Especially in a small dedicated FC.

Thanks again.

Listen carefully to what LD says, his advice is always good. Avoid addressing anything absolutely if at all posible and especially avoid addressing temp data absolutely; you will only regret it some time in the future and cause yourself more headaches.

My current project has 60 drives on profibus and 58 remote operator stations on profinet, if I referred to everything absolutely, I'd still be writing code at Christmas and it would be full of bugs.

Nick

 

[dahnuguy]

Listen carefully to what LD says, his advice is always good. Avoid addressing anything absolutely if at all posible and especially avoid addressing temp data absolutely; you will only regret it some time in the future and cause yourself more headaches.

My current project has 60 drives on profibus and 58 remote operator stations on profinet, if I referred to everything absolutely, I'd still be writing code at Christmas and it would be full of bugs.

Nick

Nick, I appreciate your concern, however..........

If I avoided addressing anything absolutely,as you suggest, I would never be able to increment an address mathmatically at runtime.

What is "RED" + 5 seconds?

Is "Sensor Number Three" greater than 12?

I am glad it works for you, but there are situations where symbolic addressing fails.

Quick, give me 12 variables in STAT and name them all with symbols before you write the program in the FB. Or I can just name the stuff that needs naming, and leave everything else as STAT_N.....

I know I could spend 2 hours giving everything I do a name and make sure they are all unique......but that's not always necessary or desirable. frequnetly, MW24 is enough. "I need to drop this array of bools into a memory location and put it through a word compare, what word is available? MW24......done".but whats the name?????? who cares, next.

Not everything has or needs to have a symbol of significance.

Now use BLKMOV SFC20 with symbols, now use the same network to move the same area of the next DB, at rubtime, with information from a calculation. Careful the symbols might be different. Now you need that "symbol math" block. Machine is in state 3, move DB3.DBX0.0 byte 20 to DB5.DBX20.0 byte 20........next time it might be state 6 goes to DB12, or even some condition changes the area from DBX20 to 40.

Don't get hung up on any one way to do things.

Some people think everything should be a symbol and you shouldn't even use the marker memory to avoid data type errors.

Do you use marker memory? Be careful, it might cause a conflict of data type.

S7 is full of exceptions and gotchas. I am just trying to make it work. If the simple way is to direct address something and it works, then so be it.

If it is better or simpler to use a db for memory areas, then I do that. If symbols are better, I do that. If a state machine is better for some process, I use one. If not, then event driven, or some other method.

Be flexible, and study the pros and cons of each method.

That was what this thread was about, if you read my first post......I see several ways to do this thing, I am exploring a possible new way, and in the process learning more about the environment I am using. Wether it works or not, it is a learning experience.

And never always do anything.

 

[TurpoUrpo]

So, why not use stl when it is needed and scl when its better. Or Graph7 when that is superior for task at hand.

You can use symbols and then pointers, that will give more readable result than absolute addresses. SCL would ease many of your programs. It makes blkmove and such block calls itself, you need only to write somthing along the lines:

BatchData := RecipeNumber[1];

Easy, fast, readable as hell. Compared to same done in ladder.

 

[Manglemender]

I appear to have caused offence, for which, I am sorry; that was not my intent. I meerly wished to offer advice, you can of course ignore it. Perhaps you took my meaning too literally.

Ultimately, you always need to reference a real address at some point but the point I was trying to convey was that of code re-useability. Considder having 10 drives all the same, if you hard code everything you end up with 10 FCs but you could have only one FC called 10 times and pass it a UDT. This might seem like a lot of trouble and just as much work as writing 10 FCs but when you want to change how the drive is controlled then you only have to change it once and not ten times.

It's always "horses for courses" and there is almost always more than one way of doing something.

and for the record yes I often use sfc20 with dynamically generated anypointers for the source and destination.

I'm always open to new ideas but I've also fallen down a few holes in my time.

Nick

 

[PeterW]

I've often used TEMP areas to hold ANY pointers for block transfers etc.

For example:

temp parameter DESTINATION type ANY.

In the code I would use

LAR1 P##DESTINATION

and then fill the pointer data with code like

L W#1002
T W[AR1, P#0.0]
L W#2
T W[AR1, P#2.0]

etc.

Therefore if anyone tinkles with the temp area in the future,. I know my ANY data will remain correct.

As mentioned above, should never access L data areas directly as you never know who may modify the code afterwards.

 

[dahnuguy]

So, why not use stl when it is needed and scl when its better. Or Graph7 when that is superior for task at hand.

You can use symbols and then pointers, that will give more readable result than absolute addresses. SCL would ease many of your programs. It makes blkmove and such block calls itself, you need only to write somthing along the lines:

BatchData := RecipeNumber[1];

Easy, fast, readable as hell. Compared to same done in ladder.

The spec says use LADer most of the time. I use STL when I MUST due to limitations in S7 LADder being incomplete.

I would love to use SCL instead of STL, but previous employers purchased the basic package without SCL. Soon I will upgrade to 5.5 which has SIM and SCL in the basic package.

I do use GRAPH for state machine sections, as it is included in the spec. My customers do not like STL, and I agree that it is difficult to use online for troubleshooting, but I do not wish to debate that issue. STL is not intuitive , people who have never seen LADder, can still see what is happening in most rungs. Even my 11 year old.

I look forward to using SCL, even if it is only inside my FCs mixed with LADder. It looks like fun.