pturmel

BTW, this can be simplified to just a single FLL targeting the .LEN element with a constant length of 22 42. {Edit: Whoops!  SLC, not Logix.}

You have to ensure the empty source string stays empty.  Marking it as read-only or a constant is probably sufficient.

At the first level in the Logix controller, a user may use an ANSI Symbol Segment containing a tag name in place of the symbol class and instance that the data access manual describes.  Using the class and instance is recommended for best performance.  When supplying additional path segments for array subscripts (Member segments) or named structure elements (additional ANSI Symbol segments), they are simply concatenated with the first level segment(s) to form a complete application path within the CIP request.  That CIP request must use the documented Logix tag read, write, or modify service codes and payload formats. The data access document I linked is a complicated slog, but I encourage you to read the whole thing if you are going to be doing tag access from a third party stack. Some additional information you may find useful: The Symbol class and Template class in the real Logix products I have in my lab do not implement "Get Attribute Single".  You must use "Get Attribute List" or "Get Instance Attribute List" as shown in that manual. There are undocumented attributes on both classes.  I encourage you to experiment.  I consider attribute #8 on the symbol class to be essential:  reading it yields an array of three UDINTs (as twelve bytes) that supply the array dimensions for the tag, with zeroes for unused subscript levels.  (All zeros if not an array.) Most devices that are intended to be used with implicit connections (I/O adapters) also support "Get Attribute Single" and/or "Set Attribute Single" for assembly buffers.  Attribute #3 of the desired assembly instance.  Reads or writes the entire data buffer.  (Writes to the output assembly will be rejected if an implicit connection owns it.)

Yes, just setting length to zero doesn't rewrite the data bytes, but all logix string instructions honor .LEN and will not use those ignored bytes.  Well-behaved OPC servers will also ignore those bytes.

You can clear just the .LEN element.

Every time I've worked with PointIO parts, with both adapters and processors, I've had to adjust the slot count to exactly match the devices installed. 

When reading from the processor, the I/O data has been brought into tags, so you are using the tag data access.  See this public Rockwell document:   https://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm020_-en-p.pdf   If you were to read directly from the I/O device, you would use parameter instances or assemblies, per the EDS file.

The screen shot shows the L18 is configured for 10 slots.  But there are only three devices. Fix the chassis configuration.

I've never smoked a laptop through an ethernet port.They are already transformer isolated.  (Exception for POE.) I do use USB ethernet occassionally, for complex networks where one connection isn't enough.

There is one possibility: Rockwell lets you use hostnames instead of IP addresses in the I/O tree, as long as your network interface has addresses for DNS servers.  If you change the IP that goes with a given DNS name in your DNS infrastructure, you should be able to indirectly change the runtime target IP address.

Some cheap laptops don't have an ethernet port.  You have to use a USB Ethernet adapter.  I am equally unimpressed with such, no matter how lightweight.

When I first read the question, I though it was about a Logix PLC changing its OWN IP address.  That is possible and fully documented (TCP/IP object class 0xF5, instance attribute #5) in the Ethernet/IP specification. Changing an I/O tree target IP is the part that isn't possible.

If you can limit the number of possible addresses for the 2nd PLC, you might get away with creating all of those instances in the 1st PLC's I/O tree, then programmatically inhibiting the ones you aren't using.  There's an SSV that can do that.

I just noticed you said CIP Safety data was in the link.  I think you are screwed.

Are you using Producer/Consumer tags?  If so, you're officially screwed.  There's no documented way to change the I/O tree programmatically.  I suspect that Rockwell's Systems group can do so, as there is a GSV that yields an instance ID for selected I/O devices.  I've never found the CIP class number and attribute lists that would go with it, unfortunately. If you are using messaging, you are in luck.  The MESSAGE data type that goes with a message instruction contains a binary encoding of the complete connection path.  It claims to be a STRING data type, but really is binary encoded.  IP addresses themselves are ASCII within the binary connection path.  That part can be replaced with string operations.  You'll have to take care to adjust the byte (length) just ahead of the IP address, and pad the ASCII to an even number of bytes (but don't include the pad in the length byte.  If you share your MESSAGE instruction's path "string" content, I can help you decode it for dynamic reconstruction.

Depends on whether space was left for more bools in the Logix tag involved, and whether a User Defined Type was used .  Please share more information.

It is not necessary.  Though it is common to unlatch the .ER bit from separate fault reset logic as a convenience.  The instruction will initialize all of those bits correctly on the rising edge of the rung.  Prescan isn't actually relevant.

Copying and pasting has been working well for me.  You can paste into a text editor if you like.

I've been a business owner for 18 years now.  (Systems Integrator.)  I refuse to compete with my distributors on training.

According to the troubleshooting section of the user manual, the processors DH+ connection is faulted (duplicate note, perhaps) or failed, or the processor itself has failed.  The RS232 light being OFF is the critical difference between blown memory and blown processor.  I recommend your client make a closer search for the backup files. ): https://literature.rockwellautomation.com/idc/groups/literature/documents/um/1747-um011_-en-p.pdf One last hope:  try using the serial port with DH+ disconnected.

Yeah.  That, too.

The zener diode + diode combination on the output will absorb reflected pulses from the opposite end of the cable.  Figuring out the impedance of the cable and terminating the far end is a better solution to such problems.  Unless the transmitter's circuit is too wimpy to carry the load when properly terminated. The following discussion for coax also applies to any kilohertz+ frequency in industrial systems: https://sciencedemonstrations.fas.harvard.edu/presentations/pulse-reflections-coax-cable

Learn ladder logic.  It and structured text share share most functionality, but electricians and technicians who follow behind you will hate you for using structured text. Learn the common patterns for holding single-bit state with a "seal-in" contact.  Prefer those over Latch and Unlatch coils unless you need that state to survive a power cycle.

It can.  In this case the 2500's spanning tree protocol might catch it.  If nothing catches the multipath condition, you will have broadcast storms that crush your bandwidth.

Interesting.  Not documented in the socket programming guide: http://literature.rockwellautomation.com/idc/groups/literature/documents/at/enet-at002_-en-p.pdf What device is at that point in the path (the error path) ?