Difference between revisions of "Src-perl-lab-scale"
Line 33: | Line 33: | ||
Any number of client programs may run, up to whatever limit might be encountered in the capacity of the scale to handle the queries. In practice we probably need only one or two clients simultaneously, but the flexibility is there in any case. | Any number of client programs may run, up to whatever limit might be encountered in the capacity of the scale to handle the queries. In practice we probably need only one or two clients simultaneously, but the flexibility is there in any case. | ||
− | + | ==scaled.pl== | |
In Linux, it is conventional to denote a daemon by a trailing 'd' in the name. The characteristics key to a daemon are 1) that it cuts off any connection to the terminal or process which started it, and 2) probably other stuff... Once started, the daemon should run forever without further attention, but it can also be replaced by another daemon if necessary. | In Linux, it is conventional to denote a daemon by a trailing 'd' in the name. The characteristics key to a daemon are 1) that it cuts off any connection to the terminal or process which started it, and 2) probably other stuff... Once started, the daemon should run forever without further attention, but it can also be replaced by another daemon if necessary. | ||
Line 39: | Line 39: | ||
The scaled.pl daemon first checks for the existence ( and viability) of an already-running instance, and if found, kills that process before setting itself up to run. | The scaled.pl daemon first checks for the existence ( and viability) of an already-running instance, and if found, kills that process before setting itself up to run. | ||
− | + | ==readscale.pl== | |
This client program simply sends a request to the fifo for the scale | This client program simply sends a request to the fifo for the scale | ||
Line 45: | Line 45: | ||
− | + | ==scale-cmd.pl== | |
This client program is the workhorse of the system, in terms of automating measurements. More involved than the readscale.pl program, it can support multiple different query intervals, so that a measurement series could be obtained every 2 seconds in addition to one every minute (whether or not that's useful). Too, multiple instances of the client could be run, perhaps each sending the results to a different file or stream. | This client program is the workhorse of the system, in terms of automating measurements. More involved than the readscale.pl program, it can support multiple different query intervals, so that a measurement series could be obtained every 2 seconds in addition to one every minute (whether or not that's useful). Too, multiple instances of the client could be run, perhaps each sending the results to a different file or stream. | ||
Line 61: | Line 61: | ||
When the client gets an "i" query from the user, it "forks" an identical copy of itself as its child. The child sets up a timing | When the client gets an "i" query from the user, it "forks" an identical copy of itself as its child. The child sets up a timing | ||
loop to repeatedly send the "print" query to the fifo. The child terminates if its interval query is ended. | loop to repeatedly send the "print" query to the fifo. The child terminates if its interval query is ended. | ||
+ | |||
+ | ==storing measurements== | ||
+ | |||
+ | So far, no particular means are provided in the client programs to store results to a named file, but there are several ways this can be | ||
+ | done. The simplest is to use output redirection to directly store the output in a file, perhaps while also being able to view it on the console (by using the tee filter). | ||
+ | |||
+ | Another way, as mentioned above, is to 'cron' the readscale.pl query program, since cron, by default, will email any output to the user that owns the cron job. | ||
+ | |||
+ | ==progress and summary== | ||
+ | |||
+ | The first iteration of this system was experimental, and did not attempt to be general or to support the many features provided by the scale itself. | ||
+ | |||
+ | Now, in the second 'go-round', we have the opportunity to clean up the program a bit as we modify it to support the new scale. Hopefully all the scale-specific settings will be limited to the initial few lines of the daemon program, so that it can more easily be adapted to new equipment down the line. |
Latest revision as of 00:22, 25 August 2007
Contents
laboratory scale logger
Software was developed to interface a Denver Instruments lab scale, model PK-6, to a computer in order to automatically record mass measurements made by the scale during long term experiments.
Currently, work is underway to adapt this software to support another scale, one in the O'Haus (Ohaus?) Navigator line. Both scales are equipped with an RS232 port, but differ in wiring and firmware.
In this wiki page I want to try to describe the workings of the older and new software under development. The new version will hopefully improve on the older, and should be a bit more generalized and configurable, though far from fully featured.
scope of work
The need for our users that is addressed by this software is to simply record measurements on some interval, which may range from seconds to hours. Where their experiment may run for days or weeks, hopefully this will free them from the need to come down to the lab to press manually read the scale.
Thus, the primary task tackled by the software is to issue the "print" command to the scale. This happens to be the letter "p" (or "P") in both cases, but other details vary -- one handles the command as an "escape", so expects the escape character followed by "p", while the other is looking for "p" followed by a carriage return.
Both scales emit a similar output, something like:
+ 17 g
in response to the "print" command. Upon receipt of this response, our software prepends the current date and time to the mass measurement value.
We do not attempt to support other functions which the lab scales provide, ranging from calibration to sensitivity adjustments. We do support a "tare" command.
overview of software
We chose the Perl language to write this software, though of course it could be done in any number of languages. More significantly, we chose the Linux operating system instead of other options, based on the flexibility of the system and on the intrinsic support for this type of software machinery by the Linux platform.
The system consists of a behind-the-scenes server, or daemon, and one or more client interface programs.
The daemon initializes the communications serial port for talking to the scale, detaches from the terminal console used to start it up, and sets up a fifo (first in, first out) file (or pipe, or socket) for handling client queries.
The client software takes commands from the user and passes them on to the daemon by sending them to the fifo. It then returns the respose received from the fifo to the user, or saves it to a file, etc.
Any number of client programs may run, up to whatever limit might be encountered in the capacity of the scale to handle the queries. In practice we probably need only one or two clients simultaneously, but the flexibility is there in any case.
scaled.pl
In Linux, it is conventional to denote a daemon by a trailing 'd' in the name. The characteristics key to a daemon are 1) that it cuts off any connection to the terminal or process which started it, and 2) probably other stuff... Once started, the daemon should run forever without further attention, but it can also be replaced by another daemon if necessary.
The scaled.pl daemon first checks for the existence ( and viability) of an already-running instance, and if found, kills that process before setting itself up to run.
readscale.pl
This client program simply sends a request to the fifo for the scale to be read, and prints the result. It could be run, for example, in a cron (scheduled) job to take a reading every hour or every 5 minutes, perhaps emailing the results to the user.
scale-cmd.pl
This client program is the workhorse of the system, in terms of automating measurements. More involved than the readscale.pl program, it can support multiple different query intervals, so that a measurement series could be obtained every 2 seconds in addition to one every minute (whether or not that's useful). Too, multiple instances of the client could be run, perhaps each sending the results to a different file or stream.
The basic user interface of the scale-cmd.pl program accepts simple queries, such as:
h -- output brief "help" information
H -- output more detailed information
i5 -- start an automated query every 5 seconds
i-5 -- remove a 5-second query
When the client gets an "i" query from the user, it "forks" an identical copy of itself as its child. The child sets up a timing loop to repeatedly send the "print" query to the fifo. The child terminates if its interval query is ended.
storing measurements
So far, no particular means are provided in the client programs to store results to a named file, but there are several ways this can be done. The simplest is to use output redirection to directly store the output in a file, perhaps while also being able to view it on the console (by using the tee filter).
Another way, as mentioned above, is to 'cron' the readscale.pl query program, since cron, by default, will email any output to the user that owns the cron job.
progress and summary
The first iteration of this system was experimental, and did not attempt to be general or to support the many features provided by the scale itself.
Now, in the second 'go-round', we have the opportunity to clean up the program a bit as we modify it to support the new scale. Hopefully all the scale-specific settings will be limited to the initial few lines of the daemon program, so that it can more easily be adapted to new equipment down the line.