Introduction

While simulations and remote control can never substitute hands-on experiments and experience, remote control experiments provide added flexibility and options in teaching and training radiochemists. Since RoboLab is based on remotely controlled equipment, the experiments can be done without the usual safety training required to enter facilities classified for radioactive work. Furthermore, institutions without suitable laboratories can perform experiments they otherwise would not be able to conduct.

RoboLab remotely controlled experiments are accessed through a web browser interface to a physical laboratory hosting the experiment. The RoboLab concept was originally developed as a pilot project at the University of Oslo (UiO) [1] before it was further expanded as a part of the EU-funded project series CINCH (CINCH-II, MEET-CINCH, and A-CINCH) [2]. The software has gone through several generations, exploiting the functionalities of the rapidly evolving IT industry and how society adapts to digital technology. Right from the start, the system has been based on the LabView graphical programming language developed by National Instruments Corp. (NI) [3]. Although it is a general-purpose programming language, LabView is frequently used for instrument control and monitoring, greatly helped by the ease with which the system is connecting to NI hardware and firmware to interface experimental hardware.

NI's LabView development system provides the possibility to quickly and easily develop web-based “virtual instruments” connected to real hardware. For remote monitoring and/or control several options exist. For RoboLab, the cloud-based SystemLink platform was selected to establish communication between the users and the server. This way, there are no restrictions on where a RoboLab user is located, provided reliable internet is available. Furthermore, SystemLink allows easy interfacing between a web application and the laboratory equipment without any firewall access issues. Firewalls gradually made the previous versions of RoboLab practically useless as institutions and software providers upgraded their security to withstand increasing threats.

The very first RoboLab system that was put to use was developed at the University of Oslo. It allows students to perform neutron activation of silver by means of an isotopic neutron source and measure the resulting gamma emissions. Through this, the students get an opportunity to learn the basic principles of neutron activation analysis by performing an irradiation experiment from their local computer. A 22 g silver disk, mounted on a holder that slides on a transportation rail, is transferred between n-irradiation and detection sites by applying suction from the destination end. Neutron activation of the stable silver isotopes with thermal neutrons (thermalised with paraffin) yields two short-lived silver isotopes according to the following nuclear reactions:

$$^{107} {\text{Ag }}({\text{n}}_{{{\text{th}}}} ,{\upgamma })^{{{1}0{8}}} {\text{Ag }}({\text{T}}_{{{1}/{2}}} = { 2}.{\text{41 min}};\sigma_{{{\text{n}},{\text{ th}}}} = {\text{ 35 b}})$$
(1)
$$^{{{1}0{9}}} {\text{Ag }}\left( {{\text{n}}_{{{\text{th}}}} ,{\upgamma }} \right)^{{{11}0}} {\text{Ag }}({\text{T}}_{{{1}/{2}}} = { 24}.{\text{6 sec}};\sigma_{{{\text{n}},{\text{ th}}}} = {\text{ 93 b}})$$
(2)

When the pre-set irradiation time is reached, the silver disk is automatically returned to the detector end. The detector is a sodium iodide γ-detector connected to a single-channel analyser that measures gammas in the 600–700 keV energy range from the silver isotopes produced in Eqs. (1) and (2) (multichannel spectra are not measured). The pre-set energy range covers both 633 keV from 108Ag and 658 keV from 110Ag. By measuring the emission rate as a function of time in suitable (user-selected) time intervals the resulting decay curve of the two isotopes can be deconvoluted. The exercise provides insight into nuclear reactions, neutron activation, disintegration properties, measurement of γ rays, and more. The web application used by the student can be adapted to the desired learning outcome without changing the RoboLab setup in the physical lab.

Another remotely controlled exercise developed at UiO deals with the absorption and detection of γ radiation. Three pneumatically operated rails with various shielding materials are placed between a 137Cs source and a γ-detector. Thus, γ absorption can be measured as a function of material type and thickness (mm). The system is prepared for expansion to use three different γ-ray sources (e.g. 57Co, 137Cs, and 60Co), but this will require measurement of the complete γ-ray spectrum by a multi-channel analyser and not simply the count rate in a hardware selected energy region as done by the current setup.

Three additional RoboLab setups were developed and implemented at the University of Hannover. These exercises offer experiments with high-resolution γ-spectroscopy of environmental samples, measurement of auto-deposition of for instance 99Tc on different metals like iron and copper, and an ion-exchange column with on-line detection.

Below is the newest version of the RoboLab software briefly described together with a description of the construction of a sixth RoboLab system, physically situated at the University of Oslo. The new system provides the remote user the opportunity to make a radionuclide generator by pumping selectable solvents through a cation exchange column. Once prepared, the column can be used to elute 1.2-min 234mPa and measure its half-life.

The new RoboLab software template

The program structure is based on the compartmentalization of tasks. LabView has built-in parallel processing capabilities that make such compartmentalization relatively easy to implement. Each task is written as a standalone module that runs completely on its own and deals only with a certain aspect of the overall system. The modules communicate with the others through messages and system variables. Figure 1 shows the general logic behind the server application template.

Fig. 1
figure 1

Schematic diagram of server system flow. The connection to the firmware is not illustrated. The person icon with a wrench illustrates the user overseeing the experiment (if needed) and the person icon with the globe is the remote user

Full size image

The core of the application is the hardware message module. This module will control the laboratory equipment and report status and results. It acts on messages issued by other modules and does not interact with the local or remote user directly. Such interactions are exclusively handled by the local and remote event handling modules. Events for the latter module are received through the cloud service. These two modules will translate user interactions into messages. Hence, a command e.g. to start counting will be handled identically regardless of if it is given locally (from the keyboard of the server computer) or received remotely (through the web client who sends messages via the cloud service). In both cases, the result of the command will be an identical message sent to the hardware module to start counting. A third module is also able to send commands to the hardware module and is constructed as an automation module. It has a stack of commands individually tagged with a time stamp. The command will be sent when the time stamp matches the system clock. In this way, the hardware module will only need to act on the command (e.g. start counting) and does not need to take into consideration the origin of the command. This keeps the system simple, modularized, and easy to maintain.

Feedback to the user is also compartmentalized. The hardware module updates a "cluster" variable (a term in LabView used to describe a variable that can hold different kinds of data). Thus, the hardware module never directly updates the data or system status on either the local computer screen or the remote web console. Instead, these are updated by their assigned modules. Again, this ensures simplicity and easy maintenance of the system—there is only one place in the program where data and status are sent to the cloud/web console, and there is only one place where the local screen is updated.

Apart from compartmentalization, this solution makes it easy to adopt the updating frequency to suit the bandwidth of the client communication. The local computer is typically updated with a 20 Hz frequency, regardless of if the values have changed or not. Such an update frequency cannot be handled by the cloud service, which has a rather slow bandwidth. Therefore, only the recently changed values are sent to the cloud service and only with a frequency of between 0.5 and 2 Hz.

The new radionuclide generator RoboLab

As briefly described in the introduction, the purpose of the new RoboLab exercise is to make a 234mPa radionuclide generator. Eluted 1.2-min 234mPa can be measured with a Geiger–Müller detector. If it suits the learning goals of a particular usage, short-time half-life measurement and determination can also be performed. Essentially, the RoboLab system can cater for a range of different student exercises, adapted both to the learning level and different issues related to making and using radionuclide generators.

Chemistry of the radionuclide generator

The 234mPa radionuclide is obtained from a generator system made from a uranyl solution. 234Th (T1/2 = 24.1-day), produced by the decay of 238U, is loaded on a cation exchange column. Ideally, the uranyl solution should be at least 240 days old to allow maximum in-growth of 234Th. 234Th decays into 234mPa and equilibrium is reached in about 12 min. Thus, once the generator is made it can be used repeatedly for e.g. half-life measurements of 234mPa.

Uranyl acetate (or any other suitable uranyl salt), where 234Th is in radioactive equilibrium, is dissolved in 1 M HCl and flushed through a cation exchange column. The dominating species of uranium and thorium in hydrochloric media at different concentrations are given in Fig. 2.

Fig. 2
figure 2

Dominating species of U and Th in hydrochloric media at different concentrations. Figure is based on information provided by Korkisch [4, pp. 4–5]

Full size image

The hexavalent uranium is nearly not absorbed onto a strong cation exchanger from a 1 M HCl solution and will pass through the column undisturbed (distribution coefficient D of UO2 between a typical cation exchanger and 1 M HCl is 19.2 [4, p. 219]). Thorium, present as Th4+, has a distribution coefficient of > 103 and will therefore be strongly retained on the sulfonated cation exchange column:

$${\text{Th}}^{{{4} + }} + {\text{ 4R}}\left( {{\text{SO}}_{3}^{ - } {\text{X}}^{ + } } \right) \, \leftrightarrow {\text{ Th}}\left( {{\text{RSO}}_{3}^{ - } } \right)_{{4}} + {\text{ 4X}}^{ + }$$
(3)

where X+ is the counter ion from the ion exchanger. Once thorium is attached to the column, the solvent is changed to citric acid. Citric acid will form a neutral complex with protactinium and will therefore elute protactinium:

$${\text{PaO}}\left( {{\text{OH}}} \right)_{{2}}^{ + } \left( {aq} \right) + {\text{2H}}_{{3}} {\text{L }} \to {\text{ PaO}}\left( {{\text{HL}}} \right){\text{H}}_{{2}} {\text{L }}\left( {aq} \right) + {\text{H}}^{ + } \left( {aq} \right) \, + {\text{ 2H}}_{{2}} {\text{O}}$$
(4)

Hardware for remote control

For pumping liquids through the system either vacuum or pressure is applied. All that is needed are remotely controlled valves to select the feed bottle and path through the experimental setup. 3/2-way solenoid valves from Bürkert (type 6606) were selected for this purpose [5]. A simple diaphragm pump able to produce a vacuum of around 100 mBar is used. The cation exchange column is Bond Elut Plexa PCX from Agilent [6]. The transportation rail for collecting eluted samples in a cup and measuring them with a Geiger-Müller tube is a LECP2 rail with a stepping motor from SMC Corporation [7]. Driver electronics for switching the valves by a TTL control signal were made by an in-house electronics workshop. All interconnections are made with Upchurch 1/8″–1/16″ (ID) perfluoroalkoxy alkane (PFA) tubes and connectors. Feed flasks contain uranyl acetate (100 Bq/g) in 1 M HCl solution, 1 M HCl solution, 10% citric acid solution, 0.5 M oxalic acid solution, and water. The oxalic acid can be used to remove thorium from the column and thus reset the system for a new user [8]. For flushing the solution from the column into the sample collection cup, pressurized air is used. A suitable pressure is selected by a manual pressure regulator.

Software

Most of the electronic components mentioned above are connected to programmable inputs or outputs of a digital I/O device (USB-6351 made by NI [9]). The input/output ports and counters of this device are controlled by the previously mentioned hardware control module.

The flow path of the solvents is directed by the user input and controlled by the mechanism of the 3/2-way solenoid valves. When an action-specific configuration of open valves is selected, the vacuum in the waste flasks forces a solution from a selected supply bottle to be sucked up and typically flow into or through the column. The solution in the column can be emptied into a waste container (by suction) or a sample dish (by pressure). This dish can be moved between positions for filling, detection, and emptying.

A total of three waste bottles are installed to separate non-active, short-lived, and long-lived radioactive waste produced during the experiment. The vacuum pump ensures that vacuum is maintained in the waste containers.

The amount of solution added to or pumped through the column is determined by a preset time (s). Tables of volume as a function of valve open times have been made. If needed, a balance can be placed under the waste bottles, thus allowing direct reading of the amount of liquid pumped through the system. This must be adapted to the targeted learning outcome and experience of the students. Standard procedures (e.g. open times) have been worked out for the different tasks. The user is urged to follow the recommended operational procedure to achieve good results.

Results

A general LabVIEW-based template that can be used for updating old and constructing new RoboLabs has been created and applied to develop the nuclide-generator exercise. A test-driven approach to both hardware and software development has been used to ensure a reliable end-product and that every part of the physical setup and the code is performing its designated function. The physical environment has been extensively tested to identify and eliminate any risk of operational accidents such as leakage and overflow. An operational procedure has been suggested based on the results.

Applying the suggested procedure, the half-life of 234mPa—determined from the fitting of a total of 15 decay curve measurements (protactinium was milked 5 times per column)—was found to be 1.16(1) min (Fig. 3).

Fig. 3
figure 3

Decay curve of 234mPa recorded after column preparation and loading according to the proposed procedure. Deviation (%) of count rates from the fitted curve is given

Full size image

The uncertainties of the fitted parameters are calculated through Levenberg–Marquardt method for non-linear curve fitting in OriginLab [10]. This result complies with the half-life value of 1.159(16) min reported by The National Nuclear Data Center [11]. The average experimental standard deviations of parallel measurements from the same column and different columns are 1.1% and 1.1%, respectively.

Regeneration of the cation exchange resin by elution of tetravalent thorium was done using 0.5 M oxalic acid as a complexing agent. As briefly mentioned above, the purpose of this step is to “reset” the column to allow the next remote user to perform the experiment (from the beginning) by reusing the exact same column. The course of regeneration was observed by recording disintegration curves of 234mPa as a function of thorium elution, and the count rate of protactinium was reduced by 93% after 200 mL 0.5 M oxalic acid was applied (Fig. 4).

Fig. 4
figure 4

Disintegration of 234mPa as a function of volumes of oxalic acid applied for regeneration of cation exchange resin

Full size image

Reuse of the previously regenerated column has shown that this 93% reduction is sufficient to not cause any disturbances in future half-life determinations. However, the retention factor of thorium in subsequent column loading is somewhat reduced and it is therefore recommended to change the column, if possible.

Proposed procedure

Thirty five ml of pre-made uranyl acetate is added to a cation exchange column previously conditioned with 2 mL of 1 M HCl and washed with 2 mL of water so that 234Th will be fixed on the column. The uranyl is subsequently eluted and removed with 10 mL of 1 M HCl. After ingrowth, 234mPa (along with 234Pa which is not considered relevant for this experiment) is eluted with 10 mL of 10% citric acid. The eluted protactinium, collected in an open dish, is moved to the detector and measured. A new elution is possible after about 12 min. If the same column is to be loaded again, 200 mL of 0.5 M oxalic acid is sufficient for the regeneration of the column, as previously explained.

Discussion and conclusion

The learning outcome rests mostly on the pedagogical approach of how a RoboLab setup is used. The system itself can only be considered as a tool for retrieving data. Therefore, to cast light upon important aspects of nuclear chemistry, one of the main goals has been to develop an engaging and comprehensive plan for the exercises. This is achieved by creating detailed operational procedures, implementing e-learning modules to guide students through data analysis, and investing additional effort into creating an interactive user interface.

According to evaluations and feedback from students, the remotely operated exercises have been great tools for teaching NRCFootnote 1 at the University of Oslo. During the restricted access to campus, RoboLab demonstrated the flexibility provided by the addition of digital methods to the teaching toolbox and proved to be a viable alternative to physical hands-on training. However, RoboLab is not to be regarded as a substitution for such training.

Development and implementation of the newest RoboLab tool, a 234mPa nuclide generator, is considered successfully finalised—software and hardware modules have been joined into a robust, leak-proof framework. The exercise is ready to be applied in NRC courses for user acceptance testing and will soon be released as a web application for general use.