OpenLab Chemstation communication with instrument problems

Hello Agilent,

I just installed Openlab Chemstation version C.01.07 sR4 [505] in a Windows 7 computer. The IP address for the computer LAN card is 10.1.1.1.101 (SN = 255.255.255.0, GW = 10.1.1.1.100). I was able to configure:

         6890 (IP = 10.1.1.105, SN = 255.255.255.0, GW = 10.1.1.1.100, Firmware Revision A.03.8, Software  Version 6.37 [006]) 

         6850 (IP = 10.1.1.104, SN = 255.255.255.0, GW = 10.1.1.1.100, Firmware Revision A.06.02, Software Version 6.37 [006]) 

 

Using CMD I can ping both instruments without a problem. I was able to configure them with Openlab Control panel, as the system shows the instrument information under the configuration tab, (Serial Number, Firmware revision, software version, type of detectors, injectors, etc), please see attachment. The problem is that when launching Chemstation, the instrument shows as NOT READY and the instrument actuals window indicates that the Instrument is OFFLINE, and it does not communicate (yes I'm clicking launch not launch offline). We doubled checked with our IS department and they assured me it is not Firewall related.

Please help.

Parents
  • Thank you for your reply,

    I was connecting them directly to the PC, each Instrument to a LAN card. Since we could not communicate, and because this is not how it is typically set-up in our company, we switch to a hub to connect to them both. The issue was not solved. 

    Agilent's field tech installed the software, we worked for hours trying to get this to work: with hub, without hub, installed and uninstalled newer and older ChemStation versions. Originally we are not able to configure them at all, but once the GC drivers were uninstalled and replaced with new versions, we were finally able to configure and partially communicate. I think it is driver related. We are out of things to check.         

  • The first configuration that you mention (each instrument having a dedicated LAN card) is not supported and I would not recommend it. Especially with both instruments and LAN cards being on the same subnet as it appears they are configured. Having both instruments connecting to the same NIC card on the PC through a hub is the recommended configuration. Either disable the second NIC card or change the IPv4 address to put it on a different subnet to make sure that it does not interfere with the instrument communication. 

     

    Have you tried changing the gateway on both instruments and the relevant PC NIC card to 0.0.0.0 yet? 

     

    I also recently ran into a similar situation where it turned out to be the ALS firmware on the GC that was preventing the instrument from configuring and communicating with ChemStation. To test if that is the case, you can try unplugging all of the ALS components from the GCs (towers, trays, external controllers) and then try to reconfigure the instrument and launch an online session. If you are able to successfully connect to the GC with the ALS disconnected, then that would point to the ALS tower, tray, and/or controller firmware potentially being the source of the problem. 

Reply
  • The first configuration that you mention (each instrument having a dedicated LAN card) is not supported and I would not recommend it. Especially with both instruments and LAN cards being on the same subnet as it appears they are configured. Having both instruments connecting to the same NIC card on the PC through a hub is the recommended configuration. Either disable the second NIC card or change the IPv4 address to put it on a different subnet to make sure that it does not interfere with the instrument communication. 

     

    Have you tried changing the gateway on both instruments and the relevant PC NIC card to 0.0.0.0 yet? 

     

    I also recently ran into a similar situation where it turned out to be the ALS firmware on the GC that was preventing the instrument from configuring and communicating with ChemStation. To test if that is the case, you can try unplugging all of the ALS components from the GCs (towers, trays, external controllers) and then try to reconfigure the instrument and launch an online session. If you are able to successfully connect to the GC with the ALS disconnected, then that would point to the ALS tower, tray, and/or controller firmware potentially being the source of the problem. 

Children
  • Thank you for all your suggestions, this is what I have done so far,

    With computer disconnected from our Network (to eliminate firewall issues, as per recommended by or IS/IT department):

       Both instruments connected through hub - failed

       Only 6850 connected through hub - failed

       Only 6850 connected through hub + auto-sampler disconnected  - failed. (when reconfiguring the instrument the system detected the absence of the auto-sampler)

       Only 6850 connected through hub + auto-sampler disconnected + GW 0.0.0.0  - failed

       Only 6850 connected through hub + re-connected auto-sampler + GW 0.0.0.0  - failed

     

    Re-connected network and GW back to 10.1.1.100:

     Both instruments connected through hub - failed

       Only 6890 connected - failed

       Only 6890 connected + no sample tray - failed (when reconfiguring the instrument the system detected the absence of the tray)

       Only 6890 connected + no sample tray + no auto-sampler controller - failed

       Shutdown everything (6890, auto-sampler controller, re-connected tray) - failed

    Every time ChemStation is launched (no matter the instrument), the Load Method window is displayed indicating that the instrument is OFFLINE and requesting to choose between downloading method to instrument, upload method to instrument or new method to instrument. I tried all 3 options without success.     

     

    I can ping the instruments using cmd and connect to them using Telnet 

     

    Any other ideas?

    Thank you

  • Please look in the Windows event log for errors. To see it, open the Event Viewer. In the navigation pane on the left, under Windows Logs, select Application. Look for sources which include 6850, 6890, or 68xx. Note that ones which indicate HPCTRtp.cpp, Line 254 are not a real problem, but other reports might provide useful clues.

  • Thank you for your answer, the computer /Windows 7 was the problem once we switched to a new computer with Windows 8.1 the installation was successful 

Was this helpful?