GridConnect DeviceNet Detective vs V2 vs NetAlert! DN-MTR

mister x

Member
Join Date
Jan 2019
Location
Canada
Posts
156
Looking for good opinions for troubleshooting Devicenet, because I will be gone before it is lol.

There's lots of options, some expensive (BALLUFF, etc.), but the above options not so much, used that is. The Rockwell adapter and 3rd party software being in the middle I'd say.

Paired with a Picoscope running serial bus decoding I think as well. Anyone have good/bad experiences with the test gear?
 
Last edited:
Hello:


The NetAlert! DN-MTR is seems to be a little easier to use than the DeviceNet Detective. I have no experience with the Detective, but reading the manual I can see it supports saving data. It does seem to have a scope option for in-depth analysis.



There is also this tool, for which you do need a Windows 10 PC, but it also allows packet capturing. When you have Layer 7 problems, you do need a packet analyzer.


https://gemac-fieldbus.com/en/can-bus-tester-2/


If your factory will be using a lot of DeviceNet/IO, the numbers of nodes is 20 or more per segment, I would recommend you Gemac.
 
I use the DeviceNet Detective, and it is sometimes helpful, but usually not.
For reference, I work at the "Bubba" level, so I don't have to deal with installs or commissioning. Ninety nine times out of a hundred, I just have to find the cable or connector that the production people wrecked, and my job is done. For those kinds of issues, the Detective is pretty much useless, since once the DNB card shows "Bus Off", nothing happens until you find the broken part. There is the odd case where the problem is random and intermittent, and that is when the Detective comes in handy. It can catch which node gives the first fault before the whole of the network fails. At time like those, it is a great tool to have. It does have a scope feature, but other than being fascinated by the squiggly lines, I have never had a need to use it.


Bubba.
 
Willxfmr:

I find extremely hilarious your metaphor about the scope traces. I am not a maintenance person but over the years I have helped maintenance people with diagnostics tools for DeviceNet and Profibus and also learned the trade by doing and tinkering, so my knowledge is very empiric; so I try to use these "squiggly lines" without going into much detail but with a sense of purpose (that is interpreting them so as to make sure the network is doing OK).

As you point out, the overwhelming majority of communication problems with these systems are due to things like the one you describe, a cable severed by production people, for example. That is, if the network was designed by knowledgeable designers and installed by people who understand the respective standard, as we would assume they would follow the rules.

I remember bout 16 years ago I fixed one network what was installed in the middle of winter but in summer started failing in day time, but not at night. The problem was incorrectly field-assembled M12 micro connectors. I never understood why ODVA did not select the middle pin of the M12 connector for shield. The middle pin is reserved for CAN_L and the person who assembled the cable did not bother to insulate the shield cable so it was doing contact with CAN_L terminal as the connector slightly changed shaped when the room temperature was increasing. It was necessary to get into the painting room of a car assembly line. At the time the NetMeter was very useful to prove the customer the improvement of the communication after reassembling the M12 connectors properly, by adding a sleeve to the shield cable. No need for a PhD in particle physics to solve the problem, but there was this customer having this line with all these equipment working incorrectly and no one in-house who could fix it.

As you mention, commissioning is a little bit more tricky in this case the Detective or NetMeter or the GEMAC tool I would say are not a luxury but an important tool to have at hand.

Of course the maintenance of a plant has so many issues which I can only imagine and would dare not lecture you. But as an evangelist for these kind of tools which I sell, I like to say that one point of tools like the Detective, NetMeter and others is that if they are used not only when the line stops, but more regularly when the line is still working, and if data is taken with care and somebody takes the time to compare with previous data, then you may be able to spot media degradation which can take place very slowly, before such an issue can stop the machine. Let's say if some screws of one DeviceNet connector become loose, or if one cable is on a cable tray soaked in oil which nobody can easily see which penetrates the cable's insulation slowly, decreasing the cable's quality. If someone takes readings this the diagnostic instrument and notices bus errors increasing over time, which are not enough to cause bus-off conditions, perhaps a significant downtime could be averted by scheduling a maintenance, checking connectors and cables and eliminate the errors, in other words bring the network to performance comparable to past experience.


Just my two cents.
 
Last edited:
When I did this sort of thing for a living, the NetMeter was my most commonly used tool. I especially liked using it to provide CAN signal statistics after I'd done an installation or repair, and for leaving installed to catch intermittent signal events.

More often, it was used to prove that no CAN bus disruption had occurred. The network got a lot of blame for dirty and damaged sensors, and bad programming.

Most of what the Detective could do, I was going to do with my PicoScope and a protocol analyzer. This was back when I used a 1784-PCD and internal RA tools, but today I would use a 1784-U2DN and Frontline Test Equipment NetDecoder.

If I could have only one of those tools for maintenance and troubleshooting of an already-installed line, it would be the NetMeter.
 
Recent issues I've come across on my end are trashed buses from bad wiring/termination, duplicate addressing problems, and bad final control elements. These are additions to existing plant systems.

I think I'll start with the PICO and a NetMeter. I'd love to have the Gemac style unit, but I can't justify that price. The U2DN might be an option if I can find one used at a good price. I don't see the NetDecoder $$ though...

Anyone use the old PCMCIA on a VM?
 
if they are used not only when the line stops, but more regularly when the line is still working, and if data is taken with care and somebody takes the time to compare with previous data, then you may be able to spot media degradation which can take place very slowly, before such an issue can stop the machine.


"Monitor the process" is an oft-ignored cry.



Another drbitboy story, so TL;DR


My dad worked for GE Large Steam Turbine, and would on occasion be sent out on a post-mortem for a water induction event. He said it was funny because the customer always called it "our turbine," except when something went wrong, at which point they would call GE and say "your turbine has a problem."



Background


Steam turbines have extraction heaters, where some of the steam going through the turbine is extracted and sent to a heat exchanger, where it condenses as it pre-heats feedwater that is heading toward the boiler. The steam condensate collects in a sump under the exchanger tubes, and drains to the condenser along with all the other extraction heaters' condensate.



What became apparent during one post-mortem is that sump drain was blocked, probably a closed valve. In that case, the extracted steam continued to condense, but floods first the sump, second the heat exchanger, and third the extraction piping coming out of the turbine itself. At that point, it only took a small pressure swing (the steam/condensate-side extraction heaters are all connected, with higher-pressure heaters upstream) to push some liquid condensate into the turbine shell, and that is the end of that turbine; you're lucky if pieces of turbine blade don't end up flying around like shrapnel.


There are temperature sensors on the feedwater before, between, and after all extraction heaters, and if you plot them all on a single (analog) strip chart recorder, they show up as a series of parallel lines, each line normally higher in temperature than the last, as each heater has a "temperature rise." If a heater is flooded, little to no heat is being transferred and its feedware inlet and outlet temperatures will be the same so the temperature rise will be zero, and the operator can see at a glance, from the resulting two lines on top of each other, that summat is amiss.


However, in this plant, the control room had been somewhat digitized and that strip chart recorder removed. The feedwater temperatures were "on-demand" only, which meant once a shift or day someone would roll a thumbwheel and push a button to select each channel, and record the data on a paper form on a clipboard.


The post-mortem


My dad asked for the most recent form and saw that one extraction heater had no temperature rise. He went back a day and saw the same thing, and the day before that, and stopped after going back a fortnight or so because it was obvious that heater had been flooded for some time.


Anyway, that is one reason why "monitor the process" was near and dear to his heart.


It's ironic that, on the boiler side of power generation, a long history of "puffing the boiler" events probably going back to the 19th century meant that the boiler operators were rigorously trained to watch their process constantly, while on the turbine side, in the same control room, that mindset has not penetrated to this day: the link above about water induction ca. 2015 says there were over a dozen events that year (there are other modes of water induction to be sure, but I doubt many of them do not show up in the process first).
 
Last edited:
I have a PCMCIA slot, it's the host operating system I was worried about. I can run anything I can find on a VM.
 
I had a large end-user who had a very poor opinion of DeviceNet, and because I couldn't come do troubleshooting for free, of me.

The second problem was that my sales job had been eliminated and I'd been put in the service group, where you couldn't even go investigate a customer problem until somebody wrote a purchase order.

The first problem arose from just one notorious conveyor belt section with a Bulletin 160 speed controller on it, connected over DeviceNet to an SLC-5/04. Periodically the conveyor would stop, and the 1747-SDN scanner would show an Error 72 for the drive, and that led them to conclude that there was something wrong with the network technology or the firmware. The drive always recovered by itself, leading to the conclusion that the problem as intermittent.

I sent them fresh cables; no improvement. I sent them a new DNet drive interface, same problem. I got permission to install the NetMeter for weeks: it showed nothing but perfect signal until the drive dropped off the network.

Finally it got to the level where plant managers were calling regional managers, and they agreed to let me go onsite with my protocol analyzer and scope. I was escorted up eight flights of stairs to the conveyor, a half-dozen sales, management, engineering, electricians, and millwrights trailing behind me.

I checked out the drive; running fine. NetMeter still didn't show any errors.

A millwright was leaning over a railing watching us, and resting his hand on the conveyor frame. Suddenly he jumped back and shook his hand in pain: "F*ck !".

I asked, of course, what had happened.

"Oh, this damned conveyor always does that. It's those plastic laces."

"The laces ? On the belt ?"

"Yeah, ever since we put in the insulated bearings and those plastic laces, it stings you every once in a while."

"Do any of the other conveyors do that ?"

"No."

I should mention at this point that the electricians and engineers were staring. This was new to them too; they just got called when the "DeviceNet failed".

"Where's the ground conductor on this conveyor ?"

He indicated a hefty ground cable... unbolted and hanging in mid-air.

The root problem was that this conveyor had static discharges through the head pulley that were pitting the bearings, so the millwrights put in insulated bearings and plastic laces, so there wouldn't be a discharge through the head pulley every time the steel laces came around, and removed the ground connection so there wasn't a path for the static to go through. Problem solved... if your responsibility was changing bearings.

The only path to ground from this 80-foot Van deGraaff generator was through the motor ground cable and then through the 480V supply conduit. Those grounds were landed on terminals on the top and bottom of the Bulletin 160 VFD, so the discharge went right through it.

It was taking 10-15 kV hits a dozen times an hour, but every week or so one of them scrambled the control board badly enough to reboot it, knocking it off the network and stopping the conveyor.

This story has a point: the NetMeter was very useful to prove that we didn't have media problems, and the stability of the firmware levels I was using dispelled suspicions of protocol problems, which let us get to the heart of the matter, breaking through a failure of inter-departmental communication.
 
Last edited:
Well, just got word that CNet and Dnet are on the 18-24 month discontinuation plan. Maybe that will motivate less usage....
 
Cite the Rockwell senior manager by name that told you that. It sounds like an opinion, rumor, or fiction (maybe not by you, but by somebody).

Both technologies are in use in supply contracts with much, much longer lifetimes than that.
 
Sorry, that was for CNET, not DNET. By the look of the email received, it's neither opinion, rumor, or fiction. All CNET products are moving to Active Mature.
 
History tells us that "active mature" can be a decade from what would colloquially be called "discontinued".

Thanks for the clarification. Because EtherNet/IP can do nearly everything that ControlNet can do, it makes sense to draw down that production capacity and long-term product planning.

I'm familiar with a handful of US Dept. of Defense and Dept. of Energy projects where we were committed to decades of product availability with ControlNet gear, and most of those decades are still ahead.
 

Similar Topics

Hello All, I am trying to connect a XPORT-EIP-MB (adaptor which converts Modbus RTU/ASCII to a EtherNet/IP) to a ControlLogix5561 PLC and to read...
Replies
0
Views
1,553
Dear all, I am trying to send out a message from Allen Bradley ControlLogix Controller (Logix5555) via the EtherNet/IP Module 1756-ENET to...
Replies
8
Views
5,856
We've run into an old system that we are upgrading which is still running Steeplechase with Citect using Devicenet to Wago. I had some experience...
Replies
4
Views
138
Sigh, DeviceNet noob... I have a 1756-L55, with a DeviceNet module, and 10 PF700 all commanded with DeviceNet. One of the PF700's blew up...
Replies
3
Views
128
Good day Forum Members I got a older Lincoln welder and hoping to make it work at our shop. Welder in question is the Lincoln Power Wave 455M...
Replies
4
Views
191
Back
Top Bottom