LabWare LIMS - Asyncronous

Volume IIEntry 7 of 90 in 20152 min read4 comments ↓

Written by Gloria Metrick on January 28, 2015. Published as written. It may not reflect how these systems work today.

I normally don't give out product-specific tips. That's what the LabWare Help Desk is for. However, there is one issue that I think many junior LabWare LIMS people don't know about and there are even more senior LabWare LIMS specialists that don't realize this. It's something that pops-up so often and such a big issue that I want to draw attention to it.

LabWare LIMS programs run asynchronously. Thus, while you might see the programs run in a certain order if you run the debugger, they might not run quite the same way when they run on their own. As your program continues to execute, the actions it has started are not necessarily finished before the next line of code begins to execute. When the system is running quickly, you probably don't realize this.

But if you do anything that slows the system down, say, by adding more code, running across a slow network, or any other factor that would slow it down, you might begin to notice that each task does not necessarily finish before it's needed by the next part of the programs.

The capitol sin, here, is to throw in a Wait() command. It's not going to fix the problem, the problem will continue to pop-up (since you can't really know how long to "wait') and it's just the wrong thing to do. You must fix the problem by figuring out how to move the code around to work properly of the system is never going to be ready for delivery.

In fact, if you use a Wait() command, I hear that there's a mythical Programmer of Vengeance that will come and cut your fingers off. Mythical or not? I don't know, but I know I need my fingers, what about you? ;-)

Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/

The conversation

4 comments from 2 people, January 28 to April 9, 2015. Gloria replied 2 times.

January 28, 2015
John H. Jones
Out of curiosity, when you do this coding or any Lims basic coding to customize the system, are future upgrades affected or is there any work that can get lost when the upgrade is applied?
1. January 29, 2015
  Gloria MetrickAuthor
  It would be unlikely that someone would lose changes in the LabWare system during their upgrade. The code in the LabWare system is separate from the system's code so you can't change any programs that come with the actual system. However, upgrades can always affect code in unintended ways. I would say this is true of any system that, even if code is separated from the core system, there are ways the system can act differently in the upgrade that cause the code to work, differently. Sometimes, there are required changes that affect this, other times, there's a bug in the new system version.
April 9, 2015
Deepak Kachare
Can this affect scheduled tasks like logging stability samples or instrument calibration samples?
1. Gloria MetrickAuthor
  Yes, it can. Everything that is done must be in the right place or it won't take place in the right order. Considering that scheduled tasks are sometimes run at a lower priority, that also means that they are receiving the resources somewhat differently. If you have problems where you log stability samples right from your user account and the scheduled task works differently, that could be one reason why, for example. It could be that your interactive task is running faster making it seem that everything must be correct as it all gets done, as expected. Then, it can happen that you run the scheduled task which might run somewhat slower and there are unexpected problems because, the slower the tasks run, the more likely you are to start seeing the errors in where the code is at - when things run fast, they often happen fast-enough to finish before the next item starts, is what I mean.

Comments are closed. This conversation is from 2015. Ask us to remove a comment

Working on the same problem in your lab?

Talk to a laboratory informatics scientist