Ethernet IP Topology Proposal

    Hi Guys

    I'm looking into an application for the first time from a design perspective.

    Attached is my proposed topology based on Ethernet/IP (assume there is power supply available to the field devices including the Arm).

    There will not be a central PLC included in this, therefore I would like the Fanuc Controller to directly communicate/control the field peripherals.

    In my mind, this is a feasible solution.

    But I have just been in discussions with a supplier, who is telling me this is not possible...….and is kind of questioning what I currently understand.

    If you can further educate me, this would also be a distinct advantage, if I have got this wrong.

    1. Can anyone explain to me why this solution is not feasible.

    2. If this is a feasible solution, as far as the field peripherals are concerned, do you have any recommended suppliers to go with such as Balluf, Wago, Beckhoff etc and a possible link?

    3. I have some things in mind for the field peripherals like https://www.balluff.com/en/de/productf…/?key=BNI006A#/

    As ever, any information or assistance in this would be greatly appreciated.

    What is the "Product Coupler"? If it is a network switch, there shouldn't be any issue with EIP. If you're trying to daisy chain devices, it then becomes dependent on device passthrough for the network connection.

    Did the supplier give a reason as to why it won't work?

    Balluff is a good product, I have had success with them in the past. Allen Bradley 1734 I/O works well with the robot as well.

    rumblefish

    Many thanks for your comment.

    The supplier didn't really go into a lot of detail as to why not, I think they were more concerned in 'hocking' another solution.

    I 'turned off' from listening to them due to this.....I was sat in the background of the meeting (silent attendee), but what I heard really got me questioning what I currently understand.

    I've added the 'product coupler' in the topology based on the suppliers information, so to 'trigger' some questions/comments from the forum...….

    What I heard was the product coupler is a requirement as the central hub for the ip address communication.

    Then you would daisy chain each field peripheral with each other and then have one of the field peripherals connected to the product coupler.

    The product coupler 'talk's to the Robot Controller.

    The product coupler then directs the information received from the Robot Controller to the respective field device via the 'daisy chain' linkage.

    Fundamentally, the Robot Controller only talks to the coupler and not each field peripheral.

    I have (and I may have incorrectly assumed this) that external io such as the balluf device can be configured with it's own explicit IP address, therefore allowing devices to directly communicate with it.

    Effectively having this device as it's own 'node' on the network.

    Have I got this wrong?

    You can purchase the EthernetIP Scanner option for the robot. Then the robot can be the master to other slave Eip devices. No daisy chain. Every device including the robot plugs directly into a central switch.

    So basically what you have drawn but no product coupler. I've never heard of that term before.

    HawkME

    Thankyou, this is exactly what is my understanding.

    The balluff device I linked to, may not be the correct device I am referring to.

    So my way of thinking of:

    1. Robot Controller with Scanner option.

    2. Ethernet cable to an industrial network switch.

    3. Allows to connect ANY ethernet/ip remote device (that can be configured with it's explicit IP address).

    4. Just by plugging into the network switch and setting the relevant ip and eds data in the Fanuc.

    Quote

    Maybe the supplier is used to and more comfortable with having a central PLC. I personally prefer to have the PLC and think there are many advantages to that but either way works.

    Agreed...……..:top:

    The project does not warrant the additional requirement of a PLC due to the nature of the application.

    What they are used to is the 'old school method' of hardwired io and the initial direction was the 'yellow brick' method and I had them convinced of a more effective solution.

    The supplier, then undid my work and tried steering them down a different path, and at the same time, had me doubting my initial advice.

    So I just wanted some confirmation from you guys, that I'm not talking crap, as they nearly convinced me I was wrong.

    Many thanks again, I really appreciate the information provided,

    HawkME

    Below is the kind of device they were referring to as the product coupler.

    https://www.beckhoff.com/EK9500/

    p.s The supplier was not the OEM...….

    I would just get a smart/managed switch and plug everything in to that. That is the topology for almost every EIP network I've done. Balluff BNI blocks allow you to physically daisy change the network connects.

    EIP connects like a normal CATV network and can coexist with other protocols on a network.

    Sounds like your on the right track now.

    Quote

    I would just get a smart/managed switch and plug everything in to that.

    Absolutely...……….:top:

    I always thought I was on the right track, but found myself 'questioning this' and wondering, 'Have a missed something here'.

    So thought I would post it here and throw it out to the masses.

    This application in essence does not constitute a 'network' of sorts and the end user knows exactly what they require as an end result.

    What is rigid, is no PLC and no HMI as they are aware of the Fanuc's and other OEM Robot Manufacturers capabilities of delivering all of this 'under one hood' and this is the route they want to adopt.

    It's not my job to steer them down a more expensive/complex route, but to advise them in areas in which they may not be aware of.

    Thus opening a door of alternative solutions for which they are exploring very comprehensively in order to commit to a scope and now they have more options on the table now to consider than they previously thought and the ethernet/ip route with the use of the field devices/blocks has kind of ticked a big box for them.

    Absolutely do-able in my opinion and will be a very good opportunity to fully explore the Fanuc system and see exactly what she can deliver.

    As always, thanks to Robot Forum Members I can be more confident knowing 'others' and myself are sharing the same thought processes.

    Much appreciation as always...………..:blumen:

    It was definitely incorrect when your suppliers told you that your system couldn't be done. So long as the robot can communicate to everything in the system, it can do the entire process by itself.

    This system though is not something that I, as an integrator, would want to install at my customers site.

    A system like this would be much cheaper than one with a PLC and HMI, but it would be much more difficult to use, and would require my customer to spend more in training for its operators. Not only would the customer's overhead increase so would the integrator's. I would need to create more in depth and lengthy documents, not to mention I would be the one to initially train anyone on how to use the system. I would likely be fielding calls from the customer constantly regarding this machine.

    Ease of use is always one of the top priorities for the integrator. Tapping a button on an HMI is always going to be easier to do than running something from the Teach Pendant.

    Your system is 100% doable and it will be cheap, but I *highly* recommend adding a PLC and HMI.

    Muteki

    Thanks for your input, but like I said this is a 'customer requirement' and not mine and I have to respectfully disagree with some of your points.

    Quote


    Tapping a button on an HMI is always going to be easier to do than running something from the Teach Pendant.

    Isn't that the same?

    Why do you think OEM Robotic Manufacturers include built in PLC's and HMI capability?

    kwakisaki

    I totally understand the difficulty of some 'customer requirement' any kind of weird, overly complicated, or bad code I ever left in a system has been at a customer's request. Usually it was because older systems were designed like this, so even then it came down to ease of use, it was just what the maintenance people were used to.

    Quote from kwakisaki

    Isn't that the same?

    Why do you think OEM Robotic Manufacturers include built in PLC's and HMI capability?

    Let me give you an example of what I mean by easier.

    On our HMI we usually put several buttons for the operator to use the robot, there is always a 'Return to Home' button, a 'Go to Maintenance Pos', maybe some short check programs that aren't run in production, etc.

    All the operator has to do to run these programs is hit a button on the HMI, to do the same thing from the Teach Pendant the operator has to go to Program Select, Choose the correct program, Hit the program start button on the operator's panel on the Robot controller. 3 times as many steps, not to mention it now has the possibility for user error, if the operator selected the wrong program and hit start.

    In the end though if it is a customer's request there is nothing you can do about it. My suggestion then would be to create very in depth guides on how to operator the system. Make sure you train all the operators and maintenance staff on how to use the system as well, don't leave until you watch each of them successfully use the system at least once. I have been in a situation where the customer has called continuously, several months after the system was installed, asking about how to use the system because I didn't prepare enough educational documents for them. It is extremely frustrating.

    How do you prevent those programs from being run in unsafe positions but still be functional in a practical sense? I'm familiar with the concept and application of program calls via a HMI but they generally make me nervous because I've seen some pretty great crashes start that way. When perfected its a great labor saver though. I've also seen/worked on cells where if you didn't stop the sequence and run home from exactly the right position then it either wouldn't call the program due to the safety interlocks or if it DID then you'd have a robot try and go through something it shouldn't.

    Quote from kwakisaki

    Whilst I respectfully appreciate your comments again, I would be interested to hear your answer to the question I originally asked you:

    Why do you think OEM Robotic Manufacturers include built in PLC's and HMI capability?

    Like I said before the robot will be able to do all the processing for a system itself, and you can set the Teach Pendant up like an HMI to let the operators work through just the Teach Pendant. Robot Manufacturers put this capability in so that no one *has* to get a third party HMI or PLC.

    That being said Fanuc Robotics is not an HMI or PLC manufacturer, third party HMI/PLCs will have much greater functionality. But still aren't 100% necessary.

    Your system is 100% doable, I just wanted to share my experience doing something similar and the problems I had with it. Namely not educating the customer well enough on the system and it coming back to us.

    Quote from ericwiz7923

    How do you prevent those programs from being run in unsafe positions but still be functional in a practical sense? I'm familiar with the concept and application of program calls via a HMI but they generally make me nervous because I've seen some pretty great crashes start that way. When perfected its a great labor saver though. I've also seen/worked on cells where if you didn't stop the sequence and run home from exactly the right position then it either wouldn't call the program due to the safety interlocks or if it DID then you'd have a robot try and go through something it shouldn't.

    It can be a little tricky to get right. For a return to home program there are some different ways to approach it. One way is to keep track of each position the robot goes to, usually setting a unique number for each position to a register, then the robot backsteps from that position.

    You can also set up a unique path for returning to home, and when the robot stops, you compare the robots current position to the positions on the safe path to determine which point along the path is the closest.

    Also setting up Dual Check Safety is a must on any Fanuc robot. It can prevent collisions before they even happen, and force the user to jog the robot to safety manually.

    A robot manufacturers reasons of built in PLC, HMI and other functionalities span across a much wider field than just 'no one *has* to get a third party HMI or PLC'.

    But this is another topic of pro's can con's and has no relevance to my thread.

    Many thanks for your comments, much appreciated.

  • kwakisaki November 18, 2019 at 8:15 PM

    Closed the thread.

Advertising from our partners