From: Fred L. <ff...@ab...> - 2012-06-07 09:38:48
|
On Tuesday 05 June 2012 12:34:33 Fred Labrosse wrote: > On Sunday 03 June 2012 19:33:50 Rich Mattes wrote: > > On 06/03/2012 12:19 PM, Fred Labrosse wrote: > > > On Saturday 02 June 2012 20:00:35 Travis Woodbury wrote: > > >> Fred, > > >> > > >> You have a cabling issue of some sort that should be resolved. I've > > >> not > > >> looked at the code to see exactly how it works, but the 'EMI?' warning > > >> has always been spot on in identifying cabling issues, from my > > >> experience. USB signalling isn't especially robust and is sensitive to > > >> poorly build/designed cables, RF noise sources near the cables, and > > >> shortcuts in filtering on the PCB's. Tough to speculate without > > >> knowing > > >> more > > > > > > Thanks for the input. Yes, I suspect cabling issues, as I have had a > > > lot > > > of that sort of issues recently. I have in particular experienced a > > > drop > > > in power provided by the USB ports from the computer and have had to > > > feed > > > in external power via powering USB hubs... However, this device is > > > directly connected to a "native" USB port, and I'm wondering if this > > > could be the problem... More investigation needed. > > > > > > Thanks. > > > > > > Fred > > > > For what it's worth, we've had a lot of problems with the USB ports on > > Dell laptops deciding to cut out intermittently when under heavy load > > (we had the two Segway modules in an RMP400 hooked up.) We were able to > > work around it by making sure all of the USB connections went through a > > USB hub to a single USB port on the computer, for whatever reason that > > helped things. Our theory was that the laptop's USB controller couldn't > > handle multiple connections at full speed. > > I agree, USB is less than good.! > > > If you need to work around it in software though, you can indeed > > unsubscribe everything from the driver, which will cause the driver to > > close the file descriptor to the port. Once everything is unsubscribed, > > if you need to change the port that the laser is connected to, you can > > the driver's port string as a Driver Property[1]. > > I think the problem is worse than that. I haven't delved in udev rules, but > my system (gentoo) provides by-id symlinks, which is very handy. However, > these seem not to be released until player is shutdown, even if the link is > pointing to the new device... I think the solution there is to come up > with a udev rule to make sure my devices always appear as the same ttyUSB > device. > > The bigger problem for now is that player does not seem to realise that it > is not getting data any more. I access the lasers via ranger interfaces > and use the GetElapsedTime() function to see how old the data is. This > seems to be updated normally even if I don't get any data... I need to > explore this a bit more though. Obviously, elapsed time was the wrong thing to do, as I understand this is the time between the last 2 data points obtained. So if I don't get any data, then this is not updated. Now using the GetDataTime(), then I can detect that I am not getting data any more (comparing it to the current time). That said, I wiggled all the USB connectors and that seems to have solved the issue... I hate USB! Fred |