I have written a serial execution program that is longer than the 2000 bytes available for a single program on the device so I am wondering what the options are to proceed:
- The Control Basic documentation says that the CALL function is not yet implemented. Is this accurate? I ask because the documentation does not include the updates about local variables and still references the A-Z variables. If this were/is available, would this be the correct means to break up the program?
- Is the execution order serial such that program 1 runs, then program 2, program 3, etc. so that variables could be used to pass to pass between programs?
- How difficult would it be to enable the number of programs on the device to be toggled to trade off programs vs memory, eg 16x2000 bytes, 8x4000bytes, 4x8000 bytes, etc?
I am pretty sure there is no CALL working, chelsea could spend some time on that soon.
She could also bump up the program size while she’s at it, there’s no good excuse for this 2k limitation. That said, it is a lot of logic all right. What are you actually doing! Just curious.
To answer your questions about the order of execution, there’s no fixed sequence. You can assume the programs are basically all ‘running at the same time’ and at the same level of priority.
The work around as you mentioned is to separate the logic into separate programs. Use one program that will be in charge of calculating a variable that sets the MODE of operation for example. Then act on that MODE in a separate program.
1 Like
Regarding the use of so much logic in one program, in some regional areas where we have customers, there is time of day pricing that varies considerably. The logic is mostly around reading a variable-defined table that contains information used to shift energy usage away from peak times where possible. This was one of the reasons I was asking about the TBL function since its applicability to variable tables could make retrieval of table entries less logic intensive.
Chelsea will report back about the TBL, we do need that and hopefully its working. If not it will be soon.
1 Like
Hi Maurice,
As of now, the 2K program size limitation is proving to make bug resolution problematic. We have 4 programs that should be one linear program all running at one time and the results are often unpredictable because they run independently without coordination. Did your team discuss the complexity of allowing the program size to be adjustable or just larger in general?
Has there been any discussion on the option for TBL capability to be used to pull values from the variables? Such capability would also reduce the size of programs since much of the logic is in indexing variable values to provide a dynamic value table functionality.
At present, our program code is a fixed size, each of which is 2k. They run one by one from 1 to 16. The running order of program code is not random. So it should be possible to split a large program into multiple programs in order. In addition, as for the table, we haven’t added it yet and will consider adding it as soon as possible.
Update: Do use caution becuase we have not tested this scenario well.
TBL function is on the todo list for the near term, a week or two.
1 Like
Hi Chelsea,
Maurice had indicated that maybe allowing the program size to be increased was an option so I was wondering if that was something that had been discussed after I had posted the original message. It would make the program easier to debug. Some additional TBL functionality would certainly make a number of task easier as well since arrays and maps are pretty standard functionality in programming.
Thanks,
Jason
The larger program size is definitely on the drawing board.
In the meantime: I would not change a VAR in anything but a single program. The system would not know when to actually send the value of the VAR or any OUT for example, to the real world. Should it do that after program1, program 2 or program 16. I would not trust our system with anything other than one program working the one item.
We will have a hard look at increasing the program size, it will likely come out on the upcoming ESP32 based products.
I strongly urge you again to break your program up into sections. Embed all the logic for a particular mode or whatever, embed that all in one program into a VAR. Then use that VAR in other programs but do not adjust the VAR in the other programs.
The TBL function should be working, Chelsea will help make it happen.
See my other reply about the large program sizes. We’ll do what we can but i really suggest breaking it up and embedding the logic into VARs which then be used in other programs. It will help keep your programs simple, easier to debug, right.
Update: Another advantage, you can put these vars (modes) on the displays and trend logs for long term debugging.
1 Like
Breaking up the program and trying to confirm expected operation continues to be rather problematic. We have broken up the logic into 7 buckets although the program is only about 10k in total size because each of the logic blocks is just large enough such that we cannot put them in the same bucket.
As for the TBL logic, we have not seen a T3000 update that would include it. We are also not sure if it is going to provide the logic to allow table style lookup of variable values, which is what would enable a reduction in the size of our logic. Documentation of its operation would definitely be helpful.
That is some chunk of logic you are running there. Chelsea will put a push on the TBL function, making sure it works and beefing up our documentation about it. Thanks for your efforts with our equipment.
Update: TBL function is working now. Turns out Jason was after something a little different though… we tried.
1 Like