Page 1 of 3 123 LastLast
Results 1 to 13 of 32
  1. #1
    Join Date
    Jun 2005
    Location
    Ohio
    Posts
    1,737
    Post Likes

    Siemens PPCL Question

    I'd like to send a digital inputs value in one MEC to another MEC. I've looked at the PPCL Manual but could not find anything specifically on it.
    Could someone show me an example statement to do this?
    I was thinking of using an LDI, but could not find the LDI's definition, just references to it.
    TIA,
    Jogas
    Four wheel therapy, my 1968 Camaro is gone and will be missed

  2. #2
    Join Date
    Sep 2007
    Posts
    255
    Post Likes
    You need to send a virtual LDO to another panel to trigger a virtual LDI. This will be done over the network.

    PPCL
    PANEL 1
    IF ("PHYSICAL.LDI".EQ.ON)THEN ON("VIRTUAL.LDO")

    PANEL 2
    IF("VIRTUAL.LDO".EQ.ON) THEN ON("WHATEVER")

    You need to create the virtual LDO in the panel where the physical point will be monitored.

  3. #3
    Join Date
    Feb 2007
    Location
    Sacramento, CA
    Posts
    79
    Post Likes

    Hmm Easier Yet

    You can access the value of a point in one controller by just using its name in the PPCL in another controller. For example if you call the outside air temperature "OAT" you can user "OAT" in the PPCL of any controller on the network (Ethernet controllers I believe would have to be on the same virtual network). Oh the joys of proprietary protocols. One caveat though, there is a memory penalty in each controller. It is not high but can come into play if you are doing lots of trending.

  4. #4
    Join Date
    Jun 2005
    Location
    Ohio
    Posts
    1,737
    Post Likes
    Quote Originally Posted by Ex-Man View Post
    You can access the value of a point in one controller by just using its name in the PPCL in another controller. For example if you call the outside air temperature "OAT" you can user "OAT" in the PPCL of any controller on the network (Ethernet controllers I believe would have to be on the same virtual network). Oh the joys of proprietary protocols. One caveat though, there is a memory penalty in each controller. It is not high but can come into play if you are doing lots of trending.
    It is programmed this way now and does not pass the change of value to the monitoring MEC's program.
    Jogas
    Four wheel therapy, my 1968 Camaro is gone and will be missed

  5. #5
    Join Date
    Nov 2007
    Posts
    24
    Post Likes
    Ex-man is correct. No need to create a virtual point. The point name has to be exactly the same in the program, luckily caps don't count. Is there a DEFINE statement at the top of the program that may be changing the point name. Have you run a Panel PPCL Report on the program.

  6. #6
    Join Date
    Nov 2007
    Posts
    24
    Post Likes
    Quote Originally Posted by WillyTech View Post
    You need to send a virtual LDO to another panel to trigger a virtual LDI. This will be done over the network.

    PPCL
    PANEL 1
    IF ("PHYSICAL.LDI".EQ.ON)THEN ON("VIRTUAL.LDO")

    PANEL 2
    IF("VIRTUAL.LDO".EQ.ON) THEN ON("WHATEVER")

    You need to create the virtual LDO in the panel where the physical point will be monitored.
    A little confusing but I think I get what your saying. When monitoring a physical point across the network you want to use a virtual point or local variable in the panel. If Panel 1 has the "PHYSICAL.LDI" point then in panel 2 you simply have a statement that says
    "VIRTUAL.LDO" = "PHYSICAL.LDI"
    or
    $LOC1 = "PHYSICAL.LDI"

    This statement
    IF("PHYSICAL.LDI".EQ.ON)THEN ON("VIRTUAL.LDO")
    Should read like this
    IF ("PHYSICAL.LDI".EQ.ON)THEN ON("VIRTUAL.LDO")ELSE OFF("VIRTUAL.LDO")
    Otherwise the "VIRTUAL.LDO" will never turn off.
    When monitoring a point across the network you would normally sample it to cut down on network traffic.
    SAMPLE(60) $LOC1 = "PHYSICAL.LDI"
    The reason for using a virtual point or local variable to monitor a point across the network is if PANEL 2 doesn't read the value due to communications failure then the virtual point value stays at the last known value and the programming line won't fail.

  7. #7
    Join Date
    Jun 2005
    Location
    Ohio
    Posts
    1,737
    Post Likes
    Thanks for the replies.
    All good info that'll help when I get back to that job.
    Does anyone have documentation on the LDI's, LDO's, LAI's and LAO's?
    Jogas
    Four wheel therapy, my 1968 Camaro is gone and will be missed

  8. #8
    Join Date
    Nov 2007
    Posts
    24
    Post Likes
    Most information can be found in the help window. Not much to it.
    L (logical) Physical, but a bit confusing because a checkbox in the Point Editor allows you to define it as a virtual point.
    D (digital) Two states like a switch or relay. On or off, open or closed, day or night. In reality Apogee looks at it as a 0 or 1 and you can use a 0 or 1 to define the state in the programming language.
    A (analog) A numerical value, Physically a voltage or current. It can be defined as a temperature, pressure, CFM, ect. For a resistive or current input measurement there's a slope/intercept calculator available in the point editor to calibrate the analog input. As a virtual point I don't think there's a limit to the value.
    I (input) The module is reading the value
    O (output) The module is setting the value
    When creating a virtual point common practice is to define it as an output point but it will also work if defined as an input point.

    Apogee PPCL is really quite simple, it's pretty much like the old BASIC programming using Boolean language. If this equals this then do this else do this, or goto this line and do that. Lines using LOOP or TABLE are calculating a value. As long as you have the PPCL programming book it will define the programming language, what the commands will do and give a basic lesson in proper programming. The programming editor will check for syntax errors, invalid point names and gross programming errors such as a backwards goto line but figuring out and writing the code is up to you.

  9. #9
    Join Date
    Sep 2007
    Posts
    255
    Post Likes
    I recommend not sending any physical points across the network, especially to a seperate BLN.

    If a physical point fails such as an OAT, you will monitor a failed point in the monitoring panel, if you monitor a virtual point it will read it's last known value.

  10. #10
    Join Date
    Nov 2006
    Location
    SE Wisconsin
    Posts
    409
    Post Likes
    I'll agree with WillyTech but add a bonus.

    Every time the program runs (top to bottom) you're going to be pulling that value from the source board (Panel 1 in the example).

    If the program runs four times in a second (for example) multiplied by 10 panels equals 40 pings to Panel 1 per second. Now multiply that for each value that is transmitted and it gets obnoxious.

    If you generate a virtual point in panel 2 (Virt.OAT) and set a delay on the frequency of importing the value (If Seconds > 900 then Virt.OAT = OAT) you will greatly cut down on network traffic.

    This is especially important on large BLN's.

    Just my $.02

    Best of Luck!

    Ken

  11. #11
    Join Date
    Jun 2006
    Location
    Des Moines
    Posts
    306
    Post Likes
    LOL, lots of good answers here, but I think we've not solved the problem.

    Jogas mentioned that it's programmed now using the physical point across the network but that Panel 02 isn't picking up the value.

    Question 01: Is this something that used to work and now doesn't or is this new PPCL that you can't make work?

    Question 02: Are these two panels on the same BLN? (and are the BLN's RS485 or ethernet).

    Advice 01: Run a panel PPCL report for Panel 02 and make sure the line is being traced and is resolved.

    Now, my own added bonus, referring to the previous bonus.

    When a point is being referenced in a panel in which doesn't exist, that panel will call out to the panel where the point is for the value of that point every time that line is hit.
    Putting a timer in front of that line isn't a bad idea, I did it that way for many years. It can slow response\control however.
    Willeytech had it right... almost. The logic was correct but you don't need the virtual points.
    The best way for this to be (although we're getting really, really picky here) is to simply put this line of code in Panel 01, where the physical point exists.

    "panel.02.virt.LDI" = "panel.01.phy.LDO"

    This method will only cause trunk traffic WHEN THE PHYSICAL DO CHANGES STATUS. Panel 02 isn't calling out for the value from panel 01 for obvious reasons. Panel 01 won't send a COV until a change of COV is seen. This is particularly important on analog points.

    Then you would adjust the "COV" in the analog point definition to attain the level of control needed without producing excess traffic.

    This way, if a point does start toggling\changing valve rapidly for valid reasons, the truck traffic is allowed to increase to maintain control. When the points settle down, so does the trunk traffic.

    EDIT: This method will also retain last known value for Panel 02 if panel 01 drops offline.
    Dingman from Iowa~
    "A lie gets halfway around the world before the truth has a chance to get its pants on."
    - Sir Winston Churchill (1874-1965)

    The Dingman's webpage, featuring the Ding_Z

  12. #12
    Join Date
    Jun 2009
    Location
    Iowa
    Posts
    54
    Post Likes
    Dingman is very close, but he has it backwards.

    When a point is being referenced in a panel in which doesn't exist, that panel will call out to the panel where the point is for the value of that point every time that line is hit.
    This is false. When a point is referenced in PPCL and it doesn't exist in the that panel, a search is done of all the panels that can be reached. When the point is found, the panel that has that point creates a record in memory that tells it to send the requesting panel the new value when it changes by the points COV limit.

    Putting a timer in front of that line isn't a bad idea, I did it that way for many years. It can slow response\control however.

    Putting the sample statement in front of the line of ppcl only samples how often that line of ppcl is executed, the data is sent by the source panel based on the above answer, regardless of the sample

    Willeytech had it right... almost. The logic was correct but you don't need the virtual points.
    The best way for this to be (although we're getting really, really picky here) is to simply put this line of code in Panel 01, where the physical point exists.

    "panel.02.virt.LDI" = "panel.01.phy.LDO"

    This method will only cause trunk traffic WHEN THE PHYSICAL DO CHANGES STATUS. Panel 02 isn't calling out for the value from panel 01 for obvious reasons. Panel 01 won't send a COV until a change of COV is seen. This is particularly important on analog points.
    This is partially false. While Dingman is correct when refering to digital points with the above example, do not do this with analog values. If you put the following line of PPCL in panel 1 for example:

    panel.02.virt.LAO" = "panel.01.phy.LAI"

    panel.02.virt.LAO will get updated every pass of the program in panel 1, totally ignoring the COV limits. If you put that same line of PPCL in panel 2, you are then throttling your trunk traffic by the COV of panel.01.phy.LAI"

  13. #13
    Join Date
    Jun 2006
    Location
    Des Moines
    Posts
    306
    Post Likes
    Ahhh, the stub points. I was forgetting about those.

    Thanks for the corrections, sounds like you really know your stuff!
    Dingman from Iowa~
    "A lie gets halfway around the world before the truth has a chance to get its pants on."
    - Sir Winston Churchill (1874-1965)

    The Dingman's webpage, featuring the Ding_Z

Page 1 of 3 123 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
  •  

Related Forums

Plumbing Talks | Contractor MagazineThe place where Electrical professionals meet.
Comfortech 365