Study : Devicenet

Hello!

I'm posting this to open a topic on the self-study of devicenet. It's a thread for findings, study results, experiments and questions. Anyone who wants to add anything, feel free

First off, it would help to determine what we're trying to figure out. So here are a few questions my meager studies have helped bring to my own attention.

1. What are the important points for choosing hardware? Are there certain things to look for? Things that we should reject out-right?

2. There are four I/O monitoring methods in the standard : strobe, poll, discrete messaging and change of state. What are the critical differences, and what sort of application differences makes one type more "fit" for a job than another?

I've done some work with my own setup that has been pretty revealing, along with my communications with SST, maker of my devicenet card. I'll be posting those results shortly.

Can anyone else add any questions or provide information from their experience that might be useful? Not alot of specifics just yet, but I'm working on it.

Thanks!

TM

SST Talks

While the information that folows here is specific to the SST 5136-DN-ISA scanner card for PCs, the situation may well apply to a number of manufacturers.

I contacted Ron Bickell at SST about training, and was told they do occasionally offer training through one of their regional sales reps, although nothing is scheduled right now. But that's not the interesting part.

When I read the manuals, I was suprised at how little information was included about using the configuration software. In fact, the software "guide" is little more than an installation cut-sheet. On the other hand, the instructions for the card's DLL files are thoroughly documented.

What Ron confirmed was that the card documentation and software were not intended for the end user in the first place. The information provided is for people, such as Entivity, using C or Visual Basic to develop applications that take advantage of the card's features. The "configuration software" is, in fact, functional example applications, meant to be used as models for programs like Steeplechase.

Mentally, I can now group the Devicenet system into three sections - the hardware (wiring), the firmware (node and card drivers) and the software (steeplechase and commissioning).

This doesn't answer any questions, but it raises a new one :

1. Can steeplechase (or a similar program) commission the network on it's own, without separate commissioning software?

The model I've used previously was AB, which requires RS Networx to set up the system independent of the PLC the network connects to.

I'm currently getting a desktop with enough horsepower to run steeplechase. I've done a number of experiments using the SST software, and I'll put those findings up shortly. Once I have this desktop set up, I'll be able to repeat these experiments and see how they relate to the VLC software.

Thanks!

TM

Go here http://www.odva.org/ for all things Device Net. There are a couple of techinical overview documents etc for download.
Have not used the software you are using but have used Omron Device Net Configurator. The latest version is really good. Have used it on networks with Omron I/O blocks, AB Powermonitor 3000, Pepperl+Fuchs absolute encoders, Wago blocks and several others. Allows you to search, setup etc. The first version was not very good.
The biggest hassle with Device Net is expilcit messaging. You have to set things up absolutely correctly and then it works like a charm. Same as for any network I guess.
ODVA have lists of tested products etc etc and are very well organised.

I don't know if this is what you are looking for in your study, but I have a couple horror stories to tell.

I had about 30 device net beacon lights from allen bradley on a device net network. The devices talked to a scanner in a plc5/40E. The node addresses for these beacon lights were set via rotary dip switches. One switch was for the 0nes place. And one switch was for the ten's place. Over time (aprox 1 mo. after install), the solder joints came loose on most all of the beacon light node switches. This caused a lot to be set at 0. Some that had just a broken ten's switch, were now set as a node anywhere from 0 - 9. Some of the teens were now all tens. Anyway, you get the picture. This didn't all become apparent until the plant had a power failure. When all of the beacons were powered back up, they all reported their new node addresses to the scanner. Needless to say, there were a few duplicates. Talk about your troubleshooting nightmares.

Second:

There isn't a true fail safe with Device Net. You can walk up to the device wires of a device and rip them out of the wall. The AB scanner will still retain the last value. AB states this is the device's responsibility. But if the device isn't connected to the scanner anymore, how can the device report its failure?

Everything is Welcome!

And since we're on the subject, you're not the first person to mention Bus-off and losing your I/O points without being able to detect it.

I need to do a little more reading on this one.

TM

From th ODVA

The following is from the ODVA pdf file, "Devicenet Overview", available at www.ODVA.org :

***

Change-of-State and Cyclic Transmission

With change-of-state, a device produces its data
only when it changes. To be sure the consuming
device knows that the producer is still alive and
active, DeviceNet provides an adjustable,
background heartbeat rate. Devices send data
whenever it changes or the heartbeat timer
expires. This serves to keep the connection alive
and let the consumer know his data source has
not faulted in some way. The minimum time on
the heartbeat prevents inherently noisy nodes
from dominating the network. By having the
device generate the heartbeat, the controller is
not burdened with having to send a nuisance
request periodically just to make sure it is still
there. This becomes even more efficient in the
multicast case.

***

I can't tell you how to implement it, but it seems the capacity is there. Perhaps by using a frequently-changing IO point as the heartbeat "pulse", then look for a change of states - three strikes and yer out?

Is your system change of state? What sort of nodes are you using? Is there anything in the documentation for them that refers to this heartbeat, or how to use it effectively? What about the AB scanner - does it say anything?

More questions ... I see nodes in my sleep! ARGH!

TM

I know in the Allen Bradley Scanner, there was a fault bit for every I/O point on device net. Monitoring this bit appeared to give an accurate comm good/bad indication for each I/O point.

Unfortunately, you couldn't write to the input image table of the scanner to clear the input.

The only way I found around this is to map all of the scanner Inputs to PLC memory registers. I usually do this anyway, so not a big deal. (Although, after mapping a turk block to a scanner to a block transfer to an array to an array, how would a maintenance man ever follow a tag all the way through the system.)

I then had to ensure that I cleared the appropriate memory registers for the device that faulted. I had to keep doing this every scan and place this clearing logic inbetween where the block transfer read was and where I was updating my virtual inputs. Depending on how many words were being used for that Input device, determined how many words I had to clear. This was quite painful.

It made additions to the device net network even more arduous. Nothing like the Allen Bradley sales seminars where the salesman would effortlessly add devices and say presto.

I never went to the lengths guatenator did in clearing out Input data arrays with the Device Fault bits; I used them directly in my ladder logic as a "valid input data" condition.

I found that actually helped me out when trying to remember what node number data was coming from. Even though I had to count in sixteens (carry the eleven, take off one sock ) I had a XIC reference in each rung where I used DeviceNet input data from which I could infer the Node number that generated the data.

In the ControlLogix scanners it becomes much easier; an array of sixty-four SINT elements is created for the scanner and each element gives the Connection Status for that Node.

Hopefully the SST card provides a similar Connection Status feature.