christian Posted January 15, 2007 Share Posted January 15, 2007 hi I'm using a LJ U12 and DAQ Factory for monitoring our production-lines. so far the program runs but I have sometimes trouble with starting. Then I receive the following codes D0004_1009 Labjack U!": Gerneral error: could not claim Labjack D0004_1009 Labjack U!": Gerneral error:close handle error I get this messages mainly on starting up, but sometimes I get this message while the program runs normal. could you please explain me what this messages mean. do you have any ideas what's the problem in my case. thanks for your help christian Link to comment Share on other sites More sharing options...
LabJack Support Posted January 15, 2007 Share Posted January 15, 2007 The first error means that Windows could not claim the U12 for some unknown reason. To prevent simultaneous access, the U12 must be "claimed" each time something tries to talk to it. We generally see this error with thread related problems, or when running multiple programs at the same time. The second error means that Windows could not close the handle to a device. I can't think of any reason why this would happen. If the problem is pretty repeatable, you could post your CTL file to see if others can recreate the same problem. Link to comment Share on other sites More sharing options...
christian Posted January 16, 2007 Author Share Posted January 16, 2007 I'm sure there is no other labjack using program running. here is the file thanks christian Link to comment Share on other sites More sharing options...
christian Posted January 17, 2007 Author Share Posted January 17, 2007 sorry I forgot to attech the file Anlagenmonitor_.zip Link to comment Share on other sites More sharing options...
AzeoTech Posted February 22, 2007 Share Posted February 22, 2007 First, I'd make sure you have the latest versions of everything. Go to www.daqexpress.com to get the latest DAQFactory Express. Go to labjack.com to get the latest LabJack drivers. Next, does this happen after you stop DAQFactory and restart only? If so, DAQFactory may not be shutting down completely before you restart. Run task manager and look at the process tab and make sure you DAQFactory doesn't show up. From your document I don't see anything wrong, at least not in the channels. You have a lot of script and its not properly indented so I couldn't check that. The one thing I noticed is that you use wait(). I recommend using delay() unless you are sure you want the feature of wait() and understand its use. Link to comment Share on other sites More sharing options...
christian Posted February 28, 2007 Author Share Posted February 28, 2007 hi The one thing I noticed is that you use wait(). I recommend using delay() unless you are sure you want the feature of wait() and understand its use. yes I'm shure I want to use the wait statement because I want the Sequence to be executet exactly every 0.2 s. I've also updated the drivers so I see no reason for the problems. do you have any other ideas ???? thanks christian Link to comment Share on other sites More sharing options...
AzeoTech Posted February 28, 2007 Share Posted February 28, 2007 Good, then it sounds like you understand what Wait() is for. Note that with the U12, DAQFactory can't really do precise timing that it can do with other devices (including the other Labjacks). This is because of the USB library used by the U12. As for your problems, we are still unable to reproduce it. Perhaps the LabJack guys could give it a try and see if they get the same issues? The DAQFactory U12 driver hasn't been changed in years and thus is quite stable. I don't think the U12 drivers have changed in a while either and I haven't heard of these issues with others. My guess is that something on your computer is causing this problem. Perhaps you have another device on an USB port that is occasionally pulling just over the power limit on the port? There are a lot of interactions between devices plugged into a PC that are not competely obvious. This is largely because motherboard manfacturers try to put multiple subsystems on the same bus or power supplies instead of isolating each one. It could also be radio interference, or it could just be a defective U12. Have you tried the U12 on other computers? In other locations (i.e. a different building)? Have you tried using LJLogger instead of DAQFactory? Link to comment Share on other sites More sharing options...
christian Posted February 28, 2007 Author Share Posted February 28, 2007 How susceptible to radio interference is the LJ? We use the system in our production area where we use high-frequency generators in a distance about 5m. I will try to shield the system using a metallcase. I can eliminate a defect in the LJ, because I tried 2 of them receiving the same errors. We have nothing changed in our running system christian Link to comment Share on other sites More sharing options...
LabJack Support Posted February 28, 2007 Share Posted February 28, 2007 To try and recreate the erorrs, should we close and restart your program a lot, or just let it run for a long time? The U12 has been through CE testing which includes RF immunity, so it is similar to other electronic devices in that regard. Have you tried running on a different computer in a different location? Link to comment Share on other sites More sharing options...
LabJack Support Posted February 28, 2007 Share Posted February 28, 2007 Also, if you run your CTL with nothing connected to the U12 (except USB), can you cause the problem? That is how we will run it. Link to comment Share on other sites More sharing options...
LabJack Support Posted February 28, 2007 Share Posted February 28, 2007 We had to comment out lines 83-86 of your A_Start sequence, as they seem to reference virtual channels that do not exist (something to do with "takte"), but we now have your program running. No errors yet. Link to comment Share on other sites More sharing options...
christian Posted March 5, 2007 Author Share Posted March 5, 2007 hi typically the errors occur when the program is running for a long time. I'm not shure if the errors occur when nothing exepting the usb is connected to the Lj. I tried to change the location a bit and at the moment the software is running. It seems to be helpfull to restart the pc in seqence but I think this is not an practical solution, because we want to have an automatic working monitorsystem for our lines the code-fragments including "takte" are leaving of special data that sould be logged but it didn't work. I think I just forgot to cut them out. thanks christian Link to comment Share on other sites More sharing options...
LabJack Support Posted March 6, 2007 Share Posted March 6, 2007 Some thoughts: 1) We have run your program a while and have not had the errors. How often do you see the errors? 2) We would expect those type of errors to be the result of threading issues. Perhaps something can be changed about the structure of your program to make sure everything is in the same thread or sequential threads? Azeotech would probably have to comment on that. 3) We are looking very closely at the U12 driver as far as threading issues. Will let you know if we find anything to improve. Link to comment Share on other sites More sharing options...
LabJack Support Posted March 7, 2007 Share Posted March 7, 2007 We did find something in the driver that could have caused your errors in a multi-threaded application. Driver version 1.20 is attached. - Close all U12 related programs. - Search your entire hard drive for "ljackuw.dll". There should only be one copy and it should be in your Windows system directory. - Replace that DLL with the attached version. - Run LJtest.exe and it should report driver version 1.20. ***Attachment removed*** Link to comment Share on other sites More sharing options...
LabJack Support Posted October 11, 2007 Share Posted October 11, 2007 Attachment to the last post has been removed. The latest driver should always be downloaded from the U12 downloads page. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.