• Not Answered

CIOC auto sense failure issue

I have a new Charm I/O card installed. Its shows up in decommisoned node list when powered up. I added it to my IO card and tried to auto sense it but it fails after trying it for nearlt 30 mins. Error: Cannot sense the CIOC card. Tried to launch it DeltaV IO studio buit it doesnt download from there as well. Tried swapping the card, decommisoning it, swapping the communication cables but nothing works. 

Can someone help with the install of these CIOC cards?

7 Replies

  • This is probably a dumb question, but did the CIOC need a flash upgrade since it was new? A version mismatch could cause an issue like this.
  • In reply to Matt Forbis:

    No the CIOC does not need a flash upgrade. Checked the version and both the PK controller and CIOC card are on v14.
  • In reply to Summer:

    Here is teh update. After troubleshooting it for hours we found that our VMware and CIOC IP address were not communicating. After fixing this we are not able to commision and download our CIOC cards corrcetly.
  • In reply to Summer:

    The most common cause of the above symptom ( Decommissioned device shows up and can be commissioned, but after commissioning, no communications) is because of Network cable connections are wrong. With the primary connected to the secondary and vice versa, the Device is seen by the Pro Plus via the broad cast messages, but once commissioned the node applies its IP addresses and this prevents the normal communications across the wrong NICS.

    In virtualized environments, we can get the virtual switches mixed up on the external NIC or in the device set up. Sometimes two wrongs make a right until they don't. I had one customer using a virtualized Pro plus on a MAC PC. We had this symptom and I walked through what seemed a crossed network in setup over the phone. Could not find the issue. We sent someone to site and they found the MAC PC had an IP address assigned to the NIC that the virtual switch was connected. to, and this blocked all the normal traffic once the Devices were commissioned to their 10.4.0.x/10.8.0.x addresses. Since the packets did not belong to the NIC's subnet, it did not pass them on into the virtual switch. Broadcasts came through though. Not being familiar with the MAC set up, I could talk him through that, and he believed there was nothing wrong with the MAC. In the end, it was blocked Unicast traffic because of network subnets not being properly connected.

    Andre Dicaire

  • In reply to Andre Dicaire:

    I worked in several DeltaV plants and most of the time I encounter this issue of swapped Primary and Secondary networks. I diagnose this issue by logging in to a DeltaV station and disconnecting its Secondary ethernet connection then ping the Primary IP address of the problematic node. The issue is confirmed when I do not get a ping reply otherwise the issue is somewhere else.
  • In reply to Neil Castro:

    Make sure to ping the Primary IP of a healthy node and confirm to receive a reply otherwise the DeltaV station that is use to send a ping may have issues as well.
  • In reply to Andre Dicaire:

    from DeltaV diag , right clic on CIOC and tcp Ping and/or telnet to get more information on possible causes