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. Here is a link to read more about the LabWare LIMS and other issues.
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? 😉
4 Thoughts to “LabWare LIMS – Asyncronous”
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?
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.
Can this affect scheduled tasks like logging stability samples or instrument calibration samples?
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.