Setting up some I/O on a KRC2 ed. 2005

Quote from Wall-E

Then, I deleted the semicolon behind the Devicenet driver name in the IOSYS file.

you mean.... before?

mapping is explained in detail in many topics and at the bottom of IOSYS file.

hmmm... still way off....

lets start with some tips:

1. do NOT put bunch of different cards at once and expect that everything works on a first attempt. try something simpler, only one input or output card (digital I/O for example) because mapping in this case is hardly going to be an issue and to verify that everything else is ok (wiring, node address, bus speed etc.). then gradually add more cards until you get acquainted with particular device and everything is working fine.

2. get documentation for your bus coupler and verify hardware settings. for example when node address is set by two dial switches and you are not sure which one is x10 or x1, set both to same value, then your node address is 11, 22, 33 etc. beware of devices that autodetect baud rate, i have seen few instances where they failed to connect at desired speed, using different baud rate may help (such as 125kbps).

3. get documentation for your bus coupler and verify io mapping format. different products/manufacturers use different ways. for example some always put analog signals at the begin of map since they typically have larger data footprint. finally, make sure to understand data sizes. one byte equals eight bits. two bytes equals 16 bits etc. just keep that in mind when doing mapping.

note i don't have this i/o module to play with so what follows is a generalization but - it should give you an idea on how to work this out:

- all inputs go into one "image" or "table". if there are analogs etc. chances are going to be at the begin of the image.

- all outputs go into one "image" or "table". if there are analogs etc. chances are going to be at the begin of the image.

- when mapping signals to a controller (robot, PLC or whatever), make sure to keep track of data in both images separately (they may be different size etc).

for example we have IO block with macid 11 and following setup:
a) bus coupler
b) DIx8 (8 signals = one byte in input image)
c) DIx8 (8 signals = one byte in input image)
d) DIx4 (4 signals = half a byte in input image)
e) DIx4 (4 signals = half a byte in input image)
f) AIx2 (two analog sigals, each is 16 bit so that is total 4 byte in input image)
g) DIx4 (4 signals = half a byte in input image)
h) DOx8 (8 signals = one byte in output image)
i) DOx8 (8 signals = one byte in output image)
j) AOx4 (four analog outputs, each is two bytes, total is 8 byte in output image)
k) DOx2 (two digital signals, = two bits)

group all input bytes into an input image, they appear in order in which they are in a rack but analogs are usually at the begin (this is why you should read manual for your buscoupler!). in this case all input cards are b,c,d,e,f,g (as appearing in the io rack) but data order in input image will likely be f,b,c,d,e,g.

now we need to determine size of the image - just add all bytes. if you end up with a fraction, round it to a next complete byte (to hold/transfer worth of 7.5 bytes, we need 8 bytes, which are going to be numbered 0-7).

lets review what we got here (note, start counting from zero):
byte 0,1 - analog input channel 1
byte 2,3 - analog input channel 2
byte 4 - digital inputs ("b")
byte 5 - digital inputs ("c")
byte 6 - digital inputs ("d" and "e")
byte 7 - digital inputs ("f" plus four unused bits that are leftover - they are wasted)

that shows what set of data from inputs usually looks like in a fieldbus telegram.

when robot devicenet driver receives that telegram, we basically get a block of data somewhere in memory that is managed by devicenet driver. we need to extract this data and map it to signals that robot programs can use (robot inputs and ouputs). this "extraction" is called mapping - we tell to robot how to transfer data from that memory block to different types of inputs. note, on the robot side, I/O are counted from 1, but I/O bytes are still counted from zero, for example:

INB0 = input byte 0 = $IN[1-8]
INB1 = input byte 1 = $IN[9-16]
INB2 = input byte 2 = $IN[17-24]
INB3 = input byte 3 = $IN[25-32]
etc

when mapping digital inputs we can use format
INBx = nodeAddr, startByteNumer, numberOfBytes

example
INB0 = 11, 4, x1

this means that input byte 0 (inputs 1-8) will be read from node/macid 11, starting with byte 4 (we had to skip bytes 0,1,2,3 in this case since those are data from analog inputs), and we are copying one byte (x1).

to finish digital inputs we could use
INB0 = 11, 4, x1 ; $in[1-8]
INB1 = 11, 5, x1 ; $in[9-16]
INB2 = 11, 6, x1 ; $in[17-24]
INB3 = 11, 7, x1 ; $in[25-32]

or we can map everything using single line (same as first line but here we transfer block of 4 bytes at once):
INB0 = 11, 4, x4 ; $in[1-32]

if that io range is already used, we just need to pick block of IO that is free. this means we can change INBx number but we are still reading from same part of the image transferred by telegram, for example:

INB10 = 11, 4, x4 ; $in[81-112]

for analog signals we can do
ANIN1 = 11, 0, 16,2, cal32767 ; this will read 16-bit (2 bytes: 0 and 1)
ANIN2 = 11, 2, 16,2, cal32767 ; this will read 16-bit (2 bytes: 2 and 3)

and of course do the same for outputs (of course put outpus into output image). in this example that would be:
byte 0,1 - analog output channel 1 ("j")
byte 2,3 - analog output channel 2 ("j")
byte 3,4 - analog output channel 3 ("j")
byte 5,6 - analog output channel 4 ("j")
byte 7 - digital outputs ("h")
byte 8 - digital outputs ("i")
byte 9 - digital outputs ("k"), note that last 6 bits are unused (wasted)

which becomes
OUTB0 = 11,7,x3 ; $OUT[1-24] but actually only outputs 1-18 are usable
ANOUT1 = 11,0, ...... etc.

Haven't used Beckhoff in quite some time, but IIRC the analog cards tend to screw with the internal addressing.

I'd suggest the same as Panic: pull all the slices, except one Digital Input, and maybe one Digital Output. Connect everything, then use a 'dnWho' from the Telnet window to see what the auto-reporting of the DN bus reports back. Assuming the bus coupler connects to the MFC, the 'dnWho' will report every slave MAC-ID on the bus and it's currently-configured byte size for inputs and outputs (should be 8 each with a single DI and single DO slice plugged in). Concentrate on getting this minimal config working first.

Well, most DeviceNet I/O units need two power sources. The communications cable carries high-quality, low-current 24VDC power which provides power for the communications bus and bus couplers. I/O power, however, is usually provided by a separate source, generally a high-current power supply that requires less quality. This allows you to use I/O devices that work at different voltages than 24VDC, or that require very high currents, or separate power supplies (like motor starters).

Many people "cheat," though, and just use the communications bus power for everything. Which can work, as long as you're not dealing with any high-voltage, or high-current I/O, or anything that might generate dangerous transients.

Quote from Wall-E

I don't want to hurt the feelings of the guy who came up with this Devicenet thing, but isn't this a mess ?

you are absolutely right....

Quote from panic mode

you are absolutely right....

Noooo, not really. If you think about it from the standpoint of when it was created, the specification makes sense. There are some particular brand implementations that are messy, like a certain like of Turck(?) I/O modules that, for whatever reason, pulled their communication power from the I/O power cable. But DN, once you're used to it, can be quite nice to work with. Robust, easy to set up, doesn't require any fancy brand-specific software (unlike, say, Profibus, which can only be set up using one of the most user-unfriendly, unintuitive pieces of software Siemens ever created). Works with dirty power supplies, as long as the communicaiton power bus is clean, works in high-noise environments, has simple (usually, but some brands manage to complicate it) addressing.... and you can build an entire bus, with no documentation, simply by querying the bus modules and getting their responses -- the slaves will literally tell you everything you need to know to set up your scan list.

No, you have to provide the power on the Comm cable -- the robot DN port requires that power, even if no other unit on the bus does.

What are the four empty terminals on the second green terminal block for? Going by the labelling, you might be able to terminate power there, assuming those terminals are linked to the V+ and V- on the 5-pin connector.

Aside from that, usually the quick test for I/O is to wright a program that will "sweep" all the output bits and turn them on, then off, about 1/sec. You run it while watching the output LEDs on the slave module, and confirm that the bits line up.

that is easy to test, check continuity between two groups of terminals for both switch positions. switch is small, seem to be SPDT or at most DPDT...

so now i get plasma cut souvenir of my choice?