News:

  • October 12, 2024, 01:56:57 PM

Login with username, password and session length

Author Topic: Feedback wanted: Instantiable programs concept  (Read 12038 times)

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6040
  • Yes Pinky, Do-more will control the world!
Re: Feedback wanted: Instantiable programs concept
« Reply #30 on: December 22, 2021, 11:39:33 AM »
If I am reading this correctly, this will be similar to RA's AOI? But without the ability to use arrays in a "nice" way? My DmD experience is subpar at best, I still get a bit lost on data blocks vs arrays in something like Psuite or RA. I guess they're all arrays, just look a bit different.

If this is similar to AOI's I may have to continue trying to make me and DmD get along, it seems DmD will get there sooner than Psuite at this point. I really miss that from RA and copy/paste + find/replace get's old after awhile.

In the AOI's of the other guys, you set the parameters as in or out which can only be used by the AOI or in/out which can be accessed outside the AOI. If I'm off base, someone else can correct me, its been a few months since I was in the RA environment.

The next step completely out of Host's control (but maybe you have some influence) is tag placeholder like support in C-More. Pair this with what you're talking about and it's the same as RA's global objects. Makes life quick and easyish. Although, if DmD's end of the deal works, there's no reason another HMI solution can't be used that does support this.

I've always understood AOIs to essentially be function calls, more like our subroutines, but I have almost zero experience with RA.

Our implementation would be closer to an object, where the data associated with each code block is contained in a small number of UDTs that are created for each instance. It would also be possible to access global data, but I would expect the bulk of the data to be in the instance UDTs. They would functionally be program blocks, but where you easily add new instances without copying anything.

We are releasing sub structures shortly (where UDTs can contain UDTs), which we think really increases the power of the instance concept.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

durallymax

  • Jr. Member
  • **
  • Posts: 13
Re: Feedback wanted: Instantiable programs concept
« Reply #31 on: December 22, 2021, 12:48:13 PM »
I'm not a CS so forgive my terminology but yes I would equate it to a function call in C or similar and like your SBR but IME not the same unless I am using your SBR wrong. I wanted to verify the latter so I did fire up DmD and attempt to create three calls of the same SBR with three instantiations of a UDT, however upon attempting to add a timer a prompt told me it wouldn't work. Now I cannot remember if its legal to use a timer inside a function in C either, but I do know you can use them in an AOI. Each instantiation of an AOI creates unique "memory" I believe. How it works behind the scenes is outside my scope. When called you do pass input and output params just like DmD. You can also specify in/out which it does not allocate memory for, it simply uses them as a pointer to go find the value and update it later.

From what you are saying, it sounds like your new object will be similar.

Nested UDT's are nice, I didn't even know it was an option in Psuite until I fat fingered a type inside a UDS and set it as one of my other UDS. An epiphany which prompted a day or twos worth of re-writing a program to clean it up. Handy features.   Even without a good find/replace and/or tag placeholder, UDTs speed up time in the HMI a decent amount.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6040
  • Yes Pinky, Do-more will control the world!
Re: Feedback wanted: Instantiable programs concept
« Reply #32 on: December 22, 2021, 01:33:24 PM »
I'm not a CS so forgive my terminology but yes I would equate it to a function call in C or similar and like your SBR but IME not the same unless I am using your SBR wrong. I wanted to verify the latter so I did fire up DmD and attempt to create three calls of the same SBR with three instantiations of a UDT, however upon attempting to add a timer a prompt told me it wouldn't work. Now I cannot remember if its legal to use a timer inside a function in C either, but I do know you can use them in an AOI. Each instantiation of an AOI creates unique "memory" I believe. How it works behind the scenes is outside my scope. When called you do pass input and output params just like DmD. You can also specify in/out which it does not allocate memory for, it simply uses them as a pointer to go find the value and update it later.

From what you are saying, it sounds like your new object will be similar.

Nested UDT's are nice, I didn't even know it was an option in Psuite until I fat fingered a type inside a UDS and set it as one of my other UDS. An epiphany which prompted a day or twos worth of re-writing a program to clean it up. Handy features.   Even without a good find/replace and/or tag placeholder, UDTs speed up time in the HMI a decent amount.

We place quite a bit of restriction on subroutines to prevent weird side effects that people don't understand. It reduces the utility, but we prefer that to increasing confusion. One major consideration for any multi-instance code is where edges (last state) are stored for all edge-centric parms or inputs. That is the biggest driver of restrictions in callable code. For the object concept, we have a decent solution.

I think there is a good amount of interest in the feature, we just gotta get to it. Finishing up the current release to support a mildly redesigned BRX CPU (that we have parts for), and then we'll jumping back into new development.

"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

RBPLC

  • Hero Member
  • *****
  • Posts: 585
Re: Feedback wanted: Instantiable programs concept
« Reply #33 on: December 23, 2021, 09:08:29 AM »
Quote
Our implementation would be closer to an object, where the data associated with each code block is contained in a small number of UDTs that are created for each instance. It would also be possible to access global data, but I would expect the bulk of the data to be in the instance UDTs. They would functionally be program blocks, but where you easily add new instances without copying anything.

I take this to mean that run time edits wouldn't be allowed. I'm not a RA user but I know that one of the chief complaints about AOI is that that can't be edited online.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6040
  • Yes Pinky, Do-more will control the world!
Re: Feedback wanted: Instantiable programs concept
« Reply #34 on: December 23, 2021, 10:00:04 AM »
Quote
Our implementation would be closer to an object, where the data associated with each code block is contained in a small number of UDTs that are created for each instance. It would also be possible to access global data, but I would expect the bulk of the data to be in the instance UDTs. They would functionally be program blocks, but where you easily add new instances without copying anything.

I take this to mean that run time edits wouldn't be allowed. I'm not a RA user but I know that one of the chief complaints about AOI is that that can't be edited online.

Creating new instances? No. If just editing the program block itself, yes.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

RBPLC

  • Hero Member
  • *****
  • Posts: 585
Re: Feedback wanted: Instantiable programs concept
« Reply #35 on: December 23, 2021, 10:22:03 AM »

Creating new instances? No. If just editing the program block itself, yes.
[/quote]

It might not be possible to allow online changes, but inability to make online changes to the program block itself will be a major complaint from users. This is certainly the case with RA.




BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6040
  • Yes Pinky, Do-more will control the world!
Re: Feedback wanted: Instantiable programs concept
« Reply #36 on: December 23, 2021, 11:12:04 AM »
It might not be possible to allow online changes, but inability to make online changes to the program block itself will be a major complaint from users. This is certainly the case with RA.

Don't know of any reason why runtime edits will be an issue, as long are you aren't creating new instances. Creating new instances would force program mode because it changes memory allocation. The only potential sticking point would be if the program edits were extensive enough to affect edge memory allocation, in which case we would need to go to program mode for that too. I would say the largest majority of program block edits would be allowed as runtime edits.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3573
  • Darth Ladder
Re: Feedback wanted: Instantiable programs concept
« Reply #37 on: December 23, 2021, 11:27:28 AM »
I apologize if this has already been covered.

I'm picturing that code blocks would appear only once in the project tree, with calls in other logic, but with instance data blocks as UDT instances, at one per use, correct?  That seems like it would align with your answer to the last question and current DM behavior.   So then the (single) code block can be edited according to normal guidelines for online edits, and additional calls to that function can be added at runtime, but new UDT variables would require a program mode synch because it's new memory, correct?   So basically like how it works now?

If that's the case, and runtime edits were critical, I'd probably create spare variables of that UDT type and call them into service as needed.   I think the variable names can even be edited from the placeholder names to real names at runtime, or is that a memory config change?
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

RBPLC

  • Hero Member
  • *****
  • Posts: 585
Re: Feedback wanted: Instantiable programs concept
« Reply #38 on: December 23, 2021, 11:38:35 AM »
Code: [Select]
Creating new instances? No. If just editing the program block itself, yes.
I think I misunderstood this. You were saying you wouldn't be able to create instances at runtime but would be able to edit the program at runtime. I believe this would be perfectly acceptable for most users.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6040
  • Yes Pinky, Do-more will control the world!
Re: Feedback wanted: Instantiable programs concept
« Reply #39 on: December 23, 2021, 04:08:40 PM »
I think I misunderstood this. You were saying you wouldn't be able to create instances at runtime but would be able to edit the program at runtime. I believe this would be perfectly acceptable for most users.

Yes. Editing code is fine, just like now. Allocating memory requires a trip to program mode.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

durallymax

  • Jr. Member
  • **
  • Posts: 13
Re: Feedback wanted: Instantiable programs concept
« Reply #40 on: December 29, 2021, 02:37:19 PM »
RA allows AOIs to be instantiated and created from scratch online but the code inside an existing AOI cannot be edited online.

I have been out of the RA ecosystem for a minute though so my memory of their intricacies is fading.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3699
    • Host Engineering
Re: Feedback wanted: Instantiable programs concept
« Reply #41 on: April 22, 2022, 11:35:25 AM »
I don't want to use any AB terminology, because I think it adds to the confusion (since I don't fully understand their terminology).  All these are re-usable, but can also be used for encapsulation (hiding IP).

Objects are what this topic started in discussion (Instantiable Programs), but we saw the need for 2 non-objects MATH Functions and User Boxes).

PLEASE provide feedback on these 3 different logic concepts (MATH Functions, User Boxes, Objects)

    MATH Function
    • fully SYNCHRONOUS
    • takes 0 to N input parameters
    • returns a bit or numeric value
    • can only be used inside a MATH expression
    Example MATH Function Usage that calculates the diagonal in feet of 2 sides that are in inches using the Pythagorean Function code block
    MATH R0 "12.0 * Pythagorean(V0, V1)"

      User Box
      • The box is FULLY SYNCHRONOUS - e.g. doing a special SCALE algorithm (Cubic Interpolation or whatever), so you can NOT use any TMR or PID or COMM
      • It's a box with 0 to N Input Parameters and 0 to N Output (In/Out?) Parameters
      • Each parameter has a Label that is shown in the Editor and Display - Do-more left justifies the Label and right justifies the parameter element
      • Probably just one input leg - an enable (i.e. the User Box is called in-line when it has power flow, does NOT get called when it does not have pf)
        (see Objects below)
      Example User Box that converts Cartesian Coordinates to Polar Coordinates in Degrees
      +---------------+
      | CART2POLARDEG |
      | X       0.707 |
      | Y       0.707 |
      | Radius  R0    |
      | Angle   R1    |
      +---------------+
      // ASSERT((R0==1.0) && (R1==45.0)


        Objects
        • It's a Program that you RUN
        • It has 0 to N Input Parameters to initialize or set specific Object Member values  and 0 to N Output Parameters to return specific Object Member values
        • You can flag each Input parameter to be passed in ONCE at FIRST SCAN or EVERY scan
        • You can flag each Output parameter to be returned ONCE at DONE or EVERY scan
        • Can contain FULLY ASYNCHRONOUS instructions (e.g. TMR, AXSCRIPT, HTTPCMD) so you can do full control behavior (remember, it's a PROGRAM, so you have access to Stage programming if you want)
        Example of running program for 4 kettles objects of 2 different recipes passing in the Recipe index (V0 and V1) and returns 4 different Batch Done bits in C0 thru C3

        +-------------------------+
        | RUN KettleA             |
        | .RecipeIndex   V0 (once)|
        | .Done                C0 |
        +-------------------------+

        +-------------------------+
        | RUN KettleB             |
        | .RecipeIndex   V0 (once)|
        | .Done                C1 |
        +-------------------------+

        +-------------------------+
        | RUN KettleC             |
        | .RecipeIndex   V1 (once)|
        | .Done                C2 |
        +-------------------------+

        +-------------------------+
        | RUN KettleD             |
        | .RecipeIndex   V1 (once)|
        | .Done                C3 |
        +-------------------------+

        RBPLC

        • Hero Member
        • *****
        • Posts: 585
        Re: Feedback wanted: Instantiable programs concept
        « Reply #42 on: April 22, 2022, 12:37:26 PM »
        To clarify, you're wanting feedback on each of the three logic concepts because they're all potentially available for development to be used in future DmD releases. You're not asking us to choose one of the three concepts because only one can be developed.

        Controls Guy

        • Internal Dev
        • Hero Member
        • ****
        • Posts: 3573
        • Darth Ladder
        Re: Feedback wanted: Instantiable programs concept
        « Reply #43 on: April 22, 2022, 02:29:12 PM »
        I can't think of anything to suggest, those ideas all look right to me.
        I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

        franji1

        • Bit Weenie
        • Host Moderator
        • Hero Member
        • *****
        • Posts: 3699
          • Host Engineering
        Re: Feedback wanted: Instantiable programs concept
        « Reply #44 on: April 22, 2022, 04:43:09 PM »
        To clarify, you're wanting feedback on each of the three logic concepts because they're all potentially available for development to be used in future DmD releases. You're not asking us to choose one of the three concepts because only one can be developed.

        We think all 3 are needed.  But a prioritized list would be good also, with some kind of weighting.  BUT, I am looking for feedback on each of the 3, independently - with some details.  If you want to utilize A/B terminology to educate me on my terminology, that would also be helpful.

        I want to do this in LAYERs - so let's nail down THIS level (e.g. for now, I do NOT want to get into the concept of what a "local" is in A/B-land until I understand it at the level I described).