Hai Guys,

Presently I have problem with VCMI & UCVH card on R core, which is failed to communicate via ToolboxST. Before rebooting the R rack, VCMI still communicate with others I/O modules & no IONET issues, only the UCVH failed to communicate with ToolboxST (message: Error connecting to target: 192.168.XXX.XXX windows socket operation failed). However, after power cycle (Reboot) on R rack the VCMI failed communicate to the I/O modules and UCVH shown red led lit at all.

Action has been taken:-
1). Power off R rack and pull out UCVH for Re-flash CF memory.
2). Download Compact Flash for R & successful. Insert the CF memory in UCVH. Installed UCVH into R rack and power up.
3). Ping the IP address & successful replied. Then download pcode runtime & application code, to permanent storage only.
4). Power down the R rack for 3 minutes and power up again. The UCVH red led still lit and failed to communicate.
5). Now I replace the VCMI card with new spare by follow the instructions as stated in GEH-6421. However, after power up the R rack, the problem still exist.

Appreciate if you can provide any advice. Let me know if you need more information.

Thanks

 

I seen this WAAAAYYYYY too many times. The problem was (more than once) a bad solder connection on the BNC connector on the VCMI. (The time it REALLY charred my arse was when it happened to the <S> IONET BNC connection on the <S> processor--screwed all communications up between the VPROs and the VCMIs and the UCVxs. It would work sometimes (when I unknowingly bumped the IONET cables) and not work others--when I didn't even touch the IONET cables (or so I thought, anyway). It was a right bugger. Caused me weeks of grief.)

Had it fixed (the solder joint), and the problem started a few months later. Tried supporting all of the IONET cables with NO tension on the <S> BNC tee/VCMI connector, had the solder joint re-soldered, and the problem still reappeared at the site months later. The Customer had ZERO money for spares, and complained LOUDLY about no support (to the wrong persons/companies). But the unit was out of warranty (long out of warranty) and there was nothing to do. And, this was at an LNG facility (bet they have money now!!!).

There were other causes (none of them the UCVx, though). Corrosion in BNC connectors (poor temperature/humidity control in the compartment where the Mark VI was located); a couple of bad VCMIs (more than a couple, actually--and downloading to the VCMIs is NOT well documented (think "topography")); a bad IONET cable (it had somewhow gotten crushed in one place--must have been the factory (this panel came from Belfort...!); and even a bad Ethernet EOL (End of Line) resistor.

There's several things to check. Again, replacing VCMIs is not documented very well (that "topography" thing--don't ask me to explain it 'cause I never completely understood it; something to do with identifying all of the cards in the processor--including the VPRO--for that VCMI, I think).

While I always found it helpful to do a logical check of every possibility to try to positively identify the root cause, most Customers didn't--they just wanted the problem fixed. So, the shotgun approach was most often used (meaning several things were tried at once with ZERO chance of identifying what the root cause was)--and when it came time to hand over the report of the service call when there was no single, root cause identified and found, well, some people threatened to withhold payment of the bill. So, I picked what I felt was the most likely cause, and threw it under the bus (never the same cause though!).

 

GT_MARK6, If you are still watching this thread I would ask if you have tried replacing the "R" core processor, UCVH? I have not seen everything, but I can say I have yet to ever see a CF card go bad or get corrupted. The CF card is only needed when the processor is cold booted, otherwise it really doesn't do much when the rack is healthy and in control. As WTF has said the process of replacing a VCMI is not well documented to the degree it should be. If you are able to ping the IP address of the processor, but not able to connect to it with Toolbox then that tells me that the processor is not booting up properly and able to at least execute its own firmware/Bios.