For example, a history extension on a NumericWritable component creates the default history name: NumericWritable. Then, another numeric writable receives the same name incremented to NumericWritable1.

 NOTE: If you use a literal name and not a script to name a history, you lose the automatic incrementing feature that the script provides. Duplicating extensions that have a literal name duplicates the exact literal name and, therefore, creates an invalid (non-unique) name. In this case, you must rename each duplicated history manually to create a unique name and avoid a fault condition.

• Starting with Niagara 4.12, the character limit for Histories is increased from 44 to 200 characters.
• Starting with Windows 10 version 1607, the MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must take action to opt-in to the new behavior. Refer to the following article for detailed instructions: “https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later”. The following points summarize the requirements that must be met for enabling the new long path behavior:
  1. The registry key Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled (Type: REG_DWORD) must exist and be set to 1.
  2. The longPathAware element should be included in the application manifest.

  When you enable this opt-in behavior, the directory management functions and file management functions will not have the MAX_PATH restrictions.

Figure 4.   History naming relationships

 

As illustrated in the following image, history names are part of the unique history extension property Id. When you rename a history at the history extension, you are renaming the history at its source. Therefore, the history configuration and the history Id both change. This concept is illustrated here:

Figure 5.   Renaming a history in the history extension

If, however, you rename a history in a History space view, such as under the History space node in the Nav sidebar, or in the Nav container view, you are changing the name of the history as it has been saved in the History space not at the configuration (or source) level. Therefore, the history Id does not change and the history extension continues to produce records under the original history name as long as that history extension is active and enabled. This results in a history split where the station no longer updates the newly-named history, as of the time of the renaming, which it contains all the records up to that time. In this scenario, a history under the original name begins with the first record after the renaming and continues recording as configured. This concept is illustrated here:

Figure 6.   Renaming a history in the history space

Renaming Summary: