Problem connecting to Control Logix Processor - exception error during init_tags

[au-amck]

Hi,
Only recent user of pycomm3 and congratulations on a great project. I have an issue recently where a PLC connection and tag reading that was working started to fail. No program changes to the python script but some PLC changes made to the processor.
The script was failing with an exception error during connection to the processor with init_tags=True. It was also causing issues connecting to the processor with programming software so it is an supplier issue, however the PLC program was still running and working as normal. The exception error showed the instance_id that caused the problem but that didn't help identify the tag. The exception was around an invalid/undefined type.

In fact the driver reported:
(send_unit_data returned not valid data', 'Destination unknown, class unsupported, instance undefined or structure element undefined (see extended status) - Extended status out of memory (05, 00)'

pycomm3.exceptions.ResponseError: failed isolating user tags

I temporarily modified the driver code to display the tag name during init_tags() and identified the tag name that was causing the problem. I was able to remove the tag from the PLC and everything was working properly again. Tag reading and PLC programming software connecting. I re-created the tag and logic and everything continues to work.

What I thought would be that if a tag is going to fail, that it should be detected and alarmed but allow the init_tags() to continue so the connection can complete. As it turns out the tag that caused the failure was not one of the ones that I was reading so the script could have kept running. An alert on the bad tag would have made it much quicker to identify the problem. An export from the programming software was also failing due to the same problem but the error was CIP Error with no additional information.

Andrew

[ottowayi]

It sounds like something got corrupted or messed up when that tag was created, if you have a backup copy of the program I would be curious to see what happened. Have you enabled logging? Sending logs in this case would be really helpful, the verbose option shows the actual packet contents and would show us what's wrong.

I would like to eventually skip errors/tags in the tag upload, but last time I looked into it I remember it being much more complicated and decided to hold off. Those tag definitions are used extensively, it's how the structured support, request size tracking, and other features are built upon. I'm currently refactoring the CIP and EIP implementations inside the library to make them more generic/in line with the spec, instead of being mostly based around the Rockwell-specific services. After that work is done, I plan to look into this and couple other improvements.

[au-amck]

Due to the sequence of events between Christmas a New Year it is a bit hard to isolate the exact cause. Unfortunately I wasn't running verbose logging at the time. I do still have the last lot of exception errors when the program failed which I've included below.

_Traceback (most recent call last):
File "C:\Pythonenvs\logix\lib\site-packages\pycomm3\logix_driver.py", line 920, in _get_data_type
template = self._get_structure_makeup(
File "C:\Pythonenvs\logix\lib\site-packages\pycomm3\logix_driver.py", line 733, in _get_structure_makeup
raise ResponseError(
pycomm3.exceptions.ResponseError: ('send_unit_data returned not valid data', 'Destination unknown, class unsupported, instance undefined or structure element undefined (see extended status) - Extended status out of memory (05, 00)')

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "C:\Pythonenvs\logix\lib\site-packages\pycomm3\logix_driver.py", line 648, in _isolate_user_tags
user_tags.append(self._create_tag(name, tag))
File "C:\Pythonenvs\logix\lib\site-packages\pycomm3\logix_driver.py", line 678, in _create_tag
new_tag["data_type"] = self._get_data_type(template_instance_id)
File "C:\Pythonenvs\logix\lib\site-packages\pycomm3\logix_driver.py", line 934, in _get_data_type
raise ResponseError(
pycomm3.exceptions.ResponseError: Failed to get data type information for 358

The above exception was the direct cause of the following exception:_

_Traceback (most recent call last):
File "chippercurrent.py", line 29, in
Residues2PLC.open()
File "C:\Pythonenvs\logix\lib\site-packages\pycomm3\logix_driver.py", line 164, in open
self._initialize_driver(**self._init_args)
File "C:\Pythonenvs\logix\lib\site-packages\pycomm3\logix_driver.py", line 193, in _initialize_driver
self.get_tag_list(program="*" if init_program_tags else None)
File "C:\Pythonenvs\logix\lib\site-packages\pycomm3\cip_driver.py", line 81, in wrapped
return func(self, *args, **kwargs)
File "C:\Pythonenvs\logix\lib\site-packages\pycomm3\logix_driver.py", line 433, in get_tag_list
tags = self._get_tag_list()
File "C:\Pythonenvs\logix\lib\site-packages\pycomm3\logix_driver.py", line 451, in _get_tag_list
return self._isolate_user_tags(all_tags, program)
File "C:\Pythonenvs\logix\lib\site-packages\pycomm3\logix_driver.py", line 653, in isolate_user_tags
raise ResponseError("failed isolating user tags") from err
pycomm3.exceptions.ResponseError: failed isolating user tags

I don't have a copy of the program that failed. If I see the problem again I'll get a verbose log and a copy of the failed program to you.
Appreciate the response.

[ottowayi]

That does give us a hint as to what happened. Failed to get data type information for 358 (in hex, 0x166) tells us that a tag said it had a data type of 0x166, but when we requested information on it we get the Destination unknown.. error meaning that it doesn't exist. My guess is something inside the program that manages the data types got corrupted. It was probably a UDT or AOI since the user-define type range is 0x100-0xEFF. I remember running into a similar issue with an AOI and Logix couldn't handle it either, it would crash if you tried to export it to an L5X. I think doing File > Compact in Logix fixed it by forcing it to recompile then entire program, rather than just the changes.

[au-amck]

It was an AOI tag. I'll check the File>Compact should I have the issue again. I wasn't sure if the 358 was the type or the instance number. Didn't have verbose turned on which may have helped.