S7-Comm Using SFB14 GET, What is bugging me ??

I have created a test project in purpose to develop a FB for handling communication between some CPU's.

1 CPU, will read out info from 1 DB from 6 other CPU's.

In my test project i only use 2 CPU, but instead i poll the comm partner 6 times.

I have discovered a BUG which i can't explain nor fix. Therefor i hope for you guys to help me out.

I Use a DB (DB20) where i have put the ID's for the comm partner CPU's. Because i only have 1 other CPU to communicate with, this DB has W#16#1 as ID for each PLC.

When i force communication error by changing ID for one of the rows in DB20. I have noticed that my FB100 fails to read the data from that CPU (OFCOURCE) but the BUG is, it also always misses to read out for the consecutive CPU, regardless of what ID i change in my DB20 connection table.

Is this my Code, or is it some mechanism inside SFB14 that causes this problem.... ?

I attach the project, which is mixed FDB and STL. Swedish Comments (SORRY) but i think you skilled people will figure out how it is intended to work.


My Archive was 409Kb to big for the forum so my project can be found here:

http://dc204.4shared.com/download/220390930/174ef778/S7-komm.zip?tsid=20100212-043249-5fe53e0

Or if it does not work please try this link

http://www.4shared.com/file/220390930/174ef778/S7-komm.html

Best Regards
Pethoek

You have locked FB14 where I guess you have packed the calls to the 6 PLCs. So I cannot see exactly what goes on.
I'll take a guess, and say that the problem is related to that the previous GET job isnt finished before the next is started. Normally you dont see the problem because a succesful GET finished quickly, whereas any problem will take longer.
You should get a good idea of what goes wrong if you look at the STATUS value from each GET call.

As you can se, the last network saves the last error for each PLC. The Status Code is 1, which is completely normal for Wrong ID.

Isn't the previous JOB finished when either NDR or ERROR flag outpus 1 ??

In Network 1, a new request can be triggered only when i got ERROR or NDR from previous attempt. OR, the the zero part of the clock memory bit, resets the "flip-flop". I have tried longer intervals between calls, but with no progress.

I cannot follow your logic, especially since I cannot see inside FB14.
Rather than assume that your bits work as you think, observe them in a VAT when the program is running. In that way you can see if a REQ goes high before NDR does. Is the new (correct) connection ID loaded before REQ is initiated.

Something goes on in networks 1-2 that I cannot follow.

If you cannot pinpoint the problem immediately, then try something simple.
Ditch all your present code.
Make 2 normal GET calls.
Make a simple condition that REQ for the 2nd GET call cannot be set before you get NDR or ERROR from the 1st GET call.
If you can get that to work, then you know it can be done in principle, and you can start to make your code more modular if that is your intention with FB100 and FB14.
If you cannot get it to work in the simple way, then maybe you have indeed found a bug with GET. Then it is only Siemens that can help.

JesperMP said:

I cannot follow your logic, especially since I cannot see inside FB14.

Click to expand...

SFB14 is a Siemens Block and therefor you can't se inside it.

All i can say, been there done that. Code works fine, Already tried the simple way, this is the modular way rendered from my simpler tries. Code works 100% when all 6 ID's in DB20 are set to W#16#1. This implies that REQ and all calculations of pointers and so on will be done correctly and in the precise order neccessary.

I just can't see what can go wrong.

NW 1, is just a flip-flop for setting the REQ flag. This is handled correctly and works 100%.

NW 2, is a modular counter, 0,1,2,3,4,5,0,1,2.... Which keep track of which partner PLC to apply GET on. Also this value is used to calculate the destination pointer for DB to store the result in.

Oh, I missed that it was from the sandard library because it didnt have a symbolic name.

Did you try the simple way with the ID=2 for the 1st call and ID=1 for the 2nd call ?
Oh, and just to eliminate that the problem may be with the IDBs, make individual IDBs for each call.

For future reference, copy your blocks to a library and archive the library, the zip file will be much smaller. e.g.

L D[AR2 said:

For future reference, copy your blocks to a library and archive the library, the zip file will be much smaller. e.g.

Click to expand...

Thanks, i will remember that. Any idéas on the problem ?

JesperMP said:

Oh, I missed that it was from the sandard library because it didnt have a symbolic name.

Did you try the simple way with the ID=2 for the 1st call and ID=1 for the 2nd call ?
Oh, and just to eliminate that the problem may be with the IDBs, make individual IDBs for each call.

Click to expand...

Well, to be honest, i haven't exactly tried it that way. Maybe that will lead to another result, but still, i have hard to really see what should be different.

I relly don't have the time to try this out today, so this will be something for the next week if no solution is posted here before that.

Have also invoked Siemens support so they will have something to do

Thanks so far for your efforts.

That it worked OK with the ID=1 for all calls is irrelevant.
We know that it works OK with your "advanced" code with ID=1.
You have to test the simple code with ID=2 and ID=1.

edit: If you cant take 5 minutes to do this test, then why do you think that people will voluntarily pore over your code, while offline when it is very difficult to guess what will happen during runtime ?

JesperMP said:

If you cant take 5 minutes to do this test, then why do you think that people will voluntarily pore over your code, while offline when it is very difficult to guess what will happen during runtime ?

Click to expand...

Will give it 5 minutes, just not right now, today pronto. Because, i have other things to attend to. Will try this next week.

And i think you got the problem wrong. It would work for ID=2, ID=3 ID=anything (within applicable range) it's just that, when i force a comm err, the next consecutive execution of GET which would read out next PLC is failing as well. The second next is working fine again.

The result is like this. Lets say my DB20 is like

PLC_ID_1 = 1
PLC_ID_2 = 1
PLC_ID_3 = 2
PLC_ID_4 = 1
PLC_ID_5 = 1
PLC_ID_6 = 1

Then i will receive an error when reading PLC_ID_3 because the ID is 2, and there is no connection with that ID in NetPro. OK.

The result when watching the destination DB Would look like the below table. This is a simplified table which only illustrates that PLC_3 and _4 will not be read correct. Should only be PLC_3.

PLC_1_DTA = 10
PLC_2_DTA = 10
PLC_3_DTA = 0
PLC_4_DTA = 0
PLC_5_DTA = 10
PLC_6_DTA = 10


And yes now you got me if i had time to write this, i would also have the time to test the simple solution but, again, now i have spent even more time, so have less time left for the other.

It's not like i post here in order for you guys to solve my problem. I have already spent 4 hours today of testing different methods of figuring iut the problem. But have not find a way yet.

Sometimes i'ts just that when other people look at your work they might see something that my eyes don't.

I'm very greatful for your time you put in here to help out.

No I think I understand what you wrote originally.
It is not impossible that you have found a bug, only unlikely.

To me it is basic troubleshooting, to try and narrow down the possible sources of the error. So if you can eliminate either that it is a bug in the S7 CPU, or it is an error in your own code, then you have saved looking for the error in the wrong place.

Siemens support replied, They said, their communication blocks usually don't like when parameters are changed while EN is enabled. They suggested that i should set EN = False when NDR or ERROR is received. Then change the ID, pointers, etc. and enable the EN again. That should do it.

I felt that it had to do something with FB14 (GET) i could really not see any problem with my code actually. The execution of my code is linear as if i would use two instances of FB14 to try out the simple way stated here earlier.

But perhaps use of two instances would work, cause they also would use two different memory locations for it's instance data. But, as This seem to be a known issue, i will first try out their suggestion, and if that does not work, i'll go for the "simple way" and do some trial and error.

When I made a PUT/GET- communication "a hundred years ago", I can remember that I had to add a time delay between the requests. Else the exchange would fail and no data was transfered.
(It was an ethernet connection between a 416-2+443-1 and 315PNDP.)

Regards
K

Siemens help files say for some of the blocks inside FB14 that they need enable disabled -> change parameters ->enable enable. So it might be more of a bug that it actually works when you have not resetted the enable between param changes.