bof

MrPLC Member
  • Content count

    8
  • Joined

  • Last visited

Community Reputation

1 Neutral

About bof

  • Rank
    Newbie

Profile Information

  • Country Australia
  1. PLC Law

    Ok, yes a bit 'tongue in cheek' But then we all have to put up with laws written by others that don't necessarily make sense!
  2. PLC Law

    PLC law 43 - The PLC can always be programmed to overcome any mechanical design deficiencies - regardless of the laws of physics. This law is dedicated to the number of times I have been asked to make something work when the designer hasn't thought the operation through or done the maths!
  3. It always comes down to $$$. This whole exercise started with the IT guys installing RSMACC to control PLC changes, without first sorting out the connectivity. So now we have half an implementation that works and half that doesn't. Hence lots of $$$ spent without the benefits. Don't get me wrong, I agree with the concept of RSMACC - but only if it works on the whole plant. By 'works' I mean that any electrician can get on line and fault find without having to be a network guru. If this costs $$$, so be it, downtime costs a hell of a lot more.
  4. One plant I work for standardised on SLC I/O. This started as a cheaper alternative to PLC5 I/O but the plant now has SLC I/O hanging off PLC5, SLC, and Control Logix processors - all using RIO. What we have noticed is that the Control Logix (1756-DHRIO Scanner) with SLC I/O combinations are prone to faulting with comms errors. Sometimes once a week, sometimes several times a day. Sometimes they go for months without problems! Now I know everyone will shout 'electrical noise' as have AB. Our problem is that we have been through all the recommended installation details without any noticeable change in the error rate. Also we have the same SLC I/O on RIO hanging off PLC5 and SLC in the same environment without any problems. Anyone else experienced anything like this? Any thoughts?
  5. Thanks, some really useful info since: 1. These particular processors are indeed on a separate subnet of the process control network. I was trying to sort out basic connectivity (on the same subnet) before delving into why we can't see them from other subnets. 2. We are looking at firmware upgrades, but if the series D and E won't respond to the list identity request at any firmware revision - there is little point in doing it. May be why the local AB rep won't guarantee that the upgrades will work. Now have enough knowledge to ask some 'tricky' questions! Other alternative is to rip them out and replace with Control Logix. AB make this sound easy, but often the devil is in the detail, and I can't have two major parts of the mill down while we try and make the conversion work. Anyone got any experience of this - i.e. replacing a PLC5 processor with Control Logix while keeping the PLC5 I/O structure? Or should this be a new thread?
  6. No Contr_Conn, fully aware of the differences between connectivity e.g. ethernet, and the protocol in use. I realise that I can use the AB_ETH driver to communicate with either of the PLC5/E's (once I sorted out how to configure the driver) just confused by the inability to see the second one using the AB_ETHIP driver when tech note ID 9842 says it's EthernetI/P compatible. Enquiring to see if anyone else has had problems with early 'EthernetI/P compatible' revisions of PLC5 firmware?
  7. Thnks for that - I had no idea that the IP address had to be entered into the station mapping screen. My help file - Linx Classic 2.51.00.21 - is next to useless regarding the AB_ETH-1 driver Will try this when I get back on site. Still confused by the second PLC5/40E, as the tech note states that Series E Revision D is EthernetI/P incompatible. Anyone able to confirm this?
  8. We are trying to connect all PLCs in a plant to an Ethernet Network and having problems with two old PLC5/40E's. To date we can ping both processors but can't see them from RSLinx. One is Series D Revision B, the second Series E Revision D.1 Now AB tech note ID 9842 says the first is not EthernetI/P compatible, but the second one should be. So would at least expect to see the second one in the EthernetI/P tree for Linx. Same tech note says that the Ethernet Device Driver (AB_ETH_1) can be used as a workround - but this driver requires to connect to a station number and there is no facility to declare a station number for channel 2 in RSLogix5! Anybody any thoughts or experience with these older revisions? Can anyone confirm series and revisions of PLC5/40E that do communicate with Linx?