Re: [Playerstage-users] Re-connect to a LMS200 laser (ranger)

[Fred L. <ff...@ab...>]

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.

Fred