From: Brian G. <br...@ge...> - 2006-10-05 20:32:14
|
hi, I just checked in some changes to the sicklms200 connection logic, to make it more robust: - The timeouts are much shorter, around 2s instead 10s. Now you actually get an error return before giving up and hitting Ctrl-C - The 'connect_rate' option now accepts a tuple of rates to try, e.g.: connect_rate [38400 9600 500000] The rates will be tried in the order provided. The default is [9600 38400 500000]. The old syntax is still supported, e.g.: connect_rate 38400 So you don't need to make any changes to your existing .cfg files if you don't want to. These changes make the driver work *much* better for me. It's all checked in on HEAD and release-2-0-patches. Let me know if you have trouble with it. brian. |
From: David Feil-S. <dfs...@us...> - 2007-03-03 01:53:04
|
Is there a specific reason that 2s timeouts were used? I've been using .2s timeouts to get connected even faster. Since no matter the baud rate I set the driver to start with, it fails the first time, faster timeouts are very useful to me. -Dave ----- Original Message ----- From: Brian Gerkey <br...@ge...> Date: Thursday, October 5, 2006 1:32 pm Subject: [Playerstage-developers] sicklms200 connection logic To: pla...@li... > hi, > > I just checked in some changes to the sicklms200 connection logic, > to > make it more robust: > > - The timeouts are much shorter, around 2s instead 10s. Now you > actually get an error return before giving up and hitting Ctrl-C > > - The 'connect_rate' option now accepts a tuple of rates to try, e.g.: > connect_rate [38400 9600 500000] > The rates will be tried in the order provided. The default is > [9600 > 38400 500000]. The old syntax is still supported, e.g.: > connect_rate 38400 > So you don't need to make any changes to your existing .cfg files > if > you don't want to. > > These changes make the driver work *much* better for me. It's all > checked in on HEAD and release-2-0-patches. Let me know if you > have > trouble with it. > > brian. > > -------------------------------------------------------------------- > ----- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Brian G. <br...@ge...> - 2007-03-03 02:05:38
|
On Mar 2, 2007, at 5:50 PM, David Feil-Seifer wrote: > Is there a specific reason that 2s timeouts were used? I've been > using .2s timeouts to get connected even faster. Since no matter > the baud rate I set the driver to start with, it fails the first > time, faster timeouts are very useful to me. I suppose because the comments in the driver suggest that the laser may be slow to respond (e.g., "This could take a while"). Might be useful to make this delay configurable from the .cfg file. Patches welcome. brian. |
From: Reed H. <re...@mo...> - 2007-03-05 12:50:52
|
Brian Gerkey wrote: > On Mar 2, 2007, at 5:50 PM, David Feil-Seifer wrote: > >> Is there a specific reason that 2s timeouts were used? I've been >> using .2s timeouts to get connected even faster. Since no matter >> the baud rate I set the driver to start with, it fails the first >> time, faster timeouts are very useful to me. > > I suppose because the comments in the driver suggest that the laser > may be slow to respond (e.g., "This could take a while"). Yeah, it depends whether the laser was already on, or if it only turns on when the serial port is opened and then needs to do its initialization and spinning up procedure. Reed |
From: Brian G. <br...@ge...> - 2007-03-05 17:31:25
|
On Mar 5, 2007, at 4:50 AM, Reed Hedges wrote: > Brian Gerkey wrote: >> On Mar 2, 2007, at 5:50 PM, David Feil-Seifer wrote: >> >>> Is there a specific reason that 2s timeouts were used? I've been >>> using .2s timeouts to get connected even faster. Since no matter >>> the baud rate I set the driver to start with, it fails the first >>> time, faster timeouts are very useful to me. >> >> I suppose because the comments in the driver suggest that the laser >> may be slow to respond (e.g., "This could take a while"). > > Yeah, it depends whether the laser was already on, or if it only > turns on when > the serial port is opened and then needs to do its initialization > and spinning > up procedure. Actually, there's a separate option to control that delay, useful on the newer Pioneers with serial-triggered power. The timeout we're talking about here is in the low-level comms, and the comment I mentioned predates the serial-power setup. brian. |
From: Reed H. <re...@mo...> - 2007-03-05 17:59:38
|
Brian Gerkey wrote: > Actually, there's a separate option to control that delay, useful on > the newer Pioneers with serial-triggered power. The timeout we're > talking about here is in the low-level comms, and the comment I > mentioned predates the serial-power setup. > Oh, I see. Sorry Reed |