Software vs. Hardware PLC?

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

How many IO ?

What you are designing as a data-acquisation system.
There are some that can work with PC hardware only, i.e. cards that you insert in PCI slots in the PC. If that is not the solution for you, then the problem is how to connect the field devices to something that you can log data from.
A low-end PLC is actually a cost-efficient way to get the data from the field devices into something you can log data from.
I recommend to go for a PLC with ethernet instead of RS232.

A soft-plc will bring you nothing. The soft-plc will still need to connect to the field devices, and that brings a whole set of complexity.
Also, the license for a soft-plc is usually as expensive as a medium to high-end PLC anyway.

no need for PLC, just get IO interface module.

you can possibly use a software like Kepware to get the data into the PC using TCP connection

What is the external device? If it supports a relatively open protocol (modbus tcp, opc ua, etc), bring in a library to do that in your c code. If it doesn't, then tell us what it does support, so we can start recommending a direction.

• If it doesn't support any open protocols, can you use a different device that does? Are you tied to this specific device?
• Soft PLCs tend to work well when you have a lot of PLC stuff to do, and you need to sneak something PCish in. Some soft PLCs allow you to execute C code straight from the PLC itself. But it sounds like your system is a PC system that just needs data collection. As JesperMP said, soft PLCs are often at the expensive end of the PLC spectrum, at least partly because PCs generally have good performance as compared to the average PLC.
• There are a lot of ways to interface with PLCs from open source PC libraries. It can be a relatively easy route; especially if your performance expectations are relatively low (1hzish).

JesperMP said:

I recommend to go for a PLC with ethernet instead of RS232.

Click to expand...

2nd the motion!

My opinion is that the extra robustness and low cost of PLC hardware will justify using an external PLC.

You never get involuntary updates from Microsoft on the PLC. You don't have to worry about a zoom conference crashing the PC. Most PLCs will last for decades.

You have to pay for I/O anyway, and the PLC cost is not much different.

There is also a convenience factor: you can do scaling, totalizing, daily min/max, and alarming in the PLC and just worry about programming the PC for displaying info.

Total_newbie said:

I [...] 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.

Click to expand...

• Why do you call this a "control" PC?
  • What does it control?
  • What does it do with the data it gets? e.g.
    • what is the final disposition of those data
    • does it make some calculations or perform other processing on the data?
    • does it send the data, or something derived from the data, to some other host?
  • Is it more than an HMI?
• What is the external device?
• What is the character of the ~1Hz real-time data? e.g.
  • number of values?
  • discrete bits?
  • analog integers?
  • analog floating points?
• What is the nature of the PLC-to-device Ethernet connection?
  • What does "normally" mean in the OP?
  • Modbus TCP?
  • Ethernet/IP or CIP?
  • ProfiNet
  • other fieldbus?
  • web API?
  • etc.
  • And why aren't you interfacing the PC directly to the device?

I understand that answers to some of those queries might not be allowed to be posted on a public forum, but answer what you can please: it will make for more informed answers (although I suspect @Tom Jenkins nailed it, or @L33er if an interface module exists).

Tom Jenkins said:

My opinion is that the extra robustness and low cost of PLC hardware will justify using an external PLC.

You never get involuntary updates from Microsoft on the PLC. You don't have to worry about a zoom conference crashing the PC. Most PLCs will last for decades.

You have to pay for I/O anyway, and the PLC cost is not much different.

There is also a convenience factor: you can do scaling, totalizing, daily min/max, and alarming in the PLC and just worry about programming the PC for displaying info.

Click to expand...

I resolved the "involuntary" update issue with Win10 by disabling Automatic Updates in group policy. Now I get updates when I want and not when Microsoft wants to shove it in.

Here is link on how...use only the section that shows editing group policy.
https://www.windowscentral.com/how-stop-updates-installing-automatically-windows-10

drbitboy said:

• Why do you call this a "control" PC?
  • What does it control?
  • What does it do with the data it gets? e.g.
    • what is the final disposition of those data
    • does it make some calculations or perform other processing on the data?
    • does it send the data, or something derived from the data, to some other host?
  • Is it more than an HMI?
• What is the external device?
• What is the character of the ~1Hz real-time data? e.g.
  • number of values?
  • discrete bits?
  • analog integers?
  • analog floating points?
• What is the nature of the PLC-to-device Ethernet connection?
  • What does "normally" mean in the OP?
  • Modbus TCP?
  • Ethernet/IP or CIP?
  • ProfiNet
  • other fieldbus?
  • web API?
  • etc.
  • And why aren't you interfacing the PC directly to the device?

I understand that answers to some of those queries might not be allowed to be posted on a public forum, but answer what you can please: it will make for more informed answers (although I suspect @Tom Jenkins nailed it, or @L33er if an interface module exists).

Click to expand...

Good competent clarifications for such a device! Let him answer the same questions, otherwise nothing is clear

NetNathan said:

I resolved the "involuntary" update issue with Win10 by disabling Automatic Updates in group policy. Now I get updates when I want and not when Microsoft wants to shove it in.

Here is link on how...use only the section that shows editing group policy.
https://www.windowscentral.com/how-stop-updates-installing-automatically-windows-10

Click to expand...

I did that, and it seems to have stopped the windows updates, but my computer still randomly reboots sometimes when it's unattended. Windows swears there's nothing recent in the install history, so who knows what else is going on....

NetNathan said:

I resolved the "involuntary" update issue with Win10 by disabling Automatic Updates in group policy. Now I get updates when I want and not when Microsoft wants to shove it in.

Click to expand...

Thanks for the tip I am running 8.1 (it works, so ...) but I found a simlar function in it!

Tom Jenkins said:

You never get involuntary updates from Microsoft on the PLC. You don't have to worry about a zoom conference crashing the PC. Most PLCs will last for decades.

Click to expand...

Wait, Why would anyone run critical services like a soft-PLC on a windows machine?

Linux, LINUX all the way.

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

theColonel26 said:

Wait, Why would anyone run critical services like a soft-PLC on a windows machine?

Linux, LINUX all the way.

Click to expand...

The only softplcs I've used ran "with" windows, instead of ON windows. The old Siemens soft PLC ran on a realtime windows kernel that was protected in case of things like blue screens, and the new ones use a hypervisor system that are even protected from things like reboots (Windows shutdown still turns off PLC tho).


Agree linux all the way, though, lol

Software vs Hardware PLC

Thank you to everyone for your very useful replies (and questions - which also clarify what I should be looking for...)

A bit more information about my application. The device that I want to get data from is a linear position sensor (MTS R-series, spec sheet is
https://www.temposonics.com/docs/temposonicslibraries/literature/sensor_selector_guide_industrial_551814_en.pdf?sfvrsn=5fde8874_3 )

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.

My control software is written in C/C++, and is running under Windows in parallel with RTX (Real-time). The RTX side is because certain control tasks in software are very time-dependent. Up till now - we were using position sensor that provide quadrature signal, and quad card was deciphering that signal and providing us with position info. Control software uses position info in real time to make corrections to other processes. (I initially wrote 1Hz would be sufficient - but now I see (based on new application requirements) - that we would probably want much faster, maybe 1000Hz.)

Some suggested using a separate PLC to handle getting data off of this position sensor - but then I still have to get data into my C/C++ application. I have "spoken" under my present code with PLC (via RS232 interface) - so I guess I could do this. I have no idea though how fast this communication would be.

In terms of just getting data directly off of device - I was looking for some C library which had code to do so. It looks like CANbus protocol (of the options above...) would be easiest to implement from my C code, and I guess that I would just use a USB to CAN adapter.

I hope that this clarifies (at least to extent that I understand issues at this point in time...) what I am looking for.

Thanks