Announcement

Collapse
No announcement yet.

Possible to adjust serial port settings via registers in on BRX platform?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts


  • Possible to adjust serial port settings via registers in on BRX platform?

    On the BRX platform, is it possible to adjust the serial port settings (baud, party, stop bits, etc.) via registers?

    Thank you.


  • #2
    Use the DEVWRITE command. This does not change the project. It only changes the registers until the next reboot so if you want it to stay changed, you need to run it on first scan.
    If you have an urgent issue, please contact AutomationDirect's Technical Support team.

    AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

    Comment



    • #3
      Originally posted by Do-more PE View Post
      Use the DEVWRITE command. This does not change the project. It only changes the registers until the next reboot so if you want it to stay changed, you need to run it on first scan.
      Thank you.

      Is there is table of said registers so that I know which ones to write to? Thanks again.

      Comment



      • #4
        Originally posted by div_by_zero View Post

        Thank you.

        Is there is table of said registers so that I know which ones to write to? Thanks again.
        They are listed in the DEVWRITE instruction. The ones you care about are listed as "Serial Port: XXXX"

        Comment



        • #5
          The help file should tell you pretty much everything you need about the instruction.
          If you have an urgent issue, please contact AutomationDirect's Technical Support team.

          AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

          Comment



          • #6
            Originally posted by Do-more PE View Post
            The help file should tell you pretty much everything you need about the instruction.
            Thanks. One more questions: is there a document somewhere that covers ALL memory addresses in BRX?

            Comment



            • #7
              Originally posted by div_by_zero View Post

              Thanks. One more questions: is there a document somewhere that covers ALL memory addresses in BRX?
              If you referring to ST bits and DST registers, they are documented in the help file.

              Comment



              • #8
                The software help file has pretty much everything you need to know. If it isn't there then try the hardware manual.
                If you have an urgent issue, please contact AutomationDirect's Technical Support team.

                AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

                Comment



                • #9
                  Originally posted by div_by_zero View Post

                  Thanks. One more questions: is there a document somewhere that covers ALL memory addresses in BRX?
                  Realize that the Do-more devices' configurations are not in "system v" memory that is directly accessible. A memory-mapped model is prone to corruption (inadvertently or maliciously). Do-more protects the device configuration by placing it in a protected area of the system called System Configuration that gets loaded at power-up. This makes it inaccessible via simple memory accesses like MOVE or a bad pointer or Data View or whatever.

                  But, as you asked originally, how then do you programmatically configure these devices? Dynamic/runtime configuration settings are a powerful feature, especially for OEMs, or where end-users may need to "configure" them via an HMI, or whatever. Do-more gives you programmatic access via the DEVREAD and DEVWRITE instructions. These instructions let you read/modify any configurable device via a device drop-down, followed by a specific "device property", followed by the value that you want to read it into or write.

                  As mentioned previously, the DEVWRITE only modifies the System Configuration in memory, not the static one that is part of the project in the ROM of the Do-more PLC. The static ROM based one gets loaded into RAM at power-up. The RAM copy is what the PLC uses when using the devices. DEVREAD and DEVWRITE access this RAM copy, not the ROM. That is why you most likely need to re-execute a DEVWRITE at power-up because the initial RAM copy at power-up is the original static one from ROM.
                  There are 10 kinds of people in this world, those who know binary, and those who do not.

                  Comment



                  • #10
                    Originally posted by franji1 View Post

                    Realize that the Do-more devices' configurations are not in "system v" memory that is directly accessible. A memory-mapped model is prone to corruption (inadvertently or maliciously). Do-more protects the device configuration by placing it in a protected area of the system called System Configuration that gets loaded at power-up. This makes it inaccessible via simple memory accesses like MOVE or a bad pointer or Data View or whatever.

                    But, as you asked originally, how then do you programmatically configure these devices? Dynamic/runtime configuration settings are a powerful feature, especially for OEMs, or where end-users may need to "configure" them via an HMI, or whatever. Do-more gives you programmatic access via the DEVREAD and DEVWRITE instructions. These instructions let you read/modify any configurable device via a device drop-down, followed by a specific "device property", followed by the value that you want to read it into or write.

                    As mentioned previously, the DEVWRITE only modifies the System Configuration in memory, not the static one that is part of the project in the ROM of the Do-more PLC. The static ROM based one gets loaded into RAM at power-up. The RAM copy is what the PLC uses when using the devices. DEVREAD and DEVWRITE access this RAM copy, not the ROM. That is why you most likely need to re-execute a DEVWRITE at power-up because the initial RAM copy at power-up is the original static one from ROM.
                    Got it. Thank you very much for taking the time, all, to reply to this. I'm good-to-go now!

                    Comment



                    • #11
                      I should also mention DATAINFO and HWINFO instructions that provide other access to the System Configuration.

                      DATAINFO provides information about a specific data block or heap-item at runtime, such as their data type or their size in bytes or element count or . . .(e.g. how many elements are in my D block?)

                      HWINFO provides information about a specific module such as the Module ID (useful when a module is OPTIONAL, use HWINFO to determine if it exists or not at runtime). Or get the X, Y, WX, WY count.

                      These are read-only. You cannot change the size of a data block or the number of screwheads on a discrete input module at runtime ;-)
                      There are 10 kinds of people in this world, those who know binary, and those who do not.

                      Comment

                      Working...
                      X