How to ensure a clean, consistent install of Codesys 3.5.4?

2014-01-11
2014-01-13
  • DavidCozens - 2014-01-11

    I have a number of PCs with codesys 3.5.4 installed, however when I inspect the library repositories I see that the different PCs have various different old versions of libraries installed, as well as those that came with 3.5.4. I want to ensure that all of my team have consistent development machines to avoid potential compatibility issues with shared development.

    When I installed codesys 3.5.4 on all of these machines I uninstalled any old versions of codesys first and then installed codesys 3.5.4 - this appears not to have removed all old libraries.

    I know that it is possible to install one version of codesys on top of another, and it is possible to compile for a variety of versions of runtime. I only need to target 3.5.4 and I want consistency, no possibility of different placeholder resolution on the different machines.

    If I uninstall codesys completely again before reinstalling is there anything I can do to ensure that all Libraries have been removed? Are there certain directories that need removing, registry entries clearing?

     
  • TimvH

    TimvH - 2014-01-12

    The normal way to remove libraries / devices is through the repository dialogs (see tools menu).
    They refer to the repository folders: C:\ProgramData\CoDeSys.
    I would not advise to just delete these files.

    Regarding the background of your question: If you have good device description files and create good libraries with correct version management, you shouldn't have to worry about this at all.

     
  • DavidCozens - 2014-01-12

    TimvH hat geschrieben:
    The normal way to remove libraries / devices is through the repository dialogs (see tools menu).
    They refer to the repository folders: C:\ProgramData\CoDeSys.
    I would not advise to just delete these files.
    Regarding the background of your question: If you have good device description files and create good libraries with correct version management, you shouldn't have to worry about this at all.

    Thanks Tim,
    With 3.5.4 the dialog should default to the correct method for adding libraries. However for some reason adding CAA File adds a reference to a specific version. I switched to using a placeholder reference and still have the problem. The library that I am compiling has the following entries in the library manager.

    CmpErrors = CmpErrors,3.3.1.40(System)
    StringUtils = StringUtils,3.5.4.0(System)
    CAA File = CAA File,3.5.3.0(CAA Technical Workgroup)
    CAA Types = CAA Types Extern,3.5.3.0(CAA Technical Workgroup)
    CmpLog = CmpLog,3.5.2.0(System)
    

    Locally on my PC this works fine, I have the following versions of SysFile installed

    3.0.2.1
    3.2.0.2
    3.3.2.50
    3.5.2.0
    3.5.4.0
    

    In the LibraryManager SysFile is resolved by 3.5.2.0, Why it isn't resolving to 3.5.4.0, I have no idea. Given that this is a library I presume that it is down to resolution through a Library profile associating 3.5.2.0 with the 3.5.4 compiler. Possibly a bug - I can chase that separately.
    The build server has the following versions of SysFile installed

    3.2.0.2
    3.5.4.0
    

    Loading my library then complains

    [ERROR]Β  Β  Β  Β  Β caa file, 3.5.3.0 (caa technical workgroup): Library Manager: Could not open library '#SysFile'. (Reason: The library 'SysFile, 3.5.2.0 (System)' has not been installed to the system.)
    

    However that is not the problem I am trying to solve here. In my development team I want to ensure a completely consistent environment, I don't want things to work on one PC and fail on another - it wastes time. The question still remains how to ensure a clean install? On the two machines I am looking at most closely, both have had more than one version of codesys installed, both had all versions of codesys uninstalled, both then had codesys 3.5.4 installed, and yet I have different libraries available on the two machines. I appreciate that I could go in to the library repository and manually delete every version of every library, do the same for devices, then uninstall and install from scratch. I was hoping that there is a cleaner mechanism, e.g. uninstall, perform some cleanup task, install from 3.5.4 and have identical environments.

     
  • DavidCozens - 2014-01-12

    Rereading your answer Tim, is it a case that a complete uninstall of codesys, followed by deleting c:\ProgramData\Codesys and re-installing should give me consistency?

     
  • DavidCozens - 2014-01-12

    DavidCozens hat geschrieben:
    Rereading your answer Tim, is it a case that a complete uninstall of codesys, followed by deleting c:\ProgramData\Codesys and re-installing should give me consistency?

    This does appear to be the solution - at least I have a consistent set of libraries - It would still be good to know what else has been left hanging around. The specific problem with the SysFile seems to be something 3S need to deal with as a new Empty library, where I just add a Library manager and then add CAA File has an unresolved reference to SysFile

     
  • TimvH

    TimvH - 2014-01-13

    Hi David,
    Thanks for informing us.
    As far as I know all "sys" libraries are hardware specific and should be resolved in the device description.
    If you get any info from 3S-Smart Software Solutions on how to handle this in your libraries, then please let us know.

     
  • DavidCozens - 2014-01-13

    TimvH hat geschrieben:
    Hi David,
    Thanks for informing us.
    As far as I know all "sys" libraries are hardware specific and should be resolved in the device description.
    If you get any info from 3S-Smart Software Solutions on how to handle this in your libraries, then please let us know.

    I have heard from 3S that this specific library resolution in 3.5.4 is in error and will be resolved.

    http://www.users-conference.com/fileadmin/Users%C2%B4%20Conference%20International/Schweden/LibraryDevelopment.pdf

    Library profiles resolve a library placeholder in the case where it is not specified by the device descriptor, or there is no device descriptor. They resolve against the version of the compiler in use.

    I do wonder if there is a need for a library to be able to specify the placeholder resolution for libraries it is referencing. Some of the problems can be solved by good design and having both libraries depend on an interface library rather than having a direct dependency. I think that there are cases where a direct dependency is needed and I don't know of a means of specifying that.

     

Log in to post a comment.