Using PAC Controllers and Brains as Gateways (serial to ethernet)

Germinal is an Opto 22 integrator over in Florida.
He wrote the following tech-tip up as a blog entry, but Mary and I felt it was better as a forum topic.

Over to you now Germinal…

Using PAC Controllers and Brains as Gateways (serial to ethernet)

on August 17th, 2011 at 10:00 PM

Recently we implemented a solution for remote monitoring of Telecom Towers and Facilities. One of the customer’s requirements was to interface with a Power Analyzer via Modbus RTU RS485, so we included an SNAP-SCM-485-422 serial module implementing a simple chart that sends just the modbus command to request from the Analyzer all the parameters at a time (it was pretty simple), then, after receiving the Analyzer’s response we converted all the characters to the values in the engineering units (volts, current, power, harmonics, etc., it was pretty simple too).

The “most nicest” part of the history is that, thinking about how to configure the Analyzer remotely, instead of having to travel to each location with a PC and a RS485 serial port, and instead of having to write a large and boring program (chart, routine, or whatever) to read and write over all the modbus configuration registers, we just installed the original configuration program supplied by the Analyzer manufacturer using the controller as a gateway.

How it was possible? What’s needed?

Each serial channel has a TCP port pre-assigned (from 22500 to 22531, can be changed) that can be directly accessed by ethernet using the controller’s IP Address and the serial module’s IP port. So, we used a “Serial to Ethernet Port Redirector” (it’s just a piece of software, there are many on the Internet, some are free) creating a virtual serial COM port in the computer (we named it “COM3”) and redirecting it to the controller’s serial port where the analyzers are connected.

Think about doing the same to monitor or program serial devices like access control readers, UPSs, or to communicate with a router or managed switch connected remotely but directly to its console input without having to stand up from your desktop. I think it’s Cool :cool:, don’t you?



Glad you bought this tip up. It’s a good one and one that I have used myself back in the day.

We had a chiller that had a serial port for connectivity. It was about the only way to really see what was going on in the chiller’s own (primitive) controller and more importantly you could reset any faults on any of the compressors remotely.
This was a huge help when summer was in full swing, as the chiller was the only one on that site and needed to run at 100% on the really hot days. It was a little old and would sometimes trip out one of its 10 stages for no good reason, other than it wanted a little rest or something.

The problem was that we did not have any maintenance staff at that location; they were all based at the main hospital site.
We had some CTs installed on the chiller which were hooked into the Opto system and we had set up an email alert if the chiller was drawing less than max amps when the outside air temperature was such that it should be 100% loaded, thus tipping us off that we should go and have a look and reset any faults.
Well, as you can imagine, I got real tired of walking the mile between hospital sites with my laptop in the hot Australian sun to see what the problem was and reset the faults via hyperterm.

Enter Germinal’s tip.
We had the Ethernet rack with the SNAP-AIPM module that had the CTs hooked up to it. We were also picking up the chiller flow and return temperature and the outside air temperature… but, thankfully, we had a few spare module slots.
So, I ordered a SNAP-SCM-232 module and hooked the chiller up to that.

Once that was done, I could stay in my nice air-conditioned basement office and simply open up a telnet session (putty is my preferred program for telnet/ssh) to the IP address of the B3000-ENET and the port number of the serial module and, boom! We were connected with the chiller.
Given the speed of Ethernet compared to serial, you could not tell from my office that I was not connected to the chiller directly. The connection was rock solid and never once gave me any trouble.
So yeah, via Opto, we had a mile long RS-232 cable… NICE!

Taking it one step further then, we then wanted to make it easy for the other Engineering staff to get access to the chiller data.
PAC Display to the rescue.
Check out the following screen shot to see how we did it:

When the operator clicks on the button, it opens a telnet session to the IP address of the B3000-ENET and port number of the serial module that the chiller is connected to.
Very easy. Very cool.

Thanks Germinal for reminding me of this cool trick that Opto can do so easily!

Code on!