Variable Speed drive with ControlNet interface

Hi all, As far as I am aware there is only Rockwell drives with ControlNet interface. Has anyone else used any other VS drive with ControlNet
interface? I know that many drives are available with DeviceNet interface.
Although ControlNet offers higher speeds (5 Mbits), for a majority of pump and fan applications, DeviceNet is more than adequate. Unless the application requires a servo drive, I cannot understand why ControlNet interface is required for a VS drive.
Any comments and or suggestions on the above observations are welcome. Thanks and regards, Raj Sreenevasan
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

interface.
Having had several nasty experiences with ControlNet, I, personally, would not recommend using it for drive operation (not if you want reliable operation anyway!). Maybe this is why other manufacturers don't offer it? DeviceNet has issues also, although I agree with you that it is more than adequate for almost all drive applications and there are plenty of manufacturers happy to provide the interface.
With all of these networks, you'll find that bit-speed means nothing - it's the actual data transfer rate that's important. I suspect that, for a servo drive, a dedicated motion card using something like SSI would be faster than ControlNet simply because it's a point-to-point link with no need to allow overheads for other network traffic right in the middle of a critical move.
If you must use comms to a VS Drive, my suggestion would be Profibus.
JM2cW, Cameron:-)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Folks, Our Client (The End User) has specified networked drives as site standard but with E3 Plus relays (A-B) you get only DeviceNet interface, whilst the VS drives are offered with ControlNet interface. Hence the reason for my question this morning.
I have since then found out that ABB's ACS800 drives are available with ControlNet interface. One of the explanations provided by Rockwell person is that a 1788CN2DN acts as a single node on the ControlNet network (with over say 30 E3 Plus relays hanging off at the DeviceNet end). Since the end user has accepted and specified ControlNet, I will go along with it (My uneasiness has been some what reduced by the knowledge there is an alternative to Rockwell drives).
Cameron & Jake, Thanks for your comments. Regards, Raj

pump
it's
servo
than
move.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Raj Sreenevasan wrote:

Raj, how long do you envision this drive system lasting? Five years? Ten years? 20 years? Think about the state of the art back then. Do you really think that an industrial net has enough staying power to leave such a thing in place? Even if it did, it would morph and probably present some incompatibilities. We're already seeing that with Profibus.
I would use a 4-20 mA current loop to control it. It is as close to being a fundamental standard as anything gets.
Of course, if you don't envision this drive having that kind of longevity, then by all means put someone's network in it.
As for Cameron's suggestions regarding Control Net, your experience may vary. Our company uses both Control Net and Profibus. We don't seem to be having too much trouble. Yes, Rockwell has a version control problem going on here. It is worse than some, but not the worst I've seen. And as far as I'm concerned, it's no worse than Profibus. Industrial networks take some tweaking to get them to work. Welcome to reality.
Jake Brodsky
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

should a modern industrial network be brought to it's knees by a "version control problem"? Even Rockwell don't know what's going on! :-( ...oh, and try bumping one of the network connections on the scanner (as one of our commissioning engineers did recently) and see how long it takes to restore comms... several *minutes* perhaps?? </rant>
After finding this out the hard way, it is now company policy that we do NOT recommend ControlNet to customers. To be fair, Devicenet had similar issues when it was first released (EDS file issues mainly), but this sort of carry-on is not acceptable at any of the plants we work in.

Begs the question: What's the worst you've seen? :-)
Cameron:-)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Cameron Dorrough wrote:

How long ago was this? The earlier major releases were a problem. We still occasionally encounter some version hate with some firmware more than two or three years old. However, the new stuff seems to have this under control. As for rejoining the network, that's not usually a problem for us. We try to ensure the physical media is hard enough (fiber optic) and protected with battery backed 24 volt power systems so that this won't be an issue. And in any case, we're talking about large water utility and waste water utility work here. Nothing moves that quickly in this application.
In fairness to AB, most networks are far less complex than what they attempted with ControlNet. I think they bit off more than they could chew, and the result wasn't pretty.

Most of my hateful problems were media related.
Some of the earlier TI-500 I/O networks which used a cable TV-ish interface were pretty difficult to work with. The problem was trying to explain to the folks who were designing and installing it all about the ways and techniques with RF (I have a radio background too). The manuals left everyone gasping in efforts to understand what they were supposed to do. They should have just said what it is and what it was.
I can recall intermittent RS-485 networks which didn't work at full speed (a blistering 56 kBPS!). The problem was that occasionally the duct bank would fill with water. Although the cable was installed with no splices through that duct bank, it had a polyethylene jacket. I spoke to Belden and they patiently explained that polyethylene can absorb up to two percent of its weight in water --and that's enough to change the capacitance per foot quite drastically.
But the worst is/was Modbus. How many flavors are there? Thirty one at last count? And yet we can't seem to get past explaining to people that Modbus is more a state of mind instead of a protocol. My favorite rant about Modbus is that it's the Cockroach of Protocols. It was first. There are many species of it. It will always be lurking in the corners somewhere, but it will never evolve in to something better than what it currently does. The only reason it continues to get perpetrated is because there are so many tinkerers who think they own it and understand it.
Jake Brodsky
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

"version
and
restore
Six months ago. After wrestling with the original setup (comms between two processor racks) for several days "resetting the keeper" and so forth and finally getting it going, out of the blue Rockwell gave us some obscure warning that the comms would crash after thirty-something days if we didn't update the firmware - right now! The lastest release supposedly fixed the problem (taking Rockwell 2 man/days to get it going, though - ie. one entire day of lost production) and I haven't heard anything from site since. As long as no-one touches it, it should work fine... touch wood. But never again.

Lucky.
Agreed. Actually, I haven't had too many problems with Modbus - using only Modicon equipment of course and avoiding all other flavours like the plague! ;-) The best I've come across lately is Modbus/TCP for high-level comms between Citect and Schneider PLC offerings - apart from short startup delays, no problems at all (once you get your head around the addressing) and best of all... NO stupid "version control problems" to worry about - as it should be! :-)
Cameron:-)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.