PLC in customer product

[Englemon]

I am on a team that is planning on using a Omron CP2E PLC in a product that is going to get plugged into a wall socket. The PLC is going to have to communicate over ethernet to a device and control some IO. It will also control a power supply over serial.

I am not very familiar with PLCs and the programming of them.

I have a couple of concerns related to this and was hoping to see if they are unfounded or not based on other peoples experience. In my experience PLCs main used is to place it in a cabinet that is intended to always receive power and is not contently power cycled. I am more inclined to use some sort of single board computer
My concerns are:

• The fact that the device will often be unplugged and left on the shelf means that the battery and memory will get affected over time when not receiving power.
• More locked down system will reduce flexibility for both ethernet and serial programming.
• Our team is more familiar with embedded programming and not PLCs. Is there a large learning curve.
• Does a PLC have lots of overhead that makes is bad for running control loops on it?

I might just be that I am only familiar with old ladder logic PLCs. But, if any of these concerns are real then I would like to know now before we go down this path. The information online can be hard to filter through.

[snarkysparky]

According to the web page the PLC has no battery.  Memory loss should not be a problem when unpowered.

It can be more difficult to program network and serial functions as ladder logic is a complete turd to use.

The low cost PLC like this one uses ladder logic for programming.  It can be very aggravating for someone coming from normal language programming.

You should easily be able to get the logic to scan in less than 10ms. But getting it to be a deterministic scan for control purposes might be tricky.
The devil is in the details of each particular PLC.

The whole reason for PLC existence is that the overall body of knowledge required to program simple machines is MUCH less than would be required for a traditional computer running a modern language.  And reading the program ladder to diagnose machine trouble is much easier also.  Maintenance personnel can be taught to do it.  With an embedded computer watching the machine state is nearly impossible without special coding to bring it out.

And lastly the PLC has a very hardened system against a noisy electrical environment.  It will stay running with all manor of voltage spikes and noise coming at it through all its inputs.  An embedded computer needs a very carefully designed IO layer to so that this cannot cause CPU corruption.

[H.O]

Running control loops is a very common task for a PLC. Even the most basic ones can run multiple PID loops. With that said you don't say anything about what sort of bandwidth you need. A 1ms difference in timing when running a temperature controller for a HVAC system makes no practical difference. That same ms might be totally unacceptable for a current controller.
 
The CP2E is able to run 1 cyclic task (your main program loop), 16 interrupt tasks and 1 scheduled interrupt task. The scheduled task can be set to run at 1ms interval (or slower) with a timing resolution of 100us - all according to the datasheet.

As far as communication goes you have to really look into the programming manuals for the system to determine if it'll allow you to do what you need. They will (likely) provide ready-made function blocks for things like MODBUS TCP and PLC<->PLC communication but if you need to communicate with custom stuff you need to do your homework. Same for RS232, it'll (likely) provide blocks for MODBUS RTU and communication with their own HMI-panels etc but for custom stuff (say receive and parse NMEA strings or talk SCPI to a power supply) you have to read up on what's possible with the specific type of PLC.

[coromonadalix]

you have Arduino's open source  plc projects... maybe something useful ??

[bidrohini]

Since you're using an Omron PLC, I think you can get more specified answers here:
https://forums.mrplc.com/index.php?/forum/17-omron/

[MitjaN]

3. Our team is more familiar with embedded programming and not PLCs. Is there a large learning curve.

History of PLCs bears quite heavily on the workflow how to work with them. They were developed by EEs for EEs. So electrical part is usually quite robust, but the IT workflow used to be PITA.

PLC programming tools (IDEs) usually support one and only one workflow process. No version control, code (text or ladder, function block diagrams) stored in proprietary formats therefore no diffs, no merges. The same concepts in PLC IDE's are sometimes presented quite differently than in common programming IDE's.  Adding any additional automation in the build system is complex if not impossible. The tools are vendor locked, so switching PLC brand means switching PLC tools. This by itself is not a major issue, but the workflow might differ so the switch takes a bit more time. And so on ..

Now things might have changed in the last 10 years, but I suspect that parts of this still hold.

So if you are more of an embedded shop working with either MCU's or SBC's I'd seriously reconsider taking a project with PLC's in it. For all of the above reasons it can be a quite significant drain on your resources. I suspect much more than if you would use a MCU or a SBC. Try figuring out why PLC is a hard requirement or even try to negotiate to use SBC or MCU instead.

[Doctorandus_P]

Omron CP2E apparently has "function blocks" and PID as such a block.

The video below @04:14 shows an Fujitsu MB91661 inside an Omron CP1E
(Warning: turn of sound or at least tune it down before starting that video).


There is nothing preventing you from just re-using the hardware and programming it like any regular microcontroller application.
On Aliexpress there are lots of clones of the Mitsubishi FX2N and they tend to have an STM32, and the single board PCB is very easy to reverse engineer. It's mostly a quite nice power supply with common mode filter and SMPS, inputs with optocouplers and either transistors or relays as outpust, and the input and output sections are many copies of the same circuit. Apart from that there is a seral port and RS485 (with the obsolete and not very robust SN75176 and without extra TVS diodes or such). And there are many variants from very cheap bare PCB's to DIN rail housings, different connector types, different number of I/O etc...

[rstofer]

So if you are more of an embedded shop working with either MCU's or SBC's I'd seriously reconsider taking a project with PLC's in it. For all of the above reasons it can be a quite significant drain on your resources. I suspect much more than if you would use a MCU or a SBC. Try figuring out why PLC is a hard requirement or even try to negotiate to use SBC or MCU instead.

You can spend the time learning ladder logic or the same (or more) time trying to harden an SBC.  PLCs are industrial strength devices, unlike the Arduino.  It's the IO that's important.

PLCs can handle different (and higher) voltages, often 120VAC or 24VAC/VDC and are quite simple to program once you draw out the ladder logic on a pad.  One machine I worked on had a drawing 30 feet long and we rolled it out on the shop floor when we had to troubleshoot or modify the equipment.

With a few hours of training, PLCs become quite easy to use.  Often the distributors have such training programs - sometimes into multiple days.  You can get quite good after 3 days of training.

[NorthGuy]

I am on a team that is planning on using a Omron CP2E PLC in a product that is going to get plugged into a wall socket. The PLC is going to have to communicate over ethernet to a device and control some IO. It will also control a power supply over serial.

You must be very rich. What is the reason?

[WattsThat]

If no one on your team is familiar with PLC’s, why use one? IMO, your comments indicate you think it is the wrong choice. Are you just looking for validation of your opinion?

PLC comm ports, especially Ethernet, will only handle predefined protocols. Read the product info carefully.

In general, your questions would be far better answered by an Omron product specialist rather than a bunch of random people on an electronics forum on the internet. Sure, some of us are well versed in PLC’s but you’re asking generic questions so you’ll get generic answers like the one above.

Oh, yeah. Forgot to mention that none of your concerns are valid with modern, industrial PLC’s. Arduinos and single board computers aren’t industrial products.

[rstofer]

Many years ago (at least 25), I used GE Fanuc PLCs distributed over a large factory and tied them together with Ethernet.  Part of the system also used dedicated coax to certain sensor modules that weren't ready for Ethernet.  I don't recall it being difficult to build up the system.

In technology terms, this was a LONG time ago and it all tied together very well.

Now that GE and Fanuc have split, I don't know what to say about the current products.

[nctnico]

If no one on your team is familiar with PLC’s, why use one? IMO, your comments indicate you think it is the wrong choice. Are you just looking for validation of your opinion?

PLC comm ports, especially Ethernet, will only handle predefined protocols. Read the product info carefully.

Nowadays many PLCs can be programmed using a more procedural programming approach. I have several customers that use PLCs in products and all seem to use some kind of procedural language. All in all, it shouldn't be too hard to get up to speed with using a PLC. IMHO the advantage is having a rugged & proved piece of hardware + software that is ready to go and work reliably for decades (assuming you buy a quality PLC brand).

Omron CP2E apparently has "function blocks" and PID as such a block.

The video below @04:14 shows an Fujitsu MB91661 inside an Omron CP1E

There is nothing preventing you from just re-using the hardware and programming it like any regular microcontroller application.
On Aliexpress there are lots of clones of the Mitsubishi FX2N and they tend to have an STM32, and the single board PCB is very easy to reverse engineer. It's mostly a quite nice power supply with common mode filter and SMPS, inputs with optocouplers and either transistors or relays as outpust, and the input and output sections are many copies of the same circuit. Apart from that there is a seral port and RS485 (with the obsolete and not very robust SN75176 and without extra TVS diodes or such). And there are many variants from very cheap bare PCB's to DIN rail housings, different connector types, different number of I/O etc...

I would rather NOT use electronics bought from Aliexpress for an industrial application. More often than not a PLC controls a machine with moving parts that can go seriously wrong if the PLC decides to go of the rails.

[WattsThat]

Nowadays many PLCs can be programmed using a more procedural programming approach. I have several customers that use PLCs in products and all seem to use some kind of procedural language. All in all, it shouldn't be too hard to get up to speed with using a PLC. IMHO the advantage is having a rugged & proved piece of hardware + software that is ready to go and work reliably for decades (assuming you buy a quality PLC brand).

Nowadays? Procedural languages? Not really, at least not in North America.

I’d really like to know what mainstream PLC products have that ability. The only noteworthy products are those that use the Codesys tools for programming with Beckhoff being the defacto champion of that (mostly German products) market segment.

The truth of the matter is that with the US and Japanese/Asian products, the majority of the brand name PLC’s are programmed with custom, proprietary programming environments. The majority of that majority use ladder logic and function block type programming models.

For the OP’s application with a low I/O count and a minimal number of control loops, any suitable low cost unit will almost certainly be a ladder diagram with function blocks environment.

Until the OP returns with more information, we’re just flogging our own biases and opinions.

[nctnico]

Nowadays many PLCs can be programmed using a more procedural programming approach. I have several customers that use PLCs in products and all seem to use some kind of procedural language. All in all, it shouldn't be too hard to get up to speed with using a PLC. IMHO the advantage is having a rugged & proved piece of hardware + software that is ready to go and work reliably for decades (assuming you buy a quality PLC brand).

Nowadays? Procedural languages? Not really, at least not in North America.

Siemens has a whole bunch of languages to use with their PLCs which you can mix to suit the problem at hand. IIRC Schneider also has the ability to use procedural language. One of my customers is an absolute guru where it comes to PLCs and he uses the tools & languages to the maximum of their extend; he travels all around the world to work on complex PLC solutions. His skills are probably far beyond what you know is even possible. From what he told me the situation is similar with people trying to translate digital logic into System Verilog / VHDL without thinking how the tools / language constructs can help them make programming easier. Such people stay stuck at PLC ladder diagrams and spend ages on a problem that can easely be solved using the tools / language constructs the right way.

And yes, each PLC manufacturer has their own environment. That is just a fact of life; deal with it.