Let me add my 2 cents…
Everything Beno said and…
There are a lot of ways to structure your strategy. My approach is usually less charts, just for simplicity and to prevent stepping on other processes when using same vars. There is no reason you can’t put everything in one chart (not powerup). If properly organized, this works fine.
How are you handling the IO reads and writes? If you’re doing direct reads and writes, then a larger strategy will suffer on speed due to time lost on access to each point. If you block read, I suggest you so so in one chart, you do not necessarily need to sync the other charts, but this depends on how critical the timing is for each process. If for the most part an IO input point does not need to be read at screaming speed (10 ms or 50ms) of an output does not need to happen any faster than most requirements (say 500ms), then set the main loop chart that reads everything to 500ms loop time. If you decide you need more speed, you can ratchet it down later.
Next, you can do the outputs, either by writing directly if they need to change (exception) or just write block the entire rack at the end of each chart. If you block read and block write, you should have plenty of power, especially if you use the latest GEN 2 R1, it is nearly 3 times faster.
In order to do exception writes, you can block read all IO including outputs (you do anyway when you block read, then compare the latest state to the internal variable state and decide if it needs to be written.
The Pac Controllers are still at 100meg ethernet, whereas the Epic is gig, which does make a difference if you’re hammering a lot of IO.
If your chart strategies are completely separate, then you could read and write in each separate chart, but since the charts have no built in management over sync, then it up to you to ensure that one process is not jamming another at the ethernet stack, this can vary like you mentioned you are having problems with because each chart will not loop at same speed or time.
Each chart has a time slice of 500usecs, and the amount of processing handled in that period of time is considerable. Make sure you are keeping the freq of reads and writes down to a minimum, even at 100meg, this still takes way more time that processing a whole bunch of logic.
The internal speed is so fast that creating vars that are like named as IO points such as New_Point_di and the variable as New_Point_din and using block read to a table such as Rack1_fTable, then unloading all the IO Point states into the respective internal vars such as New_Point_din = Rack1_fTable[989]; is not a problem. So you can create all these vars in Excel and import them into the strategy and then use Excel again to write this statement for all 1000 vars for example and just paste them into a script block. This way, you know wha tthe var is and that it is a reflection of an IO point.
Lastly, naming convention can not be stressed enough. Consistency is paramount. Don’t use double underscores, don’t use too many underscores and limit the length of the name. Opto’s convention is to prefix the var with data type, personally, I prefix my vars with the portion of the process it is associated, then the equipment name and then the type of var it is. So, P1_Tank_Level, or P1_TankLevel_ain or P1_TankLevels_fTable.
