Siemens Comms error

Hi,

I have been asked to add a few points to an existing comms block between two Siemens PLC through profibus. I thought I had done it like I have done before although when I checked the other end the figures do not tally nor do they change. I am presuming I have done something extremely daft but I can't spot it and have been pulling my hair out all afternoon going around in circles.

I have attached the line of code for the block and both PLC parts of the data block to show exactly what is going on to see if anyone has any thoughts.

Thank you in anticipation

Dave

Values on both ends are 0?
Did you check connection is up?
Are you enabling the REQ?

Hi Boneless, thank you for your reply.

The value for the Integer at the send end (PLC_1) is 1 whereas on Receive end (PLC_2) the value is 360 and then the real values being sent are 100,50 but what is being received is rubbish. The rest of the block works perfect (Some which I have added the other day).

The connection is up with no errors and the REQ is enabled on a sequence pulse. This works perfect as, like I said, the rest of the comms block works fine. I am totally confused as I have done everything that I did the other day when it worked but the last 8 lines of the block won't update. I have been going around in circles all afternoon which is why I thought I would post it on here for some fresh eyes to look and hopefully point out my clumsy mistake.

Dave

Ah sorry, looking at the wrong column .

Are you ever seeing a NDR = 1?

Only thing I can think of is downloading the connection settings once more. Everything looks fine.

I am glad its not only me that can't spot anything wrong. NDR =1 every time it Polls for the comms block and the 56 bits before the ones that are causing me trouble update perfectly. I have even thought I could of used all the available memory so I moved the new points further up the Data Block but they still don't tally when the program runs. It maybe a stupid question but the only thing I can think of is that I may need to add extra bits at the end to allow for the real values (Clutching at straws!)

What type of S7 PLC do you have?

With a S7-400, changing the parameters of put/get in Run-mode is not always possible. You can only reduce the number of bytes you want to exchange, but you can't go up. Because there is an internal buffer which is only reserved on CPU startup (warm or cold). If it's possible, try if a warmstart (Stop->Run) helps.

And I would strongly recommend you not to trigger the FB without evaluating the status outputs. Don't trigger the the block again, as long the last hasn't ended with success or with error. It may run many years without problems, but it's not correct.

Hi Thomas,
Thank you for your reply. The PLC are both S7-300 although I will try a warm start in the morning as this seems to be the only thing that I haven't tried. Should I just do the one with the code in or should I do both and if so which order.

I assumed that if I downloaded the FC File to the PLC it would automatically reset any buffers. This train of thought has opened up a new question, the block has an associated Data block (DB605). Do I need to alter anything in there as I have increased the number of bytes in the block or does it do it automatically. Excuse my question if it is a daft one but I have never really understood how comms blocks work and I am on a steep learning curve with this fault.

Dave

I would first try only if a run/stop helps, but I know this behaviour only with a S7-400.
This is also documented for the S7-400 in the Step 7 online help. If you open the F1 help of the put/get block, and then go to common parameters, then you can read this.

If the CPU is fully capable of changing the parameters, you can do this on the fly from you PLC program, you don't need to (must not when block is in usage) reload the DB.
If you have done this, maybe that has caused the problems you actually get. When there was actually job running when you downloaded the DB, then this resets the internal data for the job, maybe the FB is kind of out of sync.

Thank you Thomas, that maybe the answer as the comms block is in use virtually constantly (it is 1 of 8 that cycle every 50ms)

It is nice to know from yourself and Boneless that I do not appear to have done anything silly with my code( I am more used to Maintenance than Programming). I originally thought I may have not calculated my bytes correctly but even after writing it all out longhand I cannot find anything wrong.

The only thing that I haven't been able to do that I usually do after code change is compile the program as it comes back with an error as I am using # in the code and it says it can't check it.

I think the first thing for me to do in the morning is to power down the PLC and start it up again to see if that clears the error, failing that it will be back to scratching my head

Evening all, Just an update on an event filled day.

This morning I attended site and powered both PLC down to see if the fault cured itself when the power was restored, it never. After hours of looking at the comms block and a lot of cursing I decided to revert back to the old working code and see if I could figure it out as I added the new points. When I checked the old working code I noticed in one of the "Old Redundant" blocks that one of the bytes that I had proposed to be used was being written to. A full check showed that in the old code there was a lot of dead ends that used several bytes from the DB that when you opened the DB didn't show up.
After a lot of cursing at what I had found I rewrote the comms block using bytes in the data block that were not allocated anywhere and it all worked fine.
I have never understood why people leave code in when it is not used, and never going to be but the more confusing point for me was that although the bit was used in a FB it wasn't in the relevant DB, surely if you allocate a bit in the PLC it should automatically be written in the Data Block or am I looking at it to simple.

Anyway, Rant over........Thanks for all the help last night.


Dave