Too many times Communication failure

<p>Once again and in the middle of a sample set a communication failure for the PDA detector and due to that stopped injecting</p><p></p><p>the rest of sample set .The LACE was rebooted and still resetting the PDA did not  respond .</p><p></p><p>Only turning off the PDA and after few minutes turning on was usefull .</p><p></p><p>What can cause this repeating error ? and How do you solve it ?</p><p></p><p>Thanks</p><p></p><p>MK</p>

Comments

  • If you have your communication failure, is there an active connection between your PDA and your switch at the back of the UPLC?

    Also you can check in you DHCP server to find the IP address of your  PDA, and then use the ping command to check the connection.

    We recently had recently an electricity shutdown, and were forced to delete an entire UPLC system and make a new one in Empower before the communication was back.

    Good luck

    BJ

  • I have a Nano ACQUITY which had numerous "Communication Failure with nBSM" during the last week. I had re-installed the ICOP, re-written new methods/folder in case they were corrupted. However, it still stuck unpredictably in the middle of any runs (1st, 4th, 6th) in a set of 10 runs after each total re-boot. The control software is MassLynx. It passed the "Ping" test with Net Evaluator through the long July 4th weekend. The local engineer came in and could not find anything obvious. It passed a 6-runs test, but failed a 10-runs test after changing a new ethernet cable.  I changed the ethernet box, UPS battery back up to the PC as well last Sunday to see if this "Communication Failure" issue will go away. It still have all the green lights on the 5th run of a 7-runs test.

    I have run the nano/Synapt in the current configuration for the last few years without this problem, even 24/7 for 6 days in a stretch many, many times. Could it possibly be related to some recent security patches automatically updated by IT?

    Mine is with the nBSM using MassLynx. Yours is PDA using Empower. Just to share my puzzle and frustration as well.

  • We had similar issues. To fix it we reinstalled the ICOP, made sure the firmware is compatible with the software version (this was the main fault that we had). Just to cover it all we had upgraded and increased the space on our computers. Also our subnet IP was similar to Waters IP so we had to change that. (I am not a networking person, but this is how much I understood of what our IT department informed me)

  • Thank you for chipping in your observations.

    Our local engineers had done that with a clean software install and the intermittent issues did not go away. We had tried the following list of actions, but most of them did not help much with the intermittent nBSM pause due to "Communication Failure".

    1) Change Ethernet Box (a few), Ethernet Cables (just some, not all)

    2) Change 3 electronic boards in nBSM

    3) Swap a loaner nBSM

    4) Swap a PC (standalone, not connect to local network)

    After a couple of months of frustration, and running out of obvious items to change. We are now changing extension power cables, and put everything on different UPS batteries to spread the load/ dirty power. Our local engineer actually got a "minor shock" from the Ethernet Box indicating that the box was not grounded properly with only 2 pins power cord. It could be the build up of electrical charge causing this Communication Failure. We had set up 2 consecutive overnight runs without any incidents so far. However, we had "Marginal" in the NetEvaluator monitoring the traffic (ping). Do anyone have any idea for Pass, Marginal or Fail? Please see the attached pdf (Slide 4 for the NetEvaluator).

    Albert

  • Trying to tap into the Online Forum for suggestions.

    We still have that intermittent "Communication Failure" which halted the subsequent runs. It seems that we may have some grounding issues. It is not ideal to have strayed floating voltage on the Ethernet box (or any senitive electronics) that could give you a minor shock. The engineer suspects that it could be a Floating Ground issue. Anyone in the Forum has any suggestions or experience on this subject? I have alerted our Facility to look into it. In the meantime, I have connected a grounding wire from the Ethernet box to one of the chasis ground bolts at one of the back panels on the nano system.

    I had two overnight runs completed without any incidence. The 3rd set of test runs is more than half way through.

    Any comments on Floating Ground or Ground Loops are most welcome.

    Many thanks.

    Albert

  • Hello

    Try to see in event viewer application log for any .NET RUNTIME error

    Regards

    Rathan

  • Thank you for keeping us update on this type of issue.

    For my MassLynx/nanoUPLC, the "communication failure" was resolved after we put a grounding wire on the chasis between Synapt and one of the nanoUPLC module.

    Recently, we had numerous "communication failure" on multiple machines (BioAlliance, UPLC). Waters engineers believed that the issues were related to anti-virus installed by our IT. We still had issues after they removed anti-virus software. I have been told to unplug from the network when I am running my BioAlliance. I do not think that the root cause(s) has been identified, but I shall do whatever make sense to get my work done.