PLCs and Industrial Thread

PLCs and Industrial Equipment Thread

So which PLCs do you prefer when working on industrial controls, Holla Forums? Personally a fan of Allen Bradley, especially the compactlogix branch since I can hook 'em up to devicenet or to ethernet to get my shit done and access 'em from home on a company laptop so I don't have to go in at 2AM when a pump shuts down due to bad programming on the engineer's part. Fucking love RSLogix 5000 since it's easy to program in shit and connect it all together.

I've never had a chance to use Siemens PLCs but I hear they're alright other than having shitty proprietary software so you can't interconnect as easily. I just know to avoid Motorola like the plague since those fuckers make it so you have to get one of their technicians to come out and fix it when you need to change the programming for your system (seriously, fuck those guys).

What industrial equipment do you get to work with?

Other urls found in this thread:

en.wikibooks.org/wiki/Introductory_PLC_Programming
en.wikipedia.org/wiki/DeviceNet
rockwellautomation.com/en_NA/events/overview.page?
twitter.com/SFWRedditGifs

Ah, forgot to mention the other benefit of compactlogix is the module system that Allen Bradley built it for.

I have no fucking clue what PLC stands for. Public logic controller?

Programmable Logic Controller. All I know is they are used for actuating motors, etc. in industrial settings

And they're gorrilions of dollars AND proprietary shit. Programming them is mega- cancer too. At least it's the only place ive seen a RTOS which is neat, I guess.

Programmable Logic Controller?
It's pretty much the thing powering most of your HVAC equipment, pumps, motors, etc. It uses ladder logic (or block logic depending on the type, Rockwell supports both) and simple bits to run a program saved in memory to activate and deactivate and interpret various items in an industrial setting.

Advantage of using a PLC in industry is that they're hardened, designed to be used for 20+ years, and super fucking easy to maintain and program so you don't have to hire a specialist to do it for you. They also work a lot easier around high voltage compared to a PC. Overall PLCs are just better all-around compared to PCs for running a factory or utilities facility.

Who in their right mind would buy one of these power suckers? What is the use case?

Not when you consider you have to replace a computer ever 2-5 years whereas your PLC is gonna last you 20+ years and virtually never go bad.

Rockwell specifically designs them so you can swap 'em out with custom modules. Even factorytalk and devicenet are designed so you can use any company's system you want with them.

It's easy as fuck and even an electrician/electronics technician can reprogram them if they had to. The programming is based on how a motor control system's electrical diagram would work based on ladder logic. Ladder logic is literally just showing how a hardwired system would function, but PLCs give you the freedom to change the programming instead of having to hardwire it. It's fucking great.

Arduinos are for prototyping.

...

Also this.
I'm more of a Raspberry Pi guy myself anyways since that's what most good 3D printers use.

...

These images more or less give you an idea of the different ways you can program a PLC in RSLogix 5000. From what I know, Motorola and Siemens works on a similar method. The nice thing about proprietary in this case is that you're paying for the constant access to troubleshooting information and live sessions with the folks over at Rockwell or Siemens. It's included in the price when you buy a PLC for use at an industrial facility.

Unexpected situations come up in industry that a programmer might be able to fix but it'll take him 6-12 hours whereas you can fix it in a PLC in a matter of minutes, maybe an hour tops.

Such as? I could see someone using a pajeet language like python on the adrino and royally fucking things up. But that goes back to hiring someone who has no fucking clue what they are doing.

Well it's hard to give a description when I don't know how you'd go about coding it or what industrial situation we're in.

If we're working at a wastewater facility using an anabolic process to produce methane to power the building's heat in the winter, I certainly would rather rely on a PLC's constantly updating PID loop for determining the temperature of the fermenting vats so I don't get fucked by the EPA since it produces a paper trail showing how much methane we produced and that we didn't burn the sludge or not heat it up enough (you gotta be really fucking specific with the heat).

It's a lot easier on a cold day to tell the HMI to heat the tank an extra degree or two with a finger push and a numerical insert (or to tell the PLC to do it manually) than to write an entire fucking code to run the facility in which I have to (assuming I'm the programmer) make the changes myself instead of just telling the operator to do it over the phone. Operators don't understand code unless they're specially trained to do so, but they understand an HMI since it's more or less like bumping up a thermostat. You have to program your code to tell you when a boiler explodes or breaks down, whereas the PLC will more or less do that for you depending on the modules you have installed just based on the way you program it.

Just based on the way it's hardwired/the software works*
Polite sage.

From that pic using a industrial PLC seems more like a properiatary hardware and software. The hardware is a adrino like system with many backups for idiot proofing. The software is just pointers to memory adresses of the hardware that then are translated into your favorite langauge of choice. Complete with a verifier so you can verify every possible output of your program. Those hardware pointers output a select voltage based on another input somewhere translated by the properitary middleware. You also get huge dedicated support for if things go wrong.
Literally this is what a PLC is from my understanding.

Going along with this, programming an HMI in factorytalk or one of the custom systems like PlantPAX to do it rather than program an entire human machine interface where I don't have technical support if my programmer can't fix it.

More or less it's an I/O system interface, yep. PLCs are the industry standard if high voltage or motors are involved.

This may be to your fancy: en.wikibooks.org/wiki/Introductory_PLC_Programming

Still it boggles my mind why anyone would pay such outragous prices for something able to be built for less than 300$ max, is more secure by definition, and you can customize without needing dependency on someone else. I remember reading how the G programming language worked a while back. The whole PLC scene seems like a giant fucking mess to me.
T. neet

Pretty much the same reason Solidworks is still more popular in industry than AutoCAD. Dedicated support is huge in manufacturing where 3 hours of downtime can cost your company $12 million in lost productivity, and you're working with a group of technicians where half of them are smart individuals that could probably learn custom software and the other half are window lickers than know how to fix the mechanical systems but don't know shit about computers past the programs the employer made them learn over the course of a few months.

The window lickers are pretty necessary though since it's extremely hard to get a programmer near a super-hot piece of machinery that's rattling like crazy because something is wrong with it to figure out if they can change the program to fix it or if they have to shut down the equipment entirely for a few hours to cool down (costing a shit ton of money) to hopefully find the problem. A PLC pretty much pays for itself in about a week at most production facilities. At least the micrologix do. Compactlogix might take closer to a month to pay itself off.

The advantage is usability which is important in the industrial field when programmers demand extra to be electromechanical specialists as well (or just flat out refuse to do so).

Also I want to bring up that you'll usually have a compactlogix that communicates/indirectly controls the micrologix via messaging, and a micrologix only costs about $300-$400, which is about what you'd spend bare minimum on an industrial computer anyways after shielding and everything else. Even when you throw in the HMI and software it still pays for itself in about a year at a new facility and stays good for another decade or two.

The OS, schematics, and software are still all proprietary.

visual programming is bad because it makes it impossible to have any sort of abstraction above what they give you, and optimizing for the lowest common denominator isn't an upside. it's not like normal code would be bad either, since it you can still get stick in infinite loops with PLCs and the only reason you get out is because of the watchdog timer

I will make sure to look into that if I ever am in a position to decide on something like that. Sounds like a security risk at best. Backdoor at worst. Gah fuck neet hood. Is there anything like that in other PLC's? I sure hope not.

Well that's the thing about PLCs is you're supposed to run them through devicenet communications or other equivalents (very short very hard-wired system that prevents electrical interference and wireless access). Ethernet is typically the only "out" port where you can access it from outside the PLC, and that's typically suggested to be done as an end point within a closed network for the purpose of communicating with your computer for programming only. PLCs have built in security you can set so folks don't fuck with shit if they're not supposed to, and extension modules like PlantPAX let you set it so you know exactly which operator fucked with what at what time (and even set up what they can fuck with).

Believe it or not, one of the reasons a lot of industrial companies like PLCs is because of their inherent security just through the way they're designed and accessed. Unless some operator decides to take the company laptop home which he broke protocol to connect to the company computer so he could fuck with the program from his house not that I'd ever do that..., the ability to get into the data outside of the facility is extremely limited. Plus the electronic noise from the high voltage a PLC is usually positioned around makes wireless access virtually impossible. Don't gotta worry about blackbox shit like webcams in Windows.

You might enjoy this explanation from wiki: en.wikipedia.org/wiki/DeviceNet

I guess a better way of stating it is unless you know the program, you won't know what changing the bits on the messaging routine will do.

I think something to keep in mind with PLCs is that it's a "universal system" so to speak. The PLC is just sending a voltage to activate an item, and a messaging pulse to tell it which bits to activate. It's then the job of the individual pieces of hardware to interpret that data. A PLC might say turn on bits 5, 7, and 15. The Variable Frequency Drvie that it's connected to then converts that garbled information into settings for how to run the motor it's connected to. This means you can quickly swap out equipment and just change the message being sent, and that people who don't know what your hardware and program are, even if they can access the data somehow, are just gonna get strings of ones and zeros (or integers if working with compactlogix).

Good Morning! Bump.

Not really industrial, but i programmed an elevator.

BOM cost of the processor modules is going to be far more than $300. Virtually everything will be error-corrected, extreme temperature, hardened, certified out the ass, etc.


You can have as much abstraction as you want. These systems are designed for time-critical operations, however, so any "abstraction" is usually counter-productive. If you need to run extensive analytics, you do that back in the datacenter using data transferred from the plant historian.

Operational needs trump cyber-security needs. There's not a good way to harden a system where you need to do real-time, device-to-device messaging using devices that may be disconnected, replaced, and reconnected at any time. These systems are designed around the assumption that if you have access to the plant network, you've already achieved physical compromise of the facility.

I had them in my technical high school / college (I'm from Poland I'm it sure how it translates to American school system, but i was 15-19 when I was there). We had siemens logo! And some other more advanced ones I don't remember the name of right know. We had some pneumatic and hydraulic stuff that we controlled them with. You program them using gates. There were 2 types, one where you actually see the gates and you connect the "wires" (F something something) and the ladder type of programming. I thought it was neat, but even back then I could code in C and thought I would prefer being a software guy on the pc. Maybe I made a mistake, should have stick with this stuff.

Short circuits can and will happen in any production environment.
Production company's often buy machines from different companies and onsite electrical engineers should in theory be able to troubleshoot the programming or change things around as needed if you expand an installation.
If time is an issue, an acquired machine installation will get its new programming by contract workers from software houses specializing in PLC programming. That code still needs to be maintained by onsite technicians.

Any modern modular PLC system will have opto-electric coupled inputs, so if a DI fries you check your SCADA software to localize the faulty module, remove the wire terminal from the DI, change the DI for a new one and you are good to go. Good luck troubleshooting your cheap nigger PLC that controls a machine producing 10k and more worth of goods an hour after one of the fucking forklift drivers skirts a cable canal at the other end of the floor.


The controllers for motor drives I've seen are complex as hell and were programmed with their own specific software suites. You had to program speed and torque ramps for every operation mode that was specific to the drive and motor used.


trade school?
Logo! is more aimed at small scale automation for consumers, like for controlling your garden lights or letting a fan run for a few minutes after the lights of the office's smokers lounge was turned off. If you still want to dick around with industrial PLCs either get a small CODESYS compatible PLC off ebay or try out CODESYS SoftPLC with a BeagleBone. Or get a Simens S7 that got lost in Germany and just pirate the SIMATIC software (run it in a VM with no internet access!). Logo! is basically overpriced Lego Mindstorms.

Also, is anyone here a professional working in the field right now? Is network safety still an utter joke? Are deparment heads still insisting on accessing SCADA systems from their smartphones over the internet?

Perhaps a trade school. In poland you have 6 year elementary school, then 3 year "gimnazjum" which you can tbink kf an extended elementary school. After that you have 3 choises. "Zawodowka" where you learn specific craft. Welder, electrician, barber etc. 3 years and you dont get to have the matura exam which is necessary to go to university. "Liceum" is 3 or 4 years, you get the matura at the end, but no specific craft. Only for people who want to go to university later on. And last is "technikum" which is like a combination of both previously mentioned. Thats where i went. After that you can go to university. I'm more interested in programming micro controllers and such nowadays. I'd like to code for z80 or 6502. I know logo isn't anything serious, we had better plcs too, but logos were donated I think. Our school was in sort of partnership with Volkswagen, most people after out school would go work there, so we had a lot of stuff from them.

Remember Stuxnet? Remember SCADA hacks that predated Internet of Trash? It even goes worse. While hippies at FSF advocate for their web consumption terminals running free software, the backbone of our planet runs on God knows what proprietary krautjeetcode and they don't give a shit cuz "bruh, proprietary hardware is ok, servers too, i only care about my shitty bootloader because NSA and Chinks gonna spy me unless some tranny reverse engineers it, t. (((Stallmann)))"

Probably function block.


Most of the VFDs and Motor Controls I worked with were pretty simple to manipulate and came with presets that handled 95% of situations you'd experience in the field (if you got them properly rated anyways). Was able to figure out how to program one in about 20 minutes with just the owner's manual. It only got complicated when I had to use a European VFD one time to try and control an American motor since the ratings/system setup were different.

Electronics Manufacturing mainly. Planning to go into Cryptological technician work for a few years before switching back over to mostly maintenance-style work for larger/more complex industrial processes.

Rockwell has been working on improving it from what I could figure out. They've started doing things like RAOTM more seriously to try and teach technicians basic shit that the plant managers wouldn't teach them/didn't know how to do. Went to the one in Denver this May: rockwellautomation.com/en_NA/events/overview.page?

Managers aren't. Most of the technicians realize this is a fucking horrible idea. Instructors at educational institutes and non-technician workers like HR/Upper management keeps insisting on this bullshit though. Luckily Rockwell/Siemens for the most part have been adamant about the actual consumer side support rather than what management wants since they know the engineer/foreman/head technician is gonna be the one purchasing their products, not the HR cunt.

So pretty much the German education system but with slightly different naming conventions.

It's not a bad system. I mostly approve.

Jews

Yeah it's not bad, but the program is not that great. I was lucky that I had a chance to do some work on real hardware, most school only do theory from books because they don't have shit. Nowadays I'm a c++ programmer anyway, but it was neat to learn this.