Software vs. Hardware PLC?

It would really help to have some idea of the size of the application.

As has been asked before, how many I/O points do you have? What types.

You may not be able to say but if you could share the general type of system you are working with there may be some application specific equipment that would really fit what you are trying to do better than "rolling your own" solution (all though, roll your own is usually more fun)

Total_newbie said:

I see now that although some of these devices have Ethernet/IP - probably the one that I would be interested in has option of Profibus, CANbus, or DeviceNet.

Click to expand...

The straight forward way to do what you need is to add DeviceNet functionality to the C/C++ controller. Being an Intel board (I am assuming here), it should have PCI or PCIexpress expansion, then use off-the shelf PCI/DeviceNet master as some of the one below:
https://www.hilscher.com/products/product-groups/pc-cards/pci-express/cifx-50e-dndnm/
They provide drivers other than for Windows and if they do not have the RTX driver you can ask for the sources of the Linux driver and port it to your RTX environment.

BobB said:

Not even Linux for mine - computer power supply dies - whole process dies! Use a PLC - they are far more robust.

Click to expand...

First of all there are many different grades of PC power supplies. Second who is saying you should use a Desktop PC as a controller?

If it is a critical process use server grade hardware, or use a purpose build Industrial PC.


Further:
PC hardware on paper does not reflect PC hardware in reality. Processor, RAM and Drives are only a small portion of the story.

This is why there is a big price jump between consumer grade laptops and business grade laptops. Having use both for work I will shell out the extra money for the Business grade every time.

So it is a single Temposonic sensor (probably both position and velocity signals ?), and you need to log up to 1 kHz ?
Going from 1 Hz to 1kHz is not trivial.
Do you mean that you must sample every 1 ms, or do you mean you must be able to record a signal that may change with a frequence of 1 kHz ? If it is the latter, then you need to sample every 400 μs or faster.

A program running on a Windows PC (edit: or Linux) with RTX extensions can go down to 1 μs.
I think that the lowest RPI for Ethernet/IP is 1 ms.
Profinet IRT can go to 125 μs.
You can forget Profibus and CAN at these speeds.

edit: We are using Temposonics with Profinet interface.

Total_newbie said:

I have next-to-no experience with PLC programming. I am a C programmer, and have an application (in C) running on control PC which needs to get some real-time data (pretty slow, 1 Hz or so) from an external device which normally is configured to connect to PLC via Ethernet connection. It looks to me like I have two ways to do this.
1) Get a hardware PLC as an in-between (between device and my PC control software), and then poll the PLC (I would probably connect to PLC via RS-232, as I have done this before...) for data for my C application.
2) Have software emulator running on my PC (RSLogix?), and have external device connected through that.

At least one advantage of (2) is that I don't have to buy another PLC (though I don't know price of software emulator software...).

An advantage of (1) is that I wouldn't have any overhead of the emulator running in background on my control PC (I do have to make sure that nothing interacts adversely with control software...).

Does anyone have any input regarding this, or some other solutions which I may be missing?

Thanks

Click to expand...

This webinar from Siemens may be of interest to you.
And a question for those who are experts in this topic, is Siemens going Beckhoff? Or did I miss the point of their software controller?

Position sensor - integrate with PC application

Fastest rate that we would be sampling would be 1000Hz. We just need get to a single data point (position) from sensor at that rate.

The idea of getting some off-the-shelf application for this sounds great - but we have already built a very large application (Windows/RTX) which is getting a lot of other data from various sources (which we don't want to touch). It is just this one position sensor which we have to replace - and want the easiest way to get data from it (for the RTX side of our application).

The information about max communication rate of the different protocols (i.e. that profinet is so much faster than profibus) is very important to know.

It sounds right now that our best option is to go with profinet (assuming that the sensor we want comes with this option...), and use (as suggested) something like the https://www.hilscher.com/products/product-groups/pc-cards/pci-express/cifx-50e-repns/ card for interface. If if they have drivers that work with RTX - that would be great. Otherwise - I could hopefully get their source.

Does anyone know of any off-the-shelf C code which can construct/decipher basic Profinet packets? I guess with this (and PCI card), I would be able to get going with this project...

Total_newbie said:

Does anyone know of any off-the-shelf C code which can construct/decipher basic Profinet packets? I guess with this (and PCI card), I would be able to get going with this project...

Click to expand...

Hilsher or HMS would provide you not only the RXT driver, but also an API that will let you access the process data and diagnostics data, without your application having to decode the PROFINET packet, or DeviceNet packet or whatever. They will also provide a Windows configuration tool to configure theb master including the ability to integrate the device description data into the console.

If you need 1 ms (1000 Hz) then Profinet RT is enough. This is supported by all Profinet rated devices. To go <1ms it has to be Profinet IRT which is a higher specification.
You must also check that the sensor can provide actual data at that rate. The Profinet side can send the data, but can the sensor provide the data ?

Just want to mention that there is also Ethercat which is even faster than Profinet, and Temposonic have sensors with Ethercat (for example: https://www.temposonics.com/Products/IndustrialPositionSensors/R-SeriesVPositionSensors/R-SeriesVRP5)

Outputs: Analog, SSI, PROFINET, EtherNet/IP™, POWERLINK, EtherCAT®

Click to expand...

Total_newbie said:

Does anyone know of any off-the-shelf C code which can construct/decipher basic Profinet packets? I guess with this (and PCI card), I would be able to get going with this project...

Click to expand...

https://github.com/search?q=profinet


https://github.com/netdata-be/libnodave



?

Hilscher also has a Profinet IO Controller stack:
https://www.hilscher.com/fileadmin/...PROFINET_IO_Controller_Protocol_API_19_EN.pdf

I dont know cost or licensing model.

Ethernet communications with sensor

OK - so now (due to parts availability) - I am back to the Ethernet/IP version of this sensor. I will be using this under real-time (RTX) - so at least the ethernet and TCP/IP portions of communications protocol look like they are readily available. What is am looking for now is the next layer - "encapsulation" layer, which is generic layer for encoder ("Implementation is based on the ODVA device profile 22 hex, encoder device").

It looks like in this layer I am just sending command (in encapsulation header format) to request data from sensor. Anyone aware of any code which includes this layer? (This must be a common task in industrial applications written in "C"...)

Thanks!

What you ask is described in the CIP specification, which is available to ODVA members. Even if you had access to the specification a lot of development work would be needed to get an EtherNet/IP scanner application working properly. There are some Github sites with open source EtherNet/IP stack, or you can buy proper sources from companies like Real Time Automation or Pyramid Solutions, but their solution only makes sense if you will be producing dozens of machines per year because their sources would set you back a few tenths of thousands of US dollars. If you only need one machine, your best option is the Hilscher board which also offers you the configuration tool. With regards to open source you have to be careful as there is no assurance that this open source is not using copyrighted sources.

This definitely sounds like the route that I want to go. Code (reading info from (probably) MTS position sensor) is only going to running on a few machines - so as you say - there is no reason to purchase expensive source. I will contact Hilsher about their board.

I would be interested if anyone has experience with similar application. What I am looking to do seems to me to be a relatively standard application - reading sensor info via Ethernet /IP into code running on a control PC. I am particularly interested in what rate I can reliably expect. The sensor says in specs that it can go above 1000Hz - but will I have any problems reading this continuously via Ethernet/IP?

Thanks for all the help...

I do not know about the particular sensor. With a solution like the Hilscher board you can try reading from the API the input data as fast as you can. But the important thing is: 1) What is the minimum RPI (requested packet interval) supported by the device, and 2) What is the actual latency of this device. This RPI information is encoded in the devices' EDS (electronic data sheet) which you must register in the Hilscher configuration tool. The tool will not allow you to configure an RPI shorter than the minimum descried in the EDS itself. Presumably the vendor of the sensor has described a suitable minimum RPI which corresponds to the capability of the sensor. I would say the limitation is not the EtherNet/IP communication, rather it should be the latency of the sensor which is related to the physics of whatever physical or chemical variable it is measuring.

I've seen some equipment using R-pi.
For example, plant ventilation system using R-pi. R-pi has I/O ports. It can be using to get input signal from sensors and output to some cheap control relays. Very simple cheap design in a big well known factory. You wouldn't believe it.