OK folks, thanks for your explanations.
They are actually much more human-friendly than the KUKA docs.
Here's what I made of it (see attached).
Sadly, no christmas tree effect on the coupler, and a "Configuration error I/O driver DR2DRV" error message after I hit "Configure > I/O Driver > Reconfigure I/O Driver".
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]
when mapping digital inputs we can use format
INBx = nodeAddr, startByteNumer, numberOfBytes
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)
OUTB0 = 11,7,x3 ; $OUT[1-24] but actually only outputs 1-18 are usable
ANOUT1 = 11,0, ...... etc.
Hi Panic, thank you so much for the explanations.
All clear and simple.
I didn't find the PDF documentation for the BK5250 ; just a lousy .chm file which doesn't clear up the MACID dials question, and neither how the process image is built.
I "suppose" that it is the same as the BK5200 which goes like this :
I might want to place physically the modules in that order to avoid making even more knots in my brain...
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.
Hello folks, I'm just back from Istanbul where I survived the military coup and met with a friendly robot integrator.
As he was setting up a Devicenet system, I noticed that he plugged wires from a 24 VDC supply in one of the Devicenet cable endings.
Previously, I thought that the power was given through the coupler, but apparently it needs to be fed in directly from a power supply !
How could I miss that ?
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.
I plugged two power lines in the Coupler, and I thought that was it.
Now I realize that I need to energize the cable too.
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....
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.
Are you saying that I don't need these power lines to my Devicenet cable in my setup ?
My Turk friends had a different setup, with an external Beckhoff PLC used as a master, and the robot as a slave.
That Beckhoff PLC was nifty, with a touch screen by the way...
He has done dozens of robot integrations and knows what he's doing.
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.
OK, I re-wired the 24 V DC so that it reaches the Devicenet cable.
The reason why I had to plug it on the MFC card end is that the silly cable end that Beckhoff sold me has terminals so small that you can hardly plug the devicenet threads in, so there is absolutely no way to plug the juice here.
I would have been much better off with a simple (and MUCH cheaper) Combicon 5 pin terminal for both ends.
At the beginning, I thought I was going to flip the cable and have the big ending on the MFC side, but it's so big it doesn't fit !
Anyway, it looks silly, but at least it works, and I can see there are extra LEDs that lit up, and they are green, which has to mean I did something right
I also added 2A breaker switches as I have been advised.
Now there's only a digital input and a a digital output left, but I didn't have time to fool around with the IOSYS.INI file.
Once that is done, what is the usual way to check if the IO is working other than running a program that would make use of them ?
Tiny terminals of the fancy Beckhoff Devicenet ending
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.
This ending can act as a "terminal" , but also as a plug for a serial devicenet slave.
Therefor, there can be a second cable to daisy-chain components.
That's why there's also a little swith on the back to set it as the end or the middle of a Devicenet chain, and this is why I think it would not work to plug the power on the second green terminal.
I'll make a program as suggested, thanks !
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...
The plasma cutter is online !
At least the digital IN and OUT, which is sufficient to control the torch and run the robot with the proper timing.
Next step is to try and use the analog "divided tension" input to adjust tool X in real time (if at all possible).
Thanks to SkyeFire and Panic ; your help was invaluable !
so now i get plasma cut souvenir of my choice?
"so now i get plasma cut souvenir of my choice? "
Sure ! As long as it's Mickey Mouse.