Configuration Issues with DeviceNet

assuming all wiring is correct (including devicenet power, terminations), node address and baud rate is matching etc. - i would start with something much simpler... how about making only one card (digital input for example)? another thing is that most bus couplers rearrange data so that DI/DO appear at the end of image, after analog cards (even if analog card may be phisically closer to bus coupler). your io mapping is not taking this into account (which may as well be correct in this case since i have not used BK5200).

Well, have you checked the status lights on the bus coupler? Checked the bus cable termination resistance? Confirmed 24VDC across the power pins on the DeviceNet cable, at both ends?

If all that checks out, try the dnWho tools through the Telnet window (forum has archived posts on this).

and what are the actual settings on the bus coupler (speed, macid)?

Hello All,

I am the other person working on this project, I have worked with Profinet and KRC4 but never DeviceNet on KRC2. Thanks Panic Mode and Skyefire for the help so far!!!!

A little more background on the project...

We are trying to setup an LPDN card as a Master and the Beckhoff 5200 as the slave. There is an MFC card available which we might try if we can't get it to work with the LPDN. Taking Panic Mode's advice I have reduced the the Beckhoff to contain 1 DI card and now changed it to 1DI and 1DO so I can set POLL_RESPL and POLL_CMDL both equal to 1 with no chance of accidentally reversing the settings.

To answer your questions...

There is 23.5V applied at both Beckhoff and LPDN DeviceNet connectors from a brand new Rhino power supply.

The terminal resistance is 60.3 Ohms at the LPDN and 60.3 Ohms at the Beckhoff with all power off. Resistances changes to 56 Ohms at the Beckhoff and 65 Ohms at the LPDN when I power up the machine. (Not sure of the tolerance on the resistors? each end has a 120 Ohm resistor because I could not find a 121. I am currently considering reworking the connections just as something to try.)

Beckhoff Dip Switches set to 500 kBaud and MacID of 10. All config settings are consistent at 500kBaud ( Is it worth trying 125 or 250?)

From Beckhoff literature physical module order shouldn't matter.

All Lights on Beckhoff (Run, Connect and I/O Run) are Green

Both Lights on LPDN card are green

All Config Files are the same as above with the exception of the IOSYS which was changed to the following to reflect the removal of the analogs.
INB1=10,0,x1

OUTB1=10,0,x1

Other Info.......

We can see both devices when using dnsc1NetWho. dnsc1GetNodeInfo 00 displays the correct settings for the LPDN. dnsc1GetNodeInfo 10 will display more or less correct info when run the first time. If we run that command again the numbers in all the fields move around. For example the product code will come up as 5200 the first time and next time 5200 might be in the POLL field.

I have a strong suspicion that I am missing something silly due my lack of Devicenet experience. I have also read the manuals and the posts.

Every time we reconfig IO it spits out the same errors
1025 Configuration error 1/0 driver CH2; Module 10 Error
1034 Error on writing, driver: LPDN Ch 2
1033 Error on reading, driver: LPDN Ch 2

Any additional suggestion are more than welcome!

Have you looked at DNSC2.LOG?

Since the lights are green, your physical connection is good, and the baud rate and Mac-ID must be okay. My best guess is that some of the other data, like Vendor ID, may be incorrect. Your best bet at this point is to use a dnWho from Telnet to query the module directly.

OK I've got DI and DO working. Here's how it went...

We kept getting the following...

ERROR: [10] Data Size Mismatch
Device[10]: Data size does not match
Reading/Writing Error: LPDN2 Driver.

We eliminated the read/write errors by mapping the IO's in non-system locations

in our case INB2=10,0,x1
OUTB2=10,0,x1

When I ran dnsc2ShowDevice 10 I found something odd.

I: 00 00 00 would be displayed when POLL RESPL =3
O:00 would be displayed when POLL CMDL =1

where the number of pairs of zeros corresponded to the RESPL ans CMDL numbers.

I currently have 2 DI and 4 DO, I had tried several combos of these numbers ,which are supposed to represent BYTES according to Kuka documentation, but in my case seem to represent 2 bits because the Device[10] Error goes away when I configure the dnsc_2sl with
POLL RESPL=2
POLL CMDL=1

I can now control DI and DO, but it doesn't make a lot of sense to me.

Okay, that explains it.

On these Beckhoff "sliced" I/O setups, each "slice", or card, inserted into the backplane takes up 1 byte minimum in the address space. So even if you only have 1 Input slice, with 2 inputs on it, it still occupies 8 bits. If you add another 2-input slice, it's inputs will take up the first two bits of the next byte.
Some slices will take up more than 1 byte. An analog input that has a resolution of, say, 12 bits will occupy 16 bits in the address space. Basically, you cannot allocate bits in the I/O addressing space in blocks smaller than 8 bits. So a 9-bit slice (I don't think they exist, but...) would occupy 2 bytes, even if it was only using 1 bit of the 2nd byte.

The fact that your query against the module showed a RESPL of 3, rather than 1, tells me that your bus coupler may taking up the 1st two bytes (or possibly the last, sometimes these vendors get creative) for diagnostic information. So your DI slice may be starting at 10,2 rather than 10,0. One quick way to confirm this would be to remove the DI slice, then run the Telnet query again. The RESPL value should drop by one.

I realized I was wrong in my assumption about each pair representing bits. They represent bytes. The Beckhoff BK5200 required the first RESPL byte of 1. The other cards mapped as expected. So I changed to a 4 DI card, a 4 DO, a 4 ANIN and a 2ANOUT (all analogs 16 bit).

Final

RESPL=10
CMDL=5

Thanks to all for the help!

Ah. That's about what I would expect (apparently no diagnostic bytes). You may need to check your addressing as you go -- adding the Analog slices almost always seems to re-arrange the addressing in non-intuitive ways. (or maybe that was Wago, who uses the same form factor)

Anyway, you can map the Analog signals to the $ANIN and $ANOUT channels in the KRC, or to digital double-byte words, or even both. I've always preferred handling my Analogs digitally (if that's not an oxymoron), but everyone has their own preference. But it can be handy to read the raw digital bytes coming from an Analog input while setting known voltages onto the input hardware, and reverse-engineering the conversion ratios. And being able to set an analog output bit-by-bit can come in handy as well -- there are some analog modules out there that use really weird formatting, and every brand has their own spin on it.

that is with diagnostic byte.

for inputs we get:

4DI = 1 byte
4AI = 4x2byte = 8 bytes
then add to that 1 diagnostic byte (only 1 byte and only on inputs, location is end or begin of input image)
-----------------------------
total = 1+8+1 = 10 bytes.

for outputs:
4DO = 1byte
2AO = 2x2bytes = 4 bytes
----------------------------------
total = 1+4= 5 bytes

Whups! Yep, I added up the Input bytes incorrectly.