Studio 5000 Trends: How to Catch the PLC Fault That Never Happens While You Are Watching [Q&A]

Welcome to Factory Field Notes, the podcast for manufacturing leaders, engineers, and technical managers who want practical lessons from the plant floor. I'm your host, Vladimir Romanov. In this show, we talk about the systems, projects, and decisions that shape modern manufacturing, automation, control systems, SCADA, MES, OT networks, industrial data, reliability, downtime, and technical leadership.

My goal is to bring you real conversations and field-tested thinking on what works, what fails, and what manufacturers need to understand before they modernize. Let's get into it

How's it going, everyone? Welcome back to the next episode in which we discuss some of the most upvoted questions in our industry, which is industrial automation and manufacturing. There's, of course, a lot of changes in our space, primarily due to AI, but of course, other technologies are also resurfacing.

A lot of the fundamentals remain the same. So this week we have a lot of different questions about career, about panels, about hardware, about specific manufacturer type of problems. Without any further delay, let's get into our first question

3D printed home control cabinet on an AutomationDirect PLC

And our first comment/question is about a homemade controls cabinet

And it comes from the username retroguy55. We we have a couple of images. We'll take a look at them in just a moment. As we scroll down, they say, "Hey everyone, just wanted to share a little bit of control cabinet I built at home purely for fun. I made a post here not too long ago as a complete beginner asking for some advice.

I got some really helpful feedback, which eventually led me to picking up an AutomationDirect Productivity1000 series PLC with the part number P1M41215DD2." We can actually search this out of personal curiosity

And it's very easy to get pricing on these specifically PLCs. So I'm going to just scroll the image a little bit over so you can see. We can immediately notice that it-- this is a one hundred and sixty-five USD or US dollars PLC. We can see the immediate specifications as well. Twenty-four volts DC. It has an Ethernet port.

It has a serial and USB-C ports, which is surprising to see. Not a lot of hardware has been upgraded to that. We have a microSD card slot. We have discrete inputs, eight-point, and we have discrete outputs, seven-point, and sourcing respectively. Again, not to get into that debate. Obviously, we have some downloads.

I would assume there's gonna be some technical specifications, a product cut sheet. Again, if you're curious, all of the information is available

Going back to the actual question, so we see I decided to 3D print the enclosure because I had a ton of spare filament sitting around. It also gave me way of freedom in terms of the design, and I was able to build it pretty much exactly how I had pictured it in my head. Honestly, I absolutely loved building this from start to finish.

I'd throw on some music, measure my wires, cut them to length, crimp the ferrules, terminate everything, and just slowly put the whole thing together. Even when I screwed something up when was troubleshooting, figure it out, what the hell was I doing wrong was actually part of the fun. It was also a nice change of pace for me.

I work in hospital maintenance, and while I do enjoy my job, a lot of the day to work, day-to-day work can become pretty repetitive. This project actually made me think and kept my brain busy in a completely different way. As for the cabinet itself... So it looks like it's a very long post. I guess we'll finish it up.

As the cabinet itself, I tried to make it as compact as I reasonably could. I have two power supplies feeding the two green power buses, one bus intended for the PLC inputs and the lower current devices like the cabinet light and fan, while the other for higher current loads like pumps, heating elements, et cetera.

Below that, I added a contactor I had laying around along with two small relay modules. One had four Schneider mechanical relays and the other two solid-state relays. Both modules have built-in fuses for over relay with indicator LEDs that light up when a fuse blows, which I thought was pretty cool. If you noticed, I gave the thing the option to be battery powered.

I picked up a DeWalt battery holder and connected it to a digital booster converter mounted on the front. It takes twenty volts or so from the DeWalt pack and boosts it to twenty-four volts DC.

Reading the PLC power supply spec

The comment here I would make is, again, if we look at the PLC and if we look at the actual technical specifications, again, not to take a ton of time, but ultimately, let's see here.

External power supply required twenty-four volts plus or minus two percent. This is actually very tight. Usually, when you look at a lot of industrial hardware, you will see that it can go down all the way to usually twelve volts, which is a different standard. So the circuitry is capable. Okay, so there we go.

On the input side, you'll see that it's twelve to twenty-four volts DC, and same on the output side. Again, maybe the power supply here is a little bit tighter, but generally speaking, the power requirements for industrial hardware specifically are very loose. And again, I say that with a little bit of an air quotes if you can see me because in a lot of cases the power on the-- even the DC bus is not going to be exactly twenty-four volts

And so it says, I also added some lever style terminal blocks on the side. The idea is that they make it much easier to change out whatever I'm experimenting with without constantly having to run wires back into the enclosure or stick my hands into a tiny space every time I want to modify something.

This is a huge plus. I have done the same in a lot of my demo kits. And I... That's pretty much it. Full disclaimer, I have absolutely no idea what I'm doing. I'm sure I've done plenty of things wrong, and I'm definitely still learning. We'll take a look at that in just a moment. And this is my own PLC trainer.

The biggest thing I've learned from this project is how much I enjoy PLC and controls. Ladder logic particular has been a blessing for someone who absolutely cannot code haha. Anyways, I figured I'd share it. Hopefully, you guys get a kick out of it, and I'm always open to hearing what I could have done better or just your thoughts.

So let's take a look at the screens. So first and foremost, we have an enclosure. I personally, and this is just my own preference, I really like Pelican cases. And of course, if you have, A preference for something a little bit cheaper, there are knock-off Pelican cases, but I believe they are of a very good form factor and lend themselves extremely well for this type of prototyping at least, or home lab environments.

I have multiple sitting on the floor that you have seen in the video. So-- And, and I guess printing or 3D printing specifically a case is extremely time-consuming. Obviously, if you want to go down that route and practice something else, maybe it's fun. But if you want an alternative, you can go to a variety of different stores or even buy this on eBay or AliExpress for a very, very low cost, upon which you can then mount buttons and whatever else you need by doing some cutouts.

But in any case, we have a couple of buttons. We have a buzzer. We have a start and a stop push button. We have some switches. We have an E-stop at the bottom. We have an indicator, which I would assume is the voltage coming into the actual bus, since it is showing twenty-three volts as opposed to what this battery actually provides.

Wire gauge, color codes and lever terminal blocks

Next, we have a lot of wiring. So surprisingly, again this is not something I would ding him on, but generally speaking, you can use much smaller gauges of wires, especially for your buttons. So whatever you're conducting from your general IO, and again, we can go back to the manual, but ultimately it's going to be very small currents, so you could have saved a lot of space by running much smaller wires.

Even an Ethernet cable with eight strands, again, would be much more conservative as you don't need a whole lot of current to power and basically see the toggle of your input and/or LED that's gonna be driven in front of this panel. If you're going to use heavier loads, this obviously changes. So for your relays, for your contactors, you should be looking at what the NEC or the National Electric Code.

Nowadays, you can probably just Google or use an LLM to find the exact wire gauge that you would need. But typically speaking, from your PLC into the drive side of that relay, you would still need a fairly small wire gauge. So again, that would be one general comment. I do like the addition of tie wraps.

If you have been in the field long enough, you will certainly appreciate everything being nice and neat. Again, is this nice and neat? It, it really depends. I guess it's, it's a matter of taste, but ultimately it is better than, what I would expect a general trainer to be accomplishing. Color code-wise, again, you can Google the standards either for Europe or the North American regions, or probably Asia, which may be different.

I'm a lot more familiar with North America, secondarily with Europe, so the standards are going to be different. Red is not generally used for this purpose. You would see a lot of, safety circuits being with red and sometimes maybe a single phase of a circuit to be red. But typically, once again, that's gonna be white and black, and then you're going to have maybe two 20 using red.

I don't remember at the top of my head. I don't always choose the colors of the wiring, but I do know this is different. I see the WAGO style terminals. Again, you can buy these on AliExpress from other vendors This is what I'm assuming the user was referring to when they said a quick disconnect. Highly advisable for anyone that's building these models, and I would assume we're going to see more of those outside of the actual panel.

Let's see the next image. So exactly what I was talking about. So these are, levers, and I have a couple of them laying around on the other side. But basically, you can lever, the terminal and insert or obviously remove the wire as needed. So it makes it a lot easier for troubleshooting purposes. The labels, again, could probably be done better.

I personally have a Wi-Fi printer as well that's sitting behind me for some smaller applications if you want to invest in something a little bit more robust. You see a lot of guys with specialty printers. But for me, a diagram perhaps in the digital world would make a little bit more sense since you have so many terminals coming out and it's difficult to manage what is going in, what is coming out, and what can be connected.

In terms of the choice of elements, again, it's difficult to see the specifics, but we see the-- obviously the PLC that we've discussed and looked at the datasheet for. We have a power supply which has the line, the neutral, as well as the ground, and that converts to twenty-four volts DC. So this is the other question. I looked at the twenty-four volts being supplied, and I thought he was just going to directly feed it from the battery, we also have the power supply, so it would be interesting to see what the line voltage fluctuations would be. These are also, again, if we find the datasheet are going to be very different and again a lot more flexible because in the industrial space you have a ton of fluctuation.

Why engineers should build a training kit

In terms of general, I would say like training kit, this is amazing. My advice is whatever gets you going is of course the best solution because you can start practicing, you can start looking at ladder logic, you can start looking at other means of building control systems. You can of course also get some hands-on experience with the hardware.

And that is even for someone who's in engineering and in design and maybe specifying some of this work. If you spend a little bit of time building out a training kit, you will also learn about the challenges that the technicians often face in troubleshooting some of this hardware, in installing some of these solutions, in debugging some of the problems that result in poor software development.

So you will get an appreciation of the actual craft of putting this together in addition to learning and having something to learn with on the software side.

Hi, my name is Vladimir Romanov. I am the founder of Joltek as well as SolisPLC. With a background in electrical engineering and an MBA, and over a decade of experience leading projects in manufacturing and industrial automation, I help engineers, managers, and manufacturers make smarter technical and business decisions, modernize their operations, and build stronger careers.

If you're serious about manufacturing, automation, and staying ahead in the industry, subscribe and join the community

Failed power supply on a Panasonic FP0 test bench

All right, so it looks like in the next question, we will be doing a little bit of troubleshooting

And so this is a post that comes from the username Supereagle1. And they say, "Failed power supply?" We have an image in which we're going to look at in just a moment. There's a couple of them. And I'm trying to set up a PLC test bench with a Panasonic PLC FP0 in order to learn PLC wiring and programming.

However, while testing the outputs, specifically relay Q2, the power supply failed. The DC power just went out. There was no sound or burnt smell. So my question is, did I make a mistake planning or wiring here, or did the power supply just fail on its own? Or is a 2.5 amp not enough and the power supply fuse just blew?

Any help is greatly appreciated. So let's first take a look at the images. So we have a, contactor here on the left-hand side. We have the power supply. We have some wires dangling with a connector. We have... what I'm assuming this is the PLC that we're, trying to figure out. We've got two sets of relays.

We've got, circuit breakers, and we have what looks like some kind of a terminal with potentially a fuse block. So interesting, we do have some diagrams. So again, we have what looks like a hun- 230 volts, so this is not North America. We have that coming into the power supply, and we have twenty-four volts as well as zero, and the PLC connections here on the power supply.

Let's take a look. We have the Panasonic PLC. Again, not very familiar with this brand of PLCs, but to me, again, very kinda rough estimate, it strikes me like a MicroLogix series equivalent of PLCs. We have two push buttons, and we have what looks like two relays. We have the inputs and/or outputs of the PLC.

So it looks like input zero, one, two, all the way up to... there's eight of them. There's going to be the outputs. Same number of, maybe just four of them

All right, so very rough diagnosis. There's nothing in this panel that would generally warrant more than two and a half amps. Again, this seems to be a relatively small PLC, so I can't imagine it's drawing that much. So I think that this power supply, and again, I don't know if we can zoom in incredibly well, 2.5 amps on the 24 volt side should be more than adequate.

It is consuming 1.8 amps at the 110 to 240 VAC mark, so that's perfectly fine. What could have tripped this? So let's go back to the post once again and see here. The DC power went out. There was no sound or burnt smell. Did I make a mistake planning or wiring here, or did the power supply just fail on its own?

Power supplies don't usually fail on their own. Let's see here. While testing the outputs, specifically relay Q2. So Q2, again, it doesn't look like there's any load on this relay, therefore the coil, and obviously it depends on the data sheet, which, shouldn't consume more than, I would say fifty, maybe forty milliamps, even probably less than that.

But there is one indicator. So this is a relay rated for twenty-four volts AC. Again, that's going to be on your typically coil side. We don't have any rating here, so it is possible, it is absolutely possible that this relay is not rated to pull the current necessary. That being said, obviously, let's see here, the wiring of both of these relays, so it comes from the power supply on one side, and then the coil is enabled through the output of the PLC.

And if we look at the schematics, so again, we're looking at the Q2 relay, which is right here. One side is connected to zero volts, and so this is basically the output. So once the output is connected, then the switch is closed. There is no load on the other side of the relay, so the only thing that could have tripped it is, of course, the type of coil.

And in this case, it's impossible for us to say for sure because we don't have the number, the part number of this specific relay. And I'm just trying to zoom in, and neither-- we don't have it on the other one as well.

I/O checkout one point at a time

So I would say, again, in this specific situation, if you're putting a circuit together, I would do it item by item, meaning that if you have the power supply powering on the PLC, everything is fine.

Test out your outputs without the load. In this case, the load is basically the relay Power on and test the first relay, power on and test the second relay. Usually, you will get pretty good indication that the component that has failed is the one you're testing. And this is generally speaking what we do in the field for your I/O checkouts. At a larger scale, you have PLCs with sometimes hundreds if not thousands of I/O points. Something could have been miswired. Again, it's easy to tell that the coil is generally there, but you could have put the wire on a different pin, for example. I don't know what this terminal block looks like on the inside.

There's loose wires on the top. It, it should be fine, but again, that's why we do I/O checkouts. That's why we do them one by one. I'm also not super fond of this coiled cable that's just laying there with the connector. Again, if it happened when you energized that specific output, it's probably a good indicator that there's something wrong in the, either the wiring of that relay terminal, or if it fired once you energize the output, it's probably the relay itself.

So I would double-check the coil. I would also double-check if you can still work with this power supply. A lot of them should be resettable. I'm surprised that if there was no smoke let out or no noise that something is damaged to the point of no return

Wire numbering methods and conventions

All right, the next question we have is around wiring standards. And those of you who have seen my content over the years probably know that a lot of my work remains on the strategy, advisory, programming side. It is rare that I will go down and design a panel, and especially lay out the standards when it comes to wiring colors, wiring numbers, as an example.

Typically, I use external resources in groups that are much more knowledgeable at the NEC or the National Electric Code. Of course, I still specify a lot of the larger components that need to go inside of manufacturing plants. That being said, there's probably individuals who are a lot more knowledgeable on how to better lay out AutoCAD drawings and probably create schematics, although I have read thousands upon thousands of them of all sorts of different flavors, therefore, I do have a lot of opinions and input on that front.

And so this comes from the username RobertGarthurtX, and it's titled Wiring Numbering. And they say, "Concisely what methods, standards, and conventions are you using for selecting the numbers for your wires, and why?

I mean, when you're designing a circuit and a drawing print yourself." And like I said, I had the opportunity early in my career to obviously provide a ton of input and understand how things are done at a very large scale. So my initial work was for Procter & Gamble, in which case we had thousands upon thousands of pages of drawings per machine, and then multiple machines per line, and of course, many different lines per site.

So I have a good understanding of what I like to see in drawings, even for smaller scale projects. And so the way you reason with this and, the way you think about this when you're going to specify some of these designs is, number one, you need to think about two steps ahead, right? And what I mean by that is you're not just designing this project, you're also designing other projects for your company.

And of course, if you're working for an end user, this is going to be a little bit different than if you're working for a systems integrator or maybe for a consulting team. So if you're working for an end user, typically you will be managing a specific site. So you need to think about the assets, you need to think about the lines, you need to think about the different areas where these drawings might be utilized.

And in some cases, you don't have full say you're going to receive the equipment as is from the vendor, from the OEM or machine builder, and you're going to have to live with their design to then be incorporated into your plant. But if you do have a say, I want you to think about the following. Number one, you're going to have devices on the specific machine, so you need it to reference this equipment in some way, shape, or form.

Chances are you're going to have multiple pages for that one drawing, so when you open up a panel and there's a large stack of papers with said drawing, you want to be able to know what page the next connection is on. So number one basic is you want to obviously have a reference in your drawing, what is the equipment, and that can be on the title page.

But once you get down to your wires, you want to be able to drill down on what page that's going to be located.

Page and coordinate cross referencing

Number two, depending on how your drawings and schematics are organized, nowadays it's not uncommon to see many different IO points, many wires going in and out of a single page. Therefore, what I like to see is a coordinate-based system, meaning that we start on the top left-hand side, and of course, this is mirrored on the video.You're going from basically left to right, and you're going top to bottom, just like you would be reading a book. So if you have a signal that is referring a device which is gonna be in quadrant, and usually it's gonna be labeled at the bottom and on the right-hand side of your schematic, you see different quadrants.

So the reference is going to come in for that specific device and make it a lot easier to find. And what I mean by that, well, let's say you have an output on page number ten referencing some kind of a relay that comes into your PLC. On the PLC side, you see a reference that is going to point to the page where the relay is located, but it's also going to give you two coordinates that you can reference to find the specific relay on the drawing, which may contain many devices within itself.

Revision control for electrical prints

Referencing back the large scale of a single facility that has different machines, many lines, and of course, challenges that are associated with that. So one of the problems I had not anticipated to see on the electrical side as much as we see in software is version control. When we talk about software version control, you pretty much know, we've deployed this firmware version or, or we've made changes to the software, and you can manage a lot of that relatively easily in Git.

On the hardware side, you need to maintain a similar set of, I would say, rigor or prints once you get past a certain scale. So for example, we had case packers that were different one from another. And so the same line that produces the exact same product at the end of the output of that case packer may have a different print on the line for all the different modules that make up the entire line.

So of course, this case packer could have been version three, this other one five point two, the other one three point seven, so on and so forth. But the importance here is that you start maintaining what does it mean to have a large revision, what does it take to have a minor revision, and of course, what can fall into those categories

And so the final thought that I want you to leave with is always plan ahead and of course accommodate the customer or whomever is going to use and maintain that equipment as much as possible. Do not simply assume and think that just because you're happy with that numbering scheme, someone who's in the field that's tugging on those wires or is looking at the reference inside of that machine is not going to be frustrated with your design.

Ask questions, make sure that you're giving them something that they can use and of course integrate into their facility and make their life easier as much as possible

PanelView Plus login lost on an auction machine

All right, so the next question is a very important one. How to troubleshoot equipment that you're unfamiliar with, whom to reach out to, what steps can you take if you're in a position where you are unable to basically understand what's going on and need, support on the technical side or otherwise?

This question was posted by the username Scott Brooks, and they say, "PLC noob login issue. How to debug or find PLC help in Central New York on an old machine?" So this is a technical question in general, and we'll look at the images in just a moment. Says, "Hi, folks. Writing to try and help my dad who's in his seventies.

He's a carpenter that has owned and fiddled with many PLC-controlled machines, but this one is over his head with specific programming config work requires on his latest issue. I'm a computer scientist but have never gotten into the PLC niche specifically, so I have a better chance than him, but obviously no domain knowledge.

I predict the solution to this problem will be hire someone who knows what they're doing, and I'm primarily asking how to find such a person. He is located in Oswego County, New York." I'm not, familiar with where that is. Uh, "Some context. My dad recently bought a Shanklin Omni Sealer machine at auction.

It uses a PanelView Plus seven hundred HMI. He was able to get the machine working through some debugging, replacing backup batteries, et cetera, but at some point, he, in the process, he lost the ability to log in. There's a landing page, see pics, where he said there used to be boxes for username and password, which he has, but now the login page renders without the boxes as pictured.

It has just a grayed-out box listing question marks as the current user. If anyone has any ideas of how I could help him debug, I can provide more info. Just assume I know computers but not PLC specifics. Otherwise, as said, looking for someone who could help him or how we could search for such a person.

Thanks." So this was posted only six hours ago at the time of recording this video, so I'm assuming he has already gotten enough answers on this because this is a Rockwell system, and a lot of people in North America know primarily Rockwell. So we're looking at the HMI, and again, this is a very typical indicator that something is not connecting either on the PLC or the HMI side or, of course, something in between.

If we go to the next, screen, we will notice an older CompactLogix L35E controller. I have one of those on the other side wall, but that is besides the point. There is a couple of red flags in general in the system, but let's address the first question. He was able to log in on this specific screen, and he's not able to do so anymore.

So assuming that he had ownership of the machine and it was powered down for a while, then powered back on, I would assume that we have not lost memory, which could be the case. These PLCs only go up to version 19 of RSLogix 5000 series. So I've certainly seen instances where the PLC loses its memory completely.

Whether or not that is the case could be verified by looking at some of the other I/O. Of course, in this case, we don't even see the DeviceNet card, or the scanner powered on, which is a red flag in general. But I would say the first step is to verify that the program is still intact, because if that's not the case, you have bigger issues than that.

CompactLogix L35E checks: program, Ethernet, RSLinx

The second item is this is, as I've mentioned, a connectivity problem. It means that the HMI is not able to read and/or write the data back to the PLC, which generally means I would start checking the physical side. We're going to look at the Ethernet cable that comes in here. It's possible that it's connected over serial.

I would hope that it's connected over Ethernet. So I would start by checking the physical connection between the PLC and the HMI. Number two, of course, if there's a switch between the two, which is common. If there's other maybe VFDs or other hardware, I would certainly check the cable that goes to that switch to make sure that the switch is powered on.

Now, in this image, the other item, and it's obvious to say, but maybe not obvious to him, if you've only powered on the HMI, not the PLC, no data will be shown on the screen, because the HMI needs to be able to connect to the tags to display the actual values and populate whatever is, uh, on this specific image, which again, I think is just a login screen.

But ultimately, you should be able to click and log in the username and the password as described. So those are the checks that I would do. So number one, make sure that everything powers on. Make sure that the PLC has the run LED on, that there's no issues, that everything is okay. Number two, if you can, without the HMI, validate that you have IO working.

Again, I would assume that this person does not have access to RSLogix or Studio 5000, but you can double-check RSLinx, right? Do you have the right IP addresses? The next item is gonna be the physical connection. So that's going to be over Ethernet. Again, confirm that it's not coming in over serial. I doubt it, but again, it's definitely possible with those HMIs.

And then the other item, once you get past all of those checks, what you can do is if you reboot this HMI, and it can be different depending on the firmware revisions, but there's going to be a white, sort of rectangle in the bottom right, which you can click to go into the boot up menu instead of loading the actual program.And then you can also check some of the settings. That you can just double-check that the PLC path is set correctly on the HMI, that the IP is correctly set on the, PLC side as well as the path side. You can ping both devices. There's a couple of things you can do with free tools. If you're looking to install a software that might also be helpful, that's going to be RSLinx.

With that, you can at the very least see what is in your tree of devices. You can Once you find the IP address, double-check the firmware of your HMI. Double-check, of course, the firmware of your PLC. Of course, you will need Studio and RSLogix, well, in this case, RSLogix 5000, as well as FactoryTalk View Studio if you want to make any changes to any of the hardware.

DeviceNet red flag: back up the PLC now

I've also noticed, and I mentioned that that is a red flag, so DeviceNet is pretty much discontinued. If there's any issues with any of the settings on the DeviceNet side, I would highly recommend backing up this PLC as soon as humanly possible. And I would ask for a contractor or systems integrator to come in and take a look and give you that file, because if you lose that configuration from DeviceNet, you're going to be in a whole lot of trouble depending on what's connected to this, if it's drives, if it's remote IO.

DeviceNet is a discontinued protocol. I have done a ton of conversions on the industrial side. It is always a challenge, to work with, especially if you lack the experience

Studio 5000 v36 vs v37 vs v38

The next question is once again around Rockwell. Those of you that know me know that I certainly have a ton of different Rockwell PLCs. I have a ton of experience on the Rockwell ecosystems, and that includes PLCs, HMIs, switches, so anything that concerns the network side of things, as well as a lot of the different software tools from PlantPAx to FactoryTalk View SE, ThinManager, so on and so forth.

AssetCentre. The question that we have It comes from the user LegitimateSorbet526, and they say, "Studio 5000 version 38. Starting a new project and trying to decide between version 36, 37, 38. I know V36 has its issues, so I will start at a minimum on 37 since it fixes most known issues on 36.

How stable is 38 worth going to or just stay on latest minor version of 37?" So I certainly have a couple of comments on this front, but I will say the first resource, if you go into the Rockwell Automation Compatibility and Download Center, here you can type in-- and it's a little bit tricky sometimes. So if you type in Logix Designer, you'll see that there's gonna be a lot of different software packages, and we need to specifically find Studio 5000 Logix Designer.

And once again, you'll notice that there's gonna be a lot of different, tools, so we need to make sure that we're looking at Studio 5000 programming software, and the immediate indicator is latest version V38. If we don't necessarily click on any of the other links but just at the top one, we will notice that there's a couple of information notes you will see that we can definitely select version 38.03, which is what they recommend, as the preferred version.

That being said, if you scroll down, you will notice that there's going to be multiple active revisions of prior basically major versions and firmwares for Rockwell Automation. Now, I have not personally heard of issues on 36. Perhaps it was with one of the other firmwares like 36.05, 36.03, which are retired.

So if you were to work with 36, definitely get the 36.06. And scrolling further down, we see 34, which is active, managed. And of course, there's going to be a lot of gray triangles for versions that are limited. So the choice is, I would say, finite. So number one, I would strongly recommend personally not to go with the latest and greatest.

There might be options where it will make sense, but I would strongly consider this 3705, 3606, 3505. Again, I'm not sure what the, blue triangle means besides managed. Maybe there is a case to be made there.

Match the versions the plant already runs

But the more important question that I would have is where is this control system going? What does the client currently have?

What I would hate to happen is if they have several PLCs on 34, a few PLCs on 33, some PLCs maybe as far back as 26, and then for whatever reason, I introduce a new version that is, that requires a new install on their laptops, a new install on their servers. Not even talking about the software license cost, which again, maybe they've purchased a perpetual license with upgrades to the latest and greatest.

But again, if they have multiple PLCs, an example here on version thirty-six point O six, I would probably choose this version, against any other variations, right? But if they have thirty-five, it should be fine as well, right? So as long as they don't have something-- maybe if they have twenty-four point zero zero, then I would raise some other questions.

Or maybe if they have version twenty-one on most of their control systems, I probably would deploy a new system with, let's say, version thirty-seven or thirty-six in that specific scenario. But I would try to, again, accommodate the client as much as possible. Second to making sure that the revision is obviously supported, doesn't have any issues.

And you can read the release notes again for the specific version if you'd like to. There's gonna be information as to what some of those challenges have been. It could be a specific servo drive, it could be a VFD, it could be a protocol, right? So again, there could be nuances that you need to consider as you select the version for more advanced applications

Studio 5000 trends: a servo overtorque story

The last question we have this week has to do with trending. As many of you may know, I worked quite extensively on different data applications in various food and bev, as well as CPG and packaging facilities over the years. So I have certainly gotten quite frustrated with the tools that we get out of the box, and I have fiddled quite extensively with trends, with data collectors, with Node-RED, with Ignition data aggregators.

So I certainly have my own opinions when it comes to native trending in RSLogix and Studio 5000. That being said, this question comes from the username Life of Pi, and they say, "RSLogix Studio five thousand trends. What are some of y'all favorite setups and tips with trends when it comes to understanding a problem?

Talking about some ugly problems that require trends, robot moves, cams, encoders, virtual, et cetera. Not if an eye is flagging or not unless it's a high-speed counter card. Understand trends but want some insider insight. Give me the secret formula please." And I want to start this with a bit of an anecdote from my own personal experience, and this was only basically two years into my career, and I worked at-- and again, this is public information, at a factory out of Auburn and Lewiston, Maine, that made product faster than the naked eye could see.

So basically we had high-speed vision systems that were required to troubleshoot any failures or any mechanical or process deviation on the production line. And I still remember how one day I was brought into one of the pass-down meetings where a servo drive had catastrophically failed because of an overtorque, and we were trying to figure out what the issue was.

And at the time, we had the system at the MES level that was recording data every five minutes. So every five minutes it would just take all of the tags out of the PLC and record their values. Now, of course, as soon as I was told that there was a catastrophic failure that led to, again, that servo drive overtorquing and crashing a bunch of process, materials, I immediately knew that none of what we're saving on the production line inside of the MES is going to be useful.

None of the data was stored before the event. None of the data was stored after the event. And in most cases, an event that was maybe ten seconds long at best, we would have captured something five minutes or two point five minutes before, something two point five minutes after, and anywhere in between. My boss at the time knew this as well, so he sent me to the plant floor to plug in my machine and start trending the event. Now, the joke here is, of course, that specific issue never happened again, and we reported to upper management that we did an investigation because it caused quite a costly downtime.

But ultimately, everyone that was technically savvy knew that we couldn't do anything with the data that we provided and knew that nothing would happen again because the issue was fixed and the machine was basically put back into run mode, and the chances of us seeing the same exact issue on the new drive was extremely low

Trend setup: fixed axes, time span, sample rate

Now, what was my approach to capturing some of these faults?

Well, initially, and I do a lot of training with, technicians and engineers on this front, the first step is what is it that you're trying to see? If you simply right-click a tag in Studio or RSLogix 5000, you can create an immediate trend, and that trend is gonna be, pretty rough, Meaning that it's not going to be scaled properly.

It's not going to have a perfect or any good, time frame. It's going to default to just seeing the tag as it floats in, midair. And so it is probably a good way to see some kind of a basic waveform or maybe see some kind of a counter, but it doesn't necessarily give you the resolution for anything more complex.

So the second stage is to apply fixed labels on your X and Y axes. So you should have a general idea how far, how low or how, far up this tag is going to go. So you start applying the trend to be a fixed Y-axis height. You start applying a time frame that makes sense. You start applying a sampling rate.

So understand that a lot of your instrumentation and a lot of your tag collection systems are not going to update at a one-millisecond interval. And of course, this is an entirely different conversation. I remember making videos on this many, many years ago. But basically, if you look at even a proximity sensor, if you look at the data sheet, you will notice that it takes it sometimes forty milliseconds to scan the item, to process the internal electronics, and to send the output.

So if you're trying to read, for example, an analog sensor, realize that the true value of that sensor is not updating faster than forty milliseconds. And again, of course, that's just an example. It depends on the data sheet. Then if you start looking at anything that is mechanical, for example, relays.

Relays take two hundred and maybe three hundred milliseconds to actually open and close. So what you will notice is if you're trying to trend, for example, a mechanical relay based on a signal, it's going to be relatively unreliable. And so this is where you start getting into, those resolutions, into a lot of questions as to whether or not you're getting real data.

Now, of course, you can tweak the resolution. That also has different repercussions on your system. You have a finite number of samples that you can take, which basically means that the new data is going to start overwriting some of the old data.

Trend triggers: capture before and after the event

The next item is, of course, triggers. So like I've mentioned in my specific example, I could have sat there all day, all week, all month not seeing that specific issue.

But usually, the issue that is recurring is not going to happen while you watch it, right? That's just the rule of thumb that we have in the industrial automation space. So you need to set up what is called a trigger. So if there is a specific event you're watching for, you can say that once that signal transitions from low to high, you want to be able to record a number of samples before and after the event, right?

So you can set that window that will move basically with the specific trigger. Now, there's going to be some, I would say some opportunity to tweak different tags to what you would like to see better. And generally, what is good is after you have captured the data that you're looking for, you can pause the system and then you can analyze the tag, but also you can zoom in, you can zoom out, you can start understanding the data a lot better.

But the first step obviously starts with capturing.

Pack BOOLs into a DINT to beat the pen limit

So you also have a finite number of pens or data points that you can capture inside of Studio and RSLogix 5000. So you want to select what you would like, but there's also ways to manipulate this. What I generally mean by that is imagine for a moment that you want to capture Booleans, and you can put in a Boolean pen inside of one of those tags, and you would basically capture a Booleans.

Alternatively, you could write a Boolean to an integer, and you can assign every bit of that integer to be a Boolean, which basically gives you 16 bits worth of resolution. Of course, if it's a double integer, that becomes 32. So if you capture 32 Booleans inside of a double integer and then you trend that double integer at every sample size, you can basically figure out what was the value of each one of those Booleans.

So there's going to be little tips and tricks, but ultimately what you will need to be playing with is the sample speed as well as the number of samples that your system can handle so that you could get a reliably good window of data before you start digging in deeper. And once again, don't forget the trigger, which is going to be extremely important because a lot of the events that you're gonna be watching for can be, toggled based on the on and off switch.

Now, again, remember the previous comment. If you pull off the wrong trigger, it's possible that, again, once the relay clicked into 100 milliseconds after something else has happened, well, it's simply too late to capture some of that data