CTC Combi Pal Headspace Autosampler Overlapping Sample Runs

[Ski424]

Hi, I hope someone can help me!

I have a Combi pal autosampler attached to a Agilent 7890 GC using Ezchrom software.

I would like the Combi Pal Autosampler to overlap sample runs - For example - 5minutes before the end of the previous run, I would like it to pick up the next headspace vial and place it in the agitator, where it is shaken for 10minutes before injection. The GC will then finish the previous run, cool down to the correct temperature, and be ready for the next injection at the same time as the agitator has finished. There is an option in Ezchrom to do this, however it doesnt seem to work with the CombiPal autosampler.

From what I understand I need to stop the CombiPal checking for a GC ready signal before it moves the vial to the agitator, and make it only check for ‘GC ready’ once it is ready to inject. However it is very unclear how to do this, there are numerous sync and signal settings (‘objects’) on the CTC remote which can be changed and with different names (e.g. TTL-in1, SW-out2, opto-in4), none of which are defined in the manual.

I have tried changing the 'start' sync option from 'TTL-in1' to 'immediate' - which seems to be the suggested solution when I searched it. However, it made no difference? Is there another setting that needs changing?

Any help would be greatly appreciated!

[R13]

I do not have Ezchrom, but Chemstation for MSD.

However it might work similarly in Your software - you have to check.

In my software the last parameter in the PAL headspace settings is "GC run time"- here You have to put GC run time including the cool down time - i.e. time when GC will become "ready" after previous injection.

Then PAL itself calculates required moment to put next vial into agitator- to finish heating cycle for the "expected" injection time. It does not check for any signals from GC to start sample prep, only at the moment when it is finished checks if GC is "ready" and then immediately injects.

[Ski424]

Thanks for the reply R13,

I changed the GC runtime to be the entire cycle time, and when the start sync signal is changed to immediate, your quite right the Pal does seem to calculate correctly when it should take the next vial. However, it doesnt quite manage to take the next step. It tells me the timings and counts down, but when it gets to zero it just changes to "method finished" and does not take the next vial until the GC run has finished and the oven is at the start temp again?

I have tried changing numerous settings, like the blocking time - this only seems to pause it. I was thinking perhap I need to make alterations to the actual cycle (HS-inj), although the remote wont let me make alterations to the cycle on it, or in Ezchrom, so i guess I have to find another piece of software to do this.

On your pal, how do you know what individual signals do - e.g. TTL-in1? All it tells me is Active state = high (or low) and not much else...?

[R13]

Hi,

Quite honestly, I came to the working system so did not investigate or change signals/configurations.

I did not quite understand the problem You having now.

For example, lets say I have the method with:
-incubation 10 minutes
-syringe flush after injection 90 s
-GC oven program 17 minutes
- have established by observation, that GC cools down to the initial temperature and indicates "ready" in 2.5 minutes.

So I have to set in HS-inj method "GC run"= 20 minutes (or more).

Start sequence of 2 vials----->
1st vial is prepared in agitator, GC is "ready" and waits;
After incubation (countdown ends, message in Cemstation shortly flashes "Waiting for TTLin1");
Sample is injected, GC run starts;
1st vial is transported back to the tray, syringe is flushed for 1.5 minutes;
GC runs, CombiPAL waits idle until around 10 minutes into the GC run and then transports 2nd vial into agitator, starts incubation;
GC run for 1st vial is finished, oven cools down, GC becomes "ready" and waits (headspace incubation countdown for vial 2 is still runing);
2nd vial headspace incubation countdown ends, sample is injected and GC run starts......

It worked without problems like this when we used both Chemstation integrated sampler setup and Cycle Composer software.

[Ski424]

Thats exactly what I want it to do, and what it wont do...

I think I must need the cycle composer software (or some equivalent for eZchrom), to get it to work, and have contacted the supplier.

Its just frustrating that it doesnt come as standard with the origianl software and autosampler, as surely a large majority of labs will want to overlap samples!

Thanks for your suggestions.

[ingochrist]

Hey there,

A couple of things you need to make sure are correct:
Under Setup/Objects/Sync Signal/Start you should have:
TTL-IN1 -- Active state High (for a 6890 or 7890 GC)
Under Sync Signal you might need to add:
the signal "Prepare" (important to use a capital P and everything else lower case) with signal SW-Out2.
Please verify the cable from Interface on on the PAL to Remote on the GC that you have 6pins on the 15 pin end and 4 pins on the 9 pin plug.

The PAL should be able to prepare one sample ahead when using the correct times in the headspace Cycle. Please remember to use a Cycle Time as GC Runtime, which means GC runtime plus cool downtime. If you still have troubles, you can always use the PAL with the handheld control and it will be able to sync with your GC using contact closure communication. As getting started headspace guide can also be downloaded from: www.autosamplerguys.com.

Good luck!

Best Regards,
Ingo

[Ski424]

Just thought i'd update what has happened, and finish off this topic...

I have managed to get the sample overlap to work (woohoo!), by removing link between ezchrom and the combipal, and using the combipal remote to control the headspace, as long as the timings are correct, ezchrom waits for the injection, and the combipal will start agitation before the next GC ready. The only problem I may encounter is if the combipal injects before GC ready, then no data is collected, but by having an extra minute or so on total runtime should hopefully prevent that occuring.

Apparently the problem is more about the poor combatibility between ezchrom and the combipal, in addition to the lack of cycle composer software. At least I now have a much fuller understanding of the combipal!!