I did a project last year that involved using the ISA Algorithm in a PID. That project was written in PAC Control 9.3. I am using PAC Control 9.6c. When I try to use the PID Loop, it says ISA Obsolete and I can still chose it from the list, but for some reason it sets my Lower Clamp to -0 and my Positive Clamp to 0 (in Debug Mode). Which makes the Loop useless. Any thoughts of what I can do?
Just use the new ISA, not the obsolete one.
This KB has a lot more information on the change.
http://www.opto22.com/site/knowledgebase/kb_view_article.aspx?aid=2159
I would use the “new” one, but it does not work the same as the obsolete one.
Hmmm. Ok, odd.
Please email support@opto22.com and they can start working the issue with you.
Ok, will do. I just thought it was something simple I was missing.
Thank you.
So I figured out what was wrong with the PID loop. The clamping settings had a null value in the configuration of the card (-10 to +10 analog card) So the PID would not command it correctly. How that erases, I have no idea. Also, I want Opto to be aware that if you create a PID and associate an output to that PID (ex a reference voltage) and then you delete that PID and not assign that PID to something else, it keeps the information and writes a zero to the previous “reference voltage” . This is not good. The only way to clear the PID completely (if your are deleting it) is to recreate and use Host for the output and then delete it. Hope that makes sense. I hope you can recreate this problem and fix it. Thanks.
Huh. Wow. Yeah… Never seen that before…
Just a few quick questions.
Did you work with support on this? (If so, they will have the details and can get the software engineers to work on it).
Is this with a SNAP system?
If so, did you look at the PID loop in Pac Manager at all?
I can see how that took some time to dig into and get sorted.
Thanks a heap for following up, really appreciate that, makes these forums so powerful and useful.
No I did not work with tech support on this. This is a SNAP PAC R1, firmware 9.5c. The software version is 9.6c Feb 28, 2017.
I did not look at the PIDs in PAC Manager (not that I recall anyways). However, when I went to debug mode it had a message that says something about PAC Manager and blah, blah blah PID Loop # 6. It was weird because I deleted PID Loop #6 in PAC Control earlier that day. Another PID was trying to command an analog output and Loop #6 was continuously trying to write a “0” to the same output point even though it was deleted. Like I said I just made a new loop to #6 and just chose Host for input, setpoint and output. Debugged. Then went back to Configure, deleted Loop #6. Debugged again and the problem and error message was gone.
I’ve seen this before and figured it was by design. If you delete a PID from PAC Control, all it does is no longer download (configures?) that PID in the brain - so the brain will still have the PID configured. It seems strange at first, but if you think about scenarios where you have a brain in different strategies (for scratchpad use, or whatever) you wouldn’t want one strategy wiping out all your PIDs that were configured in another strategy. Fortunately there is a warning about PID loops being configured outside the control engine (or whatever it says) - which is probably the message you saw. PAC Manager is the for sure way to get rid of unneeded PID loops - and don’t forget to save to flash after changing/tuning PIDs!
Perhaps an option can be added when deleting a PID that will prompt if you want to clear the PID in the brain?
I think you are 100% correct. I completely understand what happened now. And yes PAC Manager would be the correct way to remove a PID. It was frustrating to troubleshoot the problem because a PID writes to the output so fast that it is hard to see the output change from, for example a 2.0 to 0.0. Maybe there should be an option to clear that PID. I assure you I will never forget this issue. Things could have been worse. Fortunately all is well.
Thanks Ben and Philip.