input vs input rel in event table

[ScottHorn]

Hello,
I have a question about "input" < or > and "input rel" > or <. I have read the manuals and help files, and understand that the input voltage considered is zeroed relative to the "baseline" at the start of an analysis when considering an event that uses inputrel instead of input. I'm having some trouble applying this concept to a real world situation. If possible could you provide some example situations where the use of input vs inputrel or vice/versa would be important in getting the desired behavior from an event table. Specifically, I'm doing the type of analysis I described in a previous post, in which one immuno-affinity process is achieved using a sequence to control multiple steps (loading, washing, elution, regeneration of column), with seperate methods for each step. There are some steps which start with a high UV signal which will eventually decrease, some that start with a low uv signal that will increase and then decrease, and some where the uv signal will change unpredictably over time. I'm wondering which type of input event I should use for each step. I understand that this is not a typical application for your software, but we've found it to be extremely flexible, and useful in a lot of situations that it was probably not initially written to handle.

Also, Mr. Ivan Vins, your suggestion about connecting the start and ready inputs and outputs worked without any problems. I am now able to run my processes as a sequence using different methods. As you can see I'm still trying to perfect my event tables, but the ability to use a different one for each step in the process has helped immensely

[Ivan Vins]

I am sorry for the late reply - I will suggest to use the Input< and Input> preferably, as we suspect some problems in the InputRel with some detectors.

The Event detection is based on signal crossing the preset level, that means the event Input< will be triggered only when the signal drops bellow the set value. If the run starts with signal below the set level, the signal must first rise over it for the drop be detected.

[ScottHorn]

The reason I ask is that I've noticed odd behavior from one of my Clarity stations with regards to the UV detector. We have one UV detector and one pH electrode (amplified) configured on the INT9 card. I noticed that events based on UV input seemed not to occur at all. In an attempt to diagnose the problem, I tried inputrel. After changing all events to inputrel instead of input they worked fine. I've even tested this in simple "dry runs" where I use the zero knob on the UV detector to simulate a peak. If I use input> or < no events take place, no matter what kind of UV input conditions I set. However, if I use inputrel the events take place normally. My detector is an older GE model, and uses a simple 0-1V 2AUFS chart recorder output.

[Ivan Vins]

This looks strange, please could you send me some example chromatograms (as prm files) ilustrating this behaviour?

[ScottHorn]

I've tried posting the relevant PRM files here, but the forum doesn't allow posts with the PRM extension. I will send them to the tech support email listed on the main website. To sum up the issue I'm having, the events I use in my methods don't work if I use the input> or input< conditions, but they do work if I use inputrel> or inputrel<. It wouldn't be a problem for me to use those two instead, but it seems that some of the events take place at different values than I set them for, and I think that may have to do with the inputrel conditions. For example, if I set a valve to change from position 1 to position 2 when the UV signal rises above 0.1 AU, if I use input> 0.1 nothing happens at all. If I use inputrel> 0.1 the event will happen, but it may happen at 0.15 or 0.05 AU instead. I believe this may be due to the fact that the UV detector input does not always start at zero with the kinds of sequences I am running. I have another clarity station where I use UV detector inputs from the same model of detector to control a fraction collector and have never had this type of problem with that system.

Scott Horn

[Petr Kohutek]

We have received the files, our programmers will inspect them and let you know as soon as possible.
I will also ask our admin to enable prm files in the forum, meanwhile it is possible to send any files packed as zip archive.

Thanks

[Daniel Mentlik]

So, the addition of *.prm, *.cal, *.gal, *.met, *.cfg, *.dsk, *.audit, *.sst, *.seq, *.dgz and *.prj should now be fully functional to posts on this forum.

[Ivan Vins]

I guess the problems are caused by the conversion of the analog signal in mV to detector signal units. According to the chromatograms, a conversion 0,002 AU per 1 mV was used. This is OK, but there is a default threshold for the Input events to eliminate multiple event triggering by the signal noise - the default value (set by the Clarity.ini file in the windows installation directory) is 1 in signal units - that means 1 AU in your case.

Please try to use 2 mAU per 1 mV for the conversion or adjust the threshold value accordingly.