Connecting Intouch HMI 2023 to Historian 2023 tag data

Hi Matt

A recent feature is that InTouch now supports logging to historian with many of the advantages this enables.
In previous versions you had to create the historian tags manually in Historian or Import tag database to have Historian log data from an InTouch application.

These new features should be reflected with some additional configuration options in Window Maker.

But It is still possible to use the previous InTouch logging features for historical logging of tag data, alarm logging must be managed separately in this case.
InTouch History and the use of the Distributed name manager configuration will have one of your InTouch application nodes log the data, generating .lgh files containing the historical data for retrieval by some InTouch components and Industrial graphics.

But I don't believe it is not possible to do both a the same time, even though the Window Maker allows you to have both enabled.

When it comes to your issue in connecting to an existing Historian there is some things to sort out.

• Is your Historian running in the same node as your InTouch application?
• Are you experiencing issues when trying to connect in the Distributed name manager configuration or the Historical Logging Configuration?
• Can you ping your historian node from the InTouch node?
• No firewalls between the nodes?
• Can you conform that your Historian is running?

Since Logging to Historian is a quite 'new' feature, there are some known limitations, but lets start with sorting out your connection issues and take it from there.

Thank you Richard.  I appreciate the detailed response.  I'm not using Historian logging from Intouch.  I've always set up Historian to connect directly through a remote IDAS to a DAS (in this case abcip).  I don't want to rely on Intouch WindowViewer to be running to ensure proper data collection.  So in my scenario here... Historian is running and collecting data from an "I/O server" machine.  I want to be able to display data on trends in Intouch that has been collected to Historian.  I've done this numerous times before on older Intouch/Historian installations before.  It's just not working on this latest release.

My 3 servers are:

• IO Server - Hostname: IO1\
• Historian - Hostname: HIST1
• Intouch HMI - Hostname: HMI1

This is in a development environment with brand new set up.  New computers, new windows domain, fresh clean software installation.  For now, all machines are running and logged in as the domain admin account.  Ping works across the board to/from all servers.  The intouch node can ping the historian.  There are no firewalls configured, no security anti-malware installed (yet).  So to answer your questions:

• Is your Historian running in the same node as your InTouch application? No, different hosts.
• Are you experiencing issues when trying to connect in the Distributed name manager configuration or the Historical Logging Configuration? I can access the Distributed Name Manager and the Historical Logging configuration, but when I configure the historical logging and select "Test Connection" it times out and fails to connect.
• Can you ping your historian node from the InTouch node? Yes.
• No firewalls between the nodes? No.
• Can you conform that your Historian is running? Yes, running and data acquisition is active is status.

Thank you for the clarifications.

So for your setup, Configuring InTouch logging or Historical Logging is not required. This only activates features to have InTouch as a source for generating historical data.

When it comes to have InTouch retrieving data from an Historian this is usually configured on the component used, (trend components etc.)

But your issue in Distributed name manager had me testing, and I also have issues to connect to my Historian, validating the credentials. No matter what kind of user I was testing and i tried various formats in the User Name.

To troubleshoot I wanted to try and use a SQL user, even though the use of SQL Server users are not recommended. To do this I had to enable SQL Server mode. This requires a restart of the SQL Server service.

After this I enabled my sa user and set a password.

Yeah.. I know, troubleshooting over security decisions, but it is my test setup.. :) .

The outcome of this was that I could configure my history provider.

So there do seem to be something going on here, I expect to be able to connect with a windows account but I can not get passed the Test connection in any way. Also the documentation has changed and some screenshots does not look as in InTouch

Even tried using the newly introduced Credentials Manager (found in Application Manager Tools menu).
But the results was the same. Need to investigate and perhaps raise a ticket with techsupport to sort that out.

At least I could view my provider in the Historical Trend Configuration

You could also explore some of the newer trend components, they have built in support for Historian Connection and could be an alternative. Still, there seems to be some broken things here, so the introduction of credentials manager might have affected several existing components.

Hello Richard,

I was able to also find success in getting it working.  I think there were two main things in the way, that after some time away from looking at the app provided me fresh eyes.  I found a simple mistake I had made.

After having trouble a couple days ago with my original historian setup, I rebuilt the Historian machine.  This is running in VMWare, so spinning up a new install was no biggie.  In doing that, I forgot 2 important steps in the intial setup:

• Disable the Windows Defender Firewall (yep... I thought I had it off, but it wasn't)
• Install SSMS to configure SQL Server.  I enabled the sa account and set the password.

Now with Firewall off and an "sa" account enabled.  I tried setting up the Distributed Historian and it worked.  I had to use the sa account and password.  For whatever reason, using either domain level security (entering domain admin account and password) or local windows security (entering hostname\administrator and password), neither worked and rejected my credentials.

Knowing that using the "sa" account is not ideal, I went back to attempting to create a stored credential in the credential manager (Application Manager > Tools).  This time around, I chose (User name and password) instead of (domain user name and password), then entered my sa account details and saved them.  Using this methods, I was able to select the saved credentials in my Distributed Name Manager setup.  My undersanding of this is that the credentials are encrypted and saved, so it's secure.  Someone would need to fact check me on that.

I'm glad you managed to get it resolved, 

I have created a ticket with techsupport to sort this out, I would expect to be able to use Windows Security, and as you I have tried all patterns of entering a username to no avail.

In my test I enabled the 'sa' account, but if you are to move forward I would suggest to use an SQL account with lower access, or create a specific account for the SQL Access to the Runtime database.

You could use the aaUser account, at least it does not have full access to your SQL Server.

Saving your credentials in the Credentials Manager is a improvement, and it is not stored in clear text, don't know the level of encryption here, but at least some measures has been taken to store it in a better way.

But it still requires you to modify your SQL Server Configuration and enable SQL Server Authentication witch is disabled by default so I would want this resolved.

I will report back any findings on this issue.

Hi, as promised some follow up.

Here is the final statement from tech support regrading the Distributed Name Manager credentials.

"
As per R&D team currently we do not support using Windows user credentials in Distributed Name Manager for the Historian connection. please let me know if I can submit enhancement request. 

"

So we can not expect to have that function using integrated security, since I personally don't have a case for this to motivate an Enhancement request i leave that to anyone more suitable for that.

At least we know its not expected to work.

I'm not sure for your use case if you need Distributed Historical Provider. You can use .NET Historical trend client, and set it up to point to the Historian without Distributed Historical provider