Open oOICEMANOo opened 6 months ago
This is an interesting one. Slots up to 15 (0-15) are handled with a single byte in the constructed path byte string. A value of 16 and up (not sure to what actual value) indicates a port. So for instance, when bridging through a network module the leading byte before the IP address would be either 18 or 19 (decimal) indicating that the address is a port, and then the value above 16 is the actual port number. Port 2 (byte value 18) would be the first external Ethernet port on an ENBT for instance.
Hmm, I see that I am checking for out of bounds values...
/* was the numeric segment valid? */
if(val < 0 || val > 0x0F) {
pdebug(DEBUG_WARN, "Numeric segment in path at position %d is out of bounds!", (int)(ssize_t)(*path_index));
return PLCTAG_ERR_OUT_OF_BOUNDS;
}
That check may not be correct, but it will require some tricks to make sure that parsing the path string works correctly if that is not done.
I don't have a chassis with that many slots. Let me see what I can code up.
I am calling this a bug since real hardware apparently can have 17 slots!
Oops, just realize that this in in the .NET project. I need to move it to the core library.
Moved the comments over to issue #443 in the core project.
Will update here when I have a version of the core project in which this is fixed.
Thanks for you help! I appreciate your time getting this worked out. Let me know if there's anything I can assist with.
Hi @oOICEMANOo - some changes have been made to the core library which will probably have resolved this issue. This is available in the versions of libplctag.NET that have been published today.
This isn't fixed yet. It depends on 462.
The setup I'm working with is not ideal and has the ENBT in slot 15 and a 1756-L62 in slot 16, I've tried a few different path settings thinking 1,16 should work but gives a bad gateway error. is it possible to connect using the higher slots.