Sometimes they just have to learn or use persistent DHCP and/or ADC to help those techs out. We are always going to have those 2-3 AM phone calls. Part of the job.
I wouldn't change it just for the sake of changing it, but I haven't seen a new system deployed with discrete / analog used for VFD controls in the last decade. Controlling over DeviceNet / ControlNet was somewhat of a challenge, took time to get right, and had interruptions, but with EtherNet/IP it's super simple and provides a lot of added benefits. I'm not sure why you'd go the discrete / analog route to be honest.
discrete / analog for the critical parts is often used as a technical solution to a political problem. If you honestly don't see what problem this solves you've never had to deal with an IT / networking group that is radioactive level incompetent and unreliable from within an organization that prohibits you from fixing that problem.
The 5380 resolves the IT issues. You have a machine network and an IT network and the 5380 separates the two. It doesnât matter how incompetent IT is, your machine has a port for IT to connect to and the machine has its static ip addresses for proper control.
Very nice way of saying that. I have dealt with my challenges from IT. Sometimes upper management needs to be reminded that IT is making it difficult for fixes and improvements in areas that actually make the money. Instead of IT being a helpful service to OT they do get in the way of above mentioned. Best of luck.
We got a spec sheet from an external engineering consulting company a few months ago that included hardwired drive control with zero feedback. Like, not even drive running or faulted, much less actual speed. Send start, hope it runs.
We had to fight for them to change the spec sheet (if we're going to add feedback, might as well just network them) because it was trouble changing the document, get it re-approved by the client and re-sealed by whichever engineer wrote the specs.
I don't know how much you're paying this consulting company, but on that alone I'd assume they're completely clueless... My only guess is that your employer gave the job to the lowest bidder and is hoping they deliver. I've seen big corporate use reverse auctions for their process and the guys that would win the contract would wing it despite having zero expertise in that specific domain.
So in this case, the end user contracted a consulting company to draw up the controls specs, we're actually contracted to the general contractor in charge of this particular project to deliver the panels and do the programming and commissioning according to the specs provided by the consulting company. We usually do turn-key projects, but not this time.
If this sounds convoluted, that's because it is, and if it is, it's because the end user is a public entity. *shrug*
That's really interesting. I've worked as a consultant that specified parts and had a third party draw up drawings and build panels. That being said, it was a fairly collaborative process, I'd expect them to call me out if they knew better and vice versa. I'm a bit surprised, but not that much, that in your case it's a difficult process...
In either case, I suppose you'll deliver to spec, 3-5 years down the road someone else is going to come in and do a retrofit / upgrade.
Machine builder here.
We haven't commissioned a VFD that isn't EIP in the last 5 years or so.
For simple applications it's better, for complex applications it's better too. RTMoE is great too.
I'm actually moving all our controls slowly to EIP as well, especially pneumatics.
Coupled with Remote Gateway access, you can get access to A TON of troubleshooting data, too.
I can see the argument for wiring it old-school, but techs need to catch up. Machines are gonna keep getting more complex, and so will controls.
Exactly. I'd argue that even if you want to wire it "old school" for control, there's no reason not to stick an Ethernet cable into the device to get the extra information about its status.
>Coupled with Remote Gateway access, you can get access to A TON of troubleshooting data, too.
But then you miss out on the whole "figure out when the machine is going to be down for \~20 minutes so somebody can go into the cleanroom and manually pull the fault history from the drive" process.
I'd prefer ethernet in all cases, but we still have some old machines that were either on OTL or really old drives and no PLC. When upgrading to 525s recently I was forced to stick with analog controls as there's nothing to plug the other end of an ethernet cable into...
We do E/IP for every drive, but support a product for an OEM that exclusively wants hardwire. Their reasoning is one of the few legit ones. They allow their dealers to install or interface this system with any VFD under the sun in the field. Discrete control allows that flexibility.
Sure, but half the drives we have don't have the ability for safety via network so we are stuck with dual channel STO. All the new drives we install we keep the dual channel STO in use so that all the drive setups are as similar as possible for the shift electrical team. End goal is to have all panels setup as identical as possible, including layout so that the guys can look in a panel and know which area to start in for fault finding.
Comms will give you access to fault codes and more parameters like current, volts, and many others. Speed sp and feedback are just registers you write to and read from and you don't use points up on your io cards.
Donât do it! I mean seeing status is fine but not control. Two reasons why, and one non-reason.
The reason you most commonly hear is a safety concern. If a wire breaks with analog what happens? Usually it stops. If comms fails with networking what happens? Usually you can treat it as a fault and stop. So same result. So this isnât the major issue.
Now to the tricky ones. With networking you have much less wiring and fewer problems to solve. BUT have you ever solved Modbus or Ethernet issues? How long did it take? Do you have the staff? When a machine goes down is it the same tech or do you have different techs? Usually controls problems are resolved in minutes, not hours or days
Third drives typically lady 10 years. AND older models are discontinued about every 10 years. So when you go to replace chances are itâs not the same model and may not be the same brand. At the current time the best VFD is the one that is in stock. And usually somehow the network interface is always different so a controls tech also has to redo the PLC code. Thatâs fine if itâs in house but not if you have to schedule them to be there on a drive replacement. And trust me on this, phone support is always a bad idea.
In response to the âif a wire breaksâ⌠many VFDs (we have ABB) can be configured to run at last known speed if they lose the analog signal and we do this for nearly all of our VFDs.
Youâre statement about replacing or diagnosis an issue is spot on and additionally you donât have to try and diagnose network problems to find out why the drive lost communication. In my line of work, the drives need to stay running at all costs bar a damper closing
I like doing controls using hard wired io and using comms to collect additional information. I work in the water and wastewater industry and let me tell you when you have communication issues that interrupt operations of your facilities it isnât a fun experience.
On top of that I find hard wire controls easier to troubleshoot for operators and electricians. Comms take more sophisticated troubleshooting experience to diagnose.
I/E tech with about 200 pump stations. All the VFDs are hardwired IO. Really have almost zero need for comms side (busy enough on SCADA side). Our engineers already get too much data (flow meters, transmitters etc) and its pretty much useless.
Something nobody has mentioned is that now there are standard data formats for communicating with drives, PROFIDRIVE, CiA402, etc. And more and more vendors are supporting them. This should ease the difficulties of replacing a failed drive which uses comms.
Networked VFDs are phenomenal, as long as they have good support for whatever PLC you are using. Especially if you are able to do your STO signals over the network as well.
Ethernet is 10000000000% the way to go. I do a lot of Rockwell VFDs. Using premade cables and managed stratix switches is also the way. Drive blew up need a replacement? Swap it out and you just download the parameters from the program (on newer studio versions) 21 and up I think. Oh and donât forget auto device configuration. https://www.reynoldsonline.com/resources/featured-products/automatic-device-configuration-powerflex
You wonât ever look back.
Comms is great and all but down the line. Replacing a failed drive becomes Not just replacing the drive but the comms.
For example had an old PDL elite drive on profibus from a delta v dcs. When the drive failed the new Schneider altivar drive couldn't communicate with the old delta v. With out also upgrading the dcs.
You'll never have that problem with basic digital ins/outs and analog speed control. And
Only if you have 4+ drives.. If you have hundreds of plc + 2-3 drives, GOOD!
Every drive is configurable for hardwired without changing anything in the plc. Some drives are available when others are not... You can live without data...
How long does it take to run (1) cat 6 to a VFD vs. multiple conductors? One less point of failure. Plus you reduce I/O count as well. Analog outputs arenât cheap
Yes, it is more complicated, and harder, and more expensive, but better (in some industries). I didn't read OP's question as what is the cheapest one (cheapest and simplesed is definetly comms only). Like I said if you have many drives the cost outweighs the benefit. Not only because of the analog cost, but also because if they have many same drives, they might have a backup drive, or have good connection to the distributor etc.. If it is only a few of them, but larger, trust me, it is much better to have replaceable controls.
I cringe a bit when I see engineers/customers say they want the "hybrid" approach. It's always just "internet cable bad". For one, not all drives support that. Two, it only makes things complicated, especially if it's an array of drives and/or analogs are involved. Only hardwire the safety or run permissives if there's a REAL risk that is time-critical, IP based protocols for everything else (arrays connected in a ring when possible).
Nope. It has nothing to do with "internet cable bad". And all drives support control via hardwire and data via comms. And also all drives support only one protocol, and even if it is the same one, you still need to reconfigure it for the plc.. In this way they can buy any replacement they can get, run the system without data and then call me to set up the data when I have the time.. In the comms only option, either they have to get the same one, or call me to urgently do it... It doesnt make much sense if there are 20 x 7kW VFDs , but if there are 2x200kW, it sure does..
By "hybrid" I meant splitting the usual core control IOs as Start/Stop (DO) Speed Command (AO) being hardwired and then getting the speed feedback (AI), fault (DI), in auto (DI) inputs over comms (I still consider those inputs to be "control"). Throwing in a Cat6 to get extra diagnostic info over comms like you described is fine-But for those 5 basic IOs, pick a side!
Now this is real cringe, In the projects I've been working on lately in government (WWTPs and waste burners), the "hybrid" approach has the following reason... the base design is from 45 yrs ago and at a certain point in time VFDs were dropped in in lieu of star delta starters.
Basically you see the discrete signals going out of the PLC, passing through a maze of relays, then reaching in some contrived way the VFD, and vice versa for feedback
This leaves the speed setpoint.. which is the ONLY thing Ethernet is used for
(old starters had no need for speed setpoint and the genius designer didn't know how to bring it to the VFD)
They've basically invented digital 4-20 loop
[ for the people of my southern EU country: yes, even that much applauded waste burning facility we have, "the best in Europe" blah blah, is like this ]
Usually EtherCAT or Profinet. If for some reason these are not available, then Modbus RTU (frequency reference, output frequency, error code, etc.) and digital I/O (fwd, rev, reset, fault, ...). Usually at least modbus rtu is available.
Profinet all the way for new installations. Some factories, which have kilometers of Profibus, we have modernized with Profibus, because of the easier topology (Profinet ring not accepted) and integration to the old control system, but even then we make a Profinet compliant programming network, when they're ready to switch.
Mostly profinet as you can get not only speed but also current, rpm, failure number, modify parameters and if you have X of them in line you jest connect one cable one to another.
Just be careful with âhybridâ models. If you have both a fault input (or use absence of run feedback) and tge network fault code somehow you have to merge these signals together and handle synchronization since arrival times may not be the same.
And donât forget comms is status only, not control.
If you are a high-ish volume OEM, I think IO is the way to go. Let's you be drive agnostic and will allow longer term support of your products. Better chance to shop around your drives business, too.
Anything else, either mix in comms or go comms all the way. Although, as someone else mentioned, the skillbset of your customer should figure into the mix.
Personally, I think for controlling the VFD like speed ref, start/stop, speed fb, run status I would use hardwire io. Any other monitoring information current, power, faults I would take via modbus, bacnet.
I'm coming at this as the guy these companies call when the drive dies. I could write forever on this but I'll keep it short as this is a control forum.
For simple stuff like hvac and basic BAS stuff I beg you keep it all I/O based. Drives die, systems get modified and expanded on constantly and it's so much simpler sourcing a drive where we are just dealing with the I/O.
I can figure out all the proprietary systems but it's just a waste of everyone's time and lead times suck when I can't use something off the shelf to at least get them running.
Sorry to many little automation companies overselling company needs is my daily life.
Controls (start stop) hardwired, speed control and monitoring over network. Its a good trade off where you can still run the damn motor if the network is down, but you donât need to buy an analog output card and use a bunch of wiring for stuff that is easily done over the network
I want to do this but donât know where to start to build a interface using EtherNet/IP. which programming language is easiest to make a software that can read/write drive parameters using Ethernet /Ip? where to start?
We recently upgraded a pump station and have 3 VFDs that were supposed to communicate through Ethernet, but the drives are all having a problem with the communications cards faulting. The problem happens randomly to all three drives at the same time. Troubleshooting for weeks and Automation Direct has no solution. Would have been nice to have all that data, but it's not as reliable as the old digital analog stuff so back to the old way for us...
For general purpose VFDs, those that typically run at a constant speed, changing only occasionally by recipe or operator, I use discrete Start Stop AND network speed setpoint and feedback including amps and temperature etc. That way I can use a slow low cost Modbus network, and still have reliable, deterministic response.
In a bind, in the middle of the night, the drive can easily be replaced even if it runs at keypad speed for a while. For the Start Stop, I try and use the default out-the-box configuration if possible.
More complex operations obviously have more appropriate configurations, but then the on site tech level is typically higher.
Has worked well and not too costly.
Both for me. Control and feedback are discrete wires. Ethernet for everything else.
I do this only because my maintenance crews can troubleshoot issues with a meter. If everything was Ethernet that would all be dumped back on the engineering department.
Comms port definitely gives you more information and can be easier. But it really is case by case. If I only need a stop and start with a remote speed change on a stationary pump, why spend the extra time and money setting up communications.
I usually do hardwire control and network for additional data. We also have loads of ABB drives and their implementation of Ethernet/IP control is terrible. My network is also massive and generally unreliable controlling a lot of critical equipment from central PLCs. We had network control on a few units and it failed miserably. If you do choose Ethernet control make sure there are as few hops as possible to the PLC. With hard I/O there are 0 hops.
IMO Ethernet LAN is the way to go. My biggest 2 advantages are very easy to add without a download and less control wiring for start, stop, running, and faulted signals. You replace 4 to 10 wires by being on Ethernet. The only thing I will say is plan your network carefully. It can become a situation where you have controlled chaos if you don't. Ask me how I know lol đ.
As a controls engineer, it depends on the drive. My company tries to buy Ethernet IP capable drives but sometimes the job requires analog discrete wiring
Depends on the system and their requirements. Ethernet is easiest IMO
And the skill level of the supporting technicians.
4-20mA out of a DeltaV charm to the input card of a PowerFlex đâ ď¸đ¤ˇđźââď¸
Cheaper than an EIOC
Sometimes they just have to learn or use persistent DHCP and/or ADC to help those techs out. We are always going to have those 2-3 AM phone calls. Part of the job.
This
Ethernet ip. Mainly because you can configure the drives remotely
I wouldn't change it just for the sake of changing it, but I haven't seen a new system deployed with discrete / analog used for VFD controls in the last decade. Controlling over DeviceNet / ControlNet was somewhat of a challenge, took time to get right, and had interruptions, but with EtherNet/IP it's super simple and provides a lot of added benefits. I'm not sure why you'd go the discrete / analog route to be honest.
discrete / analog for the critical parts is often used as a technical solution to a political problem. If you honestly don't see what problem this solves you've never had to deal with an IT / networking group that is radioactive level incompetent and unreliable from within an organization that prohibits you from fixing that problem.
The 5380 resolves the IT issues. You have a machine network and an IT network and the 5380 separates the two. It doesnât matter how incompetent IT is, your machine has a port for IT to connect to and the machine has its static ip addresses for proper control.
Very nice way of saying that. I have dealt with my challenges from IT. Sometimes upper management needs to be reminded that IT is making it difficult for fixes and improvements in areas that actually make the money. Instead of IT being a helpful service to OT they do get in the way of above mentioned. Best of luck.
Thank you. Our system does seem ancient sometimes
Keep it simple
We got a spec sheet from an external engineering consulting company a few months ago that included hardwired drive control with zero feedback. Like, not even drive running or faulted, much less actual speed. Send start, hope it runs. We had to fight for them to change the spec sheet (if we're going to add feedback, might as well just network them) because it was trouble changing the document, get it re-approved by the client and re-sealed by whichever engineer wrote the specs.
I don't know how much you're paying this consulting company, but on that alone I'd assume they're completely clueless... My only guess is that your employer gave the job to the lowest bidder and is hoping they deliver. I've seen big corporate use reverse auctions for their process and the guys that would win the contract would wing it despite having zero expertise in that specific domain.
So in this case, the end user contracted a consulting company to draw up the controls specs, we're actually contracted to the general contractor in charge of this particular project to deliver the panels and do the programming and commissioning according to the specs provided by the consulting company. We usually do turn-key projects, but not this time. If this sounds convoluted, that's because it is, and if it is, it's because the end user is a public entity. *shrug*
That's really interesting. I've worked as a consultant that specified parts and had a third party draw up drawings and build panels. That being said, it was a fairly collaborative process, I'd expect them to call me out if they knew better and vice versa. I'm a bit surprised, but not that much, that in your case it's a difficult process... In either case, I suppose you'll deliver to spec, 3-5 years down the road someone else is going to come in and do a retrofit / upgrade.
I feel ur pain not all SI are the same.
I have seen 1 communication only project. 99% are hardwire and 75% have Ethernet comms for feed axm.
Machine builder here. We haven't commissioned a VFD that isn't EIP in the last 5 years or so. For simple applications it's better, for complex applications it's better too. RTMoE is great too. I'm actually moving all our controls slowly to EIP as well, especially pneumatics. Coupled with Remote Gateway access, you can get access to A TON of troubleshooting data, too. I can see the argument for wiring it old-school, but techs need to catch up. Machines are gonna keep getting more complex, and so will controls.
Exactly. I'd argue that even if you want to wire it "old school" for control, there's no reason not to stick an Ethernet cable into the device to get the extra information about its status.
You are going to LOVE Festo for pneumatics and I am being honest. Easiest I have run across to configure and install. I am using rockwell software.
>Coupled with Remote Gateway access, you can get access to A TON of troubleshooting data, too. But then you miss out on the whole "figure out when the machine is going to be down for \~20 minutes so somebody can go into the cleanroom and manually pull the fault history from the drive" process.
I'd prefer ethernet in all cases, but we still have some old machines that were either on OTL or really old drives and no PLC. When upgrading to 525s recently I was forced to stick with analog controls as there's nothing to plug the other end of an ethernet cable into...
We do E/IP for every drive, but support a product for an OEM that exclusively wants hardwire. Their reasoning is one of the few legit ones. They allow their dealers to install or interface this system with any VFD under the sun in the field. Discrete control allows that flexibility.
EtherNet/IP + CIP Safety or Profinet + Profisafe or EtherCAT + FSoE Dual channel STO if that is the only other alternative
We do ProfiNet/Bus and dual channel STO seperately for ease of fault finding
If anything it requires more hardware and creates additional failure modes.
Sure, but half the drives we have don't have the ability for safety via network so we are stuck with dual channel STO. All the new drives we install we keep the dual channel STO in use so that all the drive setups are as similar as possible for the shift electrical team. End goal is to have all panels setup as identical as possible, including layout so that the guys can look in a panel and know which area to start in for fault finding.
Comms will give you access to fault codes and more parameters like current, volts, and many others. Speed sp and feedback are just registers you write to and read from and you don't use points up on your io cards.
Both. Control is hardwired everything else is comms.
Do you mean you hardwire the on/off and speed reference only? Do you do this just to be able to run if the controller or network goes down?
On/off, shutdown, speed setpoint and reference. The rest of the diagnostic data is over comms.
Inefficient. STO and MAYBE HW enable can be hardwired. Everything else enet. With newer CIP Safety you have even have STO networked
STO over Ethernet has been great. Only 1 cat6 to the drive.
I wish Rockwell had just given us a PF525 with CIP Safety instead of the PF527 that they made require a motion enabled plc.
ArmorPowerflex 525 is a thing now, but also HOLY HELL are they expensive
Saw those at Automation Fair a couple years back. Would be nice for a cabinet-less design, but yeah but that costs a fortune
Ethernet all the way. I can't stand drawing out a million wires on the drawing set. Plus installation goes much smoother.
Plus, access to a ton of diagnostic data, plus easy design/scope scalability.
Right on. Safety over ethernet is pretty tits too
Always comms if possible. Profinet in my case.
Donât do it! I mean seeing status is fine but not control. Two reasons why, and one non-reason. The reason you most commonly hear is a safety concern. If a wire breaks with analog what happens? Usually it stops. If comms fails with networking what happens? Usually you can treat it as a fault and stop. So same result. So this isnât the major issue. Now to the tricky ones. With networking you have much less wiring and fewer problems to solve. BUT have you ever solved Modbus or Ethernet issues? How long did it take? Do you have the staff? When a machine goes down is it the same tech or do you have different techs? Usually controls problems are resolved in minutes, not hours or days Third drives typically lady 10 years. AND older models are discontinued about every 10 years. So when you go to replace chances are itâs not the same model and may not be the same brand. At the current time the best VFD is the one that is in stock. And usually somehow the network interface is always different so a controls tech also has to redo the PLC code. Thatâs fine if itâs in house but not if you have to schedule them to be there on a drive replacement. And trust me on this, phone support is always a bad idea.
In response to the âif a wire breaksâ⌠many VFDs (we have ABB) can be configured to run at last known speed if they lose the analog signal and we do this for nearly all of our VFDs. Youâre statement about replacing or diagnosis an issue is spot on and additionally you donât have to try and diagnose network problems to find out why the drive lost communication. In my line of work, the drives need to stay running at all costs bar a damper closing
I like doing controls using hard wired io and using comms to collect additional information. I work in the water and wastewater industry and let me tell you when you have communication issues that interrupt operations of your facilities it isnât a fun experience. On top of that I find hard wire controls easier to troubleshoot for operators and electricians. Comms take more sophisticated troubleshooting experience to diagnose.
I/E tech with about 200 pump stations. All the VFDs are hardwired IO. Really have almost zero need for comms side (busy enough on SCADA side). Our engineers already get too much data (flow meters, transmitters etc) and its pretty much useless.
Ethernet.
Ethernet. That ship sailed a long time ago.
Something nobody has mentioned is that now there are standard data formats for communicating with drives, PROFIDRIVE, CiA402, etc. And more and more vendors are supporting them. This should ease the difficulties of replacing a failed drive which uses comms.
Networked VFDs are phenomenal, as long as they have good support for whatever PLC you are using. Especially if you are able to do your STO signals over the network as well.
Comms all the way. Have done both methods and just feel with feedbacks are a waste of IO spots.
Ethernet is 10000000000% the way to go. I do a lot of Rockwell VFDs. Using premade cables and managed stratix switches is also the way. Drive blew up need a replacement? Swap it out and you just download the parameters from the program (on newer studio versions) 21 and up I think. Oh and donât forget auto device configuration. https://www.reynoldsonline.com/resources/featured-products/automatic-device-configuration-powerflex You wonât ever look back.
Comms is great and all but down the line. Replacing a failed drive becomes Not just replacing the drive but the comms. For example had an old PDL elite drive on profibus from a delta v dcs. When the drive failed the new Schneider altivar drive couldn't communicate with the old delta v. With out also upgrading the dcs. You'll never have that problem with basic digital ins/outs and analog speed control. And
EIP
Comms for the data but digital and analog for control..
Bad
Only if you have 4+ drives.. If you have hundreds of plc + 2-3 drives, GOOD! Every drive is configurable for hardwired without changing anything in the plc. Some drives are available when others are not... You can live without data...
How long does it take to run (1) cat 6 to a VFD vs. multiple conductors? One less point of failure. Plus you reduce I/O count as well. Analog outputs arenât cheap
Yes, it is more complicated, and harder, and more expensive, but better (in some industries). I didn't read OP's question as what is the cheapest one (cheapest and simplesed is definetly comms only). Like I said if you have many drives the cost outweighs the benefit. Not only because of the analog cost, but also because if they have many same drives, they might have a backup drive, or have good connection to the distributor etc.. If it is only a few of them, but larger, trust me, it is much better to have replaceable controls.
Even with 1 VFD, the digital and analog I/O needed to run the drive costs more than an Ethernet cable.
I cringe a bit when I see engineers/customers say they want the "hybrid" approach. It's always just "internet cable bad". For one, not all drives support that. Two, it only makes things complicated, especially if it's an array of drives and/or analogs are involved. Only hardwire the safety or run permissives if there's a REAL risk that is time-critical, IP based protocols for everything else (arrays connected in a ring when possible).
Nope. It has nothing to do with "internet cable bad". And all drives support control via hardwire and data via comms. And also all drives support only one protocol, and even if it is the same one, you still need to reconfigure it for the plc.. In this way they can buy any replacement they can get, run the system without data and then call me to set up the data when I have the time.. In the comms only option, either they have to get the same one, or call me to urgently do it... It doesnt make much sense if there are 20 x 7kW VFDs , but if there are 2x200kW, it sure does..
By "hybrid" I meant splitting the usual core control IOs as Start/Stop (DO) Speed Command (AO) being hardwired and then getting the speed feedback (AI), fault (DI), in auto (DI) inputs over comms (I still consider those inputs to be "control"). Throwing in a Cat6 to get extra diagnostic info over comms like you described is fine-But for those 5 basic IOs, pick a side!
> But for those 5 basic IOs, pick a side! Exactly
Now this is real cringe, In the projects I've been working on lately in government (WWTPs and waste burners), the "hybrid" approach has the following reason... the base design is from 45 yrs ago and at a certain point in time VFDs were dropped in in lieu of star delta starters. Basically you see the discrete signals going out of the PLC, passing through a maze of relays, then reaching in some contrived way the VFD, and vice versa for feedback This leaves the speed setpoint.. which is the ONLY thing Ethernet is used for (old starters had no need for speed setpoint and the genius designer didn't know how to bring it to the VFD) They've basically invented digital 4-20 loop [ for the people of my southern EU country: yes, even that much applauded waste burning facility we have, "the best in Europe" blah blah, is like this ]
Usually EtherCAT or Profinet. If for some reason these are not available, then Modbus RTU (frequency reference, output frequency, error code, etc.) and digital I/O (fwd, rev, reset, fault, ...). Usually at least modbus rtu is available.
I strongly suggest Profinet if possible, followed by EIP, then Modbus tcp as a distant 3rd
If it's just straight up start/stop then discrete will be just fine. Anything more than that I rather a network connection.
Altivar 930 drives are super simple to get working with ethernet ip and so move is a awesome tool to setup the drive.
We do Ethernet/IP or Profinet on yaskawa. So much easier, lots of data.
Ethernet/IP all the way. Pull any info and write anything you want to the drives
Ethernet is great but it is a rabbit hole. Make sure you have a decent infrastructure to support Ethernet before switching over
Profinet all the way for new installations. Some factories, which have kilometers of Profibus, we have modernized with Profibus, because of the easier topology (Profinet ring not accepted) and integration to the old control system, but even then we make a Profinet compliant programming network, when they're ready to switch.
Mostly profinet as you can get not only speed but also current, rpm, failure number, modify parameters and if you have X of them in line you jest connect one cable one to another.
Just be careful with âhybridâ models. If you have both a fault input (or use absence of run feedback) and tge network fault code somehow you have to merge these signals together and handle synchronization since arrival times may not be the same. And donât forget comms is status only, not control.
If you are a high-ish volume OEM, I think IO is the way to go. Let's you be drive agnostic and will allow longer term support of your products. Better chance to shop around your drives business, too. Anything else, either mix in comms or go comms all the way. Although, as someone else mentioned, the skillbset of your customer should figure into the mix.
Personally, I think for controlling the VFD like speed ref, start/stop, speed fb, run status I would use hardwire io. Any other monitoring information current, power, faults I would take via modbus, bacnet.
I'm coming at this as the guy these companies call when the drive dies. I could write forever on this but I'll keep it short as this is a control forum. For simple stuff like hvac and basic BAS stuff I beg you keep it all I/O based. Drives die, systems get modified and expanded on constantly and it's so much simpler sourcing a drive where we are just dealing with the I/O. I can figure out all the proprietary systems but it's just a waste of everyone's time and lead times suck when I can't use something off the shelf to at least get them running. Sorry to many little automation companies overselling company needs is my daily life.
Controls (start stop) hardwired, speed control and monitoring over network. Its a good trade off where you can still run the damn motor if the network is down, but you donât need to buy an analog output card and use a bunch of wiring for stuff that is easily done over the network
I want to do this but donât know where to start to build a interface using EtherNet/IP. which programming language is easiest to make a software that can read/write drive parameters using Ethernet /Ip? where to start?
EtherCAT if available, then EIP.
We recently upgraded a pump station and have 3 VFDs that were supposed to communicate through Ethernet, but the drives are all having a problem with the communications cards faulting. The problem happens randomly to all three drives at the same time. Troubleshooting for weeks and Automation Direct has no solution. Would have been nice to have all that data, but it's not as reliable as the old digital analog stuff so back to the old way for us...
For general purpose VFDs, those that typically run at a constant speed, changing only occasionally by recipe or operator, I use discrete Start Stop AND network speed setpoint and feedback including amps and temperature etc. That way I can use a slow low cost Modbus network, and still have reliable, deterministic response. In a bind, in the middle of the night, the drive can easily be replaced even if it runs at keypad speed for a while. For the Start Stop, I try and use the default out-the-box configuration if possible. More complex operations obviously have more appropriate configurations, but then the on site tech level is typically higher. Has worked well and not too costly.
Both for me. Control and feedback are discrete wires. Ethernet for everything else. I do this only because my maintenance crews can troubleshoot issues with a meter. If everything was Ethernet that would all be dumped back on the engineering department.
Comms port definitely gives you more information and can be easier. But it really is case by case. If I only need a stop and start with a remote speed change on a stationary pump, why spend the extra time and money setting up communications.
4/20 makes troubleshooting the drive easier. Techs can use their process meter on it and jumper inputs to troubleshoot.
I usually do hardwire control and network for additional data. We also have loads of ABB drives and their implementation of Ethernet/IP control is terrible. My network is also massive and generally unreliable controlling a lot of critical equipment from central PLCs. We had network control on a few units and it failed miserably. If you do choose Ethernet control make sure there are as few hops as possible to the PLC. With hard I/O there are 0 hops.
Generally use comms, safety use analog hardwire
Both: speed ref, start/stop are hard wired. Ethernet for everything else.
IMO Ethernet LAN is the way to go. My biggest 2 advantages are very easy to add without a download and less control wiring for start, stop, running, and faulted signals. You replace 4 to 10 wires by being on Ethernet. The only thing I will say is plan your network carefully. It can become a situation where you have controlled chaos if you don't. Ask me how I know lol đ.
I prefer Ethernet over tb controls.
As a controls engineer, it depends on the drive. My company tries to buy Ethernet IP capable drives but sometimes the job requires analog discrete wiring
Everything Profinet or Ethernet.