Yes devnet you cant as its only half a card so to speak
Sent from my Nexus 5 using Tapatalk
Yes devnet you cant as its only half a card so to speak
Sent from my Nexus 5 using Tapatalk
On the MFC yes that's true, the LPDN is a 'true' card though
Eusty, the DeviNet is running fine with 2 Wago IO modules and a FESTO pneumatic block.
Now I´m trying to operate a little machine that helps the robot in some of its tasks. That´s why, conceptually, I wanted the PLC to operate as a robot slave, but I´m afraid that´s not possible.
If the PLC was used as a robot cell master I wouldn´t bother in trying to connect it as a slave, but I thought that was the correct choise for this particular application.
Do you both think that other architecture is recommended?
Thanks for the CP_5614 manual, I´ve already had a similar version.
DeviceNet using only MFC has few limitations:
- MFC can only be devicenet master
- MFC is always node 0 (macid=0)
- does not support coupling
other than that, it works just fine. I don't remember having any issue with adding PLC as a slave, just make sure that address, baud rate and mapping are valid.
That´s why, conceptually, I wanted the PLC to operate as a robot slave, but I´m afraid that´s not possible.
I can understand the reason, but once the coms is working the which is master/slave doesn't really matter. Have you tried a different GSD file? One thing about Profibus is that it can be VERY fussy to get configured, wrong GSD file etc
I have done profibus network with two KRC2 robots and S7-317F recently and although I didn't touch Siemens PLC in couple of years, it was a breeze.
All software/hardware was by customer but they had problem with old guy leaving and new one was fresh from college and had zero exposure to Siemens and Kuka. I wanted to go home so with their permission, I stepped in...
1. ripped out all profibus cables and made new ones (it is sooo simple and yet, you would not believe what some people do) (*)
2. connected them correctly (**)
3. configured both robots to be profibus slaves (with unique addresses of course)
4. imported Kuka GSD file for CP5614 (you want to use one from Kuka, not one from Siemens, they are different)
5. created PLC project from scratch, (got rid of old one, disabled safety option because that is something they can do after i'm gone, I configured it as standard CPU) (***)
6. inserted new MMC (one not contaminated with safety) and downloaded project to CPU
7. wrote programs on both robots to send data to each other through profibus (in the plc added couple of blocks to copy data from one robot to another)
about point 1... (*)
I keep finding more cases where:
1. people are ignorant and put red and green wires backwards despite color coding
2. they strip wires before terminating/closing terminals (having insulation is rather important when using profibus connectors with insulation displacement terminals)
3. they do not expose/connect shield
4. they do not pay attention to IN/OUT
5. they do not terminate correctly
about point 2... (**)
profibus network like any other bus network is based on 485 and needs terminating resistors. terminators are to be installed at the ends of the bus. in case of profibus, terminators are part of the connector and need to be turned on by moving little red switch. in this case there was three nodes (robot1, robot2, plc) so terminator was active at robot1 and plc but not at robot2. another thing to keep in mind is that connectors have two ports (A1B1 and A2B2 or "IN" and "OUT"). it is important to make sure that only IN is used at end nodes because when terminator is enabled, OUT is disconnected. the other important detail is that on nodes that have two cables connecting to same connector (here that was robot2), it still matters which one goes to IN and which to OUT (if you are smart). it is a good idea to always connect to IN cable that is going to or toward PLC. this allows you to terminate any point on network and disconnect any part of bus while keeping bus segment at/around PLC intact. this way you can test your configuration and gradually add more nodes simply by flicking terminator switch...
about point 5 (***)
Insert Kuka CP5614A2 (under Other or just search for “kuka” in hardware catalog)
sorry, don't have Step7 project or software to make a sample hardware config...
Latin Robot, can you post the GSD file you are using for the PLC? I will see if I get the same error on Monday.
Sent with Tapatalk.
Back at work! I´ve been busy with other things... the DeviceNet net failed last week when trying to connect another module (a FESTO pneumatic and D IO block) in a Daisy Chain config.
Luckyly we worked it out and is now working fine. It was a strange problem since I was sure the config files where OK, but the KRC kept sending an error in writting the driver. I made a copy of the file, run some tests with the original one that didn´t work, and finally returned to the backup deleting the modified file. When I reconfigured the IO driver with the untouched file it started working... crazy
Back to the Profibus issue (now is personal), I made some progress but I can´t get the 5614 PB card to accept the S7 300 as her slave.
I will now try a new version of Step7 and I think I have to learn how to configure a PLC as a DP slave and get it in the "Configured Stations" folder.
That´s where I think I´m failing. I left you an image where you can see what I´ve done.
are you 100% sure that your 5614 (here used as a master) is the one from KUKA GSD and not Siemens 5614?
are you 100% sure that your 5614 (here used as a master) is the one from KUKA GSD and not Siemens 5614?
Yes, I´m 100% sure because I got it from the Profibus folder in the KRC.
Display More
I have done profibus network with two KRC2 robots and S7-317F recently and although I didn't touch Siemens PLC in couple of years, it was a breeze.
All software/hardware was by customer but they had problem with old guy leaving and new one was fresh from college and had zero exposure to Siemens and Kuka. I wanted to go home so with their permission, I stepped in...1. ripped out all profibus cables and made new ones (it is sooo simple and yet, you would not believe what some people do) (*)
2. connected them correctly (**)
3. configured both robots to be profibus slaves (with unique addresses of course)
4. imported Kuka GSD file for CP5614 (you want to use one from Kuka, not one from Siemens, they are different)
5. created PLC project from scratch, (got rid of old one, disabled safety option because that is something they can do after i'm gone, I configured it as standard CPU) (***)
6. inserted new MMC (one not contaminated with safety) and downloaded project to CPU
7. wrote programs on both robots to send data to each other through profibus (in the plc added couple of blocks to copy data from one robot to another)about point 1... (*)
I keep finding more cases where:
1. people are ignorant and put red and green wires backwards despite color coding
2. they strip wires before terminating/closing terminals (having insulation is rather important when using profibus connectors with insulation displacement terminals)
3. they do not expose/connect shield
4. they do not pay attention to IN/OUT
5. they do not terminate correctlyabout point 2... (**)
profibus network like any other bus network is based on 485 and needs terminating resistors. terminators are to be installed at the ends of the bus. in case of profibus, terminators are part of the connector and need to be turned on by moving little red switch. in this case there was three nodes (robot1, robot2, plc) so terminator was active at robot1 and plc but not at robot2. another thing to keep in mind is that connectors have two ports (A1B1 and A2B2 or "IN" and "OUT"). it is important to make sure that only IN is used at end nodes because when terminator is enabled, OUT is disconnected. the other important detail is that on nodes that have two cables connecting to same connector (here that was robot2), it still matters which one goes to IN and which to OUT (if you are smart). it is a good idea to always connect to IN cable that is going to or toward PLC. this allows you to terminate any point on network and disconnect any part of bus while keeping bus segment at/around PLC intact. this way you can test your configuration and gradually add more nodes simply by flicking terminator switch...about point 5 (***)
Insert Kuka CP5614A2 (under Other or just search for “kuka” in hardware catalog)sorry, don't have Step7 project or software to make a sample hardware config...
Hi Panic,
Do I have to KUKA GSDs if I want to configure the Profibus Master setup on KRC2 or it is only for slaves. If yes, then could you provide me the GSD files. I made the configuration and copied the .ldb file to the robot but getting communication error.
Thanks
No.. you only need GSD files for slaves. This is then used to create configuration for device acting as a master.
No.. you only need GSD files for slaves. This is then used to create configuration for device acting as a master.
I do not understand fully. Could you please elaborate a bit?
Thanks
Bus is just a cable. All devices on a bus are practically wired in parallel. Because of this, only one device can talk but everyone can listen.
This requires certain regime in which one device is a master (initiates all communication) and all others are slaves (replying only when spoken to).
Each device must use same speed etc but have unique node address (macid). Duplicate macid numbers are not allowed...
In order for master to communicate with slaves, it needs some information about each of the slaves. This includes bus speed, macid of each slave, size of input block, size of output block, diagnostic info etc. This information is compiled into a database. This database is needed on the master node only but to create it you need software (bus editor) and of course a library of device description files (GSD file for each of the slaves).
On KRC2 that editor for profibus is Step7., for Devecenet it is any text editor (if using MFC). For ETHERNETIP that editor is Aplia etc.
On KRC4 all of those editors are part of WorkVisual.
Different networks have different device description files:
GSD for profit us
GSDML for profit
EDS for Devecenet
Etc.
Those device description files are downloaded from manufacturer of the particular device and must be integrated into editor before one can use them to make a configuration.
In case of KRC4 all of the non-Kuka devices are to be added into DTM catalog. Sometimes such editors also offer templates so you can make your own device description files. Such 'generic devices' are available in Work visual for Devecenet and EthernetIP. For more complicated setup and modular devices always get files from manufacturer.
Thanks Panic...
I managed to configure the Profibus network on KRC2 robot after quite a struggle. It was an old project running since 2011 and customer added new festo solenoid valves on gripper. The guy who configured the network back in 2011 didn't has the project and ended up with only .ldb file and left the company. So, I had to build the project from scratch and do the network configuration again.
So, now I have the robots running with new module we added.
nice... doing something like this for the first time can be intimidating. i ended up making my own notes for this to train our guys and help with troubleshooting.