***** UPDATE *****
We have tested 200 µl tips, which generate the "DiTi not mounted properly" error when taken from the SBS box, by placing them in the holes of the hanging racks. The arm mounted them from there without any problems. This way we have confirmed that the tip itself is not the cause of the problem.
By doing this I observed that the 96 tip hanging rack is a little more flexible than the rack in the SBS box. Therefore when the arm (or rather the finger) tries to mount the tip, it causes the rack to bend a little downwards because of the pressure applied, before mounting the tip securely and picking it up. In the SBS boxes the fitting or the "finger" in the tip is rather "hard". I wondered whether this difference in the last bit of the tip-mounting made a difference. Therefore I put a folded paper towel under the SBS box and repeated the experiment. This made the box a little unstable ( it tilted for a split second when the "finger" met the tip and pressed on it). AND WHAT DO YOU KNOW! THIS ACTUALLY WORKED. The tip was mounted without any problems.
I am not sure what is going on, but I am thinking that somewhere, somehow, there is a setting expecting this slightly bending/bouncing back movement right at the moment when the tip is being secured on the finger by application of pressure. The thing is, I do not know how to change this, but I will probalby have to get a TECAN technician have a look at this and repair or adjust the settings in the software ....
Any ideas are very welcome......
On Thursday, 3 November 2022 at 19:18:50 UTC+1 dank...@gmail.com wrote:
Any thing packed with menus and a 490 page PDF writes a fat file someplace on XYZ attempts, which transducer doesn't like a thing.. Here's the manual and an extract hinting at a log file ( for example ):
https://www.tecan.com/hubfs/394802_en_V2_3%20Application%20Software%20Manual%20Fdm%20EVOlution-1.pdf16.5.6 Log Files The log file contains information on configuration changes and other data which have been created, edited or saved. It documents pipetting and records user actions and changes to parameter values, etc. The log files are written to a specified directory (default location \Program Files\Common Files\Tecan\Logging\...)
Maybe try there as a start. poke around and find the file that changes everytime it does anything, etc. Horribly, this thing uses a MS operating system ( shudder ). But the above anyway gets you a spot in the DIR system to look, almost for sure.... the HHMMSS time stamp is the magic juice to focus your attention(s). Everybody assumes its just a Z position, well, who knows what they have dreampt up in that thing. Esp ! if it works at one end of the table and repeats this elsewhere in XY, now what. Understanding the thing is required and its a horror show when you don't have source code.
Obviously you can just carefully iterate the programmable positions you have, but a peek at the files is maybe fewer hours of tedious work. Even if/when you make it "go" the problem is nearly certain to reoccur, you cannot find the underlying logic completely via iteration without truly incredible amounts of experimentation.
Also, knowing file names by location and name is a huge leg up when talking to the phone help people. Instead of wishing you away with a click to their program, if you mumble out a specific filename, you might get 90 seconds more help before then click "Resolved" on their tracking program.
Motion control problems are usually moderately hard to really resolve. Even when you think its fixed, you usually wrong and it re- occurs sometimes. So what, keep notes and modify everything in truly "baby steps". ex: use the original tips and see if it fails with the new Cartesian settings, make a mixed system with lots of test moves and sub in the new tips one by one, etc.
and look for the file(s) !
You cannot trust even what appears to be success, anyway. There are too many things contingent on that thing to trust what appears to be a few try success. Maybe a highly specific test situation of a few tubes in a difficult to achieve 100 steps would be worth creating as a lab control, with or without this cheaper/different tip thing problem. Tap water will do, tap water with food colouring is maybe better. Most failures like this are total, not proportional, but that would show up hopefully in a last pass qualifying step you should elucidate and execute anyway. A really interesting qualifying step migth combine pH and color and give you a baseline five tubes with a ultra accurate mixed result either a colorimitter or pH tool could measure !
Finding the singular best file it makes with the most detail is surely a happy moment. If the experimenters make careful run records, tell them to make there batch files for file saving copy out that file buried in all the Microsoft noise....
Good luck, you will resolve it; ( First time, second time, etc ) but you will get the dragon slayed with effort.
Regards,
Daniel B. Kolis
--
-- You received this message because you are subscribed to the Google Groups DIYbio group. To post to this group, send email to diybio@googlegroups.com. To unsubscribe from this group, send email to diybio+unsubscribe@googlegroups.com. For more options, visit this group at
https://groups.google.com/d/forum/diybio?hl=en Learn more at www.diybio.org
---
You received this message because you are subscribed to the Google Groups "DIYbio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
diybio+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/diybio/373a9c92-7227-4352-b438-bd1fd3351e71n%40googlegroups.com.
