Feedback wanted: Instantiable programs concept

[BobO]

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.

[durallymax]

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]

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.

[RBPLC]

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]

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.

[RBPLC]

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]

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.

[Controls Guy]

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?

[RBPLC]

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]

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.

[durallymax]

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]

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]

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]

I can't think of anything to suggest, those ideas all look right to me.

[franji1]

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).