I have a strange problem with one of my libraries. Including the library in an application causes visualizations to stop working. This happen even if the library is only included in the library manager, and none of the function blocks are actually used in the program. I get a message "The online visualization is waiting for a connection. Please start the application", and applies to web visualizations as well. I can see by monitoring the cycle times in VISU_TASK that it's not actually doing anything (33uS cycle time), though it does show a status of "Valid, Active"
The rest of the program runs without any issues. I included checks_in_libs in the compile options, and have set breakpoints in all the implicit checks. There are no out of bounds issues, or bad pointers.
I can get this to consistently occur by simple adding or removing the library from the library manager. One other thing happens whenever the library is included. The program downloads and runs. I remove the library from library manager, perform a "Clean All", and try to download the new program, without the library. Every time, I'll get a message: "No connection to the device. Please rescan your network." The application in the PLC is then deleted, the PLC restarts, and then I can then download as normal.
There's nothing wrong with any of the code in the libraries. If I copy the function blocks and visualizations from the library directly into my project, I can use them without any issues. I thought maybe I could pinpoint which object was causing the problem by deleting them one by one in the library, but this doesn't solve the problem. If I delete everything from the library and include it as an empty library, the visualization works.

Questions:
1. If I include a library in the library manager, but don't actually use any of the objects in it, should it have any effect on the program? I have to do a "Clean All" in order to download after making changes to the library, because the compiler seems to recognize that I haven't actually made any changes to the program by changing a library that's not used anywhere. But it makes a difference on the visualization for some reason.
2. Is there any way to further troubleshoot why a visualization won't start? The log file doesn't contain anything useful, though sometimes I get "LOGGING BUFFER OVERFLOW; LOG MESSAGES DISMISSED"
I'm using Schneider Machine Expert 1.2.4 (Codesys 3.5.12.80), with an M241 controller

thanks

Hey,

1. Yes it can definitly affect the program, e.g. the namespace resolutions may change depending on the lib you add (or the libs you add by adding your lib).
2. Is there no exception in the plc log visible? If not, I would ask you to send this issue to the schneider support.

Best regards,
Marcel

I finally have some error messages in the log. I'll get "Allocating a new chunk of memory (60000 bytes) for the dynamic texts failed" over 300 times in the log after a download/start. References component CmpDynamicText. I can't find any information on this error, does anyone know what it means?

Looks like your plc runs out of memory.
Otherwise there is no good reason that allocating dynamic memory fails.

Best regards,
Marcel

I'm not sure if that makes sense. I've played around with the size of memory for visu in the Visualization Manager, increasing it all the way to 3 MB, and I can see the Device Memory Info reflect that (attached), but I get the same error, that it can't allocate 60KB. Or is there another memory area that being referenced here?

The size in the visu manager is no longer relevant (it will only provide the initial size required for the visualization).
If this memory is not sufficient, it will allocate more memory dynamically.

It also does not affect the component CmpDynamicText.

I don't know if the Device Memory Info includes dynamic memory, you may have to ask the OEM for that.

Best regards,
Marcel

OK, thanks for the information, it has helped me to narrow down the problem.
I had a library with quite a few enumerations, all of which had text list support. If I remove the text list support from some of them, things start to work. Then I added another library, and it stopped working again, until I removed more text list support. Maybe I was hitting the limit of available memory for text lists, which is why sometimes one library would appear to be causing the issue, another times, a different library--there's nothing wrong with the individual libraries, but adding them together required too much memory.
That does raise another question. If I go to /usr/Visu on the controller, I can see a .txt file for each text list. Are they all loaded into memory on bootup?
Another thing I've noticed is that the lists exist multiple times in the file system. So, for example, there's a file called library1.list1.txt, then there's another file called library2.library1.list1.txt, which is the same list, but library 2 contains library 1. Could this be why there's so much memory used?

Hey,
yes there are loaded into memory on startup.
There can be multiple textlists with the same name, since the lib may be included in different versions resulting in the possibility that some ids may be removed/added or their translation changed.
To ensure that the user of the textlist does not run into problems, every textlist/lib version combination will be downloaded and loaded.

Best regards,
Marcel

One further question comes up. I've been removing the text list support from the enumerations and creating separate text lists. This seems to be working better. Is there a difference between the two methods as far as memory use and allocation?

That depends where you create the textlists.
If you add the textlist in the same lib the enumeration is, I would expect no difference.
But if there is only one textlist (e.g. in the application level), there will be a difference.

Best regards,
Marcel