Niagara-MPX modules Version #11 (Build 37) (Fixes/Issues)

[Jim_Okapal]

*****************************************************************************************
Niagara-MPX modules Version #11 (Build 37) (Fixes/Issues)

*****************************************************************************************
RELEASE NOTES FROM TRIDIUM MENTION THESE ITEMS:
82) Fixed the issues from issue tracker in theTeams page
       217,218,222,224,228,230,237,238
83) Fixed the issues from issue tracker in theTeams page
       200,245,
84) Fixed the issues from issue tracker in theTeams page
      179,230,231,244,250

Note) When device is copied if the device has some Script programs,
          Script Functions,Visual Script Program with should poll enable then
          they may not work properly. We are still fixing this.

SCHNEIDER TRACKER SHEET REFERENCES THESE ITEMS FROM TRIDIUM:
1) Tstat: Initialize OutDir
2) Script Error Code (Use an Enumerated Message for result)
3) MultiState Text Fix
4) VAV Velocity Pressure (Proprietary 1840)
5) Process for Copy/Pasting custom script 
6) Object Instance Number Error Upon Creation
7) Correcting Minimum Off block script code
😎 Public Numerics in custom script programs
9) Objects inside VSP stop working when undergoing a process of block editing.
(deletes/adds/compiles)

MY COMMENT FOR ITEM #5 ABOVE: (Issue 230):

It's mentioned in the tracker sheet to copy both the script source and compiled results

from the source controller into the destination controller.   I can see this as being

problematic for keeping things simple.   

MY COMMENT FOR ITEM #6 ABOVE (Issue 237):
Remedy says for Tridium to apply the next highest instance number when preventing

duplicates,but shouldn't it be the lowest that's available to fill in empty slots? Only when
they're all filled in, should it go higher. There was an R+D conversation with the
TAB members similar to this before the EBO3.2.2 release to deal with duplicate Object
IDs.

*****************************************************************************************
FORUM ITEMS FIXES:
1) Multi-State: Problem was that the wiresheet object would only show the default
    State1/State2/etc even after changing the text in the properties sheet.
2) Vav Object: Velocity Pressure object would contain a proprietary 1840 object upon an
     upload that would cause future downloads to fail
3) MinOffDelay: Problem was that the block was delaying by seconds instead of minutes

SCRIPT EDITOR FIXES:

(PLEASE GIVE THE PERSON WHO GOT THIS WORKING WITH TRIDIUM'S PEOPLE A RAISE)
1) All user declared Public Numerics are now back onto the wiresheet block shape and
    show up by default.
2) All user delcared Public Numerics also show up on the properties page again.
     Problem was that only the first declared Public numeric would show up.
3) Public Numerics are now linkable on the wiresheet object again
4) The value status in the Initial Values tab section now updates with the initial
     start value that was chosen.
5) The Value and Start Value on the Public Vars section of the property sheet now update
     and function correctly.
6) There is one existing issue that still exists for FallThru triggers, listed here and further
     down in post.  Adding FallThru triggers in the list will temporarily be shown and then

     disappear on their own. (ISSUE)

VERY IMPORTANT TO KNOW ABOUT SETTING PUBLIC NUMERICS:
1) To set the Public Numeric, you can either use the initial values tab in the script
     editor or link an object to the exposed Public Numeric on the wiresheet. If using an
     initial value, make sure to set "Apply Initial Value" on the property sheet to Yes
     and then download the script at some point for it to take effect. If you had set
     the initial value and downloaded the script before setting "Apply Initial Value",
     you must download the script again. It is possible to use an initial value and a
     wiresheet binding at the same time, but the wiresheet object will win out.

*****************************************************************************************
EVERYTHING FROM THIS POINT DOWN LOOKS LIKE IT HAS THE SAME
PROBLEMS FROM PRIOR VERSIONS:
*****************************************************************************************
FORUM ITEMS NOT FIXED:

1) BO block shows a "Property:Unknown Property" error and goes into fault from time to
    time, but still functions when commanded ON/OFF
2) Temperature Input has an OutofService set to False upon import which is
    inconsistent with the other inputs set to True upon import
3) BV/BO: Priority arrays still show Active/Inactive even after changing text. This is
    the light blue dot section where you can override the value
4) Schedules priority level not changeable from 16
5) Event Enrollments don't have Alarm Text. (Perhaps Niagara function?)
6) String fault. Occurs when a String Value object is freshly brought into a live
    controller. It'll start out with no errors, but if you wait for a bit it'll
    show the error message "Property:Unknown Property" and go into fault.
    If you put an actual string into the PresentValue, it will pass ok, but will go
    into fault eventually as well. While in fault, the block seems to act normally.
7) Schedules: Previous Transition Time, Next Transition Time, Following Transition Time
    showing large integer number instead of Date/Time when pin slots exposed. Value is
    stuck at "True" but any blocks connected to it can still properly go ON and OFF based
    on time schedule. There are misleading values on property sheet for Previous Transition
    Time, Next Transition Time, and Following Transition Time where it can be ahead by an hour,
    or reflects a Midnight time (showing 1AM due to being ahead) when in actuality the
    next transition occurs sometime during the next day.
😎 Lonworks Link appears on objects when deleting various other objects from
    wiresheet

*****************************************************************************************
SCRIPT EDITOR CHANGES/PROBLEMS:
1) Adding FallThru triggers in the list will temporarily be shown and then disappear
    on their own. While visible, i was able to get the script to trigger a couple times.
    After that, the Fallthru trigger disappeared from the list. (ISSUE)

*****************************************************************************************
UTILITY BLOCK COMMON ISSUES NOT FIXED:
1) Some input type choices may not apply to the block type. All blocks
    have a choice of Boolean,DateTime,Float,Integer,String.
2) Input and Output names (in/out) can be changed, but the settings value
    reverts back to (in/out), while the block slot name will maintain the change.

UTILITY BLOCKS PARTIALLY FIXED:
1) Latch: Inputs for "Latch" and "Reset" default to digital and aren't selectable
    between analog and digital. This would lead someone to believe that it's a
    purely digital latch. Workaround if needing a real value would be to make sure
    a value of 0 is OFF and anything greater than that is ON.

BLOCK CONSISTENCY PROBLEM:
1) Equal: Default inputs are binary, while the other 5 comparison type of blocks
    have integer inputs as default

PERHAPS ADDITIONAL FUNCTIONALITY NEEDED:
1) IndexOf: "Find" syntax will find case insensitive items while
    "Search" syntax will find case sensitive items. May need both
    these options to handle various string scenarios.

*****************************************************************************************
VAV OBJECT ITEMS NOT FIXED:
1) Velocity Pressure block: Block still shows "Out of Service" after initial Download All
2) BoxFlow block: Priority 16 is shown which will fight the internal program of
    the VAV object if anything is attached.
3) DamperCommand block: Priority 16 is shown which will fight the internal
    program of the VAV object if anything is attached. Perhaps Priority 15 should
    be shown if outside logic needs to have control or just remove it.
4) EffectiveReheatCmd block: Needs the Priority 16 available since this is the
    feedback from the hot water valve for showing on the eCommissioning Tool.
5) DischargeAirTemp block: This object needs the Priority 16 available since this
    is the feedback from the duct temperature if available for showing on the
    eCommissioning Tool.

*************************************************************************************