manoj99

How to make a PLC Device accept data exported from Application Software

6 posts in this topic

I have a Vibration monitoring software+Hardware combination. This combination can visually be shown as following:

             
 

Sensors Connected to H/W which need to be monitored

 

Conversion Device - which converts the raw data generated by Sensors and convert them into software readable format

 

Application Software to analyze the data and generate reports, sound alarms etc.

 
 

<------->

<------->

 
       
             

 

Brief Description:

Sensors: are connected to H/W (motors, turbines, etc) to collect different type of data like sound, temperature, RPM etc

Conversion Device: It is an electronic device which receives raw data from sensors and convert this raw data into a format which can be read and understood by the Application software.

Application Software: is the one used for analysing this data generated by Conversion device. This software, based on the analysis, raise alarm, generates multiple different type of reports etc.

 

I now have a client which needs the post-analysis data generated by software to be exported to a PLC/Scada device using either “Modbus RTU” or “OPC” protocol. My problem is that I have never done this before. I, therefore, have a few queries:

1.      What is the step-by-step procedure to follow?

2.      Is it possible at all?

3.      Do we have any programming language available to program a PLC/Scada device in such a way that it accepts data generated by a software via Modbus RTU or OPC? If yes, then I would greatly appreciate it if I can be given the same.

4.      Are their any free PLC/Scada simulator software available to test communication between software and PLC /Scada? If yes, then kindly let me know.

Please do let me know in case if I am missing something, or if am going in a completely wrong direction.

 

Share this post


Link to post
Share on other sites

Analog sensors connect to the conversion device directly.  The conversion must have I/O capable of handling the analog signals.

If the field sensors are not analog but use an industrial protocol (Modbus, Ethernet/IP, Profibus), then an OPC server could probably talk directly to the field device, but it is more common to get data into a PLC using the industrial protocol and then talk to the PLC through OPC.

OPC or Modbus could be used between the conversion device and PC application software, assuming the application software has a access to an OPC client that can get data from an OPC server or a Modbus master/client.   Or an OPC server might be used to get data from the conversion device directly to a database, which the application software uses.

OPC and Modbus are both bi-directional, so results of analysis can be sent back to a PLC for control/alarm action.

1.  There is no step-by-step procedure for a project of this complexity.  

2.  With enough time and money, anything is possible.   The industrial world has done tasks like this (sensor data > PLC > analysis app) for decades now.

3.  This a question for the PLC/SCADA device vendor.

A given PLC/SCADA device determines which communications protocols it handles (many times an option), which is brand/model specific.  

If a PLC/SCADA handles a given comm protocol then its development software would have the means to deal with the comm setup and handling the comm data.  

The interaction between application software and a PLC is almost certainly a custom programming job, which is what 'systems integrators' do for a living.

4.  Freeware
I think most OPC servers will run for 2 hours in demo mode before they need to be reset, which is the development/test mode for the OPC server.  A run-time license would need to be purchased for the OPC server to run unattended.  But be aware, the purpose of an OPC server is to communicate the data to an OPC client, which needs to be associated with the application software.   One generally assumes any OPC server communicates to any OPC client, but there are freeware OPC test clients, also.

There are freeware Modbus client/master and server/slave programs of limited functionality.  They are useful for testing but I'm not sure how valuable a Modbus test program is in the scope of this project.

Direction

PLCs make real time decisions on input data and change their outputs for control purposes - turn on a motor, generate an alarm, that kind of stuff.   What data analysis is needed beyond what a PLC does?

Generally, the people who sell the high value data analyis software make it quite clear about what is needed as input for the software and what it needs to run with.   Isn't this clear for your analysis software?

1 person likes this

Share this post


Link to post
Share on other sites

Hello Dan,

Thanks a ton for your response. I really appreciate it. 

 

Analog sensors connect to the conversion device directly.  The conversion must have I/O capable of handling the analog signals.

You are absolutely correct. Yes these are Analog Sensors and they connect to conversion device directly. The conversion device does have I/O capability, however, it has been designed to export is Output to the Application Software only. 

The reason for me to ask this question was the fact that I am an IT guy and have never worked with PLC/Scada or for that matter any electro-mechanical device in past. So this is a completely new scenario to me. However, your response has certainly provided me some ammunition to research and explore some new ideas.

My main problem is, that the current scenario, "Sensor >> Conversion Device >> Analysis and Monitoring Application" is an integrated and proprietary Application Software + Hardware . Therefore, it can neither be changed/modified nor can be removed as my client won't allow that. I have to design a solution keeping in mind the fact that the data will have to be exported by Application Software to PLC rather than coming from Conversion Device to PLC directly or via an OPC Server. And PLC/Scada needs to accept this incoming data from Software itself.  

So the communication will remain in the following way:

Sensors Connected to H/W which need to be monitored

<------->

Conversion Device - which converts the raw data generated by Sensors and convert them into software readable format

<------->

Application Software to analyze the data and generate reports, sound alarms etc.

<------->

PLC/Scada

The only point of consolation for me is that the Application Software does have the facility to export data using Modbus/OPC protocol. 

Now, I will have to find the way to make PLC accept this data either by installing an OPC Server in-between this Application and PLC and make them talk, or by some other mechanism. 

And to answer your questions given under "Direction" heading:

PLCs make real time decisions on input data and change their outputs for control purposes - turn on a motor, generate an alarm, that kind of stuff.   What data analysis is needed beyond what a PLC does?

Well, the idea behind having this Application Software is to know in advance what type of problem may arise in Motors in future by analysing the data generated by functioning of Bearings and other components, thereby preventing unplanned downtime and ensuring 100% availability and functionality of plant. The data is generated by changing conditions of lubrications/temperatures/Sounds/vibrations produced by motors and other critical components of plant. PLC can generate alarm or make real time decisions, but idea behind implementing this application software + hardware combination is to predict the break-down well in advance and to avoid them completely. This is the job of this combination. 

Generally, the people who sell the high value data analysis software make it quite clear about what is needed as input for the software and what it needs to run with.   Isn't this clear for your analysis software?

This is "Hardware+Software" combination is a Real-Time Online Temperature/Velocity/Sound/Vibration Monitoring and Analysis application. The main purpose of my client behind using this application was prevention of Any unplanned downtime by getting to in advance about any problem that may come in Motors due to wear and tear. As written above, the data needed by this Application is the data collected from the changing conditions of lubrications/tempeartures/Sounds and also the amount a& type of Vibrations produced by Motors in whole as well as its components like Bearings, Blades, Belts etc separately. Hope that explanation helps. 

 

Many Thanks

Manoj

Edited by manoj99

Share this post


Link to post
Share on other sites

OK, now I have a better understanding your thread title, "How to make a PLC Device accept data exported from Application Software."

Vibration is one of those vertical knowledge categories that is so 'expert' related and sophisticated that I consider a category for which Artificial Intelligence might bring some value.   Ordinary people do not have the experience to interpret changes-over-time of frequency domain FFT charts (nor do most have the desire).   After sitting through a Bently Nevada presentation some years ago, it impressed me that the analysis of vibration and its related data is something for dedicated, expert, specialized software that relies on expert knowledge and years of experience in the field.

As I mentioned before, a PLC is real-time industral controller, it is NOT designed as an analysis platform.   This forum or another like once had a thread asking about trying to do FFT's (Fast Fourier Transforms, time domain to frequency domain conversion, a key element in vibration analysis) and the response was, no! a PLC is the wrong platform for running FFTs.

If the application software is sophisticated enough to determine that a motor should be shut down, then writing a value to a PLC programmed to recognize that value and interpret the value as "shut down motor #x", then a PLC brings some value to the party.

But if the application software already generates a report that tells you "conditions at motor #x reflect the need for shutdown and maintenance, maybe even to the level of "maintenance on bearings 13B and 14A", then it takes human beings to implement the sequence of tasks needed to do that, sequential steps like

- scheduling  (when can the motor and what it is driving be shut down)
- checking inventory for the needed parts (bearing, gaskets, whatever) and ordering if need be (and how does that affect scheduling?)
- issuance of a work order and who does the work (contractor, staff?)
- motor shutdown
- LOTO
- actual work - barriers, wrenches, pullers and the guys who do that

all of those steps involve humans doing things that PLC's don't do.  The PLC might only be involved in the shutdown part; PLC's do not issue work orders or check inventory.

So, what kind of data is the app software exporting?

A.  Data that needs further analysis (probably a task for more sophisticated software, not a human, unless you've got vibration experts on staff)?

If you need data exported for further analysis, then you need to find such expert software that includes an OPC client that can talk to the OPC server in the dedicated box.   

B.  Alarm data that needs to be annunciated (something a PLC would do as an intermediary to the actual annunciator (light, horn, bell)

If the dedicated box does analysis that can issue an alarm that means a failure is imminent and an alarm needs to be annunciated, then either Modbus or OPC could conceivably write a value to a PLC that the PLC (when so programmed) would interpret as an alarm for which it turns on an output connected to a horn/light/siren or even sends an email.

C  something else?

You select a server for server tasks and not a work station.  This is a similar situation - what is the data and what task has to be done with the data? 

Previously I said, "the people who sell the high value data analysis software (your dedicated box) make it quite clear about what is needed as input for the software and what it needs to run with.  

Now I have to ask a modified version, "the people who sell the high value data analysis software (your dedicated box) (should) make it quite clear about what data is available for export and what is available to export the data.

At a minimum, you need to figure out what kind of data is coming out of the dedicated box and what needs to be done with that data - does it need a PLC or some other software?  To some extent you know there is OPC and Modbus, but you need more particulars:

Does the dedicated box have
- OPC DA server (older, more common version?
- OPC UA server (more recent version)?

- Modbus connectivity through Ethernet (Modbus/TCP)?
- Modbus connectivity through RS-232 or RS-485 (Modbus RTU)?

Is the device a Modbus client/master?
or is the device a Modbus Server/slave?

A server/slave (almost) always has a table or map of numbered registers that are used to call the data in that register.  Some very sophisticated server/slaves have a custom programmable table/map that the programmer populates with the needed data.

Modbus is useful only for nearly realtime data points.  Although the Modbus specifications include some commands for block data transfer, almost no commercial devices implement those commands.   Those commands might be used by a proprietary software, but then you, the user, don't even need to know its Modbus, it's just the protocol used by the software.

OPC has had some means of moving blocks of data, histories, but I have no direct experience in implementation of such, so I don't know how well it works or how wide spread those functions are.

Share this post


Link to post
Share on other sites

There is a category of software for dealing with process data from controllers known as HMI software.    HMI software is designed to talk to controllers through Modbus or OPC, get data from a controller/box via Modbus or OPC, put data into a database, trend the data as Y-t charts, and since it's usually a Windows app/service, it has the power to do custom programmed analysis.

Every PLC vendor has their own branded HMI softare, then there are 3rd party HMI software vendors like Wonderware, Advanced HMI, Ignition, or Indusoft that are OPC clients out-of-the box, so they talk to OPC servers.    The OPC client will most likely have Modbus driver in its OPC client.  If not, one buys the Modbus license for it.

The software package is a toolbox of development software, a blank slate that needs to be programmed.   One buys a run-time license for the developed program.   But none of the generic HMI software packages come with pre-programmed, high level software analysis of process (vibration, in this case), that's the job of the integrator/programmer.

Share this post


Link to post
Share on other sites

Dan,

You make me think back to my days in the power generation field.  I remember working with many Bentley-Nevada systems and then having to go with their IO to a third party Sequence of Events Recorder before getting any data or signaling into the PLC or DCS.  Hopefully, that's a much easier task these days.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now