Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: BobO on June 22, 2021, 12:41:50 PM
-
Feedback wanted...
While working on nested structs in UDTs, it occurred to me that we might now have the foundation laid for instance based program blocks.
This is the basic work flow:
1. Create a UDT definition that contains all of the instance data of the program.
2. Create an object block definition, which is just a program block where you reference the UDT and program struct instance through some abstract names like $Data and $Pgm, tbd.
3. Add one or more instances of the object. The facility creates the program and UDT and adds the object instance to the list.
4. Run the object instance with RUN just like any other program.
Only one copy of the code exists, run multiple times, using the program and data instances.
Most instructions would be supported in objects, but there is a pretty big caveat there. While we can reference a structure indirectly, we cannot (yet) reference an array indirectly. What this means is that anything that needed to do array referencing of arrays unique to an instance cannot (easily) do so. So the best rule of thumb is that if you can't describe it in a 256 byte UDT with nested structures, you really can't do it in an object. I'm sure there will be ways around that, but they may be more trouble than they are worth, or more advanced than most want to learn.
The function definitely has utility as described, but I guess what I'm asking is whether the limitation to a single (and maybe more than one, we'll see) UDT per instance is so limiting for your typical application that you don't think you'd ever use it. No wrong answers.
And FYI...I've done a proof of concept. It works, and even though we still have a couple of things to work out, we think it's completely viable.
-
2. Create an object block definition, which is just a program block where you reference the UDT and program struct instance through some abstract names like $Data and $Pgm, tbd.
Could you have multiple object block definitions to deal with the case where you needed multiple UDT's if you're limited to one UDT per object block definition?
-
2. Create an object block definition, which is just a program block where you reference the UDT and program struct instance through some abstract names like $Data and $Pgm, tbd.
Could you have multiple object block definitions to deal with the case where you needed multiple UDT's if you're limited to one UDT per object block definition?
It would be easier to add more UDTs to the program definition, $Data1, $Data2, etc. Nothing to prevent it architecturally, just a question of what is needed.
-
I'm trying to understand exactly how this would work. After playing around in TIA Portal, is what you're proposing similar to a Multi-Instance Function Block? Would the UDT serve as local memory definitions? How would you troubleshoot an instance in regards to a data view or more importantly a window where you could see an instance running in ladder? I think this was brought up a few days ago on the ADC forum.
-
I'm trying to understand exactly how this would work. After playing around in TIA Portal, is what you're proposing similar to a Multi-Instance Function Block? Would the UDT serve as local memory definitions? How would you troubleshoot an instance in regards to a data view or more importantly a window where you could see an instance running in ladder? I think this was brought up a few days ago on the ADC forum.
Yes, it is essentially what you are describing. A single physical code block, that runs multiple times using different data and program instances. It is fully a program block, with its own set of stages and current execution state, so I wouldn't call it a function block...each is a full program.
You would use this any time you are currently creating multiple copies of the same program and then editing all of the global memory references. I know many users do exactly this. The big question is whether a single UDT is enough data to solve the typical problem or not.
As for debugging, you really won't know the difference. In the project tree, there will be an Object section at the same level as Tasks, Programs, and Subroutines are now. Immediately underneath that, you would have Object definitions, which are just program blocks built with abstract references to the associated program and UDT structures, rather than hard references. Underneath each Object definition is a list of instances. If you double click the definition, we open the abstract definition for editing. If you double click an an instance, we open the specific instance, with the abstract references resolved to the actual structures, so it will look exactly like debugging a program block now.
The key difference is that any reference to memory not contained with the Object's program or data structure is global, and every instance is reading/writing the same location. That can be perfectly fine...but...that can also be a big issue. We won't prevent it, but we will warn you about it.
-
And when I say "abstract reference" it would be like this:
STR $Data.BitInMyStruct
TMR $Data.TmrInMyStruct, 5000
This is what you see in the object definition.
When we display for status, we would resolve the abstract reference to the actual reference for the instance you are viewing. If when you created the instance you called the data UDT, MyUdt1, $Data would be replaced with MyUdt1, so the instance displayed would be:
STR MyUdt1.BitInStruct
TMR MyUdt1.TmrInMyStruct, 5000
Any other instances of the same object would of course resolve to the associated structures. Should feel exactly like what you do now.
-
You would define one UDT per "class" (using C++ terminology), then create instances of the "class", which would include the Program structure (.$pgm member) and instance data (UDT) structure (.$data member).
Say this is a packing machine, there would be 1 code-block to run 10 packing maches, say the code-block is called PackingMachine. Say each one uses a couple Timers, FillTimer and SealTimer. For simplicity, let's say you have 10 machines, MachineA thru MachineJ.
You would write ONE code block using PackingMachine. Say it was a Stage program, so you would write your code ONCE:
SG PackingMachine.$pgm.S0
...
SG PackingMachine.$pgm.S1
...
SG PackingMachine.$pgm.S2
...
inside Stage S2, say you use the FillTimer
PackingMachine.$pgm.S2
SG PackingMachine.$pgm.S2
TMR PackingMachine.$data.FillTimer
STR PackingMachine.$data.FillTimer.Done
JMP PackingMachine.$pgm.S3
But when the code EXECUTES for the 10 different INSTANCES in one PLC scan, it basically runs that code block 10 times, but instead of using PackingMachine, it uses 10 individual SPECIFIC INSTANCES (same code - not a copy of the code, but each execution instance at runtime just replaces PackingMachine with MachineA, then MachineB, then MachineC, ... MachineJ.
Each INSTANCE has its own program/data state, but just ONE code-block (ran 10 different times with 10 different object states). So then MachineA can be in Stage S0, MachineB in Stage S1, MachineC in Stage S2 with MachineC.$data.FillTimer.Acc equal to 1234, MachineD in Stage S2 with MachineD.$data.FillTimer.Acc equal to 5678.
If you want to see the status of the logic for MachineA, open up THAT INSTANCE, turn status ON. For MachineJ, open up THAT INSTANCE, turn status ON. THAT code will be SIMILAR to the ORIGINAL code-block (PackingMachine), but will instead show instruction status of instance MachineJ as follows (say for Stage S2):
SG MachineJ.$pgm.S2
TMR MachineJ.$data.FillTimer
STR MachineJ.$data.FillTimer.Done
JMP MachineJ.$pgm.S3
If you had a big enough screen, you could tile the 10 code INSTANCED blocks, all with status ON. The shape of the 10 Ladder Views would be IDENTICAL, but the INDIVIDUAL OBJECT INSTANCE PARAMETERs would be SWAPPED OUT.
You create/edit using the base PackingMachine code block, but you do status with the INSTANCE based code blocks (MachineA thru MachineJ). You can't "edit" MachineJ's "copy", because MachineA thru MachineJ SHARE THE SAME BASE CODE (i.e. PackingMachine).
Since you would be limited to just 256 bytes in the $data portion of the "class", how many timers, counters, PID, nested UDTs will you need? A Timer is 8 BYTEs. A REAL is 4 BYTEs. A PID is 96 BYTEs. A string can be 8 BYTEs or 64 BYTEs or ???. So you can burn through 256 BYTEs easily if you need a couple PIDs or a bunch of non-trivial strings. Hence, do we need 2 (or 3) UDTs to hold all the necessary "member" variables (Timers, PID, Strings, Recipe UDT, other UDT, etc. etc.) .$data1 .$data2 .$data3 ? ? ?
-
Let me first say that this ability would be extremely beneficial. I've got a project written for 8 similar machines and there was a whole lot of find/replace going on to get the multiple instances resolved, not to mention duplicate comments and error checking to make sure I haven't missed an instance update and the issue of incorrect logic that is duplicated 8 times and has to be corrected in eight places. Quickly adding up total number of bytes that would have gone into one UDT, I think I've got approximately 300 bytes of non-strings that are used for program control. I personally could have gotten by without adding strings to the UDT to keep the byte count as low as possible. I would very much like to see these changes as this would have completely changed how I programmed this particular machine (which is the largest I will work on). I kept trying to figure out how to use a subroutine to reduce copy/paste programming but couldn't because you can't perform multi-scan instructions in the subroutines and you can't effectively troubleshoot subroutines when you can't see specific individual instances easily for troubleshooting. If you guys can include this functionality combined with structures in UDT's and increased name lengths to keep it all organized, this will be one very powerful tool. After seeing this functionality in TIA Portal, I immediately wished it was available in DmD.
-
Name lengths become a little less relevant when you have depth. A 16 character name ends up being a big problem specifically because y'all are cramming so much into a single flat namespace. When the name is 16.16.16 it's much easier to be expressive with us changing anything. We are currently rewriting some display code to be long name friendly however, so we still want to get there. It's just a big job. We're a small company and try to pick our battles.
At the controller level, there is nothing to prevent being more than one user struct per object, so 300 bytes should be no issue. Each struct is just another reference pushed onto the stack, and the object can reference n as a easily as 1. The only real concern is how we reference them from DmD for editing, find, xref, etc. As long as we can solve a few small-ish issues there, this is manageable. I already have a simple proof on concept running in the PLC and it wasn't very hard at all. The key is nested structures. That was huge.
Thanks for the feedback so far. Would love to hear from others!
-
...and let me add that basically any structure can be added to UDTs, and that means that UDTs can be added to UDTs, not just built-ins. That's why I'm saying 16.16.16 on the names. You control all of that.
-
1) Valid point concerning names and depth.
2) Does this development segue into user-defined functions and function blocks? What about local variables?
3) Do you guys do beta-test releases that could be used in Simulator?
-
Can you reference a global array indirectly?
-
Can you reference a global array indirectly?
No. That's the primary limitation.
You could manually allocate a range from a global array and pass the index range through members in the data struct, but some will consider that more advanced than they are willing to do.
-
What about indexing in the Math box? I thought that was done differently anyway.
-
What about indexing in the Math box? I thought that was done differently anyway.
Yes, that is the best way. The array itself cannot be abstracted though and must be global. You can solve that by manually assigning a global range to an instance through struct members, and then indexing in a MATH box. You could use a global V, but you would have to make sure the program never yielded. MATH is cleaner.
-
Can you reference a global array indirectly?
And after reading this a second time, I don't think you were asking what I thought you were asking, but were proposing a valid solution to the problem I stated. Apologies.
The reason for the misread is because the way it works now is called an indirect reference. I just got stuck on the thought that you were asking whether you could access a global array through the stack, which you can't. But yes, you absolutely can craft you own indirect access method for a global array you partition. So the answer to your original question likely should have been a simple "yes".
-
We use a lot of indirectly addressed arrays in Rockwell systems, we also write and use a lot of what Rockwell calls AOI's which the UDT's look about the same, so we could use them in some of our applications. Are there plans to add the ability to access multidimensional arrays? We normally use 3D arrays for a lot of our programs.
Thanks,
JW
-
We use a lot of indirectly addressed arrays in Rockwell systems, we also write and use a lot of what Rockwell calls AOI's which the UDT's look about the same, so we could use them in some of our applications. Are there plans to add the ability to access multidimensional arrays? We normally use 3D arrays for a lot of our programs.
Thanks,
JW
We have a concept for tables that would be able to support N dimensions. Just need more engineering resources.
We are adding nested structures to UDTs though, which will make them much more powerful.
I've commented on this before, but it really is pretty easy to implement 3D arrays in MATH boxes. I think most don't want to, but it's not difficult.
-
I've commented on this before, but it really is pretty easy to implement 3D arrays in MATH boxes. I think most don't want to, but it's not difficult.
It's all about the syntax, man! Not only a clean syntax for referencing an n-D array MyArray[D0,D1,V12] that makes the MATH box easy to read, but also some built in axis-aware array functions like being able to return a subset array MyArray[,3,V100..V100+10], etc., possibly transpose to different dimensions on the fly. Plus -- it would be nice to be able to use the resulting n-D arrays in other places than MATH boxes.
While we're on the topic of making MATH boxes easier to read, I have a couple requests:
- Store linebreaks, etc., in the expression but ignore them at evaluation time. That way you can input a complex expression with the hierarchy clear so the user can follow the logic.
- Ease up a bit on Mad Parenthesis mode. The UI inserts extra sets even if they have no effect on execution order. For me at least, unnecessary parens clutter up the expression and make it harder to read. Also potentially allow other optional characters for grouping. I know square brackets are in use, but maybe curly braces? That would allow easier quick pair matching visually.
MATH D10 "((D0 + D1 + D2) - D3) - D4"
-
I've commented on this before, but it really is pretty easy to implement 3D arrays in MATH boxes. I think most don't want to, but it's not difficult.
It's all about the syntax, man! Not only a clean syntax for referencing an n-D array MyArray[D0,D1,V12] that makes the MATH box easy to read, but also some built in axis-aware array functions like being able to return a subset array MyArray[,3,V100..V100+10], etc., possibly transpose to different dimensions on the fly. Plus -- it would be nice to be able to use the resulting n-D arrays in other places than MATH boxes.
While we're on the topic of making MATH boxes easier to read, I have a couple requests:
- Store linebreaks, etc., in the expression but ignore them at evaluation time. That way you can input a complex expression with the hierarchy clear so the user can follow the logic.
- Ease up a bit on Mad Parenthesis mode. The UI inserts extra sets even if they have no effect on execution order. For me at least, unnecessary parens clutter up the expression and make it harder to read. Also potentially allow other optional characters for grouping. I know square brackets are in use, but maybe curly braces? That would allow easier quick pair matching visually.
MATH D10 "((D0 + D1 + D2) - D3) - D4"
Design details don't matter to users, only the (unpleasant) user experience, but the issue is that we don't store source. Everything is regenerated from PLC opcodes. We will be changing that when we add our C-like structured text variant. When that happens, you may find it preferable to MATH boxes, but MATH boxes could probably also store source with formatting, so it may become moot.
I suppose it would be simple enough to have an option that would generate the MATH text without verbose parens, but we chose that because operator precedence bites people. Verbose, while annoying, eliminates that confusion. And for the record, I use far more parens now at 57 than I ever did as a young guy. It isn't because I don't understand operator precedence, it's because I want to be completely clear about what I was thinking when I coded it.
As for multidimensional arrays, I can't give you what you want. It simply isn't possible with our current architecture. I offered that as a workaround. There really isn't anything more I can do, no matter how bad I'd like it to be different.
-
Design details don't matter to users, only the (unpleasant) user experience, but the issue is that we don't store source. Everything is regenerated from PLC opcodes. We will be changing that when we add our C-like structured text variant. When that happens, you may find it preferable to MATH boxes, but MATH boxes could probably also store source with formatting, so it may become moot.
Looking forward to both those developments, especially the ST!
I suppose it would be simple enough to have an option that would generate the MATH text without verbose parens, but we chose that because operator precedence bites people. Verbose, while annoying, eliminates that confusion. And for the record, I use far more parens now at 57 than I ever did as a young guy.
I figured that might be the case. As far as age goes, I'm 58 so you might change your mind next year! ;)
As for multidimensional arrays, I can't give you what you want. It simply isn't possible with our current architecture. I offered that as a workaround. There really isn't anything more I can do, no matter how bad I'd like it to be different.
I get it, it's just when you bring up the topic I can't help myself! :D (Plus the n-D array implementation you're discussing on other threads is probably at least a 95% solution anyway, so no worries!)
-
I figured that might be the case. As far as age goes, I'm 58 so you might change your mind next year! ;)
I already hate the visual clutter. The need for logical clarity simply overrides the need for visual clarity. That said, storing the source will come with text, and that could easily extend to MATH and we've talked about it.
-
While we're on the topic of making MATH boxes easier to read, I have a couple requests:
- Store linebreaks, etc., in the expression but ignore them at evaluation time. That way you can input a complex expression with the hierarchy clear so the user can follow the logic.
- Ease up a bit on Mad Parenthesis mode. The UI inserts extra sets even if they have no effect on execution order. For me at least, unnecessary parens clutter up the expression and make it harder to read. Also potentially allow other optional characters for grouping. I know square brackets are in use, but maybe curly braces? That would allow easier quick pair matching visually.
MATH D10 "((D0 + D1 + D2) - D3) - D4"
How about color coding parentheses like Excel does in formulas, or code editors tend to do? That alone would help the readability quite a bit.
I regularly find myself looking for a way to simulate or test formulas, instead of creating variables, writing it to PLC, populating variables, seeing just how it is outputted, tweak formula, write to PLC, confirm proper output, adjust formula to use real variables, and write back to PLC, finally using the new complex-ish formula in the program. Perhaps a menu in DmD or even a webpage where we could type the formula in a box, it creates a table of the variables, can apply a value to the variables to play with formulas? Then when complete could just copy and paste it into the program and away we go.
-
I regularly find myself looking for a way to simulate or test formulas, instead of creating variables, writing it to PLC, populating variables, seeing just how it is outputted, tweak formula, write to PLC, confirm proper output, adjust formula to use real variables, and write back to PLC, finally using the new complex-ish formula in the program. Perhaps a menu in DmD or even a webpage where we could type the formula in a box, it creates a table of the variables, can apply a value to the variables to play with formulas? Then when complete could just copy and paste it into the program and away we go.
That was the original purpose of the Simulator. Launch a 2nd instance of Designer and create a NEW online project to the Simulator (don't muck with your actual project). Write a code snippet (a MATH formula or ladder logic), write it to the Simulator and test it out. You already know how to monitor and edit values (Data View, Change Value). You can even use the Simulator to manipulate WX values using sliders to manipulate input values if you want.
-
Speaking of the Simulator, will it be possible at some point in the future to run the Simulator from within your current project on your current code? The Simulator as is is useful but it gets tiresome hopping from the Simulator back to your project to test things out.
-
Speaking of the Simulator, will it be possible at some point in the future to run the Simulator from within your current project on your current code? The Simulator as is is useful but it gets tiresome hopping from the Simulator back to your project to test things out.
It does that (we added that in 2.6). Open up your disk project, then hit the Simulator button on the Online toolbar and it will automagically write your offline project (say BRX or H2) to the Simulator.
-
Well, don't I look sheepish. How does the simulator handle configurations with remote I/O?
-
Well, don't I look sheepish. How does the simulator handle configurations with remote I/O?
It talks to the remote I/O.
-
Well, don't I look sheepish.
Don't feel bad - we add tons of features every release (hardware, firmware, software). It's hard for US to keep track of them all :)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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 |
+-------------------------+
-
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.
-
I can't think of anything to suggest, those ideas all look right to me.
-
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).
-
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)"
Does this imply that we would also be able to create our own Functions? In this case Pythagorean?
-
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)"
Does this imply that we would also be able to create our own Functions? In this case Pythagorean?
Yes, this is ALL about USER CREATED MATH Functions, User Boxes, and Objects. I just used Pythagorean as an example, along with the CART2POLAR and KETTLE object.
-
Just for clarification...
The Math Function and User Box execute the logic and return a result AT THE POINT the instruction is evaluated...right?
The Objects example, however, is only enabling a program block and the code is not evaluated and executed until the scan reaches the this code block. So, placement of this code block within the Execution Order can determine whether the block is evaluated on the current scan or subsequent scan...correct?
I'm just trying to make sure I have an understanding of your intentions with each example.
-
Just for clarification...
The Math Function and User Box execute the logic and return a result AT THE POINT the instruction is evaluated...right?
The Objects example, however, is only enabling a program block and the code is not evaluated and executed until the scan reaches the this code block. So, placement of this code block within the Execution Order can determine whether the block is evaluated on the current scan or subsequent scan...correct?
I'm just trying to make sure I have an understanding of your intentions with each example.
You got it!
The location of the object code block above or below the corresponding RUN instruction containing code block(s) should not matter 99.9% of the time, although it could, so yes, you can definitely organize the execution order of objects on an INSTANCE by INSTANCE basis. For example, if you have 10 instances of a specific object type, 5 could be above $Main, 5 could be below $Main in execution order (you decide), even though there is only 1 copy of the logic (that code will utilize indirect reference type parameters for each object parameter). That's the plan.
-
You got it!
The location of the object code block above or below the corresponding RUN instruction containing code block(s) should not matter 99.9% of the time, although it could, so yes, you can definitely organize the execution order of objects on an INSTANCE by INSTANCE basis. For example, if you have 10 instances of a specific object type, 5 could be above $Main, 5 could be below $Main in execution order (you decide), even though there is only 1 copy of the logic (that code will utilize indirect reference type parameters for each object parameter). That's the plan.
Thank you for the clarification, Franji.
-
Side Question
Any plans to allow passing of entire UDT's in the USER BOX parameters?
-
Side Question
Any plans to allow passing of entire UDT's in the USER BOX parameters?
That should work. All structures (including UDTs) would be passed as a reference.
The one thing we probably could NOT support is a data-block/array, but there may be some alternatives in the future to allow for processing of large blocks of data.
-
What about a simple array or strings?
-
What about a simple array?
Currently, no.
For example, say you wanted to take an average of a block of simple numeric types called MyAvg, currently there are no plans to do
MyAvg D
MyAvg V
MyAvg N
MyAvg D1000 D1999
HOWEVER, we will be providing a DIFFERENT MECHANISM (using the concept of Tables), which can provide capabilities you are probably wanting.
or strings?
A single string? Yes. An array (i.e. block) of strings? No. However, regarding TABLEs, we probably need to incorporate Tables of UDTs or Strings or other structures.
-
Private memory inside the functions and objects would be nice to have (as well as a hierarchy of memory visibility throughout the project), but that's a minor point, comparatively. Some future version could implement that.
-
Could one of you experts post a bare-bones programming example of what this thread is about?
-
Could one of you experts post a bare-bones programming example of what this thread is about?
Is this what you are seeking:
https://forum.hosteng.com/index.php?topic=3401.msg27501#msg27501
-
For example, say you wanted to take an average of a block of simple numeric types called MyAvg, currently there are no plans to do
MyAvg D
MyAvg V
MyAvg N
MyAvg D1000 D1999
HOWEVER, we will be providing a DIFFERENT MECHANISM (using the concept of Tables), which can provide capabilities you are probably wanting.
I have used the BRX for a co-processor to receive data from a serial or EIP device and crunch a bunch of numbers on different data sets. It seems that I had to either duplicate code to be work on each specific data set or copy large chunks of data from a memory area, but that takes time . If I had a mechanism to just specify that here is the UDT of data, use that. I hope tables could help that situation.
-
I have used the BRX for a co-processor to receive data from a serial EIP device and crunch a bunch of numbers on different data sets. It seems that I had to either duplicate code to be work on each specific data sets or copy large chunks of data from a memory area, but that takes time . If I had a mechanism to just specify that here is the UDT of data, use that. I hope tables could help that situation.
Currently, could the REF MATH function (https://hosteng.com/DmDHelp/Default.htm#Instruction_Set/REF_Read_Value_Indirectly.htm) work with that?
REF(V0, V1)
So if you had 3 user blocks at #32, #33, and #34, then you could set the block # (V0) to 32 (then 33 then 34) before each call of your code? (I would guess that V1 is just a FOR loop in your crunching?).
If you need to massage the data, the REFWRITE BOX (https://hosteng.com/DmDHelp/Default.htm#Instruction_Set/REFWRITE_Write_Value_Indirectly.htm) (not MATH function) is the WRITE version of REF. It takes 3 parameters, the new value, the block#, and the ID#.
-
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)"
Does this imply that we would also be able to create our own Functions? In this case Pythagorean?
Yes, this is ALL about USER CREATED MATH Functions, User Boxes, and Objects. I just used Pythagorean as an example, along with the CART2POLAR and KETTLE object.
Is Pythagorean defined within a normal MATH instruction or would it be defined in its own type of function Code-Block?
-
Is Pythagorean defined within a normal MATH instruction or would it be defined in its own type of function Code-Block?
No, it's not currently defined.
That is an example of MATH Function YOU could write and use. (Those dang Host people didn't provide a Pythagorean function? Well, I'll just write my own, thank you ;D).
-
Is Pythagorean defined within a normal MATH instruction or would it be defined in its own type of function Code-Block?
No, it's not currently defined.
That is an example of MATH Function YOU could write and use. (Those dang Host people didn't provide a Pythagorean function? Well, I'll just write my own, thank you ;D).
I know Pythagorean is not a current function. That's not what I'm asking. I'm asking how a user defined function will actually be created. I'm asking if the user defined function will be created inside of a MATH instruction or if it will be created in its own Code-Block called "Function".
-
I know Pythagorean is not a current function. That's not what I'm asking. I'm asking how a user defined function will actually be created. I'm asking if the user defined function will be created inside of a MATH instruction or if it will be created in its own Code-Block called "Function".
They will be code-blocks. We currently have 3 different code-block types, PROGRAMs, TASKs, SUBROUTINEs. You will be able to create FUNCTIONs, USER BOXes, and OBJECTs. These new ones may or may not be part of a Library mechanism - we'll see.
So, after you create the FUNCTION Pythagorean, you would open up that code-block, write the code. So then it will be accessible just like SIN, SQRT in all your MATH boxes, and most likely across all your projects, not just the one project you created it in (i.e. the source logic will be in a Library facility).
If your question then is, the Pythagorean code block will be IMPLEMENTED using a MATH box in it, e.g. SQRT(P1**2 + P2**2), could you technically recursively call it. Yes, just like current Subroutines are recursive, Functions could be recursive. For example, a lazy but optimized evaluation of Fibonacci values, i.e. see if you've already evaluated Fib of P1, if so, return that value, if not then return P1 + Fib(P1-1).
-
I know Pythagorean is not a current function. That's not what I'm asking. I'm asking how a user defined function will actually be created. I'm asking if the user defined function will be created inside of a MATH instruction or if it will be created in its own Code-Block called "Function".
They will be code-blocks. We currently have 3 different code-block types, PROGRAMs, TASKs, SUBROUTINEs. You will be able to create FUNCTIONs, USER BOXes, and OBJECTs. These new ones may or may not be part of a Library mechanism - we'll see.
So, after you create the FUNCTION Pythagorean, you would open up that code-block, write the code. So then it will be accessible just like SIN, SQRT in all your MATH boxes, and most likely across all your projects, not just the one project you created it in (i.e. the source logic will be in a Library facility).
If your question then is, the Pythagorean code block will be IMPLEMENTED using a MATH box in it, e.g. SQRT(P1**2 + P2**2), could you technically recursively call it. Yes, just like current Subroutines are recursive, Functions could be recursive. For example, a lazy but optimized evaluation of Fibonacci values, i.e. see if you've already evaluated Fib of P1, if so, return that value, if not then return P1 + Fib(P1-1).
This is what I was after. New Code-Blocks where FUNCTIONs are Implemented using a MATH box.
-
This is what I was after. New Code-Blocks where FUNCTIONs are Implemented using a MATH box.
It doesn't necessarily have to have a MATH box in the implementation. It could be a bunch of ladder logic to resolve some boolean expression, or INCs or LERPs or very complex IF/THEN/ELSE that is better implemented as Ladder Logic, not a bunch of nested IF(IF(IF(... type expressions in the calling MATH box.
As long as the value returned is a bit or numeric, and there are no asynchronous instructions, anything goes. It's just a code-block with a RETURN VALUE at the end (similar to Subroutines requiring RET at the end).
A specific MultiDimensionalArray (MDA) function could be written that you could then do
R[MDA(D10, D21, D7)] in the calling MATH function, where MDA is hard coded for a 3 dimensional array the size [5][10][40] of 2000 R's occupying R1000 through R2999. So MDA would be a MATH of returning the straight array index of the 3D coordinates P1, P2, P3 as 1000+(P1*10*40)+(P2*40)+P3. [ 0][1][2] (i.e. MCA(0,1,2)) would return the R index of 1000+(0*10*40)+(1*40)+2 or 1042. [4][9][39] (i.e. MCA(4,9,39), the highest index of each dimension) would return 1000+(4*10*40)+(9*40)+39 or 2999. This is basic C multi-dimensional array arithmetic for accessing linear memory (all flat multi-dimensional memory is linear at the processor level).
-
:o Didn't think of that!
-
It doesn't necessarily have to have a MATH box in the implementation.
[/quote]
How is the Function called? Does it have to be called within a MATH box or can it be called like other built-in functions on its own ladder rung?
-
How is the Function called? Does it have to be called within a MATH box or can it be called like other built-in functions on its own ladder rung?
We'd like to have both.
-
How is the Function called? Does it have to be called within a MATH box or can it be called like other built-in functions on its own ladder rung?
MATH Functions, by definition, are only usable in MATH boxes.
User Boxes are what you are probably calling "built-in functions" that are boxes on its own ladder rung.
Here are the terms that I defined earlier in this thread to help with our discussion
https://forum.hosteng.com/index.php?topic=3401.msg27501#msg27501
Function Blocks, Function Block Diagrams, Functions, Math Functions - each of those have different meaning in various languages, hence why I tried to scope out the difference between MATH Functions, User Boxes, and Objects so that everyone can be on the same page.
-
I know Pythagorean is not a current function. That's not what I'm asking. I'm asking how a user defined function will actually be created. I'm asking if the user defined function will be created inside of a MATH instruction or if it will be created in its own Code-Block called "Function".
They will be code-blocks. We currently have 3 different code-block types, PROGRAMs, TASKs, SUBROUTINEs. You will be able to create FUNCTIONs, USER BOXes, and OBJECTs. These new ones may or may not be part of a Library mechanism - we'll see.
So, after you create the FUNCTION Pythagorean, you would open up that code-block, write the code. So then it will be accessible just like SIN, SQRT in all your MATH boxes, and most likely across all your projects, not just the one project you created it in (i.e. the source logic will be in a Library facility).
If at all possible, the Library mechanism needs to be a thing. One of the most frustrating aspects of using the BRX currently {for my typical use case), is trying to establish a code base that can be reused between projects. Without local/global variables, importing portions of code from other projects is tedious because of potentially re-used variables. Trying to establish a code base requires a great deal of pre-planning or a lot of clean up work on the back end. Without a library mechanism, I see this being the same issue for these new features. From an end user perspective, I would like to be able write one of these new features once and have it saved in a code base where I can easily pull it into a new project with no fuss. I don't want to have to manually export UDTs, re-import them into the current project etc. to get one of these new features to work in another project. Without a library, these features will be useful but only limitedly so.
-
Going to be starting a new job in about a week as the sole EE. I am going to try to talk the new job into using BRX instead of the slightly cheaper PLC that they had talked about in my interviews. Copy/Paste and doing imports is a clunky workaround, but it is a workaround. I know I would like the library to exist, to be able to have the add-on functionality of the two 800 pound PLC gorilla's would be an amazing time-saver.
-
If by the two 800 lb PLC gorillas you mean AB and Siemens, I don't think I'd put them in the same group. Siemens' library facility is vastly superior to what I've used with AB (though admittedly it's been a while).
-
If by the two 800 lb PLC gorillas you mean AB and Siemens, I don't think I'd put them in the same group. Siemens' library facility is vastly superior to what I've used with AB (though admittedly it's been a while).
I dislike both which is why I want one that is done right and gets the BRX closer to the same functionality. It's a lot easier to knock over the competition when there aren't any strawman arguments about, "There's no Add-ons", "I don't have local variables", "It doesn't do EIP Implicit.", etc, etc. I know this stuff takes a while to develop and I'm willing to wait.
-
What's not to like about Siemens? I think it's excellent. With BRX, those are my top two go to platforms.