Announcement

Collapse
No announcement yet.

DoMore Feature Request: Program Callbacks, Index by struct field, Threads

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


  • DoMore Feature Request: Program Callbacks, Index by struct field, Threads

    I'm developing a small plc library for my company to handle some of the more complex ladder programming, and would love to have a few added features.

    Program Callbacks:
    I've noticed that we can create 'Program' structs as 'Memory Block' items. It would be nice if these could be used to store traditional programming callbacks. If 'Run' could target these (It shows up as valid, but then complains about no code-blocks referencing the target program struct.), and there was a way to set which actual code-block the struct was linked to, then the library user could implement their own program/subroutine to be called by the internal code of my library.

    Index by struct field:
    I like storing my library supporting variables in a struct on the heap. This makes sure my library isn't stepping on any data-blocks in use elsewhere. One annoyance, is that Indirect Access of a 'Memory Block' only works with 'V' addresses. Since these are just Unsigned Words, it would be nice if any unsigned word could be used, including a field of a structure.

    Threads:
    Furthermore, if the 'Program' structs are enhanced a bit, I would think you could run the same portion of a program, in multiple 'threads' where the internal data and state is stored in the struct. This could probably be made to act like a more conventional multi-threaded program.

    Ofcourse, I'm not entirely sure how the underlying fpga code is set up... but it seems like the capabilities are almost there. One particular difficulty might be viewing the thread 'Status' view while running/connected. Sub-routines are already difficult in this manner, since the same portion can be run multiple times with different data.

    Anyway, just my 2 cents. Great product, I really like the structs, configurable memory, etc.
    James Newman


  • #2
    Originally posted by Sci View Post
    Program Callbacks:
    I've noticed that we can create 'Program' structs as 'Memory Block' items. It would be nice if these could be used to store traditional programming callbacks. If 'Run' could target these (It shows up as valid, but then complains about no code-blocks referencing the target program struct.), and there was a way to set which actual code-block the struct was linked to, then the library user could implement their own program/subroutine to be called by the internal code of my library.
    You can use them, but the Program Block has to be targeted to the Memory Block based program struct at creation. For now, there is a one to one relationship between the program struct and the program block. We are definitely interested in doing a more object-centric approach where the code and instance are decoupled, but there are some non-trivial issues.

    Originally posted by Sci View Post
    Index by struct field:
    I like storing my library supporting variables in a struct on the heap. This makes sure my library isn't stepping on any data-blocks in use elsewhere. One annoyance, is that Indirect Access of a 'Memory Block' only works with 'V' addresses. Since these are just Unsigned Words, it would be nice if any unsigned word could be used, including a field of a structure.
    Opcode limitation. We had to choose exactly one block as an array index type. You can use a full expression from the MATH box...so D[CT0.Acc + sqrt(N6 + C13)] is legal. And note that you can also use an expression like that as the output parameter of MATH. So MATH D[exp] = R[exp] + N[exp] is legal.

    Originally posted by Sci View Post
    Threads:
    Furthermore, if the 'Program' structs are enhanced a bit, I would think you could run the same portion of a program, in multiple 'threads' where the internal data and state is stored in the struct. This could probably be made to act like a more conventional multi-threaded program.

    Ofcourse, I'm not entirely sure how the underlying fpga code is set up... but it seems like the capabilities are almost there. One particular difficulty might be viewing the thread 'Status' view while running/connected. Sub-routines are already difficult in this manner, since the same portion can be run multiple times with different data.
    This relates to the first part. Our debugging intention is to have a monitor function (debug mode only) that would read data at a particular program address, with provision for more complex triggers for subroutines, functions, and objects...i.e. at address 15 of function XYZ, when called from MATH box ABC...or some such thing.

    Comment



    • #3
      Originally posted by BobO View Post
      You can use them, but the Program Block has to be targeted to the Memory Block based program struct at creation. For now, there is a one to one relationship between the program struct and the program block. We are definitely interested in doing a more object-centric approach where the code and instance are decoupled, but there are some non-trivial issues.



      Opcode limitation. We had to choose exactly one block as an array index type. You can use a full expression from the MATH box...so D[CT0.Acc + sqrt(N6 + C13)] is legal. And note that you can also use an expression like that as the output parameter of MATH. So MATH D[exp] = R[exp] + N[exp] is legal.



      This relates to the first part. Our debugging intention is to have a monitor function (debug mode only) that would read data at a particular program address, with provision for more complex triggers for subroutines, functions, and objects...i.e. at address 15 of function XYZ, when called from MATH box ABC...or some such thing.
      That is helpful that expressions work for indexing while in a Math block. My particular use case involves using the indexed struct's field as an opcode parameter. I suppose I could make a new memory-block to hold the field, sort of like a temporary register, and directly reference that in the opcode. That'd add a small memory block, but avoid any of the built-in addresses. This temporary register would be a bit more clean feeling if I could make it a heap item.

      So... another couple requests.

      Discrete data type heap items. For example $TempRegister as a single unsigned word.

      ListenTCP changes (or new opcode). It would be nice if ListenIP could target DeviceReference types and continue listening. Currently, I can create a memory block of deviceref type, and use opentcp with an index to open and service multiple connections. Due to the tcp functions being async, the loops don't work ofcourse; However, I can use a program as a state-machine 'loop' that services each connection one at a time, indexing to the next after completion to be serviced on the next scan. It'd be nice if something similar could be done with ListenTCP.

      Ohh, and a couple questions:
      Is there a reference document for one of the protocols that can read/write arbitrary plc memory? I've been using modbus and custom tcp/udp, but sometimes I would like access directly and without special plc code. I've made my own custom HMI panel, and currently just memcopy X,y,c's to modbus coils for the IO monitoring maintenance pages. I seem to remember one of the protocols being publicly documented, but can't seem to find it now.

      Is there a way to get documentation on the mnemonics? I can use the export and copy/paste into notepad to work out some things, but I'd like to play with generating plc code from a 'config' program on my end. Basically a higher-level system config program that generates interface/support plc code that can be imported.

      Thanks for the response! I've been using direct logic PLCs for over a decade now, and switched to the DoMore CPU recently. The capabilities are amazing, kudos.

      Comment



      • #4
        Originally posted by Sci View Post
        Discrete data type heap items. For example $TempRegister as a single unsigned word.
        We'll get there. Probably not heap in the sense that you know it, but more likely a more tag-based approach. I was a big fan of tag-based before it was fashionable, and nicknames have always been usable in place of element names, dating all the way back to DirectSoft 1.0. After 5 years of users insisting they needed conventional elements, I finally gave up pushing. Of course now tags are all the rage, and some users fuss that Do-more isn't tag-based. Timing is everything.

        With the "create a nickname and we'll assign the element" feature and the ability to turn on element display, you can basically do that now, but I definitely see us offering the option of true tag-based programming in the future. Our approach to it will probably have some hybrid concepts...do you really want to lose all of the capabilities the current block memory provides? I don't. So the design challenge will be to create a system that marries the best of each world in a way that is intuitive and easy to use.

        Originally posted by Sci View Post
        ListenTCP changes (or new opcode). It would be nice if ListenIP could target DeviceReference types and continue listening. Currently, I can create a memory block of deviceref type, and use opentcp with an index to open and service multiple connections. Due to the tcp functions being async, the loops don't work ofcourse; However, I can use a program as a state-machine 'loop' that services each connection one at a time, indexing to the next after completion to be serviced on the next scan. It'd be nice if something similar could be done with ListenTCP.
        Not that simple. The associated socket and underlying device driver layer needs to exist somewhere, and would have to be dynamically allocated. This is one of the directions that we want to take a multi-instance object concept. We see the need and want to solve it, but it will take some effort. We'll get there eventually.

        Originally posted by Sci View Post
        Is there a reference document for one of the protocols that can read/write arbitrary plc memory? I've been using modbus and custom tcp/udp, but sometimes I would like access directly and without special plc code. I've made my own custom HMI panel, and currently just memcopy X,y,c's to modbus coils for the IO monitoring maintenance pages. I seem to remember one of the protocols being publicly documented, but can't seem to find it now.
        The native protocol is the only thing that can access that. We never intended to release it, but after much insistence by users, ADC put together a rudimentary spec. I think it has only been provided to a few HMI vendors under NDA.

        Originally posted by Sci View Post
        Is there a way to get documentation on the mnemonics? I can use the export and copy/paste into notepad to work out some things, but I'd like to play with generating plc code from a 'config' program on my end. Basically a higher-level system config program that generates interface/support plc code that can be imported.
        I think the only form of documentation for the import/export format is comments in the code, but I'm happy to check.

        Comment



        • #5
          Thanks again!

          Namespaces: Really much of what I'm trying to do is write a bit of ladder logic that can be imported into a project with a simple interface exposed, and with no memory conflicts. A way to prefix the tags with a 'namespace' similar to conventional programming languages would help ensure that imported memory addresses, names, etc... don't collide. This could probably be done completely on the domore designer side, with little or no change to the firmware.

          My wording on the documentation was interestingly ambiguous. I actually want documentation _of_ the mnemonics themselves, not a way to to put documentation in the mnemonic code, as it may have been read.

          Comment



          • #6
            Originally posted by Sci View Post
            Thanks again!

            Namespaces: Really much of what I'm trying to do is write a bit of ladder logic that can be imported into a project with a simple interface exposed, and with no memory conflicts. A way to prefix the tags with a 'namespace' similar to conventional programming languages would help ensure that imported memory addresses, names, etc... don't collide. This could probably be done completely on the domore designer side, with little or no change to the firmware.
            This is something that we would love to have. ADC has this on our personal wishlist; a library function where users could store code fragments and give them a unique name when the code is brought into the program.

            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



            • #7
              Originally posted by Sci View Post
              Namespaces: Really much of what I'm trying to do is write a bit of ladder logic that can be imported into a project with a simple interface exposed, and with no memory conflicts. A way to prefix the tags with a 'namespace' similar to conventional programming languages would help ensure that imported memory addresses, names, etc... don't collide. This could probably be done completely on the domore designer side, with little or no change to the firmware.
              We agree and as Do-more PE mentioned, we've had this on a list.

              Originally posted by Sci View Post
              My wording on the documentation was interestingly ambiguous. I actually want documentation _of_ the mnemonics themselves, not a way to to put documentation in the mnemonic code, as it may have been read.
              Nope. I understood. The comments I was referring to were DmD source code comments.

              Comment



              • #8
                Originally posted by BobO View Post
                The native protocol is the only thing that can access that. We never intended to release it, but after much insistence by users, ADC put together a rudimentary spec. I think it has only been provided to a few HMI vendors under NDA.
                Would you guys be open to releasing a DLL or having one written by someone under NDA, so that we can use Do-More protocol in our own PC-based HMI's?

                I actually like the indirection & firewalling you get from Modbus and DL protocols, so I typically use those, but I can foresee instances in which it would be nice to use native protocol.

                Comment



                • #9
                  Originally posted by ControlsGuy View Post

                  Would you guys be open to releasing a DLL or having one written by someone under NDA, so that we can use Do-More protocol in our own PC-based HMI's?

                  I actually like the indirection & firewalling you get from Modbus and DL protocols, so I typically use those, but I can foresee instances in which it would be nice to use native protocol.
                  My hot take is 'sure'. I'd probably need to consult others before a final decision was made.

                  Comment

                  Working...
                  X