DeviceNet fault programming

[JeffKiper]

I am doing a job with a 1769-SDN sitting on a CompactLogix (L32E). I am trying to cover my back side by writing all the fault log stuff before there is an issue. I have been bitten by some bad firmware in DNet nodes and it made me look like a fool. Even after they site called out a firm with a DeviceNet "GOD" (that was their words). This guy wanted to replace the SLC 5/05 processor because it was not allowing him to drill down to the backplane and see the 1747-SDN card.

I try to follow some of the gurus on this site.

A good program will be at least 50% diagnostics.

Does anybody have an idea or sample of the diagnostic logic or fault capturing stuff that would make my life a little easier?

 

[thiem]

What is on your DeviceNET that you want to fault monitor?

Generally, I do a GSV to make sure the 1769 card is active. I monitor the scanner status using the status bits in the pre defined structure. Beyond that it is probably device dependant what you want to do. I have done things like if there is a certian error code (device specific again), I will auto reboot the scanner x number of times before I display a fault on the HMI. Obviously, auto rebooting your scanner is going to be process dependant as well.

Any chance this is the robot job you posted about recently? If it is, care to share what type of robot you are talking to?

If your SDN is the master device and some of your slave devices are not I/O (other PLC or Robot, etc) I recommend you use a bit or do something (word rollover) for comm watchdog/timeout. Your scanner can be running with no errors and report all nodes are good, but the end device may have a problem. You can catch this scenerio with the comm timeout watchdog (insert your phrase there).

 

[JeffKiper]

Node status.
ABB robots the look like dumb I/O
Sorry short on time sick kid

 

[thiem]

Knowing that the end device is an ABB robot (IRC5 most likely?, or even s4c+) you are going to want to do a couple of extra things. I assume that the robot DNET device is the actual DSQC single or dual channel device net card, not a 652 I/O board. The most important is to include the comm watchdog. If the robot is single thread (read NOT multitasking) then the only place to place this watchdog is to put it in a cross connect in the EIO file. I almost always put the watchdog in the EIO file. However, if it is multitasking and one background task is strictly for handling comm, then I would put the watchdog in the main routine of this specific task. This will serve as a dual purpose. The first is to alert for comm failure, the second, you can put timers on the bit toggle to find out how fast the task is potentially running in the robot.

The second thing that should be done, is protect the DNET scanner in your compactlogix from going into run mode before the robot is powered on. Even if the robot is powering up, it takes about 100 seconds before the comm will work to the robot. I have seen some integrators literally put a timer on the run command for the scanner card for such a purpose. However, you have mulitple robots, and it was not stated if they are part of your system or not. Generally, I do not do the timer, this is where I would auto reboot the scanner card x times to try to re-establish comm from the PLC. However, with multiple robots, this may not be a good option.

The exact opposite is also true. Powering up an IRC5 with the scanner card off, can cause system failure for the IRC5 depending on how the EIO file was defined.

In short, I do all of the above for every ABB DNET system I install. The watchdog is a must. The EIO file needs to be able to power up with the scanner card off (so no system defined inputs or outputs can be tied directly to 'tags' mapped to the DNET scanner). Instead, use simulated, or virtual tags and cross connect them to the DNET tags. The last is try to catch errors on the SDN from the IRC5 being off and handle them accordingly.

 

[JeffKiper]

These are S4C+ with I/O plus on them. So we are planning on using the CAN2 bus connection. I am not running the manipulator they customer is doing all the programming on it. I got called because they have 3 robot guys that are good. They all had a PLC guy working hand and hand with them before. Now they are at a shop where PLC is black magic.
This is a combination cell that will work as 2 robots per stamping press. 1 in the front, 1 in the rear. or the identical setup next to it doing transfer on hand-off stands. The system will be able to select dual press or stand alone operation.
It has been 2007 since I touched a teach pendant so I am probably so rusty I can't spell EOAT. I have to use acronyms.
Refurbished controls on the controller and manipulator. new EOAT.

The only problem I have with rebooting is that they could be running in stand alone mode and that would kill the other cell.

 

[Ken Roach]

That's fantastic application-specific robot functional information. Thanks for posting it !

If you have to prevent a Polled I/O connection from going into run mode, you can do it programmatically. Leave the "Connection Active" box in the RSNetworx scanlist configuration for that device un-checked, then send a CIP Generic message to Enable the scanlist entry. I'll have to look up the specific Class, Instance, and Attribute for that message. It's not stored in NVRAM so on power cycle of the 1769-SDN, the programmatically-enabled connections will be disabled again, and require another MSG.

 

[JeffKiper]

Ken I am opening up RSNetworxs now to look for that Connection active check box. I will post back in a minute with some other questions I am sure.

 

[JeffKiper]

Is "Connection Active" the same as "Node Active"?

 

[Ken Roach]

Yeah; I didn't have the software open and got the nomenclature wrong. You'll see that there is a "Node Active" setting for each Slave in the scanlist, just like there can be different Electronic Keying settings for each slave.

The Node Active setting can be individually set and cleared with a MSG instruction sending a Set Attribute Single service to the 1769-SDN's DeviceNet address. The object address is Class 145, Instance (Node +1), Attribute 1.

It's described in the RA Knowledgebase (TechConnect) Answer ID # 23777.

 

[JeffKiper]

OK I am just logged into the KB and am looking at the note. Where did you find the object data?

 

[JeffKiper]

I created a way to log the fault. This system only has 5 nodes so I didn't make it super large.

Can you guys look at it and tell me if it looks OK?

 

[thiem]

Your fault logger looks ok to me. Looks like you are going to capture the faults for the first 8 nodes and only trigger off of the first 8 nodes, which is what your description says. Looks like you have a good handle on the situation. At least if something does happen, you will have the time stamp and the exact error code so you can correct the situation.

Thanks for posting the MSG info Ken. I will probably try this approach on the next job.


EDIT: You might only need the length of 1 to copy the DeviceFailureRegister[0] in the first copy, unless you really do want to copy the entire 8 sints for all nodes there.