Excellent, I’m glad you’re taking advantage of the distributed logic for just the reasons you mention: network could go down, self-regulation, etc. If you were NOT using chart logic at the I/O then you could (in most cases) just use a brain, like and SNAP-PAC-EB rather than your SNAP-PAC-R1.
Since an R1 is a controller + brain, the answer to your “do the charts live at the same place” is yes, they’re both on the R1. And the mem map is the glue that connects them. (If you had an S1 + EB1 the answer would be no: charts run in the S1, IO including PID loops happen in the EB1.)
You certainly would NOT want to write your strategies using anything but PAC Control, which is only Windows, so you can’t get away from Windows completely and keep your charts/strategies. Once they’re written, however, you could download and start your strategy/strategies via Linux without too much programming. The strategy is still Forth as you mention, underneath, although not EXACTLY the same Forth as what you might’ve used in OptoControl (since how we handle communication, I/O, etc. has changed). So Forth words or init files or custom drivers that worked w/OptoControl would NOT work with PAC Control.
Pretty much the only thing Forth-wise that’s officially supported/documented in PAC Project would be setting values for variables, which goes with what you might’ve seen when configuring a variable, the: “Initialize on strategy download” option. The corresponding Forth code is described in form 1700 (just search for that number on our website or it’s also under Help->Manuals->User’s Guide in PAC Control). If you search for “download options” in that form then scroll up a bit, you’ll see where all that syntax is documented:
A note on your MMI question: PAC Display has an option to access I/O either through the control engine or directly through the I/O Unit’s mem map (which is “better” varies depending on your situation).
Keep those good questions & ideas coming!