Murr Elektronik Cube67 network stops responding

phuz

Member
Join Date
Jun 2008
Location
Mohnton, PA
Posts
1,043
Revisiting an issue with a customer from about 6 months ago where we have two Cube67 networks. The network has a 56505 bus module and then 7 I/O modules which are connected to that bus. Randomly, the machine will stop working because it's waiting for a sensor input to advance to the next step. The network is down and I am unable to even ping the bus module. If I cycle the 24vdc power to the module, it and the I/O modules connected come back to life and the sequence resumes as if nothing was wrong.
I spoke to Murr about this and they said they've never seen one stop responding. Even if an I/O module were to fall off the bus, the main bus module should still communicate and the web server would still show connectivity. Well, not in my case. Looking for anyone who has experience with these and can shed some light. I am starting to wonder if the bus module itself needs replaced.
One of the I/O modules is on a moving part and the cable is in Cat-Track. Supposedly the life cycle of the cable is 1M cycles, but we estimated this to be around 260,000 thus far. Even if it were to fail, I would expect the I/O module to fall off, not the entire bus network.
 
They're not telling the truth about not seeing that problem (or their tech support people fail to share problems among themselves). Its been an issue before and may be on a new machine I'm currently commissioning. The latest from Murr is that all locations where components are mounted should share a common ground, so we're grounding all component locations using heavy braid. The machine is just getting going in dry cycle and I've only seen an output module fall off the network but haven't spent a lot of time investigating it.
 
Last edited:
Thanks, glad I'm not alone here. Were there other issues posted in this forum? I looked around but couldn't find any relative posts.
 
So we use Murr quite a bit, my experience is that I/O module can/have dropped off of the network and it will cause an error in the I/O tree, but it does remain ping-able. I'm not sure what would cause it to stop responding to pings and need a power cycle.

There are some "things to know" with Murr. As jstolaruk mentions, grounding is important. Use 4000-71001-0410004 on all blocks.

Pay attention to cable lengths, there is a maximum length of each branch. 10m if I remember right (we use the + node these days which has a longer length).

There was a buggy firmware revision for that node. Check which revision it currently has in it, I will go back and find my notes on which revision was buggy and what the bugs were. I remember a few years ago having to flash a few of them, the reason escapes me at the moment.

Put terminating resistor at the end of branches and unused ports: 7000-15041-0000000 The system will often function without them, but they should be there.

Early on when we first started using the system, we had some "randomness" going on, once we started properly grounding, we haven't really had "issues" since.

edit: After digging, I realized that the firmware issue I was referring to applied to the Cube67+ module only, so disregard...
 
Last edited:
The end of the lines have terminating resistors. The bus module is grounded using a strap, but I don't see how to ground the IO modules (56681) unless they are just grounded to the frame they are mounted on. There are a few 10m cables, a few 8m cables, and a few 1m cables.

Update:
I tested the module dropouts by unplugged various modules and it shows up as a disconnected module in the web server, and obviously I can still ping it. I really think this is something else and possibly a faulty main bus module. When the network would stop communicating, all of the LED indicators on the bus module were still solid green just like when it was running.
 
Last edited:
We'll see how this plays out, but I changed the polling rates of the "bad" network to 24ms input and 100ms output. I also changed the Ethernet port on the switch, which is your run of the mill 8-port Netgear office grade switch.
 
Not a big machine. I'm trying to sense some bolts being blown over from a bowl feeder to a nut runner and the switch is monitoring the tube so I need to be fast.
 
I finally got to see what the operators were saying occurs. We noticed we weren't getting prox switches and a few of the solenoids were being energized in the code, but not actually activating. One of the MURR modules had fallen off, and I could still ping the main bus module. So is this most likely a cable or an issue with the module itself? The two 56691 modules are right next to each other on the DIN rail.

network.png
 
It could be an issue with the cable between the two 56691 modules or the module itself. Did you happen to get a look at the LED's on the 56691 or the 56730? Also, the the faults page has some good information.

Another issue could be the length of the cables on that branch. Do you know how long those cables are? There is a 10m max length on each port.

I have a small chunk of code that detects when a module drops off of the network. I can share it with you when I get back into the office if you are interested.
 
I was thinking the cable, but it looks in great condition, and its only a 1m cable since the modules are next to each other. The LEDs were completely off on both the 56691 and the 56730. I don't see a faults page on the bus module web server.

Would an overcurrent cause a module to shutdown?
And yes, I am definitely interested in that. However, this application is Yaskawa. The only status I have right now is a bus module status, and 4096 means GOOD.
 
Last edited:
Any chance you are reaching a current limit?

One thing that often gets overlooked is all the devices drawing power on the 24vdc bus.

I personally found it good practice to 'feed' a fresh power supply every couple of modules with a Y-splitter. Maybe that last module (or the one before it) is reaching it's max at one point during the cycle and dropping out.
 
Any chance you are reaching a current limit?

One thing that often gets overlooked is all the devices drawing power on the 24vdc bus.

I personally found it good practice to 'feed' a fresh power supply every couple of modules with a Y-splitter. Maybe that last module (or the one before it) is reaching it's max at one point during the cycle and dropping out.

That's why I asked that yesterday. Would overcurrent cause these to drop out?
 

Similar Topics

I have a murr IMPACT67 Pro E DIO8 IOL8 M12L 5P and a Magnetic sensor MSA213K. connected to a L18. encoder is connected to port 0 and I am...
Replies
5
Views
602
Hoping someone can point me in the right direction here... Studio 5000 v33.11 We have a Murr IOL master block (#55144) configured as an EtherNet...
Replies
8
Views
2,043
Hello all, I am working with the above stated hardware for the first time. Has anyone used a EtherCAT Cube67 with Sysmac Studios before? If, so...
Replies
5
Views
1,657
Hello, I was looking for alternatives to using the standard AB Local IO and I came across the Cube 20 series from Murr. I know the response...
Replies
10
Views
2,213
Can anyone elaborate on the differences on how these technologies work? It sounds similar, but IO Link adds the addition of sending parameters to...
Replies
6
Views
3,170
Back
Top Bottom