What is DeviceNet?
Vložit
- čas přidán 26. 06. 2024
- ✅ C'mon over to realpars.com where you can learn PLC programming faster and easier than you ever thought possible!
=============================
✅ Check out the full blog post over at realpars.com/devicenet/
=============================
In this video, we will take a journey through the automation world of DeviceNet.
DeviceNet is an application-level protocol used in the automation environment.
It is a communication tool that allows you to logically talk between a PLC (Programmable Logic Controller) and many control devices, such as motors, conveyors, flowmeters, level sensors, etc.
DeviceNet was originally developed by Allen-Bradley which is a Rockwell Automation brand, and they decided to share this new technology with others and make it an open network.
It is now managed by Open DeviceNet Vendors Association (ODVA), an organization that develops standards and allows third-party vendors to utilize the network protocol.
=============================
For additional information about the DeviceNet protocol please refer to the following website:
www.odva.org/
=============================
Missed our most recent videos? Watch them here:
realpars.com/modbus-protocol/
realpars.com/pid-controller/
realpars.com/modbus/
=============================
To stay up to date with our last videos and more lessons, make sure to subscribe to this CZcams channel:
goo.gl/Y6DRiN
=============================
TWEET THIS VIDEO ctt.ac/6bene
=============================
Like us on Facebook: / therealpars
Follow us on Twitter: / realpars
Follow us on LinkedIn / realpars
#RealPars
Original DeviceNet dev team member here (spec coauthor, device profile concept creator). It's heartening to see how DNet has been adopted around the globe and how it's still being nurtured by real professionals like the RealPars team. Great video.
Hi Patrick, thank you for taking the time and watching this video. We are so delighted to get such positive feedback from an original DeviceNet dev team member.
Thanks for the awesome work!
How the hell you created something so hard to work with? It's a real headache!
@@jrdz009 Chill bro...those days ere very limited..nowdays no one will prefer device-net anymore
What a fantastic video! All needed areas covered and well treated. Thanks!
Thanks for your support!
Deeply appreciate the clear conceptualisation.
Thank you!
As usual, very insightful. Thanks Real pars!
Thanks for your support David! Happy to hear that you are benefiting from our courses. Have you also followed our free PLC Hardware course? realpars.vhx.tv/browse
Happy learning!
Terminating resistors are to suppress signal reflection. Proper shielding is supposed to reduce electrical noise specifically in voltage signal (potential)
Thank you very much.This lesson is very perfectly as the other lessons.(ın İstanbul)
Thanks for your positive feedback! Happy to hear that.
As a battle-scarred veteran of DeviceNet on the Rockwell platform, let me give everyone a free piece of advice. Avoid it. Avoid it at all costs.
Here is a list of problems that you may (and probably will) experience at some point:
1) Cabling issues. Usually fixed by unplugging the bad joint and plugging it back in. The downside however, other than the obvious interruption of the equipment and processes using it is: a) Which connector is the "bad" one? b) Does it happen to be that connection 30 feet in the air located over the oven? (or in some other inaccessible location?).
Some cables are better than others (or more correctly, some cables are worse than others), the DeviceNet thick cables usually do okay, Control Boss on the other hand is terrible (bad connections up to and including one that melted down on us).
So how do you find a bad connection? One approach is to disconnect and reconnect every last joint in the system. Might fix it, might not. My approach was to disconnect power and disconnect the resistor at one end and place my ohmmeter there. Now you should see 121 - 124 ohms of resistance. Anything more than that and you are going to have problems. To find the bad joint, have an assistant break the network in the middle and place a terminating resistor there. If you resistance came down to the 121 - 124 level, you know that the bad joint is further down the network, otherwise work your way up closer to your meter.
2) Voltage drop for your power. After several hundred feet your 24 volts ain't gonna be 24 volts anymore. More along the lines of "too low to operate properly any longer". This can be fixed by adding an inline power supply though.
3) Signal degradation. This one is a biggie, hook up a scope to a troublesome DeviceNet network and you will see what I am talking about. The signals are all over the place, how it ever works is a mystery to me. And don't expect to see the pretty textbook waveforms, if that was what was going on in your network you wouldn't have needed to hook up a scope in the first place. One of the weird things you will see is nodes that offset their signal up by a volt or so effectively making the CANH higher, and the CANL higher as well (which isn't a good thing).
We mitigated the noise problem somewhat by building a cheap filter network that we stuffed into a field termination connector. It consists of two 60.4 ohm resistors (yes, you can buy a 60.4 ohm resistor: www.digikey.com/product-detail/en/yageo/MFR-25FRF52-60R4/60.4XTR-ND/14774) in series with a 22 nanofarad cap connected to where the two resistors combine, with the other lead of the cap tied to ground. You get about 3db in noise reduction. Further details are on the web, that's where we got it from.
I suspect that Rockwell might of made a poor decision in selecting their DeviceNet transmitter chips. They seem to have their slew rate set to around the 1 Mbs range which is faster than necessary (and can lead to ringing in the waveform).
Okay, so that's some of the problems you might experience with cabling, on to hardware.
1) DeviceNet is going away. Get used to shopping for parts on eBay if you plan on using it.
2) Firmware revisions, and why a drop-in replacement usually won't work. So your spiffy input block bit the dust and you grab a new one from stores and slap it in. Good to go, right? Wrong. If you have electronic keying set to its most restrictive level (or even the intermediate setting if the firmware rev level difference is large enough), your scanner isn't going to let it in on the network. So break out RSNetworx for DeviceNet and get to fixing it. Be sure to not mess up your scan list when you do it though. Eventually you will, and then you will see what I am talking about.
3) Same as item #2, but now you need an updated EDS file. Go have a look at the EDS file repository on the Rockwell site and see if that doesn't crush your soul. It does mine. So many thousands to choose from and usually none of them work.
4) Same as #3 except now you need an EDS file from the vendor for an outdated piece of hardware. Good luck with that.
And I would be remiss if I didn't save a special place in my -rant- heart for RSNetworx for DeviceNet. I tried to get the guys from Rockwell to build it into RSLogix. That would have solved many of its problems if the user could add the block and define its bitmap in one place. But no...
1) So RSLogix for DeviceNet has had some bugs over the years, and if you work for a company that locks down the programming workstations (say for example, General Motors) you may find that you are not keeping up with the times. Therefore you probably won't be able to program that spiffy new block (one version of Networx omitted the "Okay" button for accepting and loading your new configuration to the node. However, hitting the "Enter" key still worked). Is this a DeviceNet problem? Not strictly, but does that matter when you get home several hours late because of it? It tends to blur the lines somewhat.
2) Goofy mapping. You can overlap your map on top of itself. We've done it. And remarkably, you can get replacement blocks that require you to remove part of your mapping to get them to work (I can't remember what block that this was on, but we had just about every engineer in the place out looking at it that day).
What's humorous (or makes this topical) is that I was just out to lunch with an old partner of mine that just hired on with our company last Thursday. On the way back from lunch he gets a call from a tech at Nissan asking for help on a VIN etcher that was connected to a DeviceNet network. Specifically, it was the *only* device connected to that network (besides the scanner), and it still had to be reset constantly.
Thanks for the info i am so desperate at my devicenet network always having busoff deteced
@@brianbeebee1731 In the early 2000's when GM first began to adopt DeviceNet I could see what a hot mess that we were getting ourselves into. I wrote an email to our section leader in the (un)Common Controls Group and gave him my opinion that DeviceNet wasn't ready for prime-time (IMHO it still isn't), and it would be irresponsible to use it in our factories.
He got his nose out of joint when I told him that not only was DeviceNet ill-suited for a factory floor, but their "Common Controls", while working nicely for equipment in the Body Shop, didn't work so well anywhere else. I ended the email telling him to think "PLC" not "PLC++".
At that, he demanded an apology, or he would have my job. He got neither. I retired in 2015, and have come back upon occasion for project work. On the other hand, there's not too much interest at GM these days in expanding DeviceNet networks. Nor did he last all that long as a section leader...
In any case, my advice fell on deaf ears, and GM is still paying for it.
So why all the vitriol over DeviceNet? Well, let's take some other I/O networks into consideration. Just the ones that I have had personal experience with:
Data Highway+ Remote I/O: Pretty old, but nearly bulletproof. The last problem that I had with it (around 2015) was when the boss, who wasn't exactly solid in electronics, said: "We don't need terminating resistors". In this case he did.
GE Genius I/O: Old as well, but even more reliable than DH+. The last time that we had a problem with it was when an electrician inadvertently left the terminating resistor off when he demoed out one of the presses. The other time was when the production dumped their excess plastic from the injection molder on top of the cable. Sorta melted it.
As a side note on Genius I/O, it had a nasty habit of popping you with high voltage from time to time. Not often, not dangerous, but always annoying.
Modbus: What can you say? When the heat death of the universe eventually occurs, all that there will be left will be cockroaches and Modbus. The bad thing about Modbus is that companies get pretty loose with the specs and manage to make what is probably the most open of all protocols out there somehow manage not to work.
EtherNet: Once you get BootP to work on your PC (have fun with that), and when the Field I/O modules finally settle down and decides to accept (and retain) your IP address, it's just fine.
For perspective, I could take all of the problems that I have had with these networks from the 30+ years that I've been an engineer and they would total up to about the same amount of problems that we had every six months or so with DeviceNet at GM.
@@maintenanceguy2479 Just saw this. Did you get it fixed?
@@brianbeebee1731 The worst thing about Genius I/O was that horrific cable that GE specked for it. Remember that junk? Early on, there was a problem with Genius blocks going to sleep (or dying) on you. Pretty rare though. And for very old Series Six systems your Genius Bus Controller could fail on you (most likely only needing a re-cap).
The thing with ControlNet, was AB using an Ethernet connector rather than designing their own. This led to more than one device getting blown up.
GM had a strange policy concerning Ethernet I/O. There was *one* guy up north who banned it, saying: "As long as I work for here, there will be no Ethernet I/O at GM". That's pretty much a direct quote BTW. So GM got on the Ethernet I/O bandwagon rather late compared to other companies.
The funny thing was that we had Ethernet I/O in our paint mix room long before he was ever in the position to say such a thing. Never had a problem with it. :)
@@MrWaalkman yes sir thanks for the info you shared it really help me a lot to overcome our devicenet problem thank you so much sir.
THANK YOU,very informative
You are very welcome, happy learning!
A couple of things I want to mention here. The maximum number of node address may be 64 but you will rarely if ever be able to achieve that number. Cable length restrictions and data throughput will generally limit you considerably. I generally shoot for about 24 node addresses per highway. However, if you're required to have a highway that is intrinsically safe, the number of nodes and main trunk maximum length is greatly reduced to 10 nodes and 100 ft.
Also the terminating resistors are designed to make the data highway "look" like it's infinite in length as far as the electrical signal is concerned. That is to say an electrical signal propagating down the highway never returns. Unterminated highways can allow electrical signals to reflect back onto the highway creating ghosts of messages to appear when the electrical signal hits the end of the wire. This can cause a lot of problems and make it hard or impossible to get valid messages through. This can also happen to a much smaller degree if your trunk and drop lines have orphan strands where they terminate at terminals or connectors. We generally buy pre-made cables to help alleviate this problem. You can get custom length cables pre-made for you if you have the time and know the length.
Hey Ryarios, thank you for the explanations.
Yes, it is absolutely correct that you may not be capable of using the maximum cable length and nodes in DeviceNet and depending on the circumstances it may differ from one network to another. Using the terminating resistors is inevitable as it has revealed in this video.
Sir Thanks for your Efforts 👍
You are very welcome!
the explanation is too good
Your videos are perfect!
Thanks a lot! :)
Excellent my friend
Thank you, Juan!
Muchas Gracias, por el video.
De nada, Edson!
Excellent video, I will share the link on my social networks.
Thank you!
I like how you explain it so easily
Happy to hear that!
Expertise is not just know how but make it SEAM easy 😏.
Great job as always
super sir thank youu
You are very welcome!
Great presentation
Thank you, Faizal!
thank u
thanks you so much
You're very welcome!
Good job
Thank you!
the courses in the web are only for siemens?? do you teach allen bradley ???
Hi Rucawave,
Thanks for your comment!
We mostly focus our course videos on Siemens, we do have a couple of course videos on Allen Bradley.
We are planning to add more courses to our Allen Bradley section in our course library, but we do not have any of those courses scheduled yet.
Feel free to have a browse around through our course library to see which topics we cover at the moment. bit.ly/30ZrxWq
Let me know if you have any other questions.
Happy learning!
Got a complicated problem with one of our machines using DeviceNet. Im kinda new to this but what happens is that we have several nodes in the machine including a staübli 6axis robot. For some reason when the (deadman's switch) or servo motors recieve power it knocks all of the nodes off like they are loosing connection. If we exclude the robot in the equation the nodes doesnt fault. Even with an external power supply to the robots modules this happens. Does anyone have any idea what to look for here? Have tested all the other nodes as well but works aslong as the robot doesnt recieve power.
Thank you RP so much for the good quallity material. The far right device in 7:30 looks pretty much like an IO Link master. Now that I think about it DeviceNet, IO Link and ASi-Bus work pretty much the same way: that is in the field level, are open sandards, they use an independent or special power supply (at least IO Link and ASi), theres a flat cable abailable for installation of perforating conexions (DeviceNet, ASi), and other very similar accesories in common can be used. Not surprisingly there must be also many differences between them
Thanks for sharing your knowledge with us, Erick! We appreciate that.
I o link is a scam, the aoi blows up your memory. People should just use devicenet
As always, you get top notch controls knowledge from realpars more than anywhere else. Sign up to www.realpars.com and I promise you won't regret it.
Thanks a lot for your support! Happy learning.
Great video. When a video about ASi protocol for?.Thanks
Thank you! I will forwarded this topic suggestion to our creator team. Thanks for the topic request! Happy learning!
Sir thank you for this valuable information
Please suggest best software for P & ID designing
For P&ID's, the top two major competitors are AutoDesk (AutoCAD) and Bentley (Microstation). There are also add-on software packages that make creation and management of P&ID drawings easier, such as the AutoCAD P&ID package for AutoCAD. Before buying any CAD package, request a demonstration from your local distributor so you can see what is required in order to use their software (hardware, training, etc.) and so that you fully understand the costs of the software licenses, including any annual maintenance fees. Good luck in your search!
Excellent videos.
Could you make a video about wireless HART technology?
Best regards from Mexico.
Thank you, Mario! Thanks for the topic suggestion as well, I will pass it on to our creator team :). Happy learning!
Hi Mario!
Please take a look at this video and blog post about Hart Protocol which may help you; realpars.com/hart-protocol
👍👍
Should have more like to this video
Thank you, Paras!
Can you create video about ethercat?
Hi there, thanks for the suggestion. I will pass your topic request on to our creator team.
devicenet could be used in Servo?
Yes, DeviceNet could be used, but the servo controller hardware would need to have a DeviceNet interface available.
yes installation and setup, if done wrong have fun chasing the faults. :/
Yep, can confirm. DeviceNet is a nightmare vs EIP these days
Yeahhh I’ve had my share of troubleshooting issues on our miles of conveyor system 😓
nice
Thank you, Nguyen!
Is it fitable to bycicles communication?
No, I don't think so!
Can you create a video about Fieldbus?
Hi there! We actually have created a new video course on Fieldbus, it will be live this Monday!
@@realpars Thanks! Luckily can watch it before my examination starts! Thanks for the great content guys!
do make one video on AS-i
Hi there, I will pass your topic request on to our creator team.
It would be interesting to see a comparison of all the major data highways used in control. It would probably have to be a much longer episode though.
there are master slave relationship in this protocol, how does devices communicate with scanner ?
The scanner is actually a master. We call it a scanner because it polls each node address sequentially by node number and waits for a response from the node. Each packet sent by the scanner is "addressed" to a specific node with data specific to the request.
Each node can be considered a slave node because it only responds to a request by the scanner. DeviceNet is similar to RS-485 but by using the CIP protocol over a CAN network layer, it is much more robust.
70% of broblems that i had with this system were the terminal résistance.
Now do ethernet and DLR
Thanks for the suggestion, Adam! Will pass your topic request on to our creator team.
if you can upload a video explaining different protocols Briefly , and put that video just before this one.
Hi Adil!
Thanks for your comment and your suggestion. I will pass this on to our course developers!
Thanks for sharing and happy learning!
@@realpars thank you so much
I'd rather use ASi.