Dionex/Thermo VEO CAD meets SSI Prominence in Empower3

<p>Has anyone had any luck making a VEO CAD "part of" a Shimadzu Prominence system </p><p>in Empower 3? Right now, we have the Shimadzu triggering data collection on the </p><p>CAD (via the node's com port) but this requires 2 of everything (2 instruments, 2 emthods, 2 sample sets etc.) and is far from being "idiot </p><p>proof".</p><p></p><p>When we make the Shimadzu and VEO part of the same system, we get </p><p>lots of configuration errors from the Shimadzu (at least I think that this is </p><p>the source of them).</p><p></p><p>The field engineer and sales guys we've worked with </p><p>(Thermo/Dionex mostly, SSI - a little) have not had any experience or luck with this.</p><p></p><p>CDS Details: Empower 3, (enterprise) build 3471, Service Release 1;Feature Release 1;Feature Release </p><p>2</p><p>Shimadzu driver 3.01</p><p>Dionex integration for Empower 1.12, build 3814 </p><p>(also - has anyone had luck with this driver build on Citrix servers?)</p><p></p><p>Thanks in advance,</p><p>DR</p>


  • Hi

    There is in general an issue when you connect Dionex equipment to Empower using CITRIX. Root cause is the way the Dionex instrument driver works.

    We were experiencing the following issue:

    Monitoring of detector Signal did work well but when injecting the Detector (CCAD) did not start sending the signal.

    After a loooong time of trial / error and frustration we realized that it works perfectly when you start it from a LAC/e directly.
    But we did not get it to run in CITRIX.

    Finally the reason:
    When you setup the instrument in the Dionex driver software you are creating entries into the so called timebase.
    The entry you are makingis beside a lot of other things the hostname of the Client you are working with.

    Directly after installing the Dionex driver package the timebase is empty.

    At the moment when you configure the first instrument then the entries are made.

    This is what you usually do when you test the installation. Result: You are "Branding" the Dionex driver package to "ONE" Citrix engine

    If you now clone that CITRIX engine inside the farm the timebase will contain the wrong hostname resulting into that the injection does not start the detector to collect signals.

    The same can happen by the way as well for a LAC/e

    Thermo/Dionex Switzerland did help us in trouble shooting and they provided us a powershell script that does an "unbranding" of the timebase.

    That psh script must be executed on each CITRIX engine ONCE to fix the issue.

    Otherwise : No chance to get it running in COTRIX.

    Our conclusion: Dionex chromeleon software and instrument drivers are "not really" CITRIX run able.
    However Dionex did a lot of effort to identify the problem and to help us.

    Hope this information helps a bit.

    P.S. I shared that behavior with Todd Miller in Waters. So Waters is somewhat aware about the isssue and the possible workaround.

  • Thanks for the quick reply.

    In our installation, I loaded the driver onto a LACE and onto a (development) Citrix server prior to the detector being turned on.

    When the detector was installed, it was assigned a timebase using their software on the LACE only.

    So, if I understand your reply, we can anticipate serious connectivity problems witht he Citrix server as the timebase is associated with the LACE only and this script needs to be run on each Citrix server to change that.

    Given all of this, and assuming it is at least half correct, what would we do if we wanted a couple of these things available via the same Citrix client stack? Does the script provided sort it out for present and future detectors?

    Thanks again -