So we are doing a POC with a customer to explore using Multi-Galaxy communications to allow their Plant Wide System Platform R2 install “import” screens from a skid we have built.
A quick bit of history – we are engaged with a leading technology provider for the biotech market to create an advanced “Platform” for a range of different technologies they deliver. Our end product is a sophisticated HMI, Recipe, and Reporting engine running on top of System Platform… but all for a single skid. These skids are purchased by customers who in turn install them in their facilities alongside lots of other equipment. The smart customers are taking the skid data an integrating this into their overall plantwide system.
So back to the story. Because we didn’t want to mix and mingle galaxies there is no easy way to “import” graphic screens aside from replicating a bunch of tags and redoing the graphic on their system.. until cross galaxy communication came along and allowed for viewing graphics from Galaxy A in an InTouch app from Galaxy B. If you haven’t read the whitepaper recently published you really should take the time. You get some insight into where this is going.
First step in the POC was to upgrade our current “Standard Platform” to 2012 R2. Upgrade goes fairly smooth except now we have a ton of information messages in the logger about something related to the ASB. No errors or warnings, just info messages so we ignore them for now.
Next step is to pair the galaxies (read the docs on the steps to do this) but it’s just not working. Call up support and I end up getting to the developer who actually programmed this feature so we’re in the right place.
After about 4 or 5 calls and about 4 hours we/he finally figure out the problem.
The smoking gun was an error message about not being able to open a TCP listening port. Without getting into the details the ability to listen on different ports is analogous to having different doors (ports) into the same house(IP address). This is how you can have lots of software running on your machine and communicating over the network.
With the help of the engineer we start to dig in our configuration files. We went to the configuration file for the ASB authentication manager (taking our cue from the log files) and found that it wanted to talk on port 9876.
Next step is to go to our resource monitor (Task Manager –> Performance –>Resource Monitor) in Windows to find out who is talking on Port 9876
What the heck is Agent.exe? I poke around a few different places and figure out it’s an agent from our Acronis backup software installed on the machine.
Well, I’ve got to have my Acronis running so uninstall isn’t an option. However, if you have well written software it will typically allow you to change the listening port for a particular piece of software. Because I have the developer on the line we go straight to it. Note the path and what you see is me opening up the config file in notepad.
See the section I have highlighted? Originally localhost:9877 was actually localhost:9876. We updated this file (the screenshot is an after), save it, and the restart the Watchdog service.
After a few minutes of restarting it all works!
So what was the point of breezing through all of the real details and just showing you the result? The fact is that article wasn’t really about how Acronis conflicts with the ASB. The big idea here is that even though you might have installed some piece of software on lots of other machines with no problems that’s no guarantee your next install won’t cause a problem. I guess it was kind of ironic that the piece of software we installed to allow us to try out new things and then roll back if it didn’t work was the conflicting piece of software when it came to … trying out something new.