R30iB DeviceNet to AB 1734-ADN

    I'm having a problem that I suspect is mainly on the AB/Rockwell side, but while I'm waiting for a response from Rockwell tech support, I figured I'd double-check with the hive mind here.


    My DeviceNet slave is an AB 1734-ADN Point I/O DeviceNet adapter with three I/O slices: two IB8s, and one OB8, in that order. My robot is an R-30iB running version 8.22.


    If I power up the module without powering up the robot, the adapter shows a green light on the PointBus LED (indicating communications between the adapter and the slices is good). Each slice's Module Status light is green, but the Network Status lights on are dark, which the manual says means that the "MAC ID Dupe test" has not been carried out. That makes no sense, since the slices should be automatically picked up by the adapter, shouldn't they?


    The weirdness happens when I boot the robot. Once the robot boots, it begins communicating with the adapter: the I/O DeviceNet screen shows the module online with no errors, and the DN light on the adapter turns solid green. But, when the DN connection is made, the PointBus light on the adapter changes from solid green to blinking red, and the Network Status lights on each I/O slice change to blinking green (the first slice) and blinking red (the next two slices).


    I'm stumped. On most brands, I would expect that any errors on the "backplane" connection between the adapter and the slices would show up regardless of whether the DeviceNet was active or not. Obviously, with this AB hardware, that's not the case.


    I' trying to figure out if this adapter requires some kind of setup using RSNetworx before it can be used as a simple "dumb" I/O adapter, or if I have something else going on. Right now, the DN config in the robot is set up for 2 bytes input, one byte output, which matches my hardware exactly, but I've heard that even the "dumb" AB adapters usually have extra status/control bytes that need to be accounted for in the Master-side DN configuration. But if that was the problem, shouldn't the robot be throwing DN config errors, due to the expected I/O size and the actual I/O size not matching? And I can't find anything in the AB manuals that would tell me how many "extra" bytes I might need to account for here.


    I have checked my DN cable resistance with everything turned off, and confirmed that it's 60 ohms between CAN+ and CAN-. And the robot is sourcing 24VDC on the power pins, and the shield is connected properly at both ends. There are no extra branches, or any other devices, on this DN bus -- just the robot, and the ADN.

    More fun... I dug an old Devicenet Detective bus analyzer out of storage, and added it to this robot's DN bus with a T junction. Unfortunately, the robot doesn't appear to like it -- every time I plug the DD in, the robot shuts down the bus due with DNET-055 and DNET-062 errors: "Board or network error" and "bus is off due to comm errors."


    Do the Fanuc DN boards just not like 3rd-party testing tools?

    Well... I finally stumbled over the command to query the device directly from the pendant. And it showed that the device has 2 bytes each of input and output (also the wrong product code). So I changed the device definition in the I/O DeviceNet menu to match the results the hardware returned...


    No luck. I still have exactly the same errors as before. I'm stumped -- I've run out of ideas to try.


    I also deleted the device entirely, and used the Query option and the ADD_DEF option from the Query results page. Still no good.

    I've never dealt with this device before but maybe you can connect to it with RsLinx and gain some insight. On some AB devices you have to set the number of cards attached which can be done in RsLinx.

    I have never tried using a 1734-ADN with a robot, but even with a AB PLC you have to use RSNetworx for Devicenet to build the 1734 scanlist, and then link that scan list to the PLC.


    IIRC, you create a Devicenet file for your main network, and then create a second devicenet file just for the point IO. Then you drill down into the Point IO and set it up, and save that devicenet file. Then you go back out into your main devicenet file and associate the .DNL file with your main .DNL. I can't remember exactly where you do that though.


    I had to do something similar to a Fanuc robot with IO Link one time too. It required using RSNetworx for Ethernet/IP


    the AB manual that you want to reference is 1734-um002_-en-p.pdf

    Well, it appears that each I/O "slice" was fighting for the same (factory default?) address on the 1734's backplane. It took a Logix PLC with a DevNet card and some time with RSNetworx to straighten out. I haven't gotten the 1734 assembly back to the robot yet, but based on our conversation with Rockwell tech support, it appears that the 1734 needed to be configured with mapping for the I/O "slices", and that mapping should stay in the 1734's memory when I move the module from the PLC to the robot.


    This one really caught me by surprise -- in the past, using other brands of "sliced" I/O (Wago, Beckhoff, etc), this was never an issue. One simply plugged successive slices into the bus coupler, and the Bytes Produced/Consumed count would simply grow to match. No brand-specific software config required.


    I'll have to make a point to avoid certain brands in the future, for components that are intended to be connected to robots instead of PLCs.

    Gahhh... the fun never stops with this.


    Back at the office, connected to a PLC, once we fixed the slice addressing for the IB-8 and OB-8 cards, the 1734 reported that it had 5 bytes input (to the PLC/robot), and 3 bytes output. Since there were only 2 IB-8s and one OB-8, the first output byte and first two input bytes were probably status/control bytes for the adapter.


    However, back on site, connected to the robot, when I Query the adapter, it reports back 2 bytes Input and 3 bytes output. The outputs work -- turning on the DOs mapped to the 3rd byte activate the physical outputs on the OB-8 card.


    But the inputs don't get back to the robot. Obviously, this is due to the robot only "seeing" the first two input bytes.


    The strange thing is, what the adapter reports back changes depending on what kind of query I make from the robot: POLL returns 2in, 3out.


    STRB returns 2in, 8out, but with a Mode Mistmatch in the Device Definition.


    COS and CYC both return 5 bytes input, but CYC has the Mismatch error, and COS does not.


    As an experiment, I deleted the Polled definition for the adapter, and did a Query in COS mode, followed by Add Device. This let me map the 5 bytes of inputs to my DIs, and after a reboot this worked -- I could now see the DIs. But my DO mapping went Invalid, since this definition of the adapter has 0 bytes of output.


    My working theory ATM is that my IB-8 cards are configured for Change Of State, while my OB-8 is configured for Polled, and the robot's DN driver can't handle that. One or the other, but not both together.

    Success! Finally. It took way too much wrangling, but we were able to configure all the I/O slices to Polled mode, which allowed the robot to access all the DIs and DOs.


    For the future, though, yes -- I'm making a point to our controls designers not to buy certain brands/types of I/O module if they're going to be attached to a robot rather than a PLC.

    I have to say, some of the newer SMC units are nice -- the byte sizes keep changing depending on how many modules you add, but the bus adapter has a built-in web server that, among other things, will dynamically create an EDS file unique to your hardware configuration and let you download it. I did that, pulled the values I needed from it to type into the Ethernet/IP menu in the robot, and voila! Utterly painless.


    A single fixed-sized Balluff I/O block, OTOH, ended up being impossible to connect to the same robot without using RSNetworx, for reasons I've never figured out.


    I've never had any issues with the Turck TBEN family of devices.

Advertising from our partners