Page 1 of 2 12 LastLast
Results 1 to 20 of 29

Thread: Learning Metasys and CCT

  1. #1
    Join Date
    May 2020
    Location
    NY/NJ
    Posts
    7
    Post Likes

    Learning Metasys and CCT

    I recently started at a new company that does Metasys and FX. I'm looking for resources on programming in CCT. I have a few years of experience with ALC/WebCtrl, so I'm not new to the field or programming. I understand PID loops, network I/O vs hardware I/O, and I'm slowly beginning to understand the state tables that CCT revolves around.

    I've watched a few youtube videos, read some of the help guides, and spent some time looking through CCT on my own. I have too many questions to ask all at once, but I will list some off the top of my head.

    What are the advantages of sideloops vs just adding logic/modules to the main program?
    What are passthroughs in terms of logic? Something about network inputs becoming a state table?
    Can I create custom "passthroughs" myself? (the pre-built CCT programs have water flush passthroughs for example)

    In ALC/WebCtrl, you can load a single program file into as many controllers as you want, but for Metasys I was told you have to change the name of the program file to be unique for every controller? Is that true and why?

    Has anyone else made the jump from ALC to JCI? Maybe you can share a little more...

  2. #2
    Join Date
    Apr 2014
    Posts
    700
    Post Likes
    No real advantage to adding a side loop vs just adding the modules. Sometimes it may be quicker to add a side loop then go back and edit those stupid names that it assigns.
    The pass through blocks are really just connection points to get into the state tables. I rarely ever used them in custom programs.
    The easiest way to learn is to build some programs from the selection tree to see some examples, then build a couple simple custom programs to and simulate them to test

  3. #3
    Join Date
    Apr 2014
    Posts
    700
    Post Likes
    You can load a single file into multiple controllers. No issues there. Take a look at the trunk utilities. There are a few interesting tools for automating such thing, and writing attributes (box flow parameters for instance) to multiple controllers.

  4. #4
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    3,285
    Post Likes
    Quote Originally Posted by WhoIs View Post
    What are the advantages of sideloops vs just adding logic/modules to the main program?.
    The only advantages I know of are
    1) old timers would find it familiar as that is how HVACPro worked.
    2) Johnson PIDs self tune. They use a block entered in the lover left below the hardwired inputs that monitors the stat of the outputs to turn off the tuning if the output the PID is running is overridden. ie the DAT PID will not try to tune if the CHW valve it is running is overridden. I know of no other way to make that happen in a completely custom way... Those blocks in the lower left only get there through the System Selection Tree, or by adding a sideloop... but my info is dated a little. It may have been introduced in the last few years.
    Honestly, a monkey can program CCT. It gets tough when you need to follow a sequence that is not Johnson generated... as it gets hard to know whether to just start from scratch or to bend the generated program to your will. I will say the auto generated programs have a lot of redundancies and contingency handling in them. It is most often best to start with an automatically generated program and bend it.
    One of the surest ways to tell a hacker was in there is when the states tables are unused, and there are just a few custom blocks, all with green triangles... or when nearly every block has a green triangle on it.... I know a guy that does that. It takes him twice as long to do anything and it works half as well....
    Hmmmm....smells like numbatwo to me.

  5. Dislikes Chopchop disliked this post.
  6. #5
    Join Date
    Apr 2014
    Posts
    700
    Post Likes
    Quote Originally Posted by numbawunfela View Post
    I know of no other way to make that happen in a completely custom way... Those blocks in the lower left only get there through the System Selection Tree, or by adding a sideloop... .
    You can add those no problem

  7. #6
    Join Date
    May 2020
    Location
    NY/NJ
    Posts
    7
    Post Likes
    Thread Starter
    Quote Originally Posted by numbawunfela View Post
    2) Johnson PIDs self tune.
    I've been looking into "PRAC". Do you have a simple explanation for the saturation time / tuning reset. I'm being told that sometimes the PIDs sometimes need to be "reset".


    Thank you for the replies.

  8. #7
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    3,285
    Post Likes
    Johnson PIDs will monitor the result of their control and rewrite their P and I terms as a result. Incidentally, they (Johnson software writers) do not really like D, there is a PID preprocessor that largely replaces D in most instances.
    So when a silly installer makes a valve stroke in reverse, the PID will do its darndest to work with it and will write pretty crazy values. It will take itself from 'holy crap this sucks' to just 'does not control well'. So it does quite well mostly.
    You get a service call and fix the valve, and now the wacky values are not helpful. So then you reset the tuning, so it starts in a normal spot. It will tune some, but at least you are not starting off in left field.
    Whenever the mechanicals experience a large change suddenly, it is often good to reset the PID.
    Hmmmm....smells like numbatwo to me.

  9. Likes stomachbuzz liked this post.
  10. #8
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    3,285
    Post Likes
    Off memory the saturation time is how long the PID will be calling for 100% signal before it throws a binary value saying he it 'giving it all she's got'. That often is ported to a second stage. Spit out a multistage sumthin program and look to see how it uses this.
    The metasys help is actually quite useful.
    In general I trust Johnson PIDs completely and they work fantastic 99% of the time. HVACPro PRAC PIDs had a habit of tuning themselves into a ditch. CCT PRAC+ PIDs largely avoid that and do quite well.
    Hmmmm....smells like numbatwo to me.

  11. Likes JCIman, stomachbuzz liked this post.
  12. #9
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    3,285
    Post Likes
    Quote Originally Posted by JCIman View Post
    You can add those no problem
    Thanks for the update. I tried like crazy to make that happen around 6.0, and never tried since. I will need to try again.
    Hmmmm....smells like numbatwo to me.

  13. #10
    Join Date
    Apr 2014
    Posts
    700
    Post Likes
    Quote Originally Posted by numbawunfela View Post
    Off memory the saturation time is how long the PID will be calling for 100% signal before it throws a binary value saying he it 'giving it all she's got'. That often is ported to a second stage. Spit out a multistage sumthin program and look to see how it uses this.
    The metasys help is actually quite useful.
    In general I trust Johnson PIDs completely and they work fantastic 99% of the time. HVACPro PRAC PIDs had a habit of tuning themselves into a ditch. CCT PRAC+ PIDs largely avoid that and do quite well.
    That’s pretty much it...when a pid gets to 100% the pid status goes from “normal” to “timing high”, then after the saturation time, the status goes from “timing high” to “high”. Then somewhere else in the application, you use that status point to either turn the pid off and lock the output at 100, or stage up another pid.
    Different process id’s have different saturation times, but PRAC doesn’t tune the saturation time.
    The main situation where PRAC will tune itself stupid is VAV reheats because the valves are typically way oversized.
    So PRAC sees that quick reaction when the valve barely cracks open, then tunes the prop band into the 10’s of 1000’s sometimes.
    They came out with the Lead Compensator block at 5.1 I think. It acts similar to derivative, and works pretty good on loops like VAV reheats. The reason they opted for the lead compensator vs just using derivative, it that D seriously hoses up PRAC
    The LC block is kind of a “baby D” that plays nice with PRAC.
    I agree that PRAC is great in general. I would say it will take care of over 95% of the loops. Unfortunately, I live in the other 5% world.

  14. #11
    Join Date
    Apr 2014
    Posts
    700
    Post Likes
    Quote Originally Posted by numbawunfela View Post
    Thanks for the update. I tried like crazy to make that happen around 6.0, and never tried since. I will need to try again.
    You always could add them, but it’s not immediately obvious how :-)
    The main trick is to add the one on the left and the actual output in pairs so the instance numbers are the same.
    I will fire up CCT one day soon, and I can probably give you a better step by step process. One of those things that I have to have it in front of me.
    I actually rarely add them though. I never liked that logic when it was rolled out. Too ugly and un-elegant for my taste. The “bumpless transfer”worked better in the DX in my opinion

  15. Likes numbawunfela liked this post.
  16. #12
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    3,285
    Post Likes
    Quote Originally Posted by JCIman View Post
    The reason they opted for the lead compensator vs just using derivative, it that D seriously hoses up PRAC
    The LC block is kind of a “baby D” that plays nice with PRAC.
    I agree that PRAC is great in general. I would say it will take care of over 95% of the loops. Unfortunately, I live in the other 5% world.
    Interesting! I have seen PRAC get grumpy when I try to use D, and I have fought with it a little.
    Most of the time it is when I am tuning something I am familiar with and I just want it to go... without waiting for PRAC to do it. So I either just say $%&×@ and let PRAC do it or I turn PRAC off and go it alone. The PIDs with a short time coefficient, like DAT and DAP are likety split fast and easy generally.
    Basically I figured PRAC did not like Derivative, but I had no official recognition of that fact.... although I believe there is a FSC article now that I am thinking about it... It did not say 'we do not like Derivative' it was more 'Use the Lead Compensator instead...'
    Anyhow, yes - the other 5% is where PRAC can be a liability. The issue is not that it is there. The issue is that a guy who has never tuned a PID in his life because he has relied on PRAC is hosed when he needs to manual tune the thing - since he never did it before.
    Sice the OP did ALC i am sure that is not an issue.
    Hmmmm....smells like numbatwo to me.

  17. #13
    Join Date
    Sep 2013
    Posts
    723
    Post Likes
    Quote Originally Posted by JCIman View Post
    You always could add them, but it’s not immediately obvious how :-)
    The main trick is to add the one on the left and the actual output in pairs so the instance numbers are the same.
    I will fire up CCT one day soon, and I can probably give you a better step by step process. One of those things that I have to have it in front of me.
    I actually rarely add them though. I never liked that logic when it was rolled out. Too ugly and un-elegant for my taste. The “bumpless transfer”worked better in the DX in my opinion
    Add your actual output on the right. Then go to on the left and click to add new. Sort by effective command then select the same one you added on the right. Hint not all outputs on the right have effective commands on the left. You know you did it correctly if they both have the same instance.


    Sent from my iPad using Tapatalk

  18. Likes JCIman liked this post.
  19. #14
    Join Date
    Aug 2020
    Location
    Washington DC
    Posts
    48
    Post Likes
    Interesting to see how JCI does PIDs.

    Siemens has their 'dumb' LOOP command, which does simple modulation and uses static PID values entered by the user, and then also added a much more sophisticated ADAPT command later on which self-tunes. Despite how awesome ADAPT seemed when people explained it, I rarely saw it in use, always the simpler LOOP, likely because the ADAPT statement requires many more parameters.

    Likewise, D gain was rarely used. And P I values were mostly guestimated or chugged out from a crude 'calculation'. P gain was mostly the equivalent to throwing darts while drunk and blindfolded, so the I gain was the saving grace.
    During a Siemens training class, the instructor openly warned us to not use D gain unless we were in critical environments or something, as he claimed D gain would cause equipment to modulate rapidly, causing it to be repeatedly energized, burning it out much faster.

    After tinkering very much with the LOOP command and studying intensely how it works, that's pretty much BS, but I'm sure it's one of those things that propagated around techs and magnified their complete non-understanding of control loops so they never bothered testing the waters.

  20. #15
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    3,285
    Post Likes
    Quote Originally Posted by stomachbuzz View Post
    P gain was mostly the equivalent to throwing darts while drunk and blindfolded...
    haha! Hope they make the programmers wear safety glasses when they tune PIDs!
    Interesting to hear about ADAPT. I like hearing more about that sort of thing. How others do their thing.
    Hmmmm....smells like numbatwo to me.

  21. #16
    Join Date
    Aug 2020
    Location
    Washington DC
    Posts
    48
    Post Likes
    Quote Originally Posted by numbawunfela View Post
    haha! Hope they make the programmers wear safety glasses when they tune PIDs!
    Interesting to hear about ADAPT. I like hearing more about that sort of thing. How others do their thing.
    Siemens' programming manual gives a 'catch-all' equation for calculating, roughly, PID values, but it's just generic.

    As far as the ADAPT thing, apparently it's amazingly sophisticated, but part of the issue in its popularity might have been that you had to purchase an additional license to enable this command in the controller.
    I believe because it was not actually a Siemens originated bit of coding, but rather something they licensed from someone else and had to pay royalties on its use or such.

  22. #17
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    3,285
    Post Likes
    Quote Originally Posted by stomachbuzz View Post
    Siemens' programming manual gives a 'catch-all' equation for calculating, roughly, PID values, but it's just generic...
    I would be interested in seeing that. I do aright with PID tuning, but it never hurts to add a new ingredient to the sauce and see if it makes it taste any better.
    I tend to favor a softer P and a tighter I. Then the PID is a little less aggressive at the front end, so it will not hunt. But if it is too soft, the I will pull it together at the back end.
    Hmmmm....smells like numbatwo to me.

  23. #18
    Join Date
    Sep 2013
    Posts
    723
    Post Likes
    Quote Originally Posted by stomachbuzz View Post
    Interesting to see how JCI does PIDs.

    Siemens has their 'dumb' LOOP command, which does simple modulation and uses static PID values entered by the user, and then also added a much more sophisticated ADAPT command later on which self-tunes. Despite how awesome ADAPT seemed when people explained it, I rarely saw it in use, always the simpler LOOP, likely because the ADAPT statement requires many more parameters.

    Likewise, D gain was rarely used. And P I values were mostly guestimated or chugged out from a crude 'calculation'. P gain was mostly the equivalent to throwing darts while drunk and blindfolded, so the I gain was the saving grace.
    During a Siemens training class, the instructor openly warned us to not use D gain unless we were in critical environments or something, as he claimed D gain would cause equipment to modulate rapidly, causing it to be repeatedly energized, burning it out much faster.

    After tinkering very much with the LOOP command and studying intensely how it works, that's pretty much BS, but I'm sure it's one of those things that propagated around techs and magnified their complete non-understanding of control loops so they never bothered testing the waters.
    Some good comments here, throughout the BAS industry Very few companies end up using the “D”. JCI even has a compensator block that adds in a little bit of forward predictive calculation but is not in fact part of the PID.

    I guess the thinking is most of time it is not needed.


    Sent from my iPad using Tapatalk

  24. #19
    Join Date
    Jul 2009
    Location
    Wa
    Posts
    803
    Post Likes
    Yeah started with CCT when it first came out. Prior to the FX line at all. When we first started working with it we debated the custom programming versus the system selection. I was a little rouge at first building my own programs. I wasn't arrogant enough to think I knew better than people that designed the tool. To be honest the state tables and mode changing takes some patients. Which I don't have. Also early on I was burned big time by adaptive tuning and a clean room that went out of spec when the PID just went to zero for good. This related to an oversized chilled water valve and the loop just couldn't find it's happy place and tuned it self silly then set the output to zero. Not really adaptive tunings fault, but after that I got real good at self tuning my own PID's I had trust issues! To the OP for the FX line your going to want and join the connected community. Your ABCS can get you hooked up. There is very good videos made by JCI guru Greg Willmer covering all kinds of CCT topics one is PID operation, and self tuning. I've learned over the years that starting with a base Q/A program then adding from there is a better approach then my rouge days. Also adaptive tuning is utilized most always instead of my self tuning.

  25. #20
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    3,285
    Post Likes
    Quote Originally Posted by Norriski Tech View Post
    I've learned over the years that starting with a base Q/A program then adding from there is a better approach then my rouge days. Also adaptive tuning is utilized most always instead of my self tuning.
    Good advice there
    Hmmmm....smells like numbatwo to me.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •