lab2lab systems can have variable numbers of Buffers, building2building ports, Senders and instrument stations. For all these sections the first parameter will indicate the number of that device type the system has. Each device then includes its indexing number in the parameter names e.g. parameters relating to Sender number three will all start with “Sender.3” etc.
13.8.1 Common parameters for buffers, B2B ports, senders, instrument stations and collection stations
Some parameters are common to all “End-Point” devices (including Collection Stations).
Mandatory Parameters:
|
Parameter |
Description |
|
Router.Port |
All end-point devices must specify the Router port they are connected to via their transport pipe. These must be unique. If two devices have the same router port value the system will not run and an appropriate error message will be generated at start up. |
Optional Parameters:
|
Parameter |
Description |
|
MinimumPossibleTransportTime |
All end-point devices can specify the minimum possible time that a vial can be expected to travel between it and the Router. If a vial appears to arrive at either end quick than this then it may point to a problem in the system. If this parameter is omitted a default value of 1 second is used. |
|
OffLine |
All end-point devices can be specified as Offline as their start up state. If omitted this defaults to false and a connection attempt is made to each device at start up. Alternatively devices can be taken offline and brought online while the system is operational, through the UI. |
|
Simulated |
All end-point devices can be simulated. In the case of instrument stations, the instrument or the Receiver can be simulated separately. This can be very useful during commissioning and testing. If an instrument is not available but the transport needs to be tested to that instrument, then simulating it tests every other aspect of the systems behavior. |
13.8.2 Buffers
A lab2lab system can be configured to have up to three buffers. The number of buffers has to be specified using this parameter.
<!-- Buffers -->
<add key="Buffers.Number" value="2"/>
lab2lab supports two different types of buffer; the single-port design used on older systems and the four-port design on newer systems. If a Buffer section includes the parameter “Type” and this is set to “FourPort” (not case-sensitive) then the parameters expected will be relevant to that type of Buffer. If this parameter is omitted or set to “SinglePort” (or anything other than FourPort, in fact) then a different set of parameters will be expected. Only the current Four Port Buffer is described here.
13.8.2.I Four port buffer
Example:
<!-- Buffer 1 -->
<add key="Buffer.1.Name" value="Buffer"/>
<add key="Buffer.1.Type" value="FourPort"/>
<add key="Buffer.1.MinimumPossibleTransportTime" value="00:00:00"/>
<add key="Buffer.1.NetworkAddress" value="localhost"/>
<add key="Buffer.1.TCPPort" value="33063"/>
<add key="Buffer.1.Router.Port" value="1"/>
<add key="Buffer.1.PortOnBufferHead" value="1"/>
Mandatory Parameters:
|
Parameter |
Description |
|
Type |
As explained above, a Four Port Buffer must be declared as the specified Buffer type. |
|
NetworkAddress |
Four Port Buffers are controlled through a separate software application called the ConnectController. The connection parameters for this must be set. |
|
TCPPort |
|
|
PortOnBufferHead |
The Four Port Buffer has four ports to which a pipe could be attached. This has to be specified as either 1, 2, 3 or 4. |
Optional Parameters:
|
Parameter |
Description |
|
Name |
The name to be used for the Buffer can be set; this is useful if there are multiple Buffers. This could be the location or just “Buffer B” etc. If this parameter is omitted or left blank then the section reference will be used i.e. “Buffer.1”. |
13.8.3 B2B (building2building) ports
Example:
<!-- B2B Ports-->
<add key="B2BPorts.Number" value="1"/>
<add key="B2BPorts.TrafficControlEnabled" value="true"/>
<!-- B2BPort 1 -->
<add key="B2BPort.1.SystemName" value="B2BLine1"/>
<add key="B2BPort.1.TransceiverAtThisEnd" value="Transceiver1"/>
<add key="B2BPort.1.Description" value="Connection to WSJ-386"/>
<add key="B2BPort.1.Router.Port" value="4"/>
<add key="B2BPort.1.MinimumPossibleTransportTime" value="00:00:00"/>
<add key="B2BPort.1.OffLine" value="false"/>
<add key="B2BPort.1.Simulated" value="true"/>
<add key="B2BPort.1.SystemAtOtherEnd" value="WSJ-386"/>
<add key="B2BPort.1.B2B.ControllingPC" value="localhost"/>
<add key="B2BPort.1.B2B.TCPPortNumber" value="6070"/>
Mandatory Parameters:
|
Parameter |
Description |
|
SystemName |
building2building lines can be standalone or be part of a network of lab2lab systems, all tracking vial locations through a single, central database. If this is the arrangement then each line must have a unique name. This name must specified in the SystemName parameter. |
|
TransceiverAtThisEnd |
Each building2building line has two Transceivers referred to as Transceiver1 and Transceiver2. The Transceiver to which the lab2lab system will pass and receive vials has to be specified. The building2building control software will not operate if the lab2lab systems at each end both claim to be connected to the same transceiver. |
|
Description |
A description of each line is required for display and error reporting. This could be the name of the end destination. |
|
SystemAtOtherEnd |
As with the SystemName parameter, for more complex lab2lab networks the precise name of the lab2lab system at the other end of a building2building line must be specified. If the system at the other end is not another lab2lab system but instead simply a remote Sender then the value for this parameter should be the same as the SystemName value. |
|
B2B.ControllingPC |
Each building2building line is controlled by an instance of the building2building software application. The name of the PC hosting this application and the TCP Port through which it can be contacted must be specified. |
|
B2B.TCPPortNumber |
|
Optional Parameters:
|
Parameter |
Description |
|
TrafficControlEnabled |
If a lab2lab system is acting as the center of a star-network and hence has multiple building2building lines, then optionally the TrafficControlEnabled parameter can be set. If this is true then an additional system setting control will appear in the UI allowing the maximum number of active building2building lines to be specified. If air supply requirements are a concern then it can be set that, for example, no more than 2 building2building lines can do long distance, Transceiver to Transceiver vial transfers at any one time. The Director application will control the granting of permission for such transfers as and when different lines request it. |
13.8.4 Senders
Example:
<!-- Senders -->
<add key="Senders.Number" value="5"/>
<!-- Sender 1 -->
<add key="Sender.1.Name" value="Sender A"/>
<add key="Sender.1.Description" value="L35 (floor C) Ext 4349"/>
<add key="Sender.1.MXBoard.Name" value="sender2"/>
<add key="Sender.1.MinimumPossibleTransportTime" value="00:00:00"/>
<add key="Sender.1.Router.Port" value="7"/>
<add key="Sender.1.Simulated" value="true"/>
<add key="Sender.1.OffLine" value="false"/>
<add key="Sender.1.ShortBlastEnabledForThisSender" value="false"/>
The standard end-point mandatory and optional parameters apply to Senders.
Mandatory Parameters:
|
Parameter |
Description |
|
MXBoard.Name |
The IP address or network name of the Sender’s network card must be provided. |
Optional Parameters:
|
Parameter |
Description |
|
ShortBlastEnabledForThisSender |
Depending on the physical layout of the lab2lab system, it may be useful to enable, in the Director system settings, the ShortBlast values for Senders if the distance between Sender and Router is short or the vial will drop under gravity. If enabled, then the ShortBlast control will apply to all Senders unless they have this parameter in their config file section and it is set to true. |
13.8.5 Instrument stations
There are generally two section to each Instrument Station; the Instrument and the Receiver. Each instrument type (e.g. Waters, Agilent, Bruker or ManualProcess) has their own set of extra parameters.
Example:
<!-- Instrument Stations-->
<add key="InstrumentStations.Number" value="1"/>
<!--- InstrumentStations 1 -->
<!--- Instrument -->
<add key="InstrumentStation.1.Type" value="Agilent"/>
<add key="InstrumentStation.1.OffLine" value="false"/>
<add key="InstrumentStation.1.InstrumentName" value="HPLC_01"/>
<add key="InstrumentStation.1.MinimumPossibleTransportTime" value="00:00:00"/>
<add key="InstrumentStation.1.Agilent.InstrumentType" value="HPLC"/>
<add key="InstrumentStation.1.Agilent.AnalysisTimeout" value="00:30:00"/>
<add key="InstrumentStation.1.Agilent.ControllingPC" value="WDL-543534"/>
<add key="InstrumentStation.1.Agilent.TCPPortNumber" value="16123"/>
<!--- Receiver -->
<add key="InstrumentStation.1.Receiver.MXBoard.Name" value="172.25.1.68"/>
<add key="InstrumentStation.1.Receiver.Router.Port" value="15"/>
<add key="InstrumentStation.1.Receiver.IsMotorisedReceiver" value="true"/>
<add key="InstrumentStation.1.Receiver.LCDFitted" value="false"/>
<add key="InstrumentStation.1.Receiver.Simulated" value="true"/>
13.8.6 Instruments - general
The standard end-point mandatory and optional parameters apply to Instrument Stations except that the MinimumPossibleTransportTime parameter is set in the Instrument section and the Router.Port parameter is set in the Receiver section.
Mandatory Parameters:
|
Parameter |
Description |
|
Type |
The type of instrument at the end point must be set. Current valid values are Agilent, Waters, Bruker and ManualProcess, but any other instrumentation type could be added to a lab2lab system. |
|
InstrumentName |
The name of the instrument must be provided. This is the name which the lab uses for the instrument, particularly in terms of labelling data generated by it. |
Optional Parameters:
|
Parameter |
Description |
|
AnalysisTimeout |
Agilent, Waters and Bruker instruments can all optionally have an analysis timeout value. If not set then a value of 30 minutes is used. This means that if the analysis is not completed within this time interval then it is assumed that something has gone wrong with the instrument. |
13.8.6.I Agilent instruments
Mandatory Parameters:
|
Parameter |
Description |
|
ControllingPC |
lab2lab integrates Agilent instruments via a small software utility that runs on the instrument’s controlling PC. The name of the PC and TCP Port through which the utility can be contacted must be specified. |
|
TCPPortNumber |
|
Optional Parameters:
|
Parameter |
Description |
|
InstrumentType |
lab2lab integrates with either standard HPLC stack type instruments or GC instruments. The software interface is the same for both but setting this parameter to be either HPLC or GC means that the correct image will be used in the Director UI. If omitted or blank then HPLC will be used. |
|
OutputFilePrefix |
If requested, an output file prefix can be specified. This is added in front of the instrument name when setting the data output name when an analysis is started. |
13.8.6.II Waters instruments
Mandatory Parameters:
|
Parameter |
Description |
|
ControllingPC |
lab2lab integrates with Waters instruments through a small software utility that runs on the instrument’s controlling PC. The name of the PC and TCP Port through which the utility can be contacted must be specified. |
|
TCPPortNumber |
|
Optional Parameters:
|
Parameter |
Description |
|
InstrumentType |
lab2lab integrates with Waters instruments through a standard software interface. For UI purposes, to ensure the correct image is used in the Director UI, the instrument type can be set as either LCMS, LCQTOF or HPLC. If omitted or blank then HPLC will be used. |
13.8.6.III Bruker instruments
Mandatory Parameters:
|
Parameter |
Description |
|
SampleTrack.ConnectionString |
lab2lab communicates directly with the Bruker instruments via two exposed WebServices. The connection strings for the Bruker SampleTrack and SampleProTube must be provided. |
|
SampleProTube.ConnectionString |
|
13.8.6.IV Manual process instruments
Mandatory Parameters:
|
Parameter |
Description |
|
ProcessName |
A ManualProcess instrument is merely a Collection Station to which vials can be sent. The logic which determines if a vial should be sent there is if the process name they offer matches the manual process with which the vial was registered. |
13.8.7 Receivers
Each Instrument Station has a Receiver. As previously mentioned, it is in this section that the Router port must be set.
Mandatory Parameters:
|
Parameter |
Description |
|
ProcesMXBoard.Name |
The network name or IP address for the Receiver’s network card must be specified. |
Optional Parameters:
|
Parameter |
Description |
|
IsMotorisedReceiver |
The control logic of most Receivers is similar in terms of arm extension and retraction (the exceptions are the Receiver for Agilent GCs which uses the BasicIO parameter, and Manual Processes which use a Collection Station). However, the Receivers for the Autosamplers used in H Class Waters Acquities are slightly different and for them the system needs to be informed that a motorized arm type of Receiver is being used. If omitted this defaults to false. |
|
BasicIO |
The Receivers for Agilent GCs are integrated into the instrument's carousel and only consist of one sensor and one valve, therefore they need the optional BasicIO parameter to be present and set to true. If omitted this defaults to false. |
|
LCDFitted |
Some of the older Receivers had an LCD fitted to their front which displays update messages. This was dropped from the design several years ago. Receivers with LCDs need this parameter set to true. If omitted it defaults to false. |
13.8.8 Automation senders
In the Config file Automation Senders are referred to by the older name of Chemspeed Senders.
Automation Senders used in third party integrations are a special case: logically they are treated as Senders but from a configuration point of view they are like Instrument Stations as they use a standard NMR Receiver (which is exactly like a non-motorized Waters Receiver, except with a longer arm) and have instrument station parameters.
<!-- ChemSpeed Senders-->
<add key="ChemSpeedSenders.Number" value="1"/>
<!--- ChemSpeed Sender 1 -->
<!--- ChemSpeed -->
<add key="ChemSpeed.1.Name" value="ChemSpeed"/>
<add key="ChemSpeed.1.MinimumPossibleTransportTime" value="00:00:00"/>
<!--- Receiver -->
<add key="ChemSpeed.1.Receiver.MXBoard.Name" value="172.25.1.68"/>
<add key="ChemSpeed.1.Receiver.Router.Port" value="14"/>
<add key="ChemSpeed.1.Receiver.Simulated" value="true"/>
The Chemspeed or other third party application uses a database interface to the lab2lab Director through shared tables, which is described in the 'lab2lab Installation Requirements'. Vial submission is only ever in one direction - from the integrated automation system to the Router - hence they are logically treated as Senders.
13.8.9 Collection station
In the Config file the Collection Station is referred to by the older name of Retrieval bin.
Example:
<!-- Retrieval Bin -->
<add key="RetrievalBin.Type" value="Controlled"/>
<add key="RetrievalBin.Simulated" value="false"/>
<add key="RetrievalBin.MXBoard.Name" value="172.20.1.250"/>
<add key="RetrievalBin.MinimumPossibleTransportTime" value="00:00:00"/>
<add key="RetrievalBin.Router.Port" value="17"/>
<add key="RetrievalBin.OffLine" value="false"/>
The standard end-point mandatory and optional parameters apply to Senders.
Mandatory Parameters:
|
Parameter |
Description |
|
Type |
A Collection Station can either be Controlled or Uncontrolled (not case sensitive). The latter means that it just a transport pipe going into a receptacle and vials are just blown there from the Router for a fixed period of time (5 seconds). Controlled Collection Stations have a gated mechanism with a sensor to detect the arrival of vials. |
Optional Parameters:
There are no device-specific optional parameters for Collection Stations.