Feedback wanted: Instantiable programs concept

[BobO]

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

[jwbaker3]

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

[BobO]

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.

[Controls Guy]

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.
  

Code: [Select]

MATH D10 "((D0 + D1 + D2) - D3) - D4"

[BobO]

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.
  

Code: [Select]

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.

[Controls Guy]

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!      (Plus the n-D array implementation you're discussing on other threads is probably at least a 95% solution anyway, so no worries!)

[BobO]

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.

[Bolt]

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.
  

Code: [Select]

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.

[franji1]

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.

[RBPLC]

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.

[franji1]

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.

[RBPLC]

Well, don't I look sheepish. How does the simulator handle configurations with remote I/O?

[BobO]

Well, don't I look sheepish. How does the simulator handle configurations with remote I/O?

It talks to the remote I/O.

[franji1]

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 

[durallymax]

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.