#6 Error while building project

1.0
closed
nobody
This (1)
2022-08-11
2021-10-06
vcbz
No

I am using the docker image for codesys-ide and I am trying to start with a simple task by building a project. I have created the project in a Windows Machine with Codesys v3.5 SP16.

When I run the docker image with codesys and run the following script:

# encoding:utf-8
from __future__ import print_function
import os
import scriptengine


# opens project
proj = projects.open(r"MyProject.projectarchive", primary = True)
application = proj.active_application #This line causes the error
application.generate_code()
proj.close()

I get the following error:

Error: Running script 'z:/builds/codesys_test/run.py' caused exception System.ArgumentException: Traceback (most recent call last):
File "z:/builds/codesys_test/run.py", line 25, in <module>
ValueError: ScriptObjects need a non-empty Guid! </module>

Attached you will find the Project I created. The project is archived as when I tried to first open the project without archiving the libraries, Codesys complained that it couldnt find the libraries.

In addition I modified the codesys bash file as I need to run my own scripts from a different folder in the docker container:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#!/bin/bash

WINE=wine
set -x

# get first CODESYS profile and start the script with it
profile=$(basename "$(ls -1 ~/.wine.cds/drive_c/CODESYS/CODESYS/Profiles/*.profile* | head -n 1 | sed 's,\.profile.*,,')")

echo ${profile}

# check if file exists, before we call CODESYS with it
if [ ! -f ${1}.py ]; then
echo "error: script '${1}.py' not found."
exit -1
fi

export DISPLAY=:91
Xvfb :91 &> /dev/zero &
sleep 1
export WINEPREFIX=~/.wine.cds
# test that running scripts work
${WINE} ~/.wine.cds/drive_c/CODESYS/CODESYS/Common/CODESYS.exe --culture=en --profile="'"${profile}"'" --runscript="z:${BASEPATH}/noop.py" --noUI 2> /dev/zero
# remove output log
[ -f .codesys.output.txt ] && rm -f .codesys.output.txt
${WINE} ~/.wine.cds/drive_c/CODESYS/CODESYS/Common/CODESYS.exe --culture=en --profile="'"${profile}"'" --runscript="z:${1}.py" --noUI

sleep 1
killall Xvfb
rm -rf /tmp/.X91*

If you have any idea of why this error happens or any suggestion on what could be the reason I would gladly appreciate it.

Thanks in advanced,
Victor

1 Attachments
MyProject.projectarchive

Discussion

  • vcbz - 2021-10-07

    Just an update. I have looked in more detail the output of the CODESYS cli and when I open a .project file (Without archiving) I get also an error.The eror occurs when with the python Script engine API I trying to generate the project (i.e., open(),generate_code())

    Build: Error: C188: Device not installed to the system. No code generation possible.
Build: Text: C0: Typify code...
Build: Warning: C100: Library IoStandard has not been added to the Library Manager, or no valid license could be found
Build: Warning: C100: Library CAA Device Diagnosis has not been added to the Library Manager, or no valid license could be found
Build: Warning: C100: Library Standard has not been added to the Library Manager, or no valid license could be found
Build: Warning: C100: Library CmpLog has not been added to the Library Manager, or no valid license could be found
Build: Warning: C100: Library CAA Types has not been added to the Library Manager, or no valid license could be found
Build: Warning: C100: Library Component Manager has not been added to the Library Manager, or no valid license could be found
Build: Warning: C100: Library CmpApp has not been added to the Library Manager, or no valid license could be found
Build: Warning: C100: Library CmpCodeMeter has not been added to the Library Manager, or no valid license could be found
Build: Warning: C100: Library SysCpuHandling has not been added to the Library Manager, or no valid license could be found
Build: Warning: C100: Library CmpEventMgr has not been added to the Library Manager, or no valid license could be found

    I have to mention that the project is done in a Windows Machine with CODESYS Control Win V3. So should it be possible to develop projects in CODESYS Control Win V3 and use the docker image? I also tried installing manually the Codesys Control Winv3 packages by downloading them from here:

    https://store-archive.codesys.com/ftp_download/3S/ControlWinSL/305021/3.5.16.0/CODESYS%20Control%20Win%203.5.16.0.zip

    Afterward I unzip the file and use the package extension to install both packages (CODESYS Control Win 3.5.16.0.package,CODESYS Control Win 64 3.5.16.0.package) with the following command:

    wine /home/wineuser/.wine.cds/drive_c/CODESYS/CODESYS/Common/PackageManagerCLI.exe --culture=en '--profile='\''CODESYS' V3.5 'SP16'\''' --components=typical --verbose --install=z:/builds/CODESYS_Control_Win_64_3.5.16.0.package

wine /home/wineuser/.wine.cds/drive_c/CODESYS/CODESYS/Common/PackageManagerCLI.exe --culture=en '--profile='\''CODESYS' V3.5 'SP16'\''' --components=typical --verbose --install=z:/builds/CODESYS_Control_Win_3.5.16.0.package

    Altough I am not sure if this should work as I see in the zip an .exe file which is larger than the package extension file itselfs so I dont know If I should install it directly with Wine e.g.

    wine  z:/builds/CODESYS Control Win 3.5.16.0.exe

    In addition I tried installing the libraries that were missing with the use of the helper script:

    https://forge.codesys.com/tol/codesys-4-linux/docker/ci/master/tree/codesys-ide/scripts/helper.py
commit hash: 94f31af52d15457a54b7dd8c78558d8a9ea4cd15

    alas when trying to install them I got the following error:

    *** download https://store.codesys.com/CODESYSLibs/System/IoStandard/3.5.17.0/IoStandard.compiled-library-v3 to C:\users\wineuser\downloads\dl.compiled-library-v3
*** installing https://store.codesys.com/CODESYSLibs/System/IoStandard/3.5.17.0/IoStandard.compiled-library-v3
Error: Running script 'z:/builds/run.py' caused exception _3S.CoDeSys.LibManObject.ManagedLibraryNotVerifiedException: Traceback (most recent call last):
  File "z:/builds/run.py", line 59, in <module>
  File "z:/builds/run.py", line 53, in install_missing_libraries
  File "z:/builds/run.py", line 23, in install_library
StandardError: The library 'C:\users\wineuser\downloads\dl.compiled-library-v3' could not be verified. Its contents do not match the signature.

    So what I did is manually changed the version of the library IOStandard in the script to 3.5.16.0 and the signature error did not happen again.

    Nevertheless the first error described in this comment happened. So at this moment I am not sure if the current docker container supports the use of CODESYS Control WinV3 projects or just CODESYS Control for linux SL. I could try using the linux variant but my end goal is to use CI/CD for student projects at the university and I find it easier for them to install CODESYS natively in Windows.

    I am open to any discussion on how I could use CODESYS Control Win v3 or something I am missing that could help solve this issue

    BR
    Victor

     

  • vcbz - 2021-10-13

    After going down the rabbit hole long enough I have found a temporal solution for my problem.

    Issue Summary:

    I want to compile CODESYS projects for "CODESYS Control Win V3" devices through CI/CD with a docker container from this repo. The problem is that the docker container does not find the references to some libraries even though they are installed.

    How to reproduce the issue:
    1) Create a new CODESYS project (3.5.16.0 x86) in a Windows machine through the project wizard. It is worth mentioning that I did a clean install of CODESYS and used different machines with W7 and W10 to test the reproducibility of the error.
    2) Compile the project file with the docker container as described in the first post.

    Cause of the problem

    As the error was related to the library references I first tried using the script from here:

    https://forge.codesys.com/tol/codesys-4-linux/docker/ci/master/tree/codesys-ide/scripts/helper.py
hash commit: 94f31af52d15457a54b7dd8c78558d8a9ea4cd15

    to install the libraries automatically.

    The output that I logged was:

    *** download https://store.codesys.com/CODESYSLibs/3S - Smart Software Solutions GmbH/Breakpoint Logging Functions/3.5.5.0/BreakpointLoggingFunctions.compiled-library-ge33 to C:\users\wineuser\downloads\dl.compiled-library-ge33
*** installing https://store.codesys.com/CODESYSLibs/3S - Smart Software Solutions GmbH/Breakpoint Logging Functions/3.5.5.0/BreakpointLoggingFunctions.compiled-library-ge33

    This means that the only missing library is the BreakpointLoggingFunctions. But since this library is not used and does not cause the errors I checked what information did the library manager had. I used the following script to print out more information about the libraries:

    def print_lib_info(proj):
    print("------lib info--------")
    objects = proj.get_children(recursive=True)
    for candidate in objects:
        if candidate.is_libman:
            for libref in iter(candidate):
                if libref.is_placeholder:
                    print("placeholder: %s: %s => %s" % (libref.name, libref.default_resolution, libref.effective_resolution))
                    params = libref.parameters
                    for name in params:
                        print("   param: %s => %s" % (name, params[name]))
                elif libref.is_managed:               
                    print("library: %s: %s" % (libref.name, libref.managed_library.version))
                else:               
                    print("library: " + libref.name)
    print("------lib info--------")

    Output from the script:

    ------lib info--------
placeholder: #IoStandard: IoStandard, 3.5.16.0 (System) => IoStandard, 3.5.16.0 (System)
placeholder: #3SLicense: 3SLicense, 0.0.0.0 (3S - Smart Software Solutions GmbH) => 3SLicense, 3.5.16.0 (3S - Smart Software Solutions GmbH)
placeholder: #CAA Device Diagnosis: CAA Device Diagnosis, 3.5.15.0 (CAA Technical Workgroup) => CAA Device Diagnosis, 3.5.15.0 (CAA Technical Workgroup)
placeholder: #Standard: Standard, * (System) => None
placeholder: #BreakpointLogging: Breakpoint Logging Functions, 3.5.5.0 (3S - Smart Software Solutions GmbH) => None
------lib info--------

    This made me realize that the effective_resolution property for the Standard lib was None. So I decided to manually set the redirection as follows

    if "Standard, * (System)" in libref.default_resolution:
    libref.set_redirection("Standard, 3.5.15.0 (System)")

    After setting the redirection the project could be compiled

    Build: Text: C0: ------ Build started: Application: Device.Application -------
Build: Text: C0: Typify code...
Build: Text: C0: Generate code...
Build: Text: C0: Generate global initializations...
Build: Text: C0: Generate code initialization...
Build: Text: C0: Generate relocations...
Build: Information: C0: Size of generated code: 67882 bytes
Build: Information: C0: Size of global data: 15142 bytes
Build: Information: C0: Total allocated memory size for code and data: 90344 bytes
Build: Information: C0: Memory area 0 contains  Data, Input, Output, Memory and Nonsafe data: size: 1048576 bytes, highest used address: 22456, largest contiguous memory gap: 1026120 bytes (97 %)
Build: Information: C0: Memory area 3 contains  Code: size: 1048576 bytes, highest used address: 67888, largest contiguous memory gap: 980688 bytes (93 %)
Build: Text: C0: Build complete -- 0 errors, 0 warnings : Ready for download

    Final Notes

    I also tested this error by using a W7 Virtual Machine (VM) as a build server and had similar issues related to references not being found for the standard library. The only time it worked with this VM is when the project was done inside the VM and this project file was used for the build.

    Also by using the library manager installer script mentioned in this post I noticed that the effective_resolution for the library BreakpointLogging wasnt changed and the value was still None, so it seems that installing the library did not change the placeholder it required and would need perhaps the "set_redirection" method.

    For now the problem seems to be solved and I can use the docker container with some slight modifications for my Lectures in Automation Systems at the University.

    Regards
    Victor

     

  • Ingo

    Ingo - 2022-08-11

    Thanks for diving into the rabbit whole. 😉

    I now improved the error reporting and stability of build-bootapp.

    Hint: You can call it like this, from the folder of your *.project file...

    docker run -v $(pwd):$(pwd) -w $(pwd) codesys-ide codesys build-bootapp
     

  • Ingo

    Ingo - 2022-08-11
    • labels: This -->
    • status: open --> closed
     

Log in to post a comment.