I am using the AL5B robot arm to move films onto a microscope stage for scanning, and off again. Its working pretty well, but there are a few wrinkles to iron out, and would apprciate help on the questions below - I haven’t found answers by searching the FAQ.
I am using the Lynxmotion RIOS SSC-32 (v1.06) software in Windows 7 to control an AL5B robot arm. The function it performs is to respond to one TTL input by moving a film slide onto a microscope stage and then signal done on an output, and to a second signal it respondes by moving the slide off the stage to a discard pile and signalling done. To do this I have a simple loop in the “Play” dialog that is effectively infinite:
do
if Input #1, do Sequence 1
if Input #2, do Sequence 2
while Counter#3<999 (ie, forever)
The signals happen about once per hour, so this loop is executed a lot of times without the Sequences being performed.
The problem is that the logfile:
Program Files (x86)\RIOS_SSC-32\PlayLog.txt
fills up with a record of the cycles through the while loop until after a few days when it reaches a size of ~138 kBytes, and then a dialog pops up about not being able to insert a line. The whole process stops until I dismiss the dialog, stop the loop, exit the “Play” dialog and delete the PlayLog file. The Playlog file can also be awfully persistant - I delete it and its gone from the RIOS_SSC-32 folder, but shortly after re-appears, all 138 kBytes of it - and without any loops or Sequences running. Restarting RIOS seems to be the only fix for this.
My questions are:
Is there a way to turn off the logging? I don’t really need it, and its causing more trouble than its worth.
Is there a way to ‘sleep’ after action 1, even if for a minute or so, to reduce the CPU procssing load and (if the logging can’t be disabled) reduce the data written to the log file?
A further question about restarting RIOS. I do the following steps to restore the robot arm to a state where it can play the Sequences reliably - but one part in #2 seems to be unnecessary.
On the main window (with the picture od a robot arm and lots of buttons) I hit the SSC-32 button, and load a configuration file saved previously. The Arm will move to the saved “home” position. Dismiss the “SSC-32” dialog.
Hit the “Arm” button on the main window, hit the “Arm…” button at the top-left, and check the correct Arm model is selected. The “Base” is always “Old design” even though I select “New Design” and save this on the “Arm dialog” - this seems to be a bug in RIOS. Click OK and exit from the “Arm” dialog.
Click the “Moves” button on the main dialog - then the “Play” button from that, and start playing the loop.
In #2 the config file is not recording the preveiosly selected base for the robot arm, which seems like a bug.
Thanks for any help with the log file and the Arm base configuration setting.
The only answer that I can give you is the one I am most knowledgeable about.
You could get rid of RIOS completely by using an inexpensive microcontroller such as the BotBoarduino or the Basic Atom Pro 28. You would just need to write a simple program that would send commands to the SSC-32 just like the computer was, in response to the TTL signal. This could operate continuously until 1. The Sun explodes and wipes out the Earth, or 2. You forget to pay the electricity bill.
Thanks, an option I will consider. However, the robot goes out of position slowly, with time, or more quickly if an ‘incident’ takes place (it sure whips around fast when the servos are enabled or set to the ‘standard position’!), and the steps have to be fine-tuned - which is easier if the RIOS software is the controller. I guess this could then be re-downloaded to a hardware controller. (I already have an Arduino controlling a motor that ejects film slides for the robot to pick up - its a neat, cheap, and easy way to go).
To get reproducibility, after turning on the RIOS host PC, I load a config file and enable the servos - that’s when the whipping occurs. Not sure why this is necessary. And yes, if the moves are downloaded to a hardware controller, they could be avoided, but re-learning positions has to be done a bit to often for my liking. Anyone interested >crickets< can see the project in motion here (2min movie).
The robot arm has two sets of moves - loading the film for scanning, and unloading after. The images (in this example) are cryo-electron micrographs of herpesvirus capsids and the purpose is to automate scanning of the films. The scan shown here is a 2x2 series instead of 22x25 to make the movie short!
OK, thanks for the advice. I will look into downloading (compiling?) the RIOS sequences to a controller. As for parking, I had removed the springs and the current ‘parked’ position is just where the arm relaxes too with the power off (in between cycles - ie, it runs about once per hour to unload the old slide and reload the new one). Wasn’t sure if he springs were really helping much. I also swapped out the servos for the digital equivalents, although that didn’t make much difference.
First, as an AL5D owner, I am really impressed with what you have got your arm doing. The video raised one question on workflow: After the arm placed the slide holder against the vertical dowel, it released the holder then reacquired it and made a position correction before releasing again and returning to its standby position. Was this done automatically under program control with position input from sensors, or under manual control from the operator? Either way is quite impressive.
Second, and I don’t mean this as a criticism (not knowing the design requirements of your project) but merely as a question because you have interested me. Would it not be possible to eliminate the arm altogether? From the little I can see of the entire structure, it would appear that the incoming stack loader could be rotated 90 degrees, and realigned to feed a slide holder directly against the dowel. When the scan is complete, the dowel could be dropped below the table until the loader has nearly finished pushing the old slide holder away with the next one. Then the dowel could be raised again to position the new slide.
This would still be automation of a sort although not nearly as interesting as the device you built.
In any event, you created a practical application for your robot while my audiences think I am just playing with toys.
Thanks! I had some help from a departmental workshop in building the platform where the film holders eject, and they suggested the robot, which has turned out to be better than originally expected. But the movement you refer to is:
The arm drops the film holder into a recess, with some degree of accuracy
It then pushes sideways (without re-grabbing the holder) to make sure it has dropped fully into the recess.
Currently this pushing is unnecessary as I have found why it was a little too imprecise before, although I still do the push motion just to make sure. The whole thing is a lesson in making something work with 100% reproducibility despite a bit of shaking and stuff.
The inverted Nikon microscope has limited access underneath - there are the objective lenses there - and the film box (taken from the electron microscope) would have to feed on top but under the microscope light collimator - again, not enough space. We did consider a caterpillar track-like mechanism to feed the films onto the stage, and some kind of lifter to pop it up for feeding out, but the robot has immense flexibility in that its limitations are primarily in what I program (easy to change) provided it can reproduce a sequence with sufficient accuracy. And it does. And its cost-effective!
It certainly gets attention when we have students come through, and other visitors. But its a tremendous satisfaction because the manual scanners (Nikon Super Coolscan 9000) run at about 10 minutes per film, and they have to be rotated for a second scan to capture the full area, and 100 films like this is extremely tedious. The robot is currently working with considerable reliability and I am ironing out the occasional hiccups, mostly in the discard. The duty cycle is about 2 mins/hour, so its not over-worked.
I should add - its all automatic, not sensor input, just a look-and-learn sequence I programmed with the RIOS software, and it is currently RIOS playing it back. The robot is triggered by a TTL input on one port to load, and on another port to unload. RIOS is simply sitting in a look testing each input port and running the associated sequence if the port ‘fires’. That is why my original question was poster - this looping doing mostly nothing is logged to a file that eventually can’t be written to any more, so every 2 days I have to stop, delete the file, and start again.
