Announcement

Collapse
No announcement yet.

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

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

  • BobO
    replied
    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.

    Leave a comment:


  • ControlsGuy
    replied
    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.

    Leave a comment:


  • BobO
    replied
    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.

    Leave a comment:


  • Do-more PE
    replied
    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.

    Leave a comment:


  • Sci
    replied
    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.

    Leave a comment:


  • BobO
    replied
    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.

    Leave a comment:


  • Sci
    replied
    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.

    Leave a comment:


  • BobO
    replied
    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.

    Leave a comment:


  • 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
Working...
X