First of all, apologies if this is the wrong forum. Hopefully the moderators will move the post if it is.
Without going too deep into the weeds, I am in the process of implementing a project, where a three groov EPICs will be controlling approximately 75 devices. Each device has (round numbers) a dozen parameters that will be used by the logic. I am trying to avoid having to wrangle 300 variables per EPIC.
My question is: is there something along the lines of C/C++ structs in OptoScript? I saw table variables in the PAC software, but they seem fairly limited.
As one who has programmed Opto devices to control a bunch of four pipe fan coils, it would be awesome if we could have struct types in PAC Control (and local vars), but we have to make do with what is there.
The general idea is to write your program as if you are controlling one device (and even test it if you can), and then surround the logic in a loop and grab the data you need from tables. I have a comment on using MS Excel* to help build initialization tables in Optoscript. It makes managing projects like this a bit easier and less tedious. I’m not the only Opto user to use that method.
*I actually use Libre Office, because Excel does dumb things when I copy and paste the generated Optoscript, it’s almost like it’s Microsoft’s goal to get us to use something else…
1 - Yes and no. The vast majority of the devices are basically the same, but small variations exist.
2 - Subroutines yes, pointers also yes. The pointers are kind of neat in the context, but there still has to be individual variables to point to and that’s what I’m trying to avoid.
Philip:
Thanks for the link. I get what they’re trying to do, but it seems that anything with a larger state is perhaps outside the scope of OptoScript. In my mind’s eye I see several arrays, one for each type of struct representing a device, and the logic loop (or loops) iterate through each array.
I guess I’ll have to be ok with the baroque licensing procedure for Codesys.
Larger state? Not sure what you mean by that, but handling 75 devices with a dozen parameters isn’t a big deal in Optoscript. I work on projects with three times that. Each table would represent a “member” of your “struct” and each index of the table would represent a device. For devices that have differences, you could have a table that is checked in your script that checks if that option is available.
The only thing that would need individual “variables” are your physical points. I typically already have these in a spreadsheet, and then write an excel formula to build the Optoscript initialization to get them into pointer tables.
By that I mean that OptoScript is simply not the ideal language for keeping track of large-ish states. Involving a second programming language (Excel formulas) to generate the various pointer tables is a contrivance indicative of poor fit.
While clearly doable, it would seem to me that a greenfield project would benefit from using technologies, in this case a selection of development environment, that is more closely suited to the requirements.
There are many programming environments that involve some sort of scaffolding (often in a different “programming language”) to avoid hand typing large amounts of initialization logic. These are typically integrated into a larger framework (in the mainstream software engineering context), but at that point it is semantics.
I’m in agreement with you in your desired feature for having structured datatypes (and might as well also request local variables, multi-dimensional arrays, dynamic memory allocation, etc.). However, I disagree that Optoscript is outside the scope of what you have described you need to do. 75 devices, with a dozen parameters means “wrangling” a dozen tables, not 300 variables. That is a tiny project that Optoscript can easily handle.
