Announcement

Collapse
No announcement yet.

Getting serial # of BRX and displaying on HMI

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

  • Getting serial # of BRX and displaying on HMI

    Is there a way to read the hardware serial # from a BRX PLC CPU via ladder logic?

  • #2
    Yep. Look at SerialNum, SysName, and SysDesc. They are built-in strings.

    Comment


    • #3
      Originally posted by BobO View Post
      Yep. Look at SerialNum, SysName, and SysDesc. They are built-in strings.
      Thanks BobO.

      Is it safe to assume these values are not lost after replacing a dead battery?

      On that note, is there another similar option where I can create a permanent key of sort where value of it can only be changed using DM Designer and that value is not lost during power failures, a dead battery, during an SD program upload etc., etc? In other words....a constant constant that can only be changed if done so using the DM Designer?

      Thanks.

      Comment


      • #4
        Originally posted by skyfox View Post

        Thanks BobO.

        Is it safe to assume these values are not lost after replacing a dead battery?

        On that note, is there another similar option where I can create a permanent key of sort where value of it can only be changed using DM Designer and that value is not lost during power failures, a dead battery, during an SD program upload etc., etc? In other words....a constant constant that can only be changed if done so using the DM Designer?

        Thanks.
        All of these values come from flash, so yes, they will survive a battery failure. The SysName and SysDesc fields are the name and description field from the node config (DmD or NetEdit), whereas the serial number cannot be changed by a user.

        As for the other thing, no, but wouldn't some ladder code that wrote a known place in image register accomplish the same thing?

        Comment


        • #5
          Originally posted by BobO View Post
          As for the other thing, no, but wouldn't some ladder code that wrote a known place in image register accomplish the same thing?
          That is exactly what I am trying to avoid in order to protect this company's intellectual property. Reason being, future field upgrades will be sent via SD cards. System is very simple in mechanical configuration/construction and can be easily duplicated. Basically, it consists of 20 valves, 11 RTD's, 4 Pressure sensors, 2 baffles to control air flow (at heated and at sub zero temperatures), and some other thing-a-ma jigs. However, the secret is in the MAGIC recipe developed by their process engineers. Basically, an operator puts in raw materials in to the system and presses a button that says DO IT. When the process is done, the machine puts out a "Scrumptious CAKE" if you will, each and every single time. As far as operator interaction go, two buttons. One to "Load batter" and another to "DO IT" or make Cake if you will. Well it is not exactly cake, but you get the idea. There are no HMI's, no temperature displays, no pressure displays, no step time displays, nothing of that sort to give a clue to the end user (by design) as to what the process is or what it is doing at any given moment. Only a beginning...Run time remaining... and an End. End will say Pass or Fail. Any alarm condition will fail the Cake bake. Pass, goes on to packaging. Failed stuff goes straight in to the trash bin. It works. I've seen it with my own eyes. They have nailed down the process with a rigged up MicroLogix PLC set-up. They now want to go in to mass production. Albeit with a reasonably priced PLC without any bells and whistles while being able to protect the PLC code. They do not want the end user to be able to take the SD card sent for an upgrade and then be able to load it in to another BRX they bought. That would simply allow them to duplicate this machine with the SECRET RECIPE. This customer's prototype is only 3 months old and they already have orders for 6 units based on the results of tests so far. They estimate up to 50 to 100 units in sales this year in the US and in Canada, and several hundred more by end of 3rd Q of next year. My job is to prevent the PLC CPU replication with a SD card, unless a certain pass code condition is met. It seems serial number is the only viable option as it stands now. This could get tedious if volumes get picked up. So I was looking for an option to have the ability to factory program a unique key that will always be persistent and not get lost or overwritten under any condition. That is unless the key is changed within the DM Designer environment by a factory programmer.

          Thanks again for your help.
          Last edited by skyfox; 03-26-2019, 12:22 AM.

          Comment


          • #6
            DMLoader has a method of verifying a product key and only updating if it matches. Thatís the closest thing we have now, but that facility was created speifically for that purpose...only updating if the the system is already running, and not for new systems.

            Donít know if you were aware, but Do-more also allows you to lock individual code blocks, preventing viewing/editing of critical IP.

            We could look at adding some kind of magic key, the complication is just where to add it and how to use it.

            Comment


            • #7
              And I completely forgot, the SDCard image can optionally include password and product verification. Meaning, it will refuse to update the PLC if the associated password doesn't reference a user with the appropriate permissions, and likewise if the $ProductID doesn't match.

              I think we can already do what you want.

              Comment


              • #8
                Thanks BobO.

                Password option looks like the way to go if it prevents a password protected program from being loaded on to a factory fresh PLC from an SD card.

                Comment

                Working...
                X