[FUN] Variable Speed Drives and Motor Controls

[Stephen Mitschke]

Ian, if you think these questions are of general interest, I would be very interested in the feedback.I have been working on a number of potential FF applications for a semiconductor plant. There are several applications which call for Variable Speed Drive (VSD) controls. Also, there are several applications which involve starting and stopping pumps. In most cases, the control originates from standard process variables: pressure, temperature, level, flow, etc. We developed a number of this type of application during our studies for the Application Profile Team (APT) last year. Then today I get a call from a water and waste consultant complaining how difficult it is to control pressure and flow with a VSD. From many discussions, I believe there is a need, but the manufacturers can not move until they see the demand.My personal preference, if the drive manufacturers to do act, is to have an H1 port on the VSD. Some express concern about band width on H1. I do not see this as a problem when we are controlling temperature, pressure, flow and level. H1 has more than adequate response and it offers a much simpler, and therefore more robust solution. Of course if we tried to bring all the contained parameters back over H1, there might be a problem. But from what I have seen on Modbus systems, the operators are happy with about 20 parameters in total. (This may be the integrators - think of mapping 1500 parameters from each of 200 drives.) HSE is the alternate but it presents several complications and additional cost factors and it should be redundant, if reliability is an issue. Two questions on the VSD:1. Are there others who see a need for VSD control? 2. Do you have a preference for H1 or HSE ports on the drives? The ON/OFF motor control is another area where FF could offer a good solution. The APT looked at this as a possible Flexible Function Block (FFB) application. There is also a defined and tested Advanced Function Block, the Device Control (DC) which comes pretty close, but I cannot find it. I would visualize the DC or FFB deployed in a field device similar to the Smar FR-302. Keep wiring to a minimum. The DC includes interlocks, permissives, timers and all those good things. I believe there is also a need for a motor current feedback. We usually put a current doughnut and a current relay, even on small motors, to confirm operation. With FF, this could be an analog input, motor current, with more information for the operator especially at commissioning time when you find, or do not find, an undersized fuse. A latching relay option is also desirable for those applications where you want the motor to return to last state after a power outage. Lastly, what function block should be used to switch the SP of the controlling function block, the DC, the FFB or the FR-302. The Alarm Function Block is not designed for discrete control. Is there one that is? It can be done with an FFB, but not right now.Question: Do other people see a demand for ON/OFF control?The VSD is a project that can only be resolved by the drive manufacturers. The ON/OFF controller is a control or FFB manufacturers' project. Do we have enough need to encourage these people to provide the solution? David Hobart, P.Eng.Senior Associate Sterling Valley Associates

[Stephen Mitschke]

At our Plant, we have numerous VFD's with differing protocols such as Modbus and Profibus. These range up to 12,500 horsepower. While these may work well, the need for FF should be part of any manufacturer's mix. My boss thinks the sun rises and sets on DeviceNet and has pushed this in a large way. DeviceNet does not have the segment control capabilities FF does. When DeviceNet crashes, it needs to be manually re-started.For any advanced control scenario, data exchange becomes more important as component criticality increases. Therefore the decision to go to H1 or HSE becomes a concern for bandwidth.Gerry Reynolds,Suncor Energy Inc.------ Original Message --------There are excellent reasons to control flow with a VSD rather than a control valve. VSD's don't stick (develop hysteresis) and are not subject to bad instrument air. They work quickly and provide lots of feedback on their performance. A smaller motor/pump will be necessary when the variable head of the control valve is removed. Positive displacement pumps work best with VSD.Now the drawbacks: VSDs are expensive compared with contactors in a MCC (Motor Control Center). Centrifugal pumps are not at all linear with speed vs. flow, and no pump supplier publishes this kind of curve. Centrifugal pumps operate efficiently over a very narrow range of flow and head. From my previous studies, this limits their operating range to a maximum turndown ratio (maximum flow/minimum flow) to about 3:1. Not too bad, but not the 100:1 we normally expect of a flow control loop. ON/OFF or bang-bang control is the most widely used feedback control algorithm. Properly implemented, it should be offered on any control system. Proper implementation requires tunable deadband and anticipatory control. Many suppliers of 1/8 and 1/16 DIN panel controllers even offer adaptive control for their ON/OFF controllers. Why should Foundation Fieldbus do less?Dick Caro ============================================ Richard H. Caro, CEO CMC Associates -----Original Message-----From: russell.mackenzieSent: Tuesday, April 29, 2003 6:38 PM1. yes. I have asked for it for ages. Profibus do it already, so how hard can it be? it is a stumbling block for our electrical engineer too.2. don't know. h1 sounds more adoptable. HSE sounds just as easy using standard ethernet hubs/switches etc.start stop: most of our drives are just non variable, so yes, it would be very nice for a 2 wire solution.

[Stephen Mitschke]

Other than the fact that DeviceNET will not integrate with Foundationdirectly or on a network there may be a number of other reasons that otherson the list may wish to share.There is also the problem of 'mapping' the registers to the correctregisters in the host, thus preventing plug and play but I will let otherspost their pro's and con's as well.Ian-----Original Message-----This may be seen as a contraversial response but ... why not use what is already available - DeviceNet?Some of the DCS Vendors already provide a DeviceNet interface for communications to the "Electrical world". Many VFD controllers already come with a Devicenet port. I would envision a solution where the process measurement is accomplished via Foundation Fieldbus, the control algorithm in the process controller module with the resulting output then communicated from the processor controller module via the DCS Devicenet interface out to the VFD drive.This would allow one to utilize the more "feature rich" algorithms and control languages avialable in the DCS. The interlocks could be implemented, operator interface/interactions, and even additional process interlocks. I believe that this may provide a better control solution than attempting to fit this within the framework of Foundation Fieldbus.An additional item - in the testing I have done, Devicenet is more robust to noisy environments (electrical noise) than is Foundation Fieldbus. VFD's are prone to high electrical noise (harmonics) depending on the control circuitry. I do not believe that Fieldbus would give the robust performance that one could achieve with Devicenet. If you are curious, put the VDF drive output to the motor in tray cable next to a Foundation Fieldbus cable (Type A cable) and also next to a DeviceNet cable (Class A round). See which one works better (or even works from my testing experience - we even had a 12 inch cable center to cable center separation).My opinion only - correct tool for the correct application.CheersGlennShell Canada

[Stephen Mitschke]

Without wishing to be too commercial.DeltaV was designed to do exactly this - use the appropriate tool for thejob - DeviceNet , Profibus DP , AS I , Modbus , Foundation Fieldbus , and doit in a manner that allows for plug and play wherever possible within theconstraints of the protocol.The integration can occur in the controller with data from ALL the aboveused in a single control strategy if desired , or alternatively use theappropriate bus (DeviceNet or Profibus DP) depending on world area , withoutchanging the control strategy. Register Mapping in the traditional sense isnot required.Gary LawDeltaV Product Manager -----Original Message-----I agree with Glenn's thoughts, and in fact our current design for a newtreatment facility employs FF devices as the primary element communicatingto a DCU where the PID is executed. The output is "mapped" to a VFD onDevicenet. While it may have been nice to have both elements exist on thesame H-1, since there was no vendor availability on the FF VFD's we wentDevicenet. I think there is some added benefit that at least one half theloop is executing at 500kbps versus all being on H-1. Otherwise, like Imentioned, Devicenet was widely available when it came time to "short list"qualified drive providers. Ian's correct, it's not just plug and play, andwe've come to realize the issues on that subject, but I think it's going tobe similar to version management for FF devices when it comes toupgrading/replacing devices in the future (potential to "remap" withDevicenet device)....just a few thoughtsJay KalinowskiOCWD

[Stephen Mitschke]

There seems to be some misunderstanding on FF H1 bandwidth, and why FFhas gone to great lengths to distribute control into the field. I willattempt to clarify some of these misunderstandings here.FF has several different types of communication. Each type has adifferent priority. I will not go into all of these here, but insteadjust look at 2 of interest to this topic. One type is read/writecommunication between a server(usually a field device) and aclient(usually a host or DCS). The other type is publish/subscribecommunication between two peers(often two field devices, though hostscould be involved also). When setting up an FF network with a devicethat possibly contains large amounts of data, one has to look at thetypes of data involved when assessing bandwidth. The vast majority ofthe data in these devices will be data that is written or read across aclient-server connection, and is not time critical to the control of theprocess. Any data coming from the device or going to the device that is timecritical should be transferred using a peer to peer connection. The peer topeer data has the highest priority, and should the bus becomebandwidth limited due to other communications such as the client-serverdata, the peer to peer communication is still guaranteed to occur at theappropriate scheduled time. Furthermore, FF also has mechanisms to reducethe client-server communications thus reducing bandwidth issues.I won't go into these here but some of the mechanisms include view lists andstatic revision tracking.As to the issue of using one device on one type of network (sayDeviceNet) and using another device on FF, the results can be poordepending on your needs. Systems such as DeltaV do a nice job ofintegrating different network types for the user. And if the data goingbetween the networks is not time critical, there usually is not anissue. But, FF has distributed the control to the field for a reason."Distributed Control Systems" can have large latency issues. The time ittakes to get data from a DeviceNet device to an FF device can be large,not due to any bandwidth problems on DeviceNet or FF, but due to thedata having to be shuffled through the DCS. Obviously there are timesyou want to do this, but FF was designed so the control data does nothave to go through the DCS. The control data can be sent directlybetween peer field devices at the exact time configured, thus removingany latency issues with the DCS.So, the bottom line is, when it comes to control, bandwidth is notreally the question. The question is really latency. And FF solves thelatency problem that other device networks and control systems cannot.--Tom BoydVP, EngineeringFieldbus Inc.

[Stephen Mitschke]

I don't know if there's a misunderstanding about bandwidth, and I agreeideally you'd want primary and final control elements on the same segment,but so far, relative to VFD's anyway, for the manufacturers that provide theVFD functionality that we need NONE of them offer Fieldbus as acommunication option. In years to come that will hopefully change....Jay Kalinowski

[Stephen Mitschke]

Is a VFD a final control element? If so, it will be replacing control valvesin the "NEW" plant. If this is the case the VFD becomes both an electricaland Instrumentation device. Communicating with such a device for bothcontrol and information requires more than one communication method. E & Icontinue to fight rather than get consensus.Gerry ReynoldsSuncor Energy

[Stephen Mitschke]

I agree with Tom and may be able to add some additional points.Several modern system (including SMAR's SYSTEM302) have interfaces forvarious buses which may not need mapping in the traditional sense, butmapping in some sense will still be required to fully benefit from thecapabilities in a drive. The list junkies that are on the "Alist" may recallthe topic "Cost of intelligent MCC's vs hard-wiring" back in November lastyear regarding hard wiring or buses for drives.http://www.control.com/1026161498/index_htmlBy plopping in an interface card you get relatively easy access to cyclicdata such as writing the desired speed/frequency. However, accessing thecomplete set of configuration parameters such as V/F and diagnostics etc. isanother story. Why? Because bus technologies like Profibus andDeviceNet/ControlNet does not have an equivalent to DD (*see explanatorynotes far below) so its not really feasible. The only way to get full dataon the screen is to develop device specific device pages that access theadditional data and puts it on the screen. A daunting task if you want tosupport all DeviceNet and Profibus devices. Even doing it for just one typeof device is more than what most users would want to do. I think all thathave used FF agree that just scanning I/O is no longer sufficient, we wantfull device access.I think a Siemens drive displays all data well on a Siemens host and aDeviceNet/ControlNet drive on a Rockwell host, but if you mix brands it willnot go so well even if they use the same protocol, due to the lack of DD. Inmy view, FF can come in and solve a big interoperability problem here.Technically FF can achieve full access to any drive on any host.By combining two buses for a loop the centralized controller must be usedfor the translation. Since the loop cannot be closed on the H1, you nolonger have single loop integrity. Redundancy of the controllers etc. wouldbecome an issue.I think the FF function block diagram control strategy programming language(IEC 61804) has some very rich features such as status and mode which willget lost if other bus technologies or proprietary programming languages aremixed in the loop. Today, thanks to status, a thermocuple failure will sendthe control valve to a failsafe position without me having to make anyinterlock programming whatsoever. The status is detected by the AI block andpropagated through the PID block to the AO block where the action occurs.This interlock is built into the blocks and I get it for free just bybuilding the PID. Similarly, I get the reset windup protection if somebodytakes control of the final control element (e.g. from the local panel in thedrive) or a limit is reached - this is propagated backwards up a multi-levelcascade. No other bus technology or control strategy programming languagedoes this for me.Some good points regarding mixing of buses can also be found in the prefaceof the new edition of Bela Liptak's Instrument Engineer's Handbook, volume3. I based the opening for my paper for the 2003 FF General Assembly on thisissue (and then on to HSE).http://www.fieldbus.org/generalassembly/hsepaper.pdfI quote the introduction here for your convenience: "Tower of Babel: In anew plant, it may be tempting to include many different field-level bustechnologies to accommodate the different device types, and marshal them tothe common controller network. However, it should at this point be said thatalthough most systems today have interface cards or gateways to several ofthe plethora of different buses that exist in the market, the host softwareinvariably is targeted towards one particular bus. This one bus is supportedvery well, whereas for other buses only cyclic I/O scan is possible whiledevice parameterisation is poorly supported requiring third party tools.Managing a system with many different bus technologies is an exercise incomplexity in terms of training, engineering, and support etc. The costs mayoutweigh the benefits of using bus technologies. The preface to the third edition of the Instrument Engineers' Handbook, by Bela Liptak, uses IEC 61158as an example of the dangers of combining bus technologies that areincompatible with each other in a plant: "This is like expecting to run aplant from a control center in which eight operators might speak eightdifferent languages". This standard of many incompatible buses has beencalled names such as "the gang of eight", "the eight headed monster", and"the penthouse in the tower of Babel". Rather than adding one bus technologyafter another into the system, engineering efforts should be focused towardsusing a single bus technology, FOUNDATION(tm) Fieldbus, in its H1 and HSEflavours. For example, instead of using a low-level "sensor" type bus fordiscrete I/O, consider a remote I/O device connecting to H1. This has thebenefit of embedded logic and single loop integrity as the interlocks are onthe H1 bus without going through a centralized controller."A Modbus to HSE gateway already exist as a solution for Modbus drives.However, a native FF drive would be better.Jonas Berge==================www.smar.comNotes on description of devices on other buses:DeviceNet/ControlNet has a supporting file called EDS and Profibus has itsGSD file. However, these are not equivalent of DD because they only explainbasic communication settings and cyclic parameters (scanning I/O from aremote I/O subsystem, writing speed to a drive). They do not completelyexplain all the acyclic data in the device (setup, diagnostics, calibration)like DD does. Profibus has some other mechanisms for this, namely Profile,EDDL, FDT/DTM and another scheme for PROFInet. EDDL is similar to DD. Theproblem is that different Profibus host vendors support different schemesand no device supplier provide files for all schemes so at the end of theday it is not really possible to get all data from all Profibus devices. Ithink I can say that the systems that support FF and Profibus do not supportany of the above four schemes, and for sure does not support all of them.Therefore users are usually limited to only cyclic data.