Approximately once every 6 months when in PAC Control debug mode connected to an S2 and Mistic G4 Bricks (I know these is dinosaur I/O’s) and manipulating a state of a DI or DO by disabling the point and then changing the Ival or Xval and then pressing APPLY, the controller disconnects from the debugger. Then when I switch back to Debug, the controller had reset, and all non-persistent values are back to their default values. This is quite a headache for some of our batch step processes. Has anyone else seen this?
No not many errors on this process. What I am suspicious is issues with Opto OPC with a Secondary scanner = This Computer. When the Primary scanner times out and my workstations switch to This Computer, as expected, the controller loop time increases from well under 100 to 140 or or more msec. This was when the controller crashed as I was manipulating an I/O. I have since eliminated the secondary scanner to see if the issue goes away.
I am also seeing a strange issue with PR2’s and all EPIC hardware which could also be due to the switching to the secondary scanner. The PR1/2’s in the field configured as brains on a rack with PID’s stop updating any directly read variables to PAC Display such as SETPOINT, INPUT, OUTPUT, GAIN, etc. The variables in Display runtime turn red and show xx. What is even more strange is the SEND VALUE attribute works and you can see this change when looking at the PID in debugger mode. I have also eliminated the secondary scanner in all projects in hopes of both of these issues to go away. The only way to get the displays to read normal again is by conducting a RESET in GROOV view when connecting to the PR1 running as a brain with the PID loop in question.
