79,99 €
Mehr erfahren.
- Herausgeber: Wiley-VCH Verlag GmbH & Co. KGaA
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
By closing the gap between general programming books and those on laboratory automation, this timely book makes accessible to every laboratory technician or scientist what has traditionally been restricted to highly specialized professionals. Following the idea of "learning by doing", the book provides an introduction to scripting using AutoIt, with many workable examples based on real-world scenarios.
A large portion of the book tackles the traditionally hard problem of instrument synchronization, including remote, web-based synchronization. Automated result processing, database operation, and creation of graphical user interfaces are also examined.
Readers of this book can immediately profit from the new knowledge in terms of both increased efficiency and reduced costs in laboratory operation. Above all, laboratory technicians and scientists will learn that they are free to choose whatever equipment they desire when configuring an automated analytical setup, regardless of manufacturers suggested specifications.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 360
Veröffentlichungsjahr: 2016
Ähnliche
Table of Contents
Cover
Title Page
Copyright
Dedication
Foreword
Preface
Acknowledgments
Chapter 1: Introduction
1.1 A Brief Story of Laboratory Automation
1.2 Approaches for Instrument Integration
1.3 Scripting versus Standardization in Laboratory Automation
1.4 Topics Covered in this Book
1.5 Learning by Doing: FACACO and FAKAS
1.6 Summary
Suggested Reading
Chapter 2: The Very Basics of AutoIt
2.1 What Is AutoIt?
2.2 Alternatives to AutoIt
2.3 Getting AutoIt
2.4 Writing Your First Script (Mouse Click Automation)
2.5 Knowing More about SciTE
2.6 AutoIt on Linux
2.7 Summary
Suggested Reading
Chapter 3: Timed Scripts
3.1 Controlling the Timing of Actions
3.2 Moving and Activating Windows
3.3 Sending Keyboard Inputs
3.4 “For” Loops and Variables
3.5 Organizing Your Code: Functions and Libraries
3.6 Replacing Mouse Clicks with Keyboard Shortcuts
3.7 Summary
Chapter 4: Interactive Scripting
4.1 Window Monitoring
4.2 Pixel Monitoring
4.3 “While … WEnd” Loops for Pixel Monitoring
4.4 Synchronizing FACACO and KAKAS Using Pixel Monitoring
4.5 Enhanced Pixel Monitoring Using PixelCheckSum
4.6 Blocking Access to Keyboard and Mouse
4.7 Summary
Chapter 5: Scripting with Controls
5.1 Using AWI to Get Control Information
5.2 Functions That Provide Control Information
5.3 Sending Commands to Controls
5.4 Synchronizing FACACO and FAKAS Using Controls
5.5 Dealing with Errors: If … Then
5.6 Infinite Loops and Controls
5.7 Summary
Chapter 6: E-mail and Phone Alarms
6.1 E-mail Alarms
6.2 SMS and Phone Call Alarms
6.3 Summary
Chapter 7: Using Low-Cost Equipment for Laboratory Automation
7.1 G-Code Devices
7.2 Robotic Arms
7.3 Do-It-Yourself Devices
7.4 Summary
Suggested Reading
Chapter 8: Arrays and Strings
8.1 Organized Data: Arrays
8.2 Raw Data: Strings
8.3 Summary
Chapter 9: Data Processing with Spreadsheets
9.1 Exporting Results to Spreadsheet Software
9.2 Dealing with Saved Results (Files)
9.3 Processing Spreadsheet Files
9.4 Summary
Chapter 10: Working with Databases
10.1 Starting SQlite in AutoIt
10.2 Creating SQlite Databases
10.3 Modifying an Existing SQlite Database
10.4 Databases with More Than One Table
10.5 Retrieving Data from Databases
10.6 Summary
Chapter 11: Simple Remote Synchronization
11.1 Time Macros
11.2 Synchronizing FACACO and FAKAS Using Time Macros
11.3 Summary
Chapter 12: Remote Synchronization Using Remote Control Software
12.1 TeamViewer
12.2 Synchronizing FACACO and FAKAS Using TeamViewer
12.3 Summary
Chapter 13: Text-Based Remote Synchronization
13.1 Choosing Instant Messaging Software
13.2 Writing and Reading from Trillian Using AutoIt
13.3 Synchronizing FACACO and FAKAS Using Trillian
13.4 Summary
Chapter 14: Remote Synchronization Using IRC
14.1 AutoIt and IRC
14.2 Monitoring the Connection
14.3 Synchronizing FACACO and FAKAS
14.4 Final Considerations
14.5 Summary
Chapter 15: Remote Synchronization Using Windows LAN Tools
15.1 Connecting to a LAN
15.2 Creating a Shared Folder
15.3 Synchronizing FACACO and FAKAS
15.4 Summary
Chapter 16: Remote Synchronization Using Third-Party LAN Software
16.1 Connecting to a LAN Using Bingo's Chat
16.2 Automated Communication Using Bingo's Chat
16.3 Synchronizing FACACO and FAKAS
16.4 Summary
Chapter 17: Interacting with Devices via COM Ports
17.1 Serial Communication Protocols
17.2 AutoIt and COM Ports
17.3 Monitoring in Real Time
17.4 Implications for Other Devices
17.5 Other Technologies for Instrument Control
17.6 Summary
Suggested Reading
Chapter 18: Introduction to Graphical User Interface (GUI)
18.1 Making a Very Simple GUI
18.2 Adding Simple Elements to a GUI
18.3 Setting Keyboard Shortcuts
18.4 Summary
Chapter 19: Using GUI to Control Instruments
19.1 GUIs to Control the EHMA Valve Actuator
19.2 Controlling Two or More COM Ports in the Same Script
19.3 A GUI to Control a Digital Balance
19.4 Summary
Chapter 20: Multitasking GUIs
20.1 The “GUIOnEventMode” Option
20.2 Multitasking Using GUIOnEventMode
20.3 Summary
Chapter 21: Adding Graphical Elements to a GUI
21.1 Getting Started with GDIplus
21.2 Creating Animations Using GDIplus
21.3 Summary
Chapter 22: Creating GUIs Using Koda
22.1 Getting Started with Koda
22.2 Creating a Script
22.3 Summary
Chapter 23: Some Suggestions
23.1 For Manufacturers: All Instruments with a GUI
23.2 For Manufacturers: All GUIs with Access to Controls
23.3 For Manufacturers: Stop Developing Standards for Laboratory Automation
23.4 For Users: Hardware Trumps Software
23.5 For Users: If You Can, Choose Controls
23.6 For Users: AutoIt May Not be the Best Programming Option in Some Cases
23.7 For Users: Be Aware of Technological Advances
23.8 For Users and Manufacturers: AutoIt Scripts May Serve as Basis for New Products
Suggested Reading
Appendix A: Other SciTE Features
A.1 Code Wizard
A.2 Organizing Your Scripts with Tidy
A.3 Tools that Facilitate Navigation
Appendix B: Optical Character Recognition
B.1 OCR in AutoIt
B.2 Copying from the Screen and Applying OCR
Appendix C: Scripting with Nonstandard Controls (UIA)
C.1 Downloading the UIA Software Package
C.2 Sending Instructions
C.3 Getting Information about Controls
C.4 Automating a LabView Program
C.5 Summary
Index
End User License Agreement
Pages
xiii
xiv
xv
xvi
xvii
1
2
3
4
5
6
7
8
9
10
11
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
49
50
51
52
53
54
55
56
57
58
59
61
62
63
64
65
66
67
68
69
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
107
108
109
110
111
112
113
114
115
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
135
136
137
138
139
140
141
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
167
168
169
170
171
172
173
174
175
177
178
179
180
181
182
183
184
185
186
187
188
189
191
192
193
194
195
196
197
198
199
201
202
203
204
205
207
208
209
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
Guide
Cover
Table of Contents
Foreword
Preface
Begin Reading
List of Illustrations
Chapter 1: Introduction
Figure 1.1 Common approach to make instruments work together in a laboratory. Arrows show the paths for data exchange.
Figure 1.2 Instruments working together in a framework enabled by scripting. As in Figure 1.1, arrows indicate exchange of data.
Figure 1.3 FACACO interface.
Figure 1.4 FACACO interface with samples and analyses loaded.
Figure 1.5 FAKAS interface.
Chapter 2: The Very Basics of AutoIt
Figure 2.1 SciTe autocompleting the typing of a function.
Figure 2.2 SciTe suggesting arguments to a function.
Figure 2.3 SciTE indicating that there is an error. A yellow circle appears at the left of the line with the wrong input, a red line is inserted below the line with the wrong input, and some extra comments are shown in the console (not all shown in the figure).
Chapter 3: Timed Scripts
Figure 3.1 AutoIt v3 Windows Info (AWI) window showing mouse properties.
Figure 3.2 Window tab on AWI for FAKAS.
Figure 3.3 Area indicated as “Click to Record” in The AU3Recorder utility.
Chapter 4: Interactive Scripting
Figure 4.1 Flow of action of the script in Code sample 4.3. Large numbers are the steps at which mouse clicks or keyboard inputs are done. Arrows link the steps. Smaller numbers near each arrow show the time in seconds between each action linked by the arrow. The text in bold black between steps explains that the subsequent step only comes after the action described there takes place.
Figure 4.2 AWI magnifying glass showing pixels in detail for a section of the screen containing plain black text on a white background.
Figure 4.3 FACACO at position 0,0 on the screen, and the tip of the arrow at position 252,52.
Chapter 5: Scripting with Controls
Figure 5.1 AutoIt v3 Windows Info (AWI) showing information about the “Go to sample” button and input field on FAKAS.
Figure 5.2 Control names for some cells in FACACO.
Figure 5.3 Flow of action of the script in Code sample 5.6. Large numbers are the steps at which mouse clicks (in this case, not real clicks, but the use of the function ControlClick) or keyboard inputs (also not real keyboard inputs, but ControlSend or ControlSetText) are done. Arrows link the steps. Smaller numbers near each arrow show the time in seconds between each action linked by the arrow. The texts between steps explain that the subsequent step only comes after the action described there takes place.
Figure 5.4 Graphical user interface for a hypothetical cryotrap.
Chapter 6: E-mail and Phone Alarms
Figure 6.1 Error message window generated by FAKAS if the needle is down and you try to move it to a different position.
Figure 6.2 Input field for phone numbers on Skype window after pressing Ctrl + D.
Figure 6.3 New input field that appears after the text balloon (Figure 6.2) is chosen.
Figure 6.4 Dial Figure on Skype window during a phone call.
Chapter 7: Using Low-Cost Equipment for Laboratory Automation
Figure 7.1 Hypothetical CNC router. In a typical CNC router, the drill is moved on the three perpendicular axes.
Figure 7.2 Hypothetical 3D printer. In a typical 3D printer, a horizontal plate moves on the horizontal axes and the extruder moves on the vertical one.
Figure 7.3 Hypothetical robotic arm. In most robotic arms, movements are semicircular, which make them more difficult to program than G-code devices.
Chapter 9: Data Processing with Spreadsheets
Figure 9.1 FACACO filled with hypothetical results.
Figure 9.2 Files with different Figure available from http://www.wiley-vch.de/publish/en/books/ISBN978-3-527-34158-0/ and that should be saved in the C:\PrettyPics folder. It is difficult to see as the Figure is in gray scale, but first, fourth, and fifth are in blue, and the others in red in the original files.
Chapter 10: Working with Databases
Figure 10.1 Options available for database management using SQlite browser.
Figure 10.2 SQlite browser displaying TABLE1, a part of cars.db database.
Chapter 11: Simple Remote Synchronization
Figure 11.1 Scripts based on time macros are more easily built if the different computers being synchronized have exactly the same time being displayed.
Chapter 12: Remote Synchronization Using Remote Control Software
Figure 12.1 A master computer controlling a follower computer by means of remote control software.
Figure 12.2 TeamViewer Toolbar.
Figure 12.3 TeamViewer window wrapping FAKAS window.
Chapter 13: Text-Based Remote Synchronization
Figure 13.1 Two computers connected to the Internet sending interactive instructions to each other.
Figure 13.2 Trillian list of contacts, its main interface.
Figure 13.3 Trillian chat window.
Figure 13.4 Trillian menu with Preferences highlighted.
Chapter 15: Remote Synchronization Using Windows LAN Tools
Figure 15.1 Location accessed using the command ncpa.cpl on the start button for Windows 8.1 which shows a list of Networks available for a computer found using ncpa.cpl.
Figure 15.2 Command prompt on Windows 8.1.
Figure 15.3 Typical result for the ipconFigure command. In this case, the IP address that we need is the IPv4 for the Ethernet adapter, which is 169.254.119.211. This number will be probably different on your machine.
Figure 15.4 Path of computer 166.254.105.223 accessed from computer 169.254.119.211 via LAN.
Figure 15.5 Menu opened using the right button to share a folder.
Figure 15.6 Window that enables sharing of a folder.
Figure 15.7 Message showing that the folder that now can be shared with “Everyone.”
Figure 15.8 Message confirming that now the folder is shared in the LAN.
Figure 15.9 Window showing computer 166.254.105.223 accessed from computer 169.254.119.211 via LAN, this time listing the Shared folder.
Chapter 16: Remote Synchronization Using Third-Party LAN Software
Figure 16.1 Computer listed along with its IP address on Bingo's Chat interface.
Figure 16.2 Opening the menu to change the network being accessed by Bingo's Chat.
Figure 16.3 Choosing the correct IP address for a LAN connection using Bingo's Chat.
Figure 16.4 Elements of Bingo's Chat interface with two computers connected.
Figure 16.5 Finding the log files of conversations using Bingo's Chat.
Figure 16.6 Log files of Bingo's Chat.
Figure 16.7 Portion of a Bingo's Chat log file open on a web browser.
Chapter 18: Introduction to Graphical User Interface (GUI)
Figure 18.1 GUI generated with Code sample 18.3.
Figure 18.2 Sketch of a GUI for an automated dilutor.
Chapter 19: Using GUI to Control Instruments
Figure 19.1 GUI with radio buttons to control the EHMA valve actuator.
Figure 19.2 GUI with a combo box to control the EHMA valve actuator.
Figure 19.3 GUI that controls two EHMA valve actuators.
Figure 19.4 GUI that controls a digital balance.
Figure 19.5 Improved GUI for controlling a digital balance.
Chapter 22: Creating GUIs Using Koda
Figure 22.1 Main elements of the Koda interface.
Figure 22.2 If you select one or more controls in a form, and click on them using the right button, a menu appears.
Figure 22.3 Submenu activated when Align is chosen in the menu in Figure 22.2.
Figure 22.4 Submenu activated when Control is chosen in the menu in Figure 22.2.
Figure 22.5 Example of code generated from a Form in Koda.
Figure 22.6 Setting an event to be linked to a control.
Figure 22.7 Choosing the generated code to be in OnEventMode.
List of Tables
Chapter 1: Introduction
Table 1.1 Summary of differences between scripting and standards for laboratory automation
Appendix C: Scripting with Nonstandard Controls (UIA)
Table 1.1 Summary of differences between scripting and standards for laboratory automation
Practical Laboratory Automation
Made Easy with AutoIt
Matheus C. Carvalho
Author
Dr. Matheus C. Carvalho
Southern Cross University
Centre for Coastal Biogeochemistry Res.
PO Box 157, Lismore, NSW, 2480
2480 Lismore
Australia
Cover
Microplate / fotolia.com $\mbox © Caleb Foster; Vials autosampler tray / fotolia.com © bigy9950
All books published by Wiley-VCH are carefully produced. Nevertheless, authors, editors, and publisher do not warrant the information contained in these books, including this book, to be free of errors. Readers are advised to keep in mind that statements, data, illustrations, procedural details or other items may inadvertently be inaccurate.
Library of Congress Card No.: applied for
British Library Cataloguing-in-Publication Data
A catalogue record for this book is available from the British Library.
Bibliographic information published by the Deutsche Nationalbibliothek
The Deutsche Nationalbibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data are available on the Internet at <http://dnb.d-nb.de>.
© 2017 Wiley-VCH Verlag GmbH & Co. KGaA, Boschstr. 12, 69469 Weinheim, Germany
All rights reserved (including those of translation into other languages). No part of this book may be reproduced in any form – by photoprinting, microfilm, or any other means – nor transmitted or translated into a machine language without written permission from the publishers. Registered names, trademarks, etc. used in this book, even when not specifically marked as such, are not to be considered unprotected by law.
Print ISBN: 978-3-527-34158-0
ePDF ISBN: 978-3-527-80198-5
ePub ISBN: 978-3-527-80196-1
Mobi ISBN: 978-3-527-80197-8
oBook ISBN: 978-3-527-80195-4
Cover Design Bluesea Design, McLeese Lake, Canada
This book is dedicated to my family, near and far away.
Foreword
Would you like to have a lab assistant willing to do the most tedious repetitive tasks in your laboratory perfectly every time? Would you like that lab assistant to work for a few cents an hour for 24 h a day, 7 days a week, 365 days a year? Better yet, would you like the salary of that lab assistant covered under the operational overhead of your institution?
This is all more than possible with the laboratory automation wizardry explained in detail by Matheus Carvalho in this book. Practical Laboratory Automation – Made Easy with AutoIt is a tour de force in laboratory automation. It allows scientists to harness automation to radically increase productivity as is common in industry. Specifically, Carvalho guides even the most inexperienced user into a deep dive of AutoIt in the context of laboratory automation. AutoIt is a zero-cost software tool that automates mouse clicks and keyboard entries in Windows. These properties enable seamless integration into the operation of other programs – like the shockingly expensive proprietary programs that come bundled with most conventional modern scientific equipment. AutoIt source code was openly released under the GNU GPL (up to v.3.2 2006), and then went on two paths. The AutoHotkey project remains open source and AutoIt became closed source, but remains freeware with a supportive online community.
My own introduction to AutoIt came several years ago when we needed to make the same measurement in my laboratory every few minutes for hundreds of hours continuously. This was a waste of time for even the least-skilled and poorly paid student researcher. The obvious solution was to add a single loop to the equipment vendor's proprietary software running the tool to make the measurements. The vendor tried to extort thousands of dollars from us to include this new functionality. Unfortunately for the vendor, a student found AutoIt. Our problem was solved in seconds. Now a few pennies of electricity would enable the worst measurement in my laboratory to be completed without any wasted student hour. Besides teaching me the value of AutoIt, this experience set me on the path of first making our own scientific tools and eventually into the open-source scientific hardware community. This has saved my laboratory hundreds of thousands of dollars and Practical Laboratory Automation may do the same for you.
Now our initial use of AutoIt is trivial compared to the super user abilities that Carvalho demonstrates throughout this book. This is a book you should read with a computer on your lap so that you can ensure you learn the skills by trying them out as Carvalho explains new techniques. You will walk away after reading it with the technical skills to automate even the most complex scientific equipment. I should point out that although the techniques Carvalho explains in this book are complex (e.g., pixel monitoring, scripting, and remote synchronization) this book is written for the nonspecialist Windows user. It really has been “made easy.” Anyone who works in a laboratory – even if he/she does not know anything about coding, robotics, embedded systems, or microcontrollers will have no problem using the techniques discussed to automate his/her own equipment. As Practical Laboratory Automation correctly points out, this will enable you freedom from lock-in with the equipment vendors using Windows as the platform of their machine, which alone should save you money and help your lab function more efficiently. It also offers the potential to “resurrect” formally quasi-functional tools collecting dust in the corner of your laboratory now (such as those where the software is no longer supported). However, even more exciting is the opportunities this book gives you to use automation to tackle new types of experiments that would simply have been too time-consuming or cost-prohibitive for all but the most wealthy laboratories.
You have made a good decision to purchase this book. It will make your laboratory more efficient and save you money. My hope is that it functions as a good “gateway” drug that it pulls you into open-source scientific hardware community. This community is building from scratch progressively more sophisticated automated research tools for a tiny fraction of the cost of proprietary equipment. Both the source code for the hardware and the software are being shared openly enabling rapid diffusion and technical evolution. As you become familiar with automation and comfortable with the ability to improve the functionality of your equipment, the technical jump to hacking open hardware becomes far less intimidating. So, fire up your computer, turn the page, and get started.
Joshua PearceMichigan Tech Open Sustainability Technology LabOpen-Source Lab: How to Build Your Own Hardware and Reduce Research CostsHoughton, MI
Preface
Some years ago, I found by chance a very cheap robotic arm (∼US$ 100) for sale. This robotic arm could be controlled using a computer, similarly to autosamplers of analytical equipment. A device with that capability and costing so little was a surprise to me, because I was used to autosamplers costing as much as a brand new car. At that point, I was familiar with AutoIt, the scripting language presented in this book, and I realized that using it I could try to use the robotic arm as a substitute for the expensive autosamplers. I did it, and it worked perfectly.
The test with the robotic arm made clear for me that AutoIt could be used to integrate any type of devices in the laboratory, enabling not only money saving, but also total freedom regarding the choice of equipment. As I came to realize, my colleagues were not aware of such possibilities. Therefore, I decided to share this idea with other professionals, and published two articles in scientific journals about AutoIt used in the context of laboratory automation. However, scientific articles are short, not allowing for an in-depth coverage of AutoIt, and thus I decided that a book would be a better way to disseminate the idea among laboratory technicians and scientists.
This book covers several aspects of AutoIt in the context of laboratory automation. I expect it to empower readers in two ways:
1.
By providing independence from instrument manufacturers. In the same way I could use a cheap robotic arm as an autosampler for analytical equipment, readers will become able to combine any type of equipment very easily. Doing so, it will be possible for them to choose the device that is the best or the most cost effective for a given task, regardless of what manufacturers could have originally suggested. If you are familiar with the field of laboratory automation, this may come as a surprise. Nowadays, the prevalent view is that integration of laboratory equipment is very complex and accessible only for specialized professionals. This book will demonstrate that with AutoIt such integration is very simple and accessible to virtually any laboratory technician or scientist.
2.
By presenting AutoIt. AutoIt is not just another scripting language. Because it automates mouse clicks and keyboard entries, AutoIt is a very powerful tool that allows complete automation of a program, and also total integration among different programs. Being free to get and easy to learn, AutoIt is a fantastic tool that can be used not only in the context of laboratory automation, but also as a general way to easily increase productivity when using the computer.
AutoIt is a scripting language, and scripting is a type of programming. Although many readers probably have some background in programming, I wrote this book assuming that the reader has only a little or no such background. I did so to make the book accessible for all interested readers, in such a way that they do not need to first learn to program to only then learn AutoIt. AutoIt is an ideal first programming language, both for its simplicity and practical scope. In fact, it could be said that AutoIt is fun, because there is an inherent satisfaction when solving problems, especially difficult problems. AutoIt makes it easy to solve some usually perceived as difficult problems.
I hope you find this book useful, and that you can apply some of the techniques here presented in your work. AutoIt has not only made part of my work much easier, it has also enabled substantial economic savings in the operation of the laboratory. I am sure that the same can be true for you.
23 July 2016
Lismore, NSW, Australia
Matheus Carvalho
Acknowledgments
I am very grateful to Alessandra Carvalho, who helped me make the book more readable, and Douglas Tait and Joshua Pearce, who made useful comments on the book.
I am also grateful to Reinhold Weber, from Wiley VCH, who believed in the idea of the book and helped make it become real.
Chapter 1Introduction
1.1 A Brief Story of Laboratory Automation
Through human history, there has always been a quest for automation. For instance, the water mill, which has been used by different ancient cultures, can be considered an example of mechanical automation in the general sense of replacing human labor with a more reliable and powerful alternative. By replacing human labor with a water mill, our ancestors achieved the following aims of automation: reduced production costs, increased production efficiency, and improved safety in the production process. With the industrial revolution, when powerful engines became available, automation in this general sense maximized production efficiency as never before in human history. Further development of electronics and computing brought automation to its present and familiar stage, in which finely controlled motors execute precise tasks emulating (and surpassing) human efforts, movement sensors open doors for people to pass through, and computer programs save works without users needing to remember doing that.
Scientific laboratories have adopted automation as its technology developed. The first documented solutions in laboratory automation were devised by scientists to improve their own work. Devices such as automated filters and siphons have been built by ingenious means since the late nineteenth century. With the advent of electronics, a wide range of new devices, such as conductivity meters, gas analyzers, pH meters, and automated titrators, became available. Soon after the Second World War, automation tended to become predominantly provided by specialized companies making the devices, due to the increased complexity in manufacturing. The exponential progress in computing then enabled the opening of the first fully automated laboratory by Dr Masahide Sasaki at the Kochi Medical School in Japan in the early 1980s. In the following decade, similar laboratories were opened in Japan, the United States, and Europe. The approach followed in such fully automated laboratories started becoming known as total laboratory automation (TLA).
TLA was and still is very expensive. Because of that, only a few laboratories, normally those involved in fields that can produce high financial returns, such as drug discovery, can afford to implement it. In order to make TLA more accessible for medium- and small-scale laboratories, the concept of modular automation was introduced in the late 1990s. Through this concept, smaller laboratories could purchase one or a few automated instruments and progressively upgrade them when money became available. A very recent development in modular automation that has the potential to reduce even further costs in laboratory automation is the adoption of open-source hardware, which has its blueprints freely available. Enabled by open-source microcontrollers, and open-source building devices such as three-dimensional (3D) printers, this technology enables users to build their own devices at a surprisingly low cost.
Modular automation, including open-source hardware, however, does not work in all situations because of the difficulty in integrating instruments built by different manufacturers. The negative effect of this lack of integration cannot be overemphasized. It has been recognized as a problem for more than 25 years, and attempts have been made to resolve it by means of standardization of the communication between instruments. Unfortunately, such standardization has never become widespread, and to date, it has remained difficult to integrate instruments built by different manufacturers. This book aims to present a way to overcome this limitation, and thus enable laboratories to implement automation at a much lower cost than by traditional means. The approach presented in this book is very simple and accessible for most professionals in laboratories even if they do not have a background in electronics or computing. It is also a very powerful approach, which overcomes virtually any lack of compatibility between instruments.
1.2 Approaches for Instrument Integration
As explained above, a fundamental aspect of laboratory automation is instrument integration, that is, the ability to make instruments work together. The following are the two ways to enable instrument integration.
1.2.1 The Usual Approach for Instrument Integration
Communication between laboratory instruments is usually implemented by a computer controlling one instrument, which in turn controls others (Figure 1.1). There is data interchange between the computer and the first instrument, and between instrument 1 and the other instruments. However, there is no direct communication between the computer and the instruments being controlled by instrument 1. In other words, only instrument 1 can be directly controlled by the computer and, consequently, by the user. An advantage of this approach is simplicity: the user only needs to operate a single program that controls the whole set of instruments.
Figure 1.1 Common approach to make instruments work together in a laboratory. Arrows show the paths for data exchange.
However, this approach also considerably limits options for users. For example, let us assume that instrument 2 breaks down and needs to be replaced. The user then finds an alternative to instrument 2, which performs better and costs less than the usual instrument supplied by the manufacturer of instrument 1. Ideally, the user should be able to connect this alternative instrument to instrument 1 and continue the work. In practice, however, this is not possible in most cases, because instrument 1 was built to communicate exclusively with instrument 2 and vice versa. Therefore, the user has no choice but to buy a second instrument 2.
1.2.2 Instrument Integration with Scripting
The limitation of the traditional approach of instrument integration (Figure 1.1) can be eliminated by scripting. As explained above, with scripting, the user coordinates the programs that control different instruments. This way, if the different instruments set up to work together have each a software interface, they can be integrated using scripting (Figure 1.2).
Figure 1.2 Instruments working together in a framework enabled by scripting. As in Figure 1.1, arrows indicate exchange of data.
In Figure 1.2, there is no direct communication between instruments; instead, the computer communicates with all instruments. It is important to note that this is conceptually different from the scenario in Figure 1.1, in which the computer controlled only instrument 1, and instrument 1 controlled the others.
In the example outlined earlier, the user needed to replace instrument 2. If the user finds a replacement for instrument 2, which has a program controlling it, he/she can readily make it work together with instrument 1 using the arrangement in Figure 1.2. To do so, the user does not need any knowledge of electronics or even advanced computing; scripting is all that is necessary. Thus, in our hypothetical history, the user could both save money and obtain a better instrument.
The example is hypothetical, but resembles the routine activities of a laboratory technician. It is common that when replacing a broken instrument the normal alternative is either too expensive or takes a long time to become available. In such cases, the damaged instruments could be replaced by cheaper and ready-to-use alternatives, by means of scripting. Two examples can be found among the reading suggestions at the end of this chapter. In one, the autosampler of a machine was coupled to a water analyzer, because the analyzer did not have an autosampler, and was not even designed to work with one. In the other case, a low-cost robotic arm (less than US$ 500) was used as autosampler for an automated titrator, rather than using the autosampler originally designed for that instrument, which would cost more than US$ 50 000.
Another aspect that gives an advantage to scripting is that it is not always possible to use one instrument to control several others (Figure 1.1). In most cases, instruments are designed to communicate with only another one. With scripting, there is no limit on the number of instruments that can be synchronized.
1.3 Scripting versus Standardization in Laboratory Automation
Scripting is not the first proposed solution for the problem of lack of compatibility between instruments. However, as will be explained below, it is the only one with real odds of solving this problem.
The usually proposed solution for the compatibility problem in laboratory automation is the adoption of standards. Such standards would mean that all instruments would communicate using the same protocols. This would make the integration of instruments very simple, and the problem of replacing instrument 2 (Figure 1.1) illustrated above would be very easily solved.
Although such a solution looks desirable, it is very difficult to be put in practice. A recent effort in this direction that stands out by its large magnitude is SiLA (Standards in Laboratory Automation). According to their website, http://www.sila-standard.org, SiLA is a consortium of several system manufacturers, software suppliers, system integrators, and pharmaceutical corporations, among others. There are several working groups composed of high-skilled experts dealing with device control and interfaces, command dictionary specification, data standard, process management system, and so on. If, on the one hand, it is impressive to see such a combined work with the aim of improving laboratory automation, then, on the other hand, the necessity of such endeavor warns that the problem at hand is complex.
In addition to the complexity of the problem itself, there is resistance of manufacturers in adopting a potential standard that may or may not become widespread. As the proposers of SiLA themselves admit (see the relevant publication in the reference list at the end of this chapter), newcomers need to spend time, resources, and money to implement SiLA. In addition, SiLA will be successful only if all players in the industry adopt it. It is a very ambitious goal, which is still far from being reached.
Now let us compare this situation with scripting. The first aspect is that the technology for enabling scripting is ready; there is no need for further development (although of course this development continues in the form of bug fixing and improvements in the scripting language). In other words, integration of laboratory instruments using scripting can be implemented now, while uniform standards are not yet available for most laboratory equipment.
The second aspect is that it is much easier for manufacturers to adapt to scripting than to adopt standards. In fact, manufacturers do not need to do anything, as scripting was designed to deal with software “as is.” As will be explained in the last chapter of this book, however, there are measures that manufacturers can adopt if they want their software to be “script-friendly.” These are minor modifications that are much easier to adopt than standards.
The third aspect is that standardization necessarily creates restrictions to further development. If a new and more efficient way of implementing a software solution is devised, but it is outside the scope of the standard, either the solution must not be implemented or the standard needs to be modified. With scripting, there is no risk of such problem unless a very radical change in the way computers work comes to place, like, for example, the abolition of mouse and keyboard use (which is extremely unlikely).
The fourth aspect is how users need to adapt to changes brought by scripting or standards. In order for them to work, standards need a universal interface, called integrator, that controls all programs. Scripting also demands that users learn how to control several different programs using a common framework. This book provides information on this aspect, which, as will be seen, is quite accessible. An important point is that the programs used for scripting are free of cost. By contrast, integrators are not always free.
The fifth aspect is that adoption of standards indicates that in many cases perfectly working devices would become obsolete for just not following the standard. This could be translated into huge costs of modifying existing equipment, or obtaining new ones. Nothing of this is necessary if scripting is used, since it demands no modification in the equipment. Another consequence of this aspect is that old equipment, many times compatible with only older computers, can be “resurrected” and made to work with newer counterparts (up to a point; Windows versions before XP are not fully supported, see more details in Chapter 2).
The sixth aspect is that by enforcing standards, laboratories miss the opportunity of using the myriad of new devices and technologies that appear at a frantic pass every day. These devices do not necessarily follow the standards that are proposed to be used by laboratory instruments. Therefore, any creative use of traditional instruments and revolutionary new devices becomes hampered with the adoption of standards. The same is not true with scripting: any new device can be used in conjunction with traditional laboratory instruments by means of this technology.
In summary, scripting is by definition a better solution than the adoption of standards for laboratory automation. It is easier, cheaper, and can be implemented now. Standards cost money, time, and are not ready yet (and may never be). Table 1.1 summarizes the differences between the two approaches.
Table 1.1 Summary of differences between scripting and standards for laboratory automation
Scripting
Standards
Technological availability
Ready
In development
Backward compatibility
Yes
No
Universal acceptance
Not necessary
Necessary
Difficulty for manufacturers
None
High
Easily adaptable for new technologies
Yes
No
Difficulty for users
Little
Little to high
Cost for manufacturers
Zero or small
High
Cost for users
Zero or small
High in most cases
1.4 Topics Covered in this Book
Before knowing what this book is about, it may be important to clarify what it is not about, because this book differs in many aspects from previously published books on laboratory automation.
The previously published books on laboratory automation often covered electronics, and even some aspects of mechanics. They also often presented deep discussions about communication protocols, or some advanced concepts in programming. In some sense, these books demanded (or aimed to provide) an encyclopedic knowledge to users who are already necessarily specialized in another profession. This book is different from these previous ones in that it does not cover any of those diverse subjects, except superficially for some of them. This is because of the novel approach presented here: instead of building instruments or creating software interfaces for them, using scripting we can simply coordinate the software interfaces, which are already easily available for existing instruments and combine them. Therefore, this book is mainly focused on how to use scripting to coordinate software interfaces, which is much more accessible than the subject of previously published books for the ordinary laboratory technician or scientist without a deep background in computer science or robotics, and without time to devote to learning a complex new subject.
It is important that the book be read in sequence, especially for those without knowledge on programming. It is suggested for those who do not have a background in programming to read this book from Chapters 1 to 5, at least, and test all the scripts presented therein. The next chapters can be understood much more easily, provided the initial ones are studied first. For readers with experience in programming, it can still be useful to have a look into the initial chapters to know how AutoIt works. It will be seen that the codes used throughout this book are often very simple, and the readers will probably have no problems understanding them. A reference for the language is not presented in this book, rather only the aspects of the language that are useful in specific contexts are presented. Therefore, chapters about loops or conditionals will not be found; however, these subjects are presented as parts of chapters dealing with their uses, as they become necessary. A final comment for those with a background in programming: throughout the book, the “best practices” for writing scripts in AutoIt are deliberately ignored, but are available at http://https://www.autoitscript.com/wiki/Best_coding_practices. It has been done to simplify the learning for people without a background in programming, as these best practices may be confusing for uninitiated readers.
Chapter 2 introduces AutoIt. As it is explained there in detail, AutoIt stands out as a very powerful yet simple scripting language that is perfect to be used for laboratory automation.
Chapters 3–5 are arguably the most important in this book. They describe how AutoIt can be used to synchronize instruments built by different manufacturers and controlled by a single computer. All examples in these chapters are for the teaching software written for this book.
Chapter 6 shows how AutoIt can be used to implement alarms to deal with problems during automated measurements. In this case, not only the teaching programs are used, but also third-party software is introduced, demonstrating that AutoIt is versatile and can combine communication software very easily with laboratory instruments.
Chapter 7 shows how AutoIt can be used to integrate low-cost automation devices, such as CNC routers, 3D printers, and robotic arms, with laboratory equipment. Again, third-party software is also used in the examples.
Chapter 8 was written for readers without any background in programming, as it covers arrays and strings. However, readers with some programming background can also find this chapter beneficial by reading it to check the details of the language on these topics.
Chapters 9 and 10 show how AutoIt can automate the export of data generated by instrument software, and how the processing of such data can be made easier and faster.
Chapters 11–16
