Results 1 to 5 of 5

Thread: Best Practices for commenting program revisions?

  1. #1

    Default Best Practices for commenting program revisions?

    Hello,

    This is my first post here. Glad to be here. We're a small OEM that just started using IFM controllers and CodeSys earlier this year. We're already supporting the 6th revision of one of our programs. Can you tell me what you do for commenting incremental revisions between programs. I thought maybe I could insert a blank network at the top of PLC_PRG and just use if for an overall header comment. I see that's not going to work.

    Do you flag individual networks that change between revisions with what revisions altered those networks? Like what you would see on a blue print, notations that refer the reader to a separate revision block, index, appendix?

    Related to this, is there a way CodeSys can read the serial number of the controller. Either for using in an HMI or storing with logged data? Thanks in advance for the help.

  2. #2
    Join Date
    May 2009
    Location
    Minneapolis, MN
    Posts
    300

    Default

    Just make a comment in the Variable Decleration in the PLC_PRG (top part of the screen).

    Yes you can read the serial number of the controller, I believe you are using the CR04xx. You will need to use the GET_HW_INFO function block.

  3. #3

    Default

    Thanks Erik. Hadn't thought about that. I'll be making it a habit from here out.

  4. #4
    Join Date
    Apr 2014
    Location
    Chicago
    Posts
    5

    Default

    What works best for myself is create a global variable file under Resourses and name it Revision History of something. Then when ever you make a change add it to this file. Also in this file is where the program revision used by CoDeSys is set so you can make the revision and document it all in one place example:

    VAR_GLOBAL
    g_strSoftwareVersion :STRING(80) := 'MyProject_V100' = ; (* Software version that can be viewed from the downloader application *)

    Revision, history:
    V100 01-31-14
    SJP: First Inital release
    end_var

    This has the benefits of being able to be exported or printed separate from a POU and if developing under multiple different target you keep commonality between projects. But if your question was about POU vs Project then a suggestion is comment the POU with your change and then reference the change in the global project revision history.

  5. #5

    Default Best Practices for commenting program revisions

    Hi

    Could anyone share the Junos High Availability Best Practices for High Network Uptime book .
    This is a great book on how to implement a high availabity network ,but unfortunatly I couldnt get it

    Please if you can share it, it will be a nice gift.

    Thanks for your help.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •