I am using a FTDI based USB-RS422 converter and a SICKLMS200 laser and I
have now tried your new driver. These are my findings.
When I am using kernel 2.6.18-5 (in Debian 4) the "old" driver works
fine at baudrates 9600 and 38400. It usually works with 500000 also but
I know that I have had problems sometimes when I have tried this mode.
Normally I use 38400 because I know it will work.
With your driver everything seems to be ok at all baudrates. 500000 have
been working every time I have tried it so far. (perhaps 8 times, I
dont really remember). 38400 also work every time.
I have been trying to use a newer kernel version in debian, version
2.6.22-3 from Debian backports to fix another problem I was having. With
this kernel the "old" sicklms200 driver would always time out at any
baudrate. Which was a bit disappointing. I dont know what they have
changed in the kernel (or the ftdi serial driver) to cause this.
When I tried your new driver with this new kernel I was actually able to
get the laser working most of the time. But only at 500000, 38400 never
works? I get different timeouts every time. I could not try 9600 because
the driver told me it was not a supported transfer speed.
It is strange that the higher baudrate works but not the lower one.
Aside from this the driver starts up faster than the old one which is nice.
Kevin Barry wrote:
> Hello all,
> I've been working on fixing up the SICKLMS200 driver.
> Changes so far:
>  The old FTDI method. Linux only. (With no changes made).
>  Fake baud rates as used by the CP21xx RS422 to USB. (Ie you
> open a tty at speed 230400 as far as the OS is concerned, but at the
> RS422 level it's actually 500k). This might work with non-CP21xx
> methods, and this mode but with no remapping (ie set
> serial_high_speed_baudremap to 500000) might work with other
> converters. I've only tested it with the Cp21xx, but on both Mac OS X
> and Linux.
> Example configuration files are included.
> --Better time outs. I've increased some timeouts and decreased some
> timeouts, but most importantly I added a separate time out for receive
> the header of the message. This is because it /can/ take a long time
> to get the whole message sometimes, but if you don't get the header
> quickly, you'll never get the message. This makes the trial/error of
> connecting at different baud rates much faster.
> --PLS support ??
> I don't have a PLS to test with. But I looked at the code from the
> sickpls and it seems almost identical. The password is different, but
> I now generate the password based off the response from the
> GetLaserType() query (Meaning it works on LMS and should work on PLS).
> The only other difference I could find was that the intensities are
> &'ed with 0x07 rather than 0x0E, so I included this too. I'm concerned
> that the PLS might not support SetLaserRes and SetLaserConfig, but I
> left them active for now hoping that someone can test it.
> For now I'm distributing this as a tarball because I'd really like
> some testing and I think an external module is easier to test with.
> Especially in the case of the PLS where I might need to make a few
> versions before it works. But I'll be submitting a patch soon. If
> people with FTDI's could test this patch too and report on high speed
> mode success/failure. Also if people not using any high speed mode
> could test this to ensure I didn't do anything silly with the timeouts
> (Though I've tested a bit at 38400 and it seems good).
> -Kevin Barry
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> Playerstage-developers mailing list