You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old February 13th, 2018, 01:08 PM   #1
phuz
Member
United States

phuz is offline
 
Join Date: Jun 2008
Location: Mohnton, PA
Posts: 705
Murr Elektronik Cube67 network stops responding

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.
  Reply With Quote
Old February 13th, 2018, 01:40 PM   #2
jstolaruk
Member
United States

jstolaruk is offline
 
Join Date: Dec 2004
Location: Detroit, SE Michigan
Posts: 3,157
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.
__________________
"You can live to be a hundred if you give up all the things that make you want to live to be a hundred." Woody Allen

Last edited by jstolaruk; February 13th, 2018 at 01:58 PM.
  Reply With Quote
Old February 13th, 2018, 01:56 PM   #3
phuz
Member
United States

phuz is offline
 
Join Date: Jun 2008
Location: Mohnton, PA
Posts: 705
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.
  Reply With Quote
Old February 13th, 2018, 01:58 PM   #4
jstolaruk
Member
United States

jstolaruk is offline
 
Join Date: Dec 2004
Location: Detroit, SE Michigan
Posts: 3,157
Not that I'm aware of, this issue is new to me but not my customer. I'll post here again when I have an update.
__________________
"You can live to be a hundred if you give up all the things that make you want to live to be a hundred." Woody Allen
  Reply With Quote
Old February 13th, 2018, 02:03 PM   #5
dmroeder
Lifetime Supporting Member
United States

dmroeder is offline
 
dmroeder's Avatar
 
Join Date: Apr 2006
Location: Vancouver, WA
Posts: 1,995
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 by dmroeder; February 13th, 2018 at 02:07 PM.
  Reply With Quote
Old February 13th, 2018, 02:12 PM   #6
phuz
Member
United States

phuz is offline
 
Join Date: Jun 2008
Location: Mohnton, PA
Posts: 705
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 by phuz; February 13th, 2018 at 02:30 PM.
  Reply With Quote
Old February 14th, 2018, 07:47 AM   #7
phuz
Member
United States

phuz is offline
 
Join Date: Jun 2008
Location: Mohnton, PA
Posts: 705
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.
  Reply With Quote
Old February 14th, 2018, 08:53 AM   #8
jstolaruk
Member
United States

jstolaruk is offline
 
Join Date: Dec 2004
Location: Detroit, SE Michigan
Posts: 3,157
Update: I've got the RPI set for 4ms (the fastest allowed), a (4) branch network with a total of 14 modules. No problems so far.
__________________
"You can live to be a hundred if you give up all the things that make you want to live to be a hundred." Woody Allen
  Reply With Quote
Old February 14th, 2018, 09:10 AM   #9
phuz
Member
United States

phuz is offline
 
Join Date: Jun 2008
Location: Mohnton, PA
Posts: 705
Quote:
Originally Posted by jstolaruk View Post
Update: I've got the RPI set for 4ms (the fastest allowed), a (4) branch network with a total of 14 modules. No problems so far.
Wow, that's smoking!
  Reply With Quote
Old February 14th, 2018, 09:21 AM   #10
jstolaruk
Member
United States

jstolaruk is offline
 
Join Date: Dec 2004
Location: Detroit, SE Michigan
Posts: 3,157
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.
__________________
"You can live to be a hundred if you give up all the things that make you want to live to be a hundred." Woody Allen
  Reply With Quote
Old February 19th, 2018, 01:38 PM   #11
phuz
Member
United States

phuz is offline
 
Join Date: Jun 2008
Location: Mohnton, PA
Posts: 705
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.
Attached Images
File Type: png network.png (17.8 KB, 44 views)
  Reply With Quote
Old February 19th, 2018, 01:55 PM   #12
dmroeder
Lifetime Supporting Member
United States

dmroeder is offline
 
dmroeder's Avatar
 
Join Date: Apr 2006
Location: Vancouver, WA
Posts: 1,995
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.
  Reply With Quote
Old February 19th, 2018, 02:26 PM   #13
phuz
Member
United States

phuz is offline
 
Join Date: Jun 2008
Location: Mohnton, PA
Posts: 705
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 by phuz; February 19th, 2018 at 02:34 PM.
  Reply With Quote
Old February 20th, 2018, 03:23 PM   #14
Rson
Member
United States

Rson is offline
 
Join Date: Jun 2017
Location: Michigan
Posts: 6
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.
  Reply With Quote
Old February 20th, 2018, 03:24 PM   #15
phuz
Member
United States

phuz is offline
 
Join Date: Jun 2008
Location: Mohnton, PA
Posts: 705
Quote:
Originally Posted by Rson View Post
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?
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
RSLogix 5000 rung comment editor stops responding skeleton_bob LIVE PLC Questions And Answers 4 May 28th, 2017 01:02 AM
Banner DMX 100 gateway stops responding after sometime. shiv4nsh LIVE PLC Questions And Answers 8 May 27th, 2017 10:29 AM
DH485 network issues Nole LIVE PLC Questions And Answers 3 March 14th, 2016 04:30 AM
s7 200 gaannesh LIVE PLC Questions And Answers 10 April 20th, 2008 11:33 PM
New PLC Network Help kbradray LIVE PLC Questions And Answers 5 April 5th, 2007 10:22 AM


All times are GMT -5. The time now is 06:51 AM.


.