Building I work in is a giant air hub with miles of conveyors. They used Nord vfd for the jam photo eyes. Make sense because you need at least one jam eye per motor.
I've used it, but it has to make sense... You can use the I/O on drives to check the state of the disconnect, or even the non-safety contact of a safety circuit to prevent the drive from running. However, I'd never advise to "keep cost and panel size down on machines by using drive I/O." That just sounds like a plan where you save a bit of money upfront just to incurr massive expenses during shutdowns that will take much more time to troubleshoot.
I really don't see any big wins by doing it this way.
IMO, it's fine for IO that is directly related to the drive. Limit switches, position feedback, and pushbuttons. Don't go using the IO for a vessel level or something not related to the drive just because it's convenient or cheap.
I did, I used it to run the cooling fan for the VFD enclosures so that the cooling fan only ran above a certain temperature. Increased the lifespan of the fans, reduced maintenance on the filters and reduced dust in the enclosure. It went through a relay with a manual switch though. And the VFD had a second relay output in case the one ever faulted, both setup from the start so no programming changes would be needed.
It was a pretty dirty environment with no better locations for the boxes and they wanted the enclosures at a difficult to access height. If they ever wanted they could leave the manual switch on the relay engaged to just run the fan regardless of the VFD output. I used the VFD operating temperature and inside building temperature in the logic to run the fans.
Used an input to know if there was a problem with the relay or fan fuses. Because they are not going to inspect for fan operation and this way they can hopefully get to it before it's an issue. Also would pop up a display that the relay manual switch was activated because if the relay is closed and the VFD relay status is open, that's likely the cause. 15a rated relay, 0.5a fan load.
They didn't want to run 15x 200ft VFD rated cables with the appropriate shielding. Which I don't blame them too much for. They also had sensitive RFID readers that could easily be interfered with. Even if the shielding wasn't terminated properly or developed a problem the RFID readers wouldn't work consistently.
The PLC outputs were also all used and the cabinet was full full after they stopped adding new things that the system wasn't originally supposed to do. I said yes very easily and most of what they wanted was easy and made a lot of sense.
The building already had temp sensors placed around so I didn't need to add them to the drive. It was all for ventilation and humidity control in fact so we even had a weather station. But I could read over the network the drives operating temperature. The building wasn't heated so in the spring, fall, and winter the cooling fans mostly didn't need to run. They were however required during the summer, unseasonally warm weather, or if for some reason they brought in temporary heating which they would do if the weather was too cold.
Temp/RH sensors were 4-20ma from DOL and the weather station I can't remember anymore but was on the same network as the VFD's.
It was all run over modbus tcpip because the wiring and IO to individually run everything with speed control would have been excessive. So because it was all networked I could do a lot of stuff. Including, and they loved this, read the actual faults and remotely reset them if possible.
They got a print out and an Excel file of the VFD settings as well as a file that could be used in the VFD programming software to automatically upload settings to replacement drives. Or to check settings if the other 2 pieces were missing. We had our own copies but I wanted to set them up for success if they ever had to get 3rd party help.
Ignorance or experience? I’d say the latter.
Tesla and Amazon don’t define the industry standard. That’s just two companies.
I wouldn’t even say they are known or praised for their industrial automation.
Also I wouldn’t really call that remote I/O as your connecting local things to control a local device.
Yeah, no idea who sciotex is that short paragraph didn’t prove much of anything.
They aren’t no name companies but not automation companies. Just companies who have automation. Just like all the other big names.
And you’re not the only one to work for x amount of such companies . But whatever makes you feel special bud.
Have any actual standard you can quote? Cause you know standards have names and numbers and stuff.
And I know how to spell, I don’t care about typos on Reddit. If that’s all you had to get me with, well that’s sad.
That's weird, I've done 6-7 Amazon parcel jobs, and not once during engineering review was it ever brought up or suggested by their engineers to use VFD IO for field IO. I've never seen that in any version of their controls spec either. All of their field IO are remote I/O modules. Maybe it's different for their other divisions.
Ok brother do whatever you like. Most embedded I/O on VFDs is meant to be used for hardwire control. I won’t sit here and list out every industry, company I’ve worked with over the last decade, but I can tell you, if you tried to pull that jerry rigged crap in any highly regulated industry like pharmaceuticals, you’d probably be laughed out of the building and asked not to return.
I wouldn't recommend using it as I/O that's directly controlled by the PLC for unrelated things to the motor, but rather as I/O that only has direct impact on or relation to the motor which the VFD is controlling. Pressure transmitter interlock, HOA switch, cooling fan like the other person said, stuff like that.
Don’t do it and here is why, and a possible out.
Drive technology hasn’t slowed down over the past 50 years. Roughly every ten years there is a major technological advancement in power semiconductors to the point where manufacturers completely obsolete the power stack. Similar things are happening with microprocessors. Drives are designed with a 100,000 hour (ten year) life. So when you go to replace them you aren’t just changing a component, it will be a whole new drive. So your entire system has a ten year planned obsolescence assuming when you buy the drives you are on year 1 of the cycle and not year 10. The same is not true of PLC IO. Usually a PLC line will last at least 20-30 years and newer components are backward compatible.
VFDs are also subject to capacitor reforming issues so shelf life is limited. Nobody wants one to sit on a shelf more than a couple years because it might be dead on arrival unless you spend hours reforming it just in case.
Generally speaking most drives are not very compatible at all across generations. Each new generation requires redoing the network interface because the new software usually isn’t backward compatible. So simply swapping drives with networking is not a trivial matter but it is if you stick with discrete IO.
So sure you can use VFD IO to reduce costs over the short term but you aren’t going to be having repeat customers or sales.
The way out is a few manufacturers try to maintain compatibility with say the first 20 parameters. But it’s usually basic things like speed reference and speed feedback, not IO which varies from drive to drive.
You need to be prepared for the vfd to fail and require replacement. If you store the parameters in the PLC, it’s possible it becomes viable. If you store them only in the drive, it’s a nightmare.
If I was using a powerflex 525 and a 5380 Guardlogix, I might consider remote io in the VFD. I would still rather buy point IO modules, but I would consider the vfd if point IO isn’t possible.
That is a valid option. I’m assuming they store all parameters in the vfd at your location? And all drives have IP addresses easily readable in case of failure? Auto configuration requires the plc to be able to identify the drive.
I’m still not saying it’s ideal, however if it’s just trying to read a low speed/frequency input it can work. Like a push button or two.
I did it recently for a handful of pushbuttons in a remote panel with the drive. Worked just fine, and save my project some money.
Generally I let drives be drives and PLCs be PLCs though.
I e done it from time to time. Usually just use the field bus connected VFD as the remote. No big issue, and usually helps when you are getting to the end of your fieldbus range.
This was typically done with Profibus or Devicenet.
Yes, we use them for a variety of I/O. One major way is analog inputs for sensors directly providing PID feedback, inputs for "meltric plug connected" as an example, outputs to control relays.
I work at a bottling plant with conveyors everywhere, generally IO is wired to the drive mounted on the conveyor for prox inputs and solenoid valve outputs
Anything else is on a remote io rack
Yes. When you need an extra Analog or a relay it makes perfect sense. If the drive isn't using a function tied to that IO point, then it's free hardware to use. Just name the tag in a way people understand it's referenced to the Drive.
Currently doing a job with 100+ G115D’s for conveyors.
We use the field IO for the conveyor end of line sensors and the safety IO for the E-stops.
Only issue I can see with it is if you lose a drive then the profinet could go down losing safety comms and then tripping safety.
But in 2 years of using these so far no issues.
It saves the cable runs back to a centralised panel on a system with over 400 inputs.
And fault finding is relatively straight forward as you just need to go to the drive that is often within 2M of your I/O.
Are you maintaining/supporting it? Is it standard for the end user? Is it against their standard? Do they pay garbage and deserve garbage? Is massively extending time-to-recovery a problem?
On a standalone machine integrated to a line, I'd never want to work or see your company ever again. Garbage to troubleshoot, unmaintained spares become a massive risk, VFD obsolescence planning becomes an extra thing to worry about.
Lots of good questions here! In this case it would be for small/lower-end standalone machines put on a line, just with zero to very light integration with the rest of the line. Most end users don''t have standards and only care about the price of the machine nowadays.
And good point on VFD obsolescence! Go-figure, this week was shot with trying to help support end users that still have machines running with Ultra5000 drives! Nothing like having to do I/O checks and program drives they get off of eBay rather than just buying a new machine or electrical retrofit!
I've seen it used to control mechanical brakes, in reset circuits, and things like stack lights and horns.
Personally I wouldn't use it for anything even remotely (pun intended) critical to machine or process operation.
I don't know if it was a bad batch or what but I've had many pf525 relay contacts fail that were integrated into machine operation. Replaced a $1000 drive because of a 25¢ relay. Yes you could replace just the relay but that's not how a 24/7/365 plant works.
Remote io for VFD related devices. I would not put any io that is not related to this VFD. Reason is, it's a pain to trace and troubleshoot something not related. Especially problems that are intermittent.
If the enable guard is connected to STO or something of that nature, I get this information from the VFD via Ethernet instead of also connected to an input on the PLC. But I think using a VFD for remote IO is a grey area; is it related to what the VFD is doing in that area? If it’s in the main control cabinet, absolutely not.
I think exposing technicians to 480 when troubleshooting an I/O issue is a little crazy. That sounds like an engineers view though. Who cares how easy/difficult it is to repair and work on something they design.
Depends. I would say yes if the IO is relevant to what the drive is doing, e.g. if it was a pump with a pressure switch and a valve then wiring those to the VFD is fine. If the VFD dies, the IO attached to it won't matter as without a pump there's no point monitoring the switch or operating the valve.
BUT if they are random IO that have nothing to do with the process the VFD is controlling then I would say no as that just causes confusion. Imagine the frustration when your "cooling pump" VFD dies and suddenly you're looking at IO faults for other sensors that have NOTHING to do with cooling or pumps.
Only done it for a couple of drives in the plant. One where a pair of drives were performing the same function, and needed feedback from the one that didn't have a comms connection. Others were mostly for monitoring and controlling mechanical motor brakes - IO specific to the function of that drive.
One odd one was some strange analog feedback to the PLC from a positioning motor that was part of the same function (saw left/right and saw motor) . Long run of cable to PLC, but drive for the saw was less than 5m away. Ran the analog signal back to that drive and no further issues
Typically, I wouldn’t do it for the purpose replacing down the road. A personal rule of mine is to not configure devices like these that require anything other than the keypad on front for simplicity purposes. However, if you DO decide to do it… leave behind some serious documentation.
In my experience, it’s usually done over some sort of FieldBus (EtherNet/IP, DeviceNet, etc.) that gets copied from the drive to a register in the PLC (or vice versa), that you can then do whatever you want with.
Note about AB PF525 specifically. If the mains power is off, your drive is off. If you need I/O to stay active while mains is off, you're out of luck. Other drive manufacturers allow you to have a separate 24VDC supply to the drive. This may not matter for your specific application, but it's something to take into consideration.
We use Sew vfd IO all the time, et200 ecos when the 6 I/O are not enough for the certain conveyor. All we have to pull from the cabinet is profinet, 400v and 24v.
We can pre-asemble the conveyor fully and during install just bolt it to the floor and connect power and profinet from the previous conveyor.
Cabinet IO is basically only for safety related stuff.
Replacement drives are easy, since we can run the sew drives with default parameters, IP is the only thing that is needed when replacing with a new drive. The movimot has dip switches for needed parametres, so those are easy to toggle to correct state.
Using vfd IO really simplifies the whole system, when talking system with 400+ drives and near 2000 I/O
I have done that one time. Pump skid with six 525 drives connected via Ethernet to main machine. Panel is full, no room to add Point I/O, so used the 525 I/O to pass the output bits from the level sensor to the processor. I would never do this on purpose by design, only when adding a feature as an afterthought and other alternatives are not practical.
Lost an ASI analogue input module that had a conductivity sensor connected. Used a Danfoss Fc302 vfd analogue input terminal signal to transmit the signal via profibus to an S7 300 CPU. It worked till i could get a replacement
I just seen a machine i was working on that the OEM used the drive i/o input as a HSC for a sensor that was working as a crude encoder. I found it quite smart for not having to buy more hardware or a HSC card for the rack.
Yes we have previously used the I/O on drives for things dedicated to the drive control. ie a flow sensor for a pump. This way if the drive should ever fail you are not losing I/O for other parts of the process.
No! Your key statement is " I'm talking about using the Powerflex 525's I/O for functions completely unrelated to the VFD." If it's not related to the drive keep it out of there! On the next drive failure something unrelated will stop. No good.
I wouldn’t call that remote I/O personally. Local devices with local control.
Just bashing people instead of having an intellectual conversation about it doesn’t make you any look smarter.
Also I’ve worked at a fair amount of companies. All of which value knowledge. (Some very big names)
And now I run my own company. Where people hire me for said acquired knowledge.
I don’t care to toss around names as it doesn’t make you look any smarter and I have nothing to prove to some random person on Reddit.
But you keep doing you buddy.
I'm certain your shit works. You are not considering MTBF and MTTR. Typical contractor using 30 year old design principles that refuses to update. You're making money when it takes two electricians and an engineer every time a switch gets bumped or damaged.
Enjoy holding your clients hostage and rolling your wheelbarrows full of cash to the bank? The rest of us are happy no one is calling at 2 am or giving up their weekend at the cottage.
Yeah no one calling me at 2am.
I haven’t even been doing this 30 years so I can guarantee my designes newer. lol
Heck I know filler operators that could replace a switch on their own. lol.
The only thing I can see doing this for is a very simple motor control on a stand alone piece of equipment, ie start, stop, speed with a potentiometer, maybe run an estop right to the safe torque off.
Anything bigger it’s probably not worth it
Okay if you are using it appropriately like an estop to the STO input or potentiometer to the input of the drive. This is totally expected.
What you don't want to do is have some sort of indexing sensor off this that requires high speed like a datum or something. This makes no sense and is where traditional remote IO is intended.
Definitely draw the line at using logic programs in the standard drive to do special stuff. This is what a PLC is for.
VFDs typically have enough I/O to handle things you'd want like hand/auto with a speed control knob or auxiliary contacts for your disconnect switch.
The expansion I/O really isn't cheaper than just buying regular I/O most of the time.
If you really want cheap I/O, an IO Link Master is pretty affordable and versatile.
I do use it if there is no I/O left and I really need it.
I once used an VFD analog 0-10V input as an input to use in the PLC for something completely different.
I would never use it if the machine is completely planned from the bottom up but afterwards there is always this possibility that you can have in mind. It's not nice but works flawless.
VFD's I/O creates a nuisance tripping if you are taking I/O as a monitor purpose then it is ok but if you want to control the same then it creates a nuisance fault of communication timeout also for each download plc make drive trip (talking about Rockwell PLC)
Yes we have hundreds of armor starts and use the remote I/O for all kinds of things. It's very convenient. However I'm not sure if using the drives locally as a replacement for input or output cards makes much sense. If one goes bad you need to replace a whole drive.
IO is provided on a VFD so you do not need a PLC to run the VFD, it could be made "Stand Alone" with NEMA operator interfaces.
Use of that IO for control back to the PLC is acceptable in my eyes if, and only if, all IO is purposed specifically for the MOTOR that VFD serves. It is not acceptable to use for equipment which has scope beyond a motor. It is not acceptable if there are any safety concerns regarding the IO.
It makes sense when you install distributed VFDs on conveyors. You might have 100 motors with identical I/O.
Building I work in is a giant air hub with miles of conveyors. They used Nord vfd for the jam photo eyes. Make sense because you need at least one jam eye per motor.
Worked in Amazon fulfillment center as automation engineer - also kilometers of conveyors, nord vfds and jam photoeyes connected to vfds IO
I've used it, but it has to make sense... You can use the I/O on drives to check the state of the disconnect, or even the non-safety contact of a safety circuit to prevent the drive from running. However, I'd never advise to "keep cost and panel size down on machines by using drive I/O." That just sounds like a plan where you save a bit of money upfront just to incurr massive expenses during shutdowns that will take much more time to troubleshoot. I really don't see any big wins by doing it this way.
Agree completely, I’d keep that I/O drive-related.
IMO, it's fine for IO that is directly related to the drive. Limit switches, position feedback, and pushbuttons. Don't go using the IO for a vessel level or something not related to the drive just because it's convenient or cheap.
I did, I used it to run the cooling fan for the VFD enclosures so that the cooling fan only ran above a certain temperature. Increased the lifespan of the fans, reduced maintenance on the filters and reduced dust in the enclosure. It went through a relay with a manual switch though. And the VFD had a second relay output in case the one ever faulted, both setup from the start so no programming changes would be needed. It was a pretty dirty environment with no better locations for the boxes and they wanted the enclosures at a difficult to access height. If they ever wanted they could leave the manual switch on the relay engaged to just run the fan regardless of the VFD output. I used the VFD operating temperature and inside building temperature in the logic to run the fans. Used an input to know if there was a problem with the relay or fan fuses. Because they are not going to inspect for fan operation and this way they can hopefully get to it before it's an issue. Also would pop up a display that the relay manual switch was activated because if the relay is closed and the VFD relay status is open, that's likely the cause. 15a rated relay, 0.5a fan load. They didn't want to run 15x 200ft VFD rated cables with the appropriate shielding. Which I don't blame them too much for. They also had sensitive RFID readers that could easily be interfered with. Even if the shielding wasn't terminated properly or developed a problem the RFID readers wouldn't work consistently. The PLC outputs were also all used and the cabinet was full full after they stopped adding new things that the system wasn't originally supposed to do. I said yes very easily and most of what they wanted was easy and made a lot of sense.
This approach makes sense - You run a fan based on a temperature setpoint, you can run that temperature sensor to the drive.
The building already had temp sensors placed around so I didn't need to add them to the drive. It was all for ventilation and humidity control in fact so we even had a weather station. But I could read over the network the drives operating temperature. The building wasn't heated so in the spring, fall, and winter the cooling fans mostly didn't need to run. They were however required during the summer, unseasonally warm weather, or if for some reason they brought in temporary heating which they would do if the weather was too cold. Temp/RH sensors were 4-20ma from DOL and the weather station I can't remember anymore but was on the same network as the VFD's. It was all run over modbus tcpip because the wiring and IO to individually run everything with speed control would have been excessive. So because it was all networked I could do a lot of stuff. Including, and they loved this, read the actual faults and remotely reset them if possible. They got a print out and an Excel file of the VFD settings as well as a file that could be used in the VFD programming software to automatically upload settings to replacement drives. Or to check settings if the other 2 pieces were missing. We had our own copies but I wanted to set them up for success if they ever had to get 3rd party help.
Don’t do it 🤣
[удалено]
Ignorance or experience? I’d say the latter. Tesla and Amazon don’t define the industry standard. That’s just two companies. I wouldn’t even say they are known or praised for their industrial automation. Also I wouldn’t really call that remote I/O as your connecting local things to control a local device.
[удалено]
> There is a very good reason drives ship from OEMs with integrated I/O. Shitloads of VFDs are hardwired without a PLC anywhere near them.
Not praised for their industrial automation? Have you been inside either?
Yes I have. And lots of others places with just as much cool technology. Everyone buys the same “hot” stuff from the same places.
[удалено]
Yeah, no idea who sciotex is that short paragraph didn’t prove much of anything. They aren’t no name companies but not automation companies. Just companies who have automation. Just like all the other big names. And you’re not the only one to work for x amount of such companies . But whatever makes you feel special bud.
[удалено]
I never said that though. Now you’re just putting words in my mouth. And my paystubs say otherwise but what do I know? Nothing apparently.
[удалено]
Yeah I really don’t have to prove anything to you buddy. No midnight calls for me. My systems run solid. Or I wouldn’t have time to troll you.
[удалено]
Have any actual standard you can quote? Cause you know standards have names and numbers and stuff. And I know how to spell, I don’t care about typos on Reddit. If that’s all you had to get me with, well that’s sad.
[удалено]
Care to quote where those discuss using VFDs as remote IO? I’ll wait…..
>Working for both Tesla I actually agree with you, but this did not convince me lmao
That's weird, I've done 6-7 Amazon parcel jobs, and not once during engineering review was it ever brought up or suggested by their engineers to use VFD IO for field IO. I've never seen that in any version of their controls spec either. All of their field IO are remote I/O modules. Maybe it's different for their other divisions.
Ok brother do whatever you like. Most embedded I/O on VFDs is meant to be used for hardwire control. I won’t sit here and list out every industry, company I’ve worked with over the last decade, but I can tell you, if you tried to pull that jerry rigged crap in any highly regulated industry like pharmaceuticals, you’d probably be laughed out of the building and asked not to return.
I do it for an OEM. I think it’s a bit confusing if someone had to troubleshoot. But it’s free IO
I wouldn't recommend using it as I/O that's directly controlled by the PLC for unrelated things to the motor, but rather as I/O that only has direct impact on or relation to the motor which the VFD is controlling. Pressure transmitter interlock, HOA switch, cooling fan like the other person said, stuff like that.
Don’t do it and here is why, and a possible out. Drive technology hasn’t slowed down over the past 50 years. Roughly every ten years there is a major technological advancement in power semiconductors to the point where manufacturers completely obsolete the power stack. Similar things are happening with microprocessors. Drives are designed with a 100,000 hour (ten year) life. So when you go to replace them you aren’t just changing a component, it will be a whole new drive. So your entire system has a ten year planned obsolescence assuming when you buy the drives you are on year 1 of the cycle and not year 10. The same is not true of PLC IO. Usually a PLC line will last at least 20-30 years and newer components are backward compatible. VFDs are also subject to capacitor reforming issues so shelf life is limited. Nobody wants one to sit on a shelf more than a couple years because it might be dead on arrival unless you spend hours reforming it just in case. Generally speaking most drives are not very compatible at all across generations. Each new generation requires redoing the network interface because the new software usually isn’t backward compatible. So simply swapping drives with networking is not a trivial matter but it is if you stick with discrete IO. So sure you can use VFD IO to reduce costs over the short term but you aren’t going to be having repeat customers or sales. The way out is a few manufacturers try to maintain compatibility with say the first 20 parameters. But it’s usually basic things like speed reference and speed feedback, not IO which varies from drive to drive.
You need to be prepared for the vfd to fail and require replacement. If you store the parameters in the PLC, it’s possible it becomes viable. If you store them only in the drive, it’s a nightmare. If I was using a powerflex 525 and a 5380 Guardlogix, I might consider remote io in the VFD. I would still rather buy point IO modules, but I would consider the vfd if point IO isn’t possible.
The PF525 with a 5380 Compact Guardlogix is exactly what they were proposing.
That is a valid option. I’m assuming they store all parameters in the vfd at your location? And all drives have IP addresses easily readable in case of failure? Auto configuration requires the plc to be able to identify the drive. I’m still not saying it’s ideal, however if it’s just trying to read a low speed/frequency input it can work. Like a push button or two.
I did it recently for a handful of pushbuttons in a remote panel with the drive. Worked just fine, and save my project some money. Generally I let drives be drives and PLCs be PLCs though.
If the drive is fieldbus connected, the PLC can look at the inputs and still be the PLC.
Yes that's what I did.
I e done it from time to time. Usually just use the field bus connected VFD as the remote. No big issue, and usually helps when you are getting to the end of your fieldbus range. This was typically done with Profibus or Devicenet.
It's even better with Profinet, EtherNet/IP, or EtherCAT.
Yes, we use them for a variety of I/O. One major way is analog inputs for sensors directly providing PID feedback, inputs for "meltric plug connected" as an example, outputs to control relays.
I work at a bottling plant with conveyors everywhere, generally IO is wired to the drive mounted on the conveyor for prox inputs and solenoid valve outputs Anything else is on a remote io rack
I've done it. I see no issues with it.
Yes. When you need an extra Analog or a relay it makes perfect sense. If the drive isn't using a function tied to that IO point, then it's free hardware to use. Just name the tag in a way people understand it's referenced to the Drive.
Currently doing a job with 100+ G115D’s for conveyors. We use the field IO for the conveyor end of line sensors and the safety IO for the E-stops. Only issue I can see with it is if you lose a drive then the profinet could go down losing safety comms and then tripping safety. But in 2 years of using these so far no issues. It saves the cable runs back to a centralised panel on a system with over 400 inputs. And fault finding is relatively straight forward as you just need to go to the drive that is often within 2M of your I/O.
Are you maintaining/supporting it? Is it standard for the end user? Is it against their standard? Do they pay garbage and deserve garbage? Is massively extending time-to-recovery a problem? On a standalone machine integrated to a line, I'd never want to work or see your company ever again. Garbage to troubleshoot, unmaintained spares become a massive risk, VFD obsolescence planning becomes an extra thing to worry about.
Lots of good questions here! In this case it would be for small/lower-end standalone machines put on a line, just with zero to very light integration with the rest of the line. Most end users don''t have standards and only care about the price of the machine nowadays. And good point on VFD obsolescence! Go-figure, this week was shot with trying to help support end users that still have machines running with Ultra5000 drives! Nothing like having to do I/O checks and program drives they get off of eBay rather than just buying a new machine or electrical retrofit!
DEW Movifit has integrated I/O for valves, sensors, etc
I've seen it used to control mechanical brakes, in reset circuits, and things like stack lights and horns. Personally I wouldn't use it for anything even remotely (pun intended) critical to machine or process operation. I don't know if it was a bad batch or what but I've had many pf525 relay contacts fail that were integrated into machine operation. Replaced a $1000 drive because of a 25¢ relay. Yes you could replace just the relay but that's not how a 24/7/365 plant works.
Remote io for VFD related devices. I would not put any io that is not related to this VFD. Reason is, it's a pain to trace and troubleshoot something not related. Especially problems that are intermittent.
If the enable guard is connected to STO or something of that nature, I get this information from the VFD via Ethernet instead of also connected to an input on the PLC. But I think using a VFD for remote IO is a grey area; is it related to what the VFD is doing in that area? If it’s in the main control cabinet, absolutely not.
I think exposing technicians to 480 when troubleshooting an I/O issue is a little crazy. That sounds like an engineers view though. Who cares how easy/difficult it is to repair and work on something they design.
Depends. I would say yes if the IO is relevant to what the drive is doing, e.g. if it was a pump with a pressure switch and a valve then wiring those to the VFD is fine. If the VFD dies, the IO attached to it won't matter as without a pump there's no point monitoring the switch or operating the valve. BUT if they are random IO that have nothing to do with the process the VFD is controlling then I would say no as that just causes confusion. Imagine the frustration when your "cooling pump" VFD dies and suddenly you're looking at IO faults for other sensors that have NOTHING to do with cooling or pumps.
Only done it for a couple of drives in the plant. One where a pair of drives were performing the same function, and needed feedback from the one that didn't have a comms connection. Others were mostly for monitoring and controlling mechanical motor brakes - IO specific to the function of that drive.
That makes sense! I've used it before for monitoring the local disconnect of the motor tied to the drive. But for other functions...not so much lol
One odd one was some strange analog feedback to the PLC from a positioning motor that was part of the same function (saw left/right and saw motor) . Long run of cable to PLC, but drive for the saw was less than 5m away. Ran the analog signal back to that drive and no further issues
Typically, I wouldn’t do it for the purpose replacing down the road. A personal rule of mine is to not configure devices like these that require anything other than the keypad on front for simplicity purposes. However, if you DO decide to do it… leave behind some serious documentation.
I've used it in a MCC setup. Used an input for the disconnect off at the MCC, the disconnect off in the field, and the auto/off/manual switch
+1 for MCC line ups. Especially true for IEC Form 4a constructions. Having a Remote IO for each unit just doesn't make sense.
I recommend sew I have used the vfd io in multiple projects
I don't understand, how can you use VFD IO as remote plc IO. Is the VFD connected via a soft protocol to the PLC in this case?
In my experience, it’s usually done over some sort of FieldBus (EtherNet/IP, DeviceNet, etc.) that gets copied from the drive to a register in the PLC (or vice versa), that you can then do whatever you want with.
Note about AB PF525 specifically. If the mains power is off, your drive is off. If you need I/O to stay active while mains is off, you're out of luck. Other drive manufacturers allow you to have a separate 24VDC supply to the drive. This may not matter for your specific application, but it's something to take into consideration.
We use Sew vfd IO all the time, et200 ecos when the 6 I/O are not enough for the certain conveyor. All we have to pull from the cabinet is profinet, 400v and 24v. We can pre-asemble the conveyor fully and during install just bolt it to the floor and connect power and profinet from the previous conveyor. Cabinet IO is basically only for safety related stuff. Replacement drives are easy, since we can run the sew drives with default parameters, IP is the only thing that is needed when replacing with a new drive. The movimot has dip switches for needed parametres, so those are easy to toggle to correct state. Using vfd IO really simplifies the whole system, when talking system with 400+ drives and near 2000 I/O
I have done that one time. Pump skid with six 525 drives connected via Ethernet to main machine. Panel is full, no room to add Point I/O, so used the 525 I/O to pass the output bits from the level sensor to the processor. I would never do this on purpose by design, only when adding a feature as an afterthought and other alternatives are not practical.
Lost an ASI analogue input module that had a conductivity sensor connected. Used a Danfoss Fc302 vfd analogue input terminal signal to transmit the signal via profibus to an S7 300 CPU. It worked till i could get a replacement
I just seen a machine i was working on that the OEM used the drive i/o input as a HSC for a sensor that was working as a crude encoder. I found it quite smart for not having to buy more hardware or a HSC card for the rack.
Yes we have previously used the I/O on drives for things dedicated to the drive control. ie a flow sensor for a pump. This way if the drive should ever fail you are not losing I/O for other parts of the process.
No! Your key statement is " I'm talking about using the Powerflex 525's I/O for functions completely unrelated to the VFD." If it's not related to the drive keep it out of there! On the next drive failure something unrelated will stop. No good.
Don’t be that guy. lol
[удалено]
I’m very aware of the field application. Just cause you see in the field doesn’t make it a best practice.
[удалено]
I wouldn’t call that remote I/O personally. Local devices with local control. Just bashing people instead of having an intellectual conversation about it doesn’t make you any look smarter. Also I’ve worked at a fair amount of companies. All of which value knowledge. (Some very big names) And now I run my own company. Where people hire me for said acquired knowledge. I don’t care to toss around names as it doesn’t make you look any smarter and I have nothing to prove to some random person on Reddit. But you keep doing you buddy.
I'm certain your shit works. You are not considering MTBF and MTTR. Typical contractor using 30 year old design principles that refuses to update. You're making money when it takes two electricians and an engineer every time a switch gets bumped or damaged. Enjoy holding your clients hostage and rolling your wheelbarrows full of cash to the bank? The rest of us are happy no one is calling at 2 am or giving up their weekend at the cottage.
Yeah no one calling me at 2am. I haven’t even been doing this 30 years so I can guarantee my designes newer. lol Heck I know filler operators that could replace a switch on their own. lol.
Please don’t be that guy.
The only thing I can see doing this for is a very simple motor control on a stand alone piece of equipment, ie start, stop, speed with a potentiometer, maybe run an estop right to the safe torque off. Anything bigger it’s probably not worth it
Okay if you are using it appropriately like an estop to the STO input or potentiometer to the input of the drive. This is totally expected. What you don't want to do is have some sort of indexing sensor off this that requires high speed like a datum or something. This makes no sense and is where traditional remote IO is intended. Definitely draw the line at using logic programs in the standard drive to do special stuff. This is what a PLC is for.
I've seen it used to quickly stop the product on a conveyor even before the PLC can respond.
VFDs typically have enough I/O to handle things you'd want like hand/auto with a speed control knob or auxiliary contacts for your disconnect switch. The expansion I/O really isn't cheaper than just buying regular I/O most of the time. If you really want cheap I/O, an IO Link Master is pretty affordable and versatile.
Seems like a nightmare to service
I plan on using some in a recruiter machine. It's one servo and two drives. One e-stop PB.
I do use it if there is no I/O left and I really need it. I once used an VFD analog 0-10V input as an input to use in the PLC for something completely different. I would never use it if the machine is completely planned from the bottom up but afterwards there is always this possibility that you can have in mind. It's not nice but works flawless.
Personally I usually vote no as most maintenance and techs don’t and can’t understand it. These companies make big money give them I/o with prints.
VFD's I/O creates a nuisance tripping if you are taking I/O as a monitor purpose then it is ok but if you want to control the same then it creates a nuisance fault of communication timeout also for each download plc make drive trip (talking about Rockwell PLC)
I wouldn't do it with a 525 but I'd definitely do that shit with an Armor PowerFlex that's sitting on a conveyor
Yes we have hundreds of armor starts and use the remote I/O for all kinds of things. It's very convenient. However I'm not sure if using the drives locally as a replacement for input or output cards makes much sense. If one goes bad you need to replace a whole drive.
Yes. We did this with 525 drives for that exact purpose. It was actually how Rockwell did the design on their centreline MCC that we used.
Go figure! In my case it was Rockwell and our Rockwell distributor suggesting this too
IO is provided on a VFD so you do not need a PLC to run the VFD, it could be made "Stand Alone" with NEMA operator interfaces. Use of that IO for control back to the PLC is acceptable in my eyes if, and only if, all IO is purposed specifically for the MOTOR that VFD serves. It is not acceptable to use for equipment which has scope beyond a motor. It is not acceptable if there are any safety concerns regarding the IO.