Agilent 6890A signal 1 buffer overflow

[Bren]

Siluria.zip

Files requested in the Technical Support note

(230.97 KiB) Downloaded 770 times

Hello,

I am running Clarity as a trial on an Intel Q8400 running Windows 7 x64 to control an Agilent GC 6890A with firmware A.03.07. Everything seems to be working except I get the error "GC Error Agilent 6890 - signal 1 buffer overflow" usually two or three times at the end of a run but not always. Signal 1 is a FID detector at 1-100V, 10Hz. I get the chromatogram but have to click through the error messages or it stalls Clarity.

Anyone have any ideas?

Thanks

Edit: I am using a JetDirect card J4100A with a static IP to talk to the GC over ethernet.

[Daniel Mentlik]

Dear Bren,
the files and the error message indicate to a problem with the 6890 GC, when the communication is slow and Clarity does not get the data in time. Taken into account your Clarity version, it is most probably a false message that appeared even after the bug was already repaired in the code.

The false message was found and repaired in the version 3.0.3.269, thus the update to the latest Clarity release (3.0.3.358) available on our web pages should help. The newest version is available on our website for free download to registered users with the filled-in serial number of their station, thus, please, update your account on our website http://www.dataapex.com (using the menu Login/Account Details) with the s/n of your station (as can be found using the Help/About command from the main Clarity window). The download center can be found here.

To reinstall Clarity, it is recommended to backup your data first (just to make sure), uninstall the current version using the Start button/All Programs/Clarity group/Remove Clarity and then install the new, downloaded version. When you are asked whether to preserve the existing configuration, select yes.

[Bren]

Great! thanks a lot, everything is running smoothly with the current version of Clarity. I have tested with both serial and LAN control and do not get any error messages, however serial control seems much more responsive (sending methods and starting runs, etc.). Using serial control is not a problem for us but is this behavior expected, if not any ideas?

Thanks again.

[Daniel Mentlik]

Dear Bren,
the relative slowness of the LAN communication is caused by the JetDirect card. We have experienced some slowing of the communication with it, compared to the serial communication, but it should not cause any real problems.

[Bren]

Ok, I will stick with serial unless I need remote communication.

Thanks for the help,
Bren