IO Comms On Profinet

Secret

Member
Join Date
Aug 2005
Location
Beds
Posts
55
Hi all,

I am trying to get my head round Profinet comms.
I need to communicate with a Robot that has a profinet card fitted.
The card is set to 32bytes in and out. IP address and name are set.
Using an S7 313C with a CP-343-1. The node is set on the profinet network in the hardware config and the CP-343 is 'seeing' the node. When the remote card is powered down the 343 -1 goes into fault and when the remote card is powered up the fault goes off.

The bit I'm struggleing with is getting the data, from looking through various manuals I believe I need to use PNIO_SEND and RECV.

What is the CPLADDR refering to?
I attach the hardware config of the rack, node and the PNIO_SEND and RECV rung.

Currently I have put 190 in the CPLADDR as it's hex for 400 which is the I/O start address of the module???

Thanks for reading, any pointers gratefully received.... :)

SS_01.jpg

SS_02.jpg

SS_03.jpg
 
It's the start address of the module as seen by the CPU. Your screen shot shows it as 368
Click on the PNIO blocks and press F1 to see the help provided.
 
Hi, thanks.

I looked through the help files and managed to fathom most of it. So it is the start address of the CP343-1 rather than the remote module itself?

Here's my next stupid question then....

In the CP343-1 config it says the I/O area is 16 bytes long (fixed value), therefore I assumed it was data reserved for info from the card - status etc. I assume more than 16 bytes of remote I/O or inverters etc can be gathered through the profinet....

I have used a CP343-1 before but for cpu to cpu messaging so this is new ground for me.

Thanks for the info so far....
 
Last edited:
Morning all.

Any advance on the question above re. data size. Also if you have 2 remote I/O units how does the addressing reflect this?

Cheers
 
When you double click on the remote Node in your hardware config, usually one of the tabs will allow you to configure the words that you want to send/receive from that module (or at least it did before).

Also, W#16#190 is 190 in hexadecimal or 400 in decimal. To match your card, you should have W#16#170 instead I think.

You configure the data size on the remote node itself. Can you post what it looks like when you double click your remote node? I remember there was another way of doing this (potentially from the card itself).
 
CPLADDR must be set to the IO addresses that the cp343-1 itself is set to.
So 368 decimal becomes 170 hexadecimal (so CPLADDR=W#16#170). Not W#16#190 !

The SEND and RECEIVE pins must be set to data block areas that covers the entire IO image that is setup on the module.
Since it starts from Byte 0, and goes to byte 431, the area must be 432 bytes in size, not the 32 bytes in the screenshot above.
Alternatively (and more sensible) change the addresses for the robot to start from byte 0 instead of from byte 400.
 
......

Also, W#16#190 is 190 in hexadecimal or 400 in decimal. To match your card, you should have W#16#170 instead I think.

You configure the data size on the remote node itself. Can you post what it looks like when you double click your remote node? I remember there was another way of doing this (potentially from the card itself).

Hi, thanks.
I did 190 hex as I assumed (wrongly) I was pointing at IW400 which is what the remote node is set up to write to (second pic) the node is set for 32bytes in and out 400 to 431.
 
CPLADDR must be set to the IO addresses that the cp343-1 itself is set to.
So 368 decimal becomes 170 hexadecimal (so CPLADDR=W#16#170). Not W#16#190 !

The SEND and RECEIVE pins must be set to data block areas that covers the entire IO image that is setup on the module.
Since it starts from Byte 0, and goes to byte 431, the area must be 432 bytes in size, not the 32 bytes in the screenshot above.
Alternatively (and more sensible) change the addresses for the robot to start from byte 0 instead of from byte 400.

Morning and thanks.

As above for the 170 vs 190 value.

OK so that irons out how you address the next remote module, the next 32 bytes up.
However I'm still confused why the CP343-1 card is fixed at 16 bytes in the hardware config. Does it reserve the first 16bytes for status or anything?

SS_04.jpg

Cheers
 
Last edited:
Here's a stupid suggestion, have you tried accessing MIW400/MQW400 directly?

If that works you may get away with a block write instead of the PN IO functions.
 
Here's a stupid suggestion, have you tried accessing MIW400/MQW400 directly?

If that works you may get away with a block write instead of the PN IO functions.

Hi whats a MIW/MQW?

I started off looking at IW400-431 as I assumed it would work in the same way as PROFIBUS I thought nothing could be so difficult as what this has turned out to be but hey ho thats Siemens for you.....
 
The 16 bytes of address are used by the CPU to control the CP343 and check status of the CP343. The PNIO_SEND and PNIO_RECEIVE blocks read/write to his area.

The IO address space for the Profinet IO connected to the CP343 cannot be directly accessed by the CPU. PNIO_SEND/RECEIVE copy data to/from data blocks in the CPU to/from the CP343's I/O addresses.

In the h/w config right click on the CP343 and find the manual - there is an example in there.
 

Similar Topics

Any insight greatly appreciated. I need to communicate to a slave device (non Siemens) with a siemens plc with profinet and profibus DP-V1 for...
Replies
4
Views
3,732
I am looking to monitor Profinet communications to some drives from a Siemens S7 1200 plc. By monitoring I mean detection of the drives on the bus...
Replies
0
Views
4,155
I'm trying to communicate between an S7-319 and a Sick CLV650 Profinet scanner. The scanner is setup and scanning ok and gets an IP from the PLC...
Replies
0
Views
1,547
Hi Can anyone help with this standard problem. I have a 315 2PN/DP CPU, the Profinet is to be connected to a PC which will send the CPU a...
Replies
2
Views
1,611
Has anyone setup communications with Red Lion 3.0 MODBUS to Baker Hughes Centrilift GCS VFD? Thanks
Replies
0
Views
70
Back
Top Bottom