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.

Terminating resistors are to suppress signal reflection. Proper shielding is supposed to reduce electrical noise specifically in voltage signal (potential)

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.

What a fantastic video! All needed areas covered and well treated. Thanks!

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.

As usual, very insightful. Thanks Real pars!

Deeply appreciate the clear conceptualisation.

Thank you very much.This lesson is very perfectly as the other lessons.(ın İstanbul)

THANK YOU,very informative

Your videos are perfect!

Sir Thanks for your Efforts 👍

Excellent video, I will share the link on my social networks.

Excellent my friend

the explanation is too good

I like how you explain it so easily

Muchas Gracias, por el video.

super sir thank youu

Great presentation

thank u

thanks you so much

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.

Good job

Great video. When a video about ASi protocol for?.Thanks

Sir thank you for this valuable information Please suggest best software for P & ID designing

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

👍👍

Excellent videos. Could you make a video about wireless HART technology? Best regards from Mexico.

the courses in the web are only for siemens?? do you teach allen bradley ???

yes installation and setup, if done wrong have fun chasing the faults. :/

Should have more like to this video

Can you create video about ethercat?

nice

devicenet could be used in Servo?

do make one video on AS-i

Is it fitable to bycicles communication?

Can you create a video about Fieldbus?

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.

there are master slave relationship in this protocol, how does devices communicate with scanner ?

70% of broblems that i had with this system were the terminal résistance.

I'd rather use ASi.

Now do ethernet and DLR

if you can upload a video explaining different protocols Briefly , and put that video just before this one.