Hello，
I would like to use the RevPi instead of the Siemens PLC, but I am not sure if the RevPi has the same or better data handling capabilities as the Siemens. I would like to know how the data handling capability of the RevPi compares to the Siemens CPU 1511-1PN and CPU 1515-2PN. Apart from that, if I use profinet, how long is its communication cycle?
Best regards,
Cade
RevPi versus Siemens PLC
Dear Purecade,
I know nothing of "regular" PLC's, really, but your comment about the communication cycle brought me here. So here is a sort-of answer to your question. Coming from a software world, the focus on I/O or slave or communication cycle always surprised me.
I have a little system running, probably tiny by any of your standards. A few pumps, three-way valves and a few heating elements. I run the control loop once per second. That is plenty fast for any of the systems I control. The heating elements take minutes to heat up the tank, the three-way valves take 10 seconds or so to reach their final point in case of a full swing. Everything runs in Docker containers, connected over MQTT. Each of these introduce their own uncertainties about timing and latency. So all in all, I run a pretty rough system, timing-wise.
The only things that are timing sensitive are the alarms and the emergency stop button. When a circuit breaker trips, or when someone presses the emergency stop button, waiting for the next control loop run is too slow. For that I use the event-based option in revpypyload. I have not measured the latency, but when I listed to the sound of the breaker tripping (manually) and the pump motors stopping, there is no delay that I can hear or see.
So this gives me a system that 1) I can develop in using normal-for-me systems (message bus, Python, JavaScript, InfluxDB, Docker and GIT), with 2) relatively low CPU load because I don't run the control loop all that often and 3) with near-instantaneous response times to alarm events. I have not had to worry about hardware timing yet. I have a hard time imagining a situation where I would have to, since my timing-sensitive components are not mixed with the non-timing sensitive components.
And even if timing became an issue, I can always move components that are not timing sensitive off of the revpi and onto any other computing device, be that another revpi, an industrial PC or a cloud hosted system. Docker and MQTT make such component placement transparant.
So I guess my point is: maybe the direct 1:1 comparison between the revpi and (say) a Siemens PLC ignores some of the opportunities that the revpi offers. But then, if the hardware timing of the external modules cannot be met, no amount of MQTT and Docker can save you.
Kees Jan
I know nothing of "regular" PLC's, really, but your comment about the communication cycle brought me here. So here is a sort-of answer to your question. Coming from a software world, the focus on I/O or slave or communication cycle always surprised me.
I have a little system running, probably tiny by any of your standards. A few pumps, three-way valves and a few heating elements. I run the control loop once per second. That is plenty fast for any of the systems I control. The heating elements take minutes to heat up the tank, the three-way valves take 10 seconds or so to reach their final point in case of a full swing. Everything runs in Docker containers, connected over MQTT. Each of these introduce their own uncertainties about timing and latency. So all in all, I run a pretty rough system, timing-wise.
The only things that are timing sensitive are the alarms and the emergency stop button. When a circuit breaker trips, or when someone presses the emergency stop button, waiting for the next control loop run is too slow. For that I use the event-based option in revpypyload. I have not measured the latency, but when I listed to the sound of the breaker tripping (manually) and the pump motors stopping, there is no delay that I can hear or see.
So this gives me a system that 1) I can develop in using normal-for-me systems (message bus, Python, JavaScript, InfluxDB, Docker and GIT), with 2) relatively low CPU load because I don't run the control loop all that often and 3) with near-instantaneous response times to alarm events. I have not had to worry about hardware timing yet. I have a hard time imagining a situation where I would have to, since my timing-sensitive components are not mixed with the non-timing sensitive components.
And even if timing became an issue, I can always move components that are not timing sensitive off of the revpi and onto any other computing device, be that another revpi, an industrial PC or a cloud hosted system. Docker and MQTT make such component placement transparant.
So I guess my point is: maybe the direct 1:1 comparison between the revpi and (say) a Siemens PLC ignores some of the opportunities that the revpi offers. But then, if the hardware timing of the external modules cannot be met, no amount of MQTT and Docker can save you.
Kees Jan
Hello Purecade and kjkoster these articles can help further
- How to use the KUNBUS Gateway modules
- RevolutionPi Gateway Tutorial
- Measuring analog data with the AIO module - a good example of performance and cycle time
- RevolutionPi Hardware FAQ | Is there any information about the performance of the RevPi?
