pharos-bts Posted June 15, 2009 Share Posted June 15, 2009 I'm using a UDIN-44 USB I/O controller from Audon to read/write some 24V digital signals with DAQFactory 5.81. It works fine using the virtual com port assigned when installing its driver, and a simple ASCII sequence to read or write to the I/O bits. But if the device is momentarily disconnected from the USB port, DAQFactory immediately takes up 100% CPU time and the PC locks up requiring disconnection of power. This happens even with a blank DF document containing only the serial driver Quick Device Configuration ie which virtual comms port & protocol is used (9600-1-8-N); no inputs or polling being setup. The problem doesn't occur if the device is connected after DF starts running, only when it is hot-disconnected once communication is established. By comparison the test program supplied with the device does freeze for 3 or 4 seconds after momentary disconnection with a 'failed to connect' message, but then picks up communication again and carries on. The supplied drivers refer to the 'Native USB device driver for FTDI FT8U232/245' (Future Technology Devices International). Is this a known issue, and/or do I have to live with the possible inconvenience ? Thanks for any input Link to comment Share on other sites More sharing options...
AzeoTech Posted June 15, 2009 Share Posted June 15, 2009 This is actually an issue with their virtual com driver, not DAQFactory. DAQFactory uses standard windows calls to the serial port, which the virtual com driver hijacks. If it was a real serial device, you could plug and unplug the device at will and DAQFactory would care less. On well written virtual com drivers for USB->Serial converters, this is true as well. However, poorly written com drivers have the issues you are seeing. Its especially bad that it hangs when DAQFactory first tries to init the port. The software supplied with the hardware undoubtably uses a native driver and bypasses the virtual com port altogether. So you have two choices: 1) live with it 2) try and use their native driver instead of the virtual com port. You'd have to use the extern() functions to load their DLL, if they have one. I should add that this is why I always recommend when using serial to ethernet devices that you connect over the raw port on ethernet and avoid using any virtual comm software that the manufacturer of the converter may have provided. Link to comment Share on other sites More sharing options...
pharos-bts Posted June 15, 2009 Author Share Posted June 15, 2009 OK thanks, that makes sense. I'll have a look at their .dll documentation and see if I can approach it that way within a reasonable timescale. Link to comment Share on other sites More sharing options...
pharos-bts Posted June 17, 2009 Author Share Posted June 17, 2009 Your summary about the bad Virtual com driver behaviour was spot on: I reprogrammed everything using the direct .dll approach, which took a good bit more effort but now it works well. DAQFactory doesn't crash when an open device is disconnected, and by closing and re-opening the device handle I can resume data collection once it is plugged back into the USB. Link to comment Share on other sites More sharing options...
AzeoTech Posted June 17, 2009 Share Posted June 17, 2009 Often the best, most reliable solutions require more effort initially, but usually results in less effort overall because you aren't wasting a lot of time dealing with failures. I'm glad you got it working. Link to comment Share on other sites More sharing options...
RJE Posted July 5, 2009 Share Posted July 5, 2009 I have the same problem using a generic USB/serial device. Would the recommended SeaLevel USB to serial devices suffer from the same problem? I've scanned through the manual for the single port device and there was no mention of a supplied DLL file. rje Link to comment Share on other sites More sharing options...
AzeoTech Posted July 6, 2009 Share Posted July 6, 2009 Not that I know of. The cheapy converters (the ones that you can buy from any old site for $20), all use the same virtual comm driver because they all use the same chip even though they are packaged different. SeaLevel makes their own stuff so they use a different driver so it should work a lot better. Personally, I dislike USB in general for reasons I will only go into if someone really wants to know, and strongly recommend using a serial to ethernet converter instead. With Ethernet, you can bypass any other software completely and go directly to the device (using their RAW port). That said, there are times, such as with a laptop in a non-permanent installation, that ethernet is not as convenient. Bottom line is that you get what you pay for. If you want something reliable, spend the extra bucks and go to sealevel or one of the other places that specialize in industrial devices. I would imagine these places will also offer you much better technical support. Which manual did you scan, and what DLL are you referring? Link to comment Share on other sites More sharing options...
RJE Posted July 6, 2009 Share Posted July 6, 2009 So you are saying the Sealevel devices should work better? I was looking at their SeaLink USB 1 port serial adapter to replace the cheapie one I have now. My computer has no serial port. You mentioned above that you had 2 choices: "2) try and use their native driver instead of the virtual com port. You'd have to use the extern() functions to load their DLL, if they have one." That is why I was reading the manual for this unit and I still need to email them to see if the drivers are good for Vista x64, they do not mention that, only Vista. Then we have W7 coming in fast! I would be interested in your opinion on USB as I come from 20 some odd years in industrial control where 232 & 485 were it and now computer manufacturers are dumping the serial port. I remember programming Xycom display monitors one line at a time, you wanted a square then four lines of code, drawline, x,y, then drawline x,-y etc. and a 10 I/O logic controller was the size of a Buick. rje Link to comment Share on other sites More sharing options...
AzeoTech Posted July 7, 2009 Share Posted July 7, 2009 Yes, the sealevel ones should almost certainly work better. I've been recommending their devices for years and have never had a complaint. As for the DLL, I doubt your cheapy unit comes with a DLL, and truthfully that may not resolve the problem. It depends on where the bug is in their software. The problem with USB is that it requires localized software written by the manufacturer. Hardware manufacturers typically are just that, hardware guys, not software guys, and so the drivers aren't necessarily perfect. Even if you have a company like SeaLevel that has good software guys and that do lots of testing, you are still relying on a piece of software that is only used by a small number of people. However, both Ethernet and Serial drivers are built in to the operating system. Ethernet drivers in particular are constantly in use by every computer out there so as you would expect, they are rock solid, or at least as solid as the OS. By using Ethernet or serial devices, you can completely bypass any software provided by the manufacturer and go directly to the OS and hardware. In summary: 1) USB: 6 ft max cable length, ethernet: 600 ft and easily extended 2) USB: requires driver from hardware manufacturer (except flash drives, and other VERY common devices), ethernet: no extra software required 3) USB: can only connect to one computer at a time, Ethernet: if the device supports it, can communicate with multiple PCs at once 4) USB: plug and play handled by OS and manufacturer driver, Ethernet: plug and play handled by hardware layer In my personal opinion, USB devices do not belong in the industrial world. They are fine for lab bench apps (mostly), but for industrial apps, the slight extra cost and installation required of Ethernet is well worth it. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.