We have moved a lab from another state in with us at my location and they use proprietary(Proger) devices ran by a software called Prowin. Everything operates via R232 connections and the software was configured/supported overseas. What we would like to do is connect Opto controllers to act as kind of a man in the middle to pass data being read by the proprietary devices to our Aspen historian application. The “controllers” are not connected via ethernet but directly to stand alone PC’s via RS232. Getting the PC’s(HMI) computers connected to our network isnt a problem but we are needing some guidance on how to proceed to get Opto to collect the data. Personally my goal is to use this as a stop gap until we could move the processes over to Opto completely but currently we have to leave these process running the Prowin.
A few problems that we are running into is that there are very few people in our company in Germany that supports this setup. Instead of running a custom proprietary solution we want to go with Opto that is more widely used, supported, as well as its something we understand to a certain degree. As far as I know the Prowin uses several configuration files but Im not certain of how and where it stores data.
Can anyone help me at least get started with this or point me in the right direction? Currently Aspen is using Opto’s OPC capabilities to collect data and the Proger systems do not have any sort of OPC server built in. Our hope is to use Opto to collect the data and use its OPC functionality without interupting the Proger/Prowin systems.
BUT. You don’t want to ‘break’ the current Proger/Prowin connection. You want to keep that working.
In effect you want to send the Proger device data to both Prowin AND the Opto controller at the same time?
If I am right… Its going to be tricky because of the RS232 connection. It does not allow for parallel connections.
Before we get too deep. Is this the correct data flow?
Yes basically we were thinking Proger ----device —Opto controller then
Opto —>Prowin
Opto --> Aspen at the same time.
Basically using Opto to basically eavesdrop on whats going on then we use Opto and Opto’s OPC to communicate with the Aspen server. So essentially it would be parralel communication.
I did find that Prowin writes data files with Feeds, Temp, Agitation etc to the local harddrive. Would it be possible to create a stragegy that imports this data to create tags for it?
Basically all we are wanting Opto to do is tell us whats happening on those machines not actually doing any of the actual work.
SoftPAC. https://www.opto22.com/products/softpac
Using PAC Control running on a SoftPAC control strategy you can open the local Prowin files and get the data into the Opto universe. Once its an Opto strategy tag you can use OptoOPC to move the data into Apsen.
This is one of the main advantages for SoftPAC over a hardware controller. It has access to all the files on the local PC that it is running on.
Just program up a comm handle and read the file into the strategy, get the data you need using substring commands and you should be up and running.
Node-RED. Running on Windows : Node-RED
Load Node-RED on the same PC as the Prowin files and use the ‘file’ and ‘tail’ nodes to monitor the new Prowin data as it comes in. You could then use the Node-RED PAC (node-red-contrib-pac (node) - Node-RED) node to move the data to one of your existing PAC Controllers. Of course, once its there, you can again use OptoOPC to move the data into Aspen.
So, which should you use? Duno. Depends on your comfort level in each environment.
Personally, I have done both and find Node-RED a bit more comfortable in string manipulation.
But if you are more like @philip you probably could make short work of it in PAC Control. <grin.
Either way, given the non-parallel capabilities of RS232, its fantastic that you found the Prowin data files on the PC hard drive… Software solution for the win.
You could do a man in the middle with two RS232 ports on the Opto22 system, where the strategy echos the commands and responses back and forth between the Proger and computer. Your strategy can then do what it wants with the data it “sees”. If you only need one side of the serial conversation, then you may be able to build a sniffer cable that splices in the Tx of the Proger serial to the Rx pin on the PAC and listen away.
If the goal is to continue to use the Proger device and remove the computer, then the first option would probably be best. Is the serial protocol documented?
Philip, have you successfully done that serial echoing?
Mary and I tried it using a PAC S controller a few years back and ended up in timing hell… Ultimately, we could not get it working and had to give up on the idea.
I like the idea of just sniffing one line and have done that many a time myself.
Thanks for chiming in on this very interesting thread.
I’ve used a PAC to echo serial data out a tcp port so I could interact with some RS-422 Optomux boards over telnet. That was my very first Opto22 project many years ago…
I have also used SNAP serial modules to talk to each other to test throughput of these modules as I found strange issues with them (basically found that you can overflow their buffer very easily and get no error back from the transmit command when pushing more data, just silently drops it). So this was essentially a timing issue - I had to make sure I didn’t send data faster then the baud rate, once I did that I was able to get real close to the rated throughput.
This is probably protocol dependent. ASCII protocols probably wouldn’t care since they are built with someone typing in commands in mind and the receiver buffers data until it receives a termination character.
If the protocol requires a contiguous payload (say like Modbus RTU), then there can be no breaks/pauses in the communications for that request or response payload. To avoid failures the echo loop will need to be very tight to make sure that a character is sent as soon as it is received - this may not be possible on a PAC controller, and may be what you were running into.
A naive approach to get around that for request/response protocols would be to buffer the incoming data and then transmit it out once the data stops. This will add a lot of latency - and cut your bandwidth by half, but it would likely work.
A more sophisticated method would be to start transmitting the data once you have a few characters in the buffer. The number of characters to buffer will need balanced to minimize latency and prevent breaks in the communication.
It may be long gone now, but if you run across that old project I would be interested in seeing if I could get it working.