I have a 580 drive/bypass that I need to control via BACNet. I have the dive connected to the mstp bus and can see the drive in N4. I need to control start/stop and speed over the bus but unsure of the parameters that I need to set in the bypass for this control.
ABB 580 w/ bypass BACNet control
1 reading
tucsds
1 - 20 of 20 Posts
Joined
·
79 Posts
I have a 580 drive/bypass that I need to control via BACNet. I have the dive connected to the mstp bus and can see the drive in N4. I need to control start/stop and speed over the bus but unsure of the parameters that I need to set in the bypass for this control.
Joined
·
1,100 Posts
I assume the 580 is the same as the 550, but do you see both the Drive and bypass? They appear as separate devices.
https://search.abb.com/library/Down....aspx?DocumentID=3AXD50000027537&LanguageCode=en&DocumentPartId=1&Action=Launch look around page 308 (assuming you have a ACH 580-001)
https://search.abb.com/library/Down....aspx?DocumentID=3AXD50000027537&LanguageCode=en&DocumentPartId=1&Action=Launch look around page 308 (assuming you have a ACH 580-001)
Joined
·
1,100 Posts
If you don't see the drive as one device and the bypass as another something is wrong. Again, I'm assuming it's still the same as a 550. In the 550, you connected the MSTP trunk of the BMS to the bypass, the bypass acted as a router to serve up the drive and the bypass points. The Bypass would talk to the drive internally over MODbus. There is a setting in the drive to change this comm from MODBUS to BACNet, do not do this as you will break the communication between the drive and the bypass. I am did this and could then only see the bypass like you describe. I had to return this internal communucation back to MODBUS to see the drive.
Joined
·
2,696 Posts
If I remember on 550s the drive was a MSTP slave and would only show up via BACnet discovery on systems that supported salve proxy. Maybe that was just with systems I played with.
kontrol out
kontrol out
I have not had experience with the ABB 580 series drives or N4. I've had good success with setting up the controls on ABB ACH550 drives and ACH550 drives w/ Eclipse bypasses on JCI N2 and Extended Arch. Bacnet. After a cusory reading of the ACH580 Drive manual that VAEngineer attached and the ACH580 Eclipse manual now attached, the setup for the ACH580 is similar to the ACH550, but the ACH580 Eclipse manual must be used to set up the Bypass for operation. All communication wiring should be done on the Eclipse bypass terminals. The Eclipse manual covers the setting of the necessary parameters and values. You will need the MAC ID (Hardware Address , Node ID) for the drive and bypass. Also will need the Instance Number for both. Procedures are in the bypass manual to convert the Instant Number into the correct Parameter values.(If Instance Numbers are used in N4) And you'll need your communication protocols and data for the parameter values as well. As VAEngineer stated the Drive communicates with the bypass via Modbus. If that has been changed or changed and put back to Modbus, those settings will need to be checked by referring to the Eclipse bypass manual.
Joined
·
217 Posts
How many people are actually controlling the start/stop of a VFD via the BACnet communications channel? This seems like a very bad practice. We usually specify that the start/stop and speed signals must be hard wired. Too many bad things can happen when the comm trunk has issues. Just my opinion.
Joined
·
1,100 Posts
I've fought this battle and lost, the majority of people here believe like you do, but I don't see it as an absolute. Being an engineer, I realize that there always tradeoffs for every engineering solution. In this case, the idea is that MS/TP comms are not reliable enough and therefore shouldn't be allowed. To me this is an absolute statement and may or may not take into consideration all the factors needed to make a proper assessment. For instance, In an average month, how many times does the VFD get shutdown? What is providing the speed signal and is the speed signal changing (i.e. does it run constant speed or is it on a schedule or is it based on demand)? For instance, lets say the VFD is for a fan on a constant volume system that runs 24/7 and the engineer has specified that it is supposed to run at 47 Hz in order for the fan to generate a certain static pressure that was determined before hand, perhaps this might be a for Laboratory hood exhaust. Since the system would almost never be shutdown (24/7) and the speed is constant, why bother running extra wires to it to get extra reliability? You could program the speed directly into the VFD, you could also program the VFD to continue with last command when BACNet comms are lost. In this instance, lets say this hood exhaust is one part of a larger system that also controls the AHU serving the lab as well as a whole bunch of VAVs or rehat coils etc. Now supposes this hood exhaust is hard wire for start stop and speed to a controller and that controller suffers some sort of issue, be it lightning surge, bad power supply, needed a reprogram for some other system it controls and had to reboot etc. With the hardwire solution when this controller goes down, so does the hood exhaust (and most likely the AHU since those fans would be wired the same). Not good for a laboratory to loose the hood exhaust or the AHU!. Now if you are thinking of using comms to start and stop say a pump that cycles 25 times a day, you would need to perform a different risk calculation. in the last case I would tend to favor hard wire start stop, but for something that would almost never be shut off except for maintained or change speed very often than why not?
Also, you can minimize risk of comms loss in other ways, for instance, best practice would be of course to have a dedicated MS/TP trunk for each VFD, or 2nd best would be a trunk for only VFD's assuming all the VFD are same manufacturer, this way you minimize the risk of a rogue device causing a comm loss. Also possible these days to specify a drive with BACnet/IP comms. I also just posted a wireless BACnet/IP to MS/TP convertor that is all of $32. Cheap enough to be dedicated to each drive or batch of drives.
But, as far as I can tell, the biggest reason against it is time during initial setup. Using VFD's in this way means the installing contractor would have to learn how to program potentially a dozen different manufacturers VFD's. Each one would have a different screen to use to figure out how to enable it to receive start/stop and/or speed signals over comms, where the command is to "continue with last value after loss of comms", etc etc. By contrast, a hardwire start/stop and speed signal is exactly the configuration of how every single VFD leaves the factory, all you need to do is figure out which terminals to land the wires on. Hardwire proponents also point out that in 5 or 10 years when the VFD dies and needs to be replaced, the tech who comes in behind you does not need any special knowledge of the original programming of the drive and can get the system back up and running in an absolute minimum amount of time. All these things are definite advantages to hardwiring.
So is it worth it really depends on the application and the implantation. It's all about what is an acceptable level of reliability (in other words risk). BTW, Every VFD I have seen in the last 15 years all have multiple Inputs and Outputs, and the good ones are always BACNet rated as B-ASC device and have canned routines for stuff like Fan speed control, pump control, lead lag operation etc, but No contractor I've ever seen uses them in that manner. I played around on one project with wiring an Ebtron fan inlet air flow meter into the Analog input of the drives letting the drives PID loop control speed to achieve desired setpoint. We send the setpoint hardwired to another input and the start/stop hard wired as well. It has been working perfectly for about 3 or 3-1/2 years now. There is absolutly no hunting of the drives. They are the best controlled fans I have on the campus.
Joined
·
9,698 Posts
Joined
·
9,698 Posts
I tend to agree.... can you tell? Hehe
I think many of us more vocal ones have been burned by this and have a little PTSD.
We had a big shot executive specifically tell a BIG customer we were going to run EVERY drive in a chiller plant via comms. Why? Because he likes to blab about things he knows nothing about.
Only took 2 guys a few weeks to get it to work moderately well.
I personally was not involved. I made some suggestions that they appreciated after they were a week and a half into the whole thing..... I am pretty sure they spent more time than was strictly necessary, but not using comms wuda been the fastest. They specifically said (along with maybe another dozen controls guys) that pulling separate Start/stop/statuses was the way to go. Just pull the plug and do it right they said.... But the executive couldn't tolerate egg on his face... and being he is the big shot, the large expenditure on labor to make it work was apparently 'justified'.
Can it work? Sure! Mcquay sorta does it on their ahus. But it is an isolated network to 2 drives tops. Mr VA does it. Good for you Mr VA, I hope the monty python video is aright. Good for a chuckle.
Anyhow. Getting off my soapbox.
Do what you like....
Joined
·
2,696 Posts
Although not preferred when set up correctly VFD controlled via cimms is reliable enough for any situation other than mission critical. This includes how the VFD is configured for loss of comm and how the controls is programmed from command versus feedback signals.
Although it is not my preferred method I have done it. I also believe to run comms to the drive even if you are hardworking the IO. In this case I generally use the VFD onboard IO to pick up points and mitigate the use of controller IO that you are using to control the drive.
kontrol out
Although it is not my preferred method I have done it. I also believe to run comms to the drive even if you are hardworking the IO. In this case I generally use the VFD onboard IO to pick up points and mitigate the use of controller IO that you are using to control the drive.
kontrol out
Joined
·
2,439 Posts
We don't command drives over the comm bus. Seen some bad things, and don't purposely bend myself over. Just traveled to a site several hours away to look at VFD issues for a ground source loop. New customer and not familiar with the site. Get there and the guy is explaining they can't control the VFD's, constant issues. Lon comm controlled only I find. These VFD's were about 20 feet from the panel, and I look over and there is a box of 18/8 in the corner. It was like some divine intervention making me do it LOL. In about 4 hours they were hardwired, and all new points on the graphics. That was about a month ago, and they've had no problems since. Another 27 story high end condo that I took over from a out of business contractor decided the condenser loop pumps, and the massive cooling tower fans were a good candidate for lon com controlled VFD's. The drives are in the same mech room as the controllers. Like 15 feet. It makes my head spin on the critical plant stuff why and the HE** someone would do this. I have fought issue after issue on the cooling tower VFDs. I'm to the point now if they call. I say until you hardwire the things like I've told you, you're wasting your breath. This is a long way of saying don't do this if at all possible. Now I had 17 yaskawa drives commanded over an N2 bus that seem to work ok. This was the sales guy lining out the electrician prior to me getting there and conduit wasn't sized right to add more wires. Recently we did an upgrade to the AHU's, and Mr. RC slipped in some new wiring for the SF/RF VFD's to be controlled via wiring. Yep its a pet peeve for sure.
Joined
·
1,100 Posts
I got better!
Joined
·
9,698 Posts
Hahaha!
I love how patient he is as he carefully walks everyone through his nonsense reasoning.
Joined
·
2,227 Posts
If it’s an AHU the safety relay MUST be hardwired. This is a mandatory in my world, I’ve seen too many frozen coils.
I liked JCIs SA bus control of Eaton VFDs idea but only saw it implemented once.
I believe they do the same thing with York chillers and SA bus but never saw it implemented
Joined
·
225 Posts
>...but for something that would almost never be shut off except for maintained or change speed very often than why not?
You answered your own question. Almost never changes. There always are COV easter eggs in a vendor's implementation. Some devices will run on happily for weeks without being written to, some devices will relinquish that priority if unwritten to within a period and some devices will fail silently and statistics then breaks that data exchange on both your (controller) and the vfd's end. Pref here is to hardwire and pull in & trend extra data through BACnet interface.
Talking ABB they're trustworthy enough to control via BACnet interface. Biggest problem in doing so here is I've walked into enough sites when some electrician has replaced my ABB with a cheap VFD, tells customer they have to run VFD manually and I then look like the as$hole because I now have to sell him a new controller to pick up the points + time & parks to tie it in because someone thought they could save $1k.
You answered your own question. Almost never changes. There always are COV easter eggs in a vendor's implementation. Some devices will run on happily for weeks without being written to, some devices will relinquish that priority if unwritten to within a period and some devices will fail silently and statistics then breaks that data exchange on both your (controller) and the vfd's end. Pref here is to hardwire and pull in & trend extra data through BACnet interface.
Talking ABB they're trustworthy enough to control via BACnet interface. Biggest problem in doing so here is I've walked into enough sites when some electrician has replaced my ABB with a cheap VFD, tells customer they have to run VFD manually and I then look like the as$hole because I now have to sell him a new controller to pick up the points + time & parks to tie it in because someone thought they could save $1k.
Joined
·
187 Posts
Some Carrier units control VFD via Modbus and take that data and output over BACnet. The VAV units with SystemVu. Kinda neat.
Personally I like the speed signal to be hardwired, especially something like fan speed. VAVs can move too quickly and the fan needs to slow down faster than BACnet write speed. I guess you could do a COV thing but it gives me a weird feeling. I'm more okay with start/stop being written over the network, since realistically that happens once per day. As bigguy said, there should still be an electromechanical safety shutoff. I like using BACnet to pull data like speed feedback, fan status, power usage, etc.
Personally I like the speed signal to be hardwired, especially something like fan speed. VAVs can move too quickly and the fan needs to slow down faster than BACnet write speed. I guess you could do a COV thing but it gives me a weird feeling. I'm more okay with start/stop being written over the network, since realistically that happens once per day. As bigguy said, there should still be an electromechanical safety shutoff. I like using BACnet to pull data like speed feedback, fan status, power usage, etc.
Joined
·
9,698 Posts
This is correct, but a detail often overlooked (not you necessarily) is that the comms running the drives is isolated. It is the 2 drives and that is it. Makes for a much lower risk scenario. Maybe I am thinking of McQuay units with the isolated modbus trunk for the fans.... anyway
I had a site where they sold the customer to install a bunch of gateways to get those drives onto bacnet for visibility only. No functional improvement whatsoever. They asked me to do it and I refused. Said 'I want no part of that. You dont run your fans that way reliably'. They kept saying 'but these are already talking. There is no difference!'... They told me I was being stubborn...
Anyway, the job went way over on hours because the existing system had comm issues that were taking down the supply fans intermittently as what was happening on the broader system was interfering with the fans.
I didn't look so stubborn after the job.
Joined
·
788 Posts
McQuay definitely does it that way. Works great, unless you want to replace the drive. Then you are stuck getting same exact make and model which means more expensive and longer lead time. I had a Daikin MAU with a bad VFD. It was a danfoss drive, so I figured I would call Danfoss and order the equivalent and be on my way. Danfoss would not confirm that the McQuay branded drive could be directly crossed to a non McQuay branded drive for purposes of Modbus comms. It probably would have worked, but they told me I had to order through McQuay dealer. I had the equivalent drive on the shelf, but ended up waiting 5 weeks and paying almost 50% premium.
1 - 20 of 20 Posts
-
?
-
?
-
?
-
?
-
?
-
?
-
?
-
?
-
?
-
?
-
?
-
?
-
?
-
?
-
?
-
?
-
?
-
?
-
?
-
?
