1765 PLC - Get IP Address

[dalporto]

Edit: title is wrong: 1756. Sorry.




Hello.


Is there a way or an instruction to retrieve the CPU IP Address from the program (and assign each part to an INT)? Not sure if I'm clear: I want the PLC to read its own IP address.



I found it can be done for an onboard Ethernet Module, but is it possible to get the CPU address?


With Schneider it's quite easy, but with Rockwell I'm not even sure this can be done.


Thanks.

 

[5618]

I presume you're using 1756-L8x with an on-board port.

MSG, CIP Generic, Get Attribute Single, Instance 1, Class f5, Attribute 5, Communication Path THIS.

For destination, make a UDT like this or other names to your liking:
IPAddress SINT[4]
Subnet SINT[4]
Gateway SINT[4]
DNS1 SINT[4]
DNS2 SINT[4]
Domain SINT[50]

Here's my AOI code to turn the octets into a string for HMI display.

DestString.Len := 0;

for i := 3 to 0 by -1 do

[INDENT]// Octet to string and append
temp := Source[i] & 255;
DTOS (temp, tempString);
CONCAT (DestString, tempString, DestString);

// Dot
if i > 0 then
[INDENT]DestString.DATA[DestString.LEN] := 46;
DestString.LEN := DestString.LEN + 1;
[/INDENT]end_if;

[/INDENT]end_for;

Source is InOut SINT[4]
DestString is InOut STRING16
(These are part of a larger UDT)

i & temp are local DINT
tempString is local STRING16

STRING16 is a custom 16 length string defined in Data Types - Strings
The default 82 length string would probably work fine too

 

[dalporto]

Thank you very much.


I'm waiting for the L82 this week, I'll let you know how it went.

 

[dalporto]

Here's my AOI code to turn the octets into a string for HMI display.

I have 4 units that are 95-98% similar.


I use that with Schneider to I can deal with the differences.


If IP = 100 then I_AM_U1
If IP = 110 then I_AM_U2
etc.


That way I only have a master program that I can only change IP address and dump it 4 times and the PLC take care of the differences.

 

[dalporto]

I presume you're using 1756-L8x with an on-board port.

MSG, CIP Generic, Get Attribute Single, Instance 1, Class f5, Attribute 5, Communication Path THIS.

For destination, make a UDT like this or other names to your liking:
IPAddress SINT[4]
Subnet SINT[4]
Gateway SINT[4]
DNS1 SINT[4]
DNS2 SINT[4]
Domain SINT[50]

I'm halfway there. Any idea? Should be 172.24.1.100 / 255.255.0.0 / 172.24.0.1.


Looks like a kind of offset missing.

 

[dalporto]

Oh. They are backward.


But still.

 

[5618]

The SINT data type is a signed data type, so with the MSB set it displays as negative the other bits. If you COP, BTD, or otherwise bit transfer to a USINT or something with more bits, you'll see 192, 255, or anything else over 127 as the correct value, not negative something. Maybe USINT arrays would work, never tried it. I usually just turn them into strings from there.

 

[dalporto]

I confirm it works.


Thank you very much sir!

 

[5618]

Cool. Since a string is made of mostly SINTs, I think it would be more correct to leave domain as SINT and the rest feel fine as USINT. I probably got the MSG parameters and UDT structure from the Rockwell Knowledgebase.

I don't use DNS or domain, so... what if they were eliminated from the UDT? Would the MSG just stop filling data without error when the destination ends? Would it keep writing to whatever was next in memory? Dunno, and probably won't try it.

 

[JeremyM]

Cool. Since a string is made of mostly SINTs, I think it would be more correct to leave domain as SINT and the rest feel fine as USINT. I probably got the MSG parameters and UDT structure from the Rockwell Knowledgebase.

I don't use DNS or domain, so... what if they were eliminated from the UDT? Would the MSG just stop filling data without error when the destination ends? Would it keep writing to whatever was next in memory? Dunno, and probably won't try it.

The message will fail if the destination is too small. However, the destination array can be COP’d to a smaller UDT without issue, provided the data/fields are aligned.

 

[plvlce]

I don't use DNS or domain, so... what if they were eliminated from the UDT? Would the MSG just stop filling data without error when the destination ends? Would it keep writing to whatever was next in memory? Dunno, and probably won't try it.

I believe the MSG instruction will error if the destination size does not match what it expects, cf this thread.