开云体育

Greg,
You need to check the settings for the port. It is probably
defaulting to 9600 speed, and just needs to be reset to a higher
maximum setting. Assuming you have Windoze installed, look at the
Control Panel, System Properties, Ports, Com1 (or 2), then look at
properties. You can reset the max speed there. Contact me off-list
if you have a problem finding the properties screen.
Harlan

Well, I installed JMRI on my 1 year old laptop and it says that my
COM port can only be set to 9600. I don't understand the reasons
why. Anyway, if this is true for JMRI, what about other loconet apps?
Will any software work on my laptop, such as pr1dos, ... with an
MS100 or PR-1?

If I get a Locobuffer, will that work either?

The LocoBuffer will almost certainly work. It uses standard serial speeds. I've never heard of somebody having trouble with those.

The MS100 needs a non-standard speed, or a specific alternate. On many PCs, the Sun communications library we use can't configure the port to either of those, and you get the message you're seeing. I'm not a Windows expert, and I don't really understand what causes this. Some hardware can do it, and some can't.

Your port is probably fine for other programs, because the problem appears to be in the Sun library, not in the hardware itself.

There's an alternate library (RXTX) for which the source code is available, and it may well be possible to modify it so that it works. But this is going _really_ slowly, as I keep having to learn new Windows stuff. Help from somebody who understands C programming on Windows would help a lot!

Sorry for the problem.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

At 9:27 PM +0000 5/31/02, jondavis76051 wrote:

One thing I am interested in trying is to port JMRI over to the PalmOS
platform (using IBM VisualAge/Java Micro Edition); although, I don't
know how successful this kind of endeavor would be.

Sounds like an interesting project.

Although I've not looked at it in any detail, I think most of the communications stuff should go over pretty cleanly. So you'll be able to talk to the various DCC command stations over the Palm serial port (which we know can speak the LocoNet rate)

You'll probably have to rethink the GUI, because the existing stuff takes _way_ too much space for a Palm screen. You'd probably also want to recode it without Swing, just to save space. That's a good idea anyway, as the works should be independent of the GUI on general principles.

Let me know if there's anything I can do to help.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

I have a loptop that won't set teh correct serial port speed for
JMRI either. It does run the MS100 correctly using WINLOK.

Dale.

--- In jmriusers@y..., Bob Jacobsen <Bob_Jacobsen@l...> wrote:

Well, I installed JMRI on my 1 year old laptop and it says that my
COM port can only be set to 9600. I don't understand the reasons
why. Anyway, if this is true for JMRI, what about other loconet

apps?

Will any software work on my laptop, such as pr1dos, ... with an
MS100 or PR-1?

If I get a Locobuffer, will that work either?

The LocoBuffer will almost certainly work. It uses standard serial
speeds. I've never heard of somebody having trouble with those.

The MS100 needs a non-standard speed, or a specific alternate. On
many PCs, the Sun communications library we use can't configure the
port to either of those, and you get the message you're seeing. I'm
not a Windows expert, and I don't really understand what causes

this.

Some hardware can do it, and some can't.

Your port is probably fine for other programs, because the problem
appears to be in the Sun library, not in the hardware itself.

There's an alternate library (RXTX) for which the source code is
available, and it may well be possible to modify it so that it

works.

But this is going _really_ slowly, as I keep having to learn new
Windows stuff. Help from somebody who understands C programming on
Windows would help a lot!

Sorry for the problem.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@l..., 510-486-7355, fax 510-495-2957)

There's an alternate library (RXTX) for which the source code is
available, and it may well be possible to modify it so that it works.
But this is going _really_ slowly, as I keep having to learn new
Windows stuff. Help from somebody who understands C programming on
Windows would help a lot!

Got a URL for this one - I may be able to have a look, we have the MSDN kit
at work with _all_ the MS dev tools and libraries. Only problem is your
machine just isn't the same after you load it all!!!

At 9:27 PM +0000 5/31/02, jondavis76051 wrote:

One thing I am interested in trying is to port JMRI over to the PalmOS
platform (using IBM VisualAge/Java Micro Edition); although, I don't
know how successful this kind of endeavor would be.

Sounds like an interesting project.

Although I've not looked at it in any detail, I think most of the
communications stuff should go over pretty cleanly. So you'll be able
to talk to the various DCC command stations over the Palm serial port
(which we know can speak the LocoNet rate)

I have got a long custom HotSync cable for my Palm to do something with Java
and JMRI on it. I wondered about just displaying a throttle Widget on the
Palm with most of the work being done on the PC.

However I have gotten distracted by these little uControllers and so my Java
on Palm ideas are parked...

At 8:51 AM +1200 6/3/02, Alex Shepherd wrote:

> There's an alternate library (RXTX) for which the source code is

available, and it may well be possible to modify it so that it works.
But this is going _really_ slowly, as I keep having to learn new
Windows stuff. Help from somebody who understands C programming on
Windows would help a lot!

Got a URL for this one - I may be able to have a look, we have the MSDN kit
at work with _all_ the MS dev tools and libraries. Only problem is your
machine just isn't the same after you load it all!!!

That would be _great_!

The code comes from . It's what Mike Davison set up for comms on Linux. I've been working with the 1.4 version 15 from rxtx-1.4-15.tar.gz on their download page.

When I asked their mailing list, Trent Jarvi wrote:

This should be possible with rxtx 1.4 and some modification. At the
moment rxtx supports the speeds Sun javax.comm does (and maybe a couple
more). The speed can be set to custom speeds using the baud_base and
divisor.

sstruct.custom_divisor = ( sstruct.baud_base/cspeed )

Check SerialImp.c and how it sets 14400, 28800, 12800 and 256000

There will be a little more work needed but that should point to where it
can be done.

The LocoNet PE mentions that the rate can be generated with a divisor, so that part should be OK.

Line 450 of SerialImp.c has a case statement that seems to somehow be decoding the cspeed parameter (from a set of flags) into an integer speed. Line 472 then seems to find the right divisor. So I think that if I could just figure out how to get the MS100 baud rate through to there, life would be good.

But I don't understand the "translate_speed" call at line 384, nor the preprocessing (which seems to want _not_ Windows!) at line 428.

translate_speed seems to convert the original integer baud rate to flags. But then the preprocessing at line 428 should be skipped on Windows, leaving it to fall through to line 492. So the question is how Windows wants to have it's baud rate set to a non-standard rate. Does it have cfsetispeed and cfsetospeed calls?

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

The code comes from . It's what Mike Davison set
up for comms on Linux. I've been working with the 1.4 version 15 from
rxtx-1.4-15.tar.gz on their download page.

I've downloaded both the RXTX stuff and the MinGW package that appears to be
the Win32 development package for RXTX on Win32, which thankfully does not
require the while MS Developer Studio (virus) to be installed.

I will have a dig around to see if this baudrate issue can be sorted.

If we go down this path does it mean that we will have to migrate the
current JMRI port access from using the SUN CommAPI to this RXTX API or does
the RXTX api fit under the existing SUN commAPI and implement the same
driver interface. Guess it will become clear to me after I dig into it a
bit...

Cheers

Alex

I'm not an expert on this topic, but I did do some related work for Linux and
as a result suspect that rxtx will replace the suncomm library on Windows.
This is how it is used on Linux - remove sun, install rxtx.

Mike

At 9:58 AM +1200 6/4/02, Alex Shepherd wrote:

If we go down this path does it mean that we will have to migrate the
current JMRI port access from using the SUN CommAPI to this RXTX API or does
the RXTX api fit under the existing SUN commAPI and implement the same
driver interface. Guess it will become clear to me after I dig into it a
bit...

The RXTX folks have two versions of their library, called 1.4 and 1.5. The member function names and arguments, classnames, functionality, etc, are identical between the two. Version 1.4, which is what Mike used on Linux if I recall correctly, implements the same API as Sun's javax.comm, so it works without any changes to JMRI. That's nice, because we can use RXTX on some machines, and other implementations on other machines. Right now we use RXTX on Linux & MacOS X, Patrick Beard's implementation on MacOS classic, Sun's on Windows, and IBM's on OS/2.

The RXTX version 1.5 puts all the classes in an "org.gnu.io" package tree, instead of the javax tree. Apparently this is important for certain uses which are intended to be 100% "free" software.

So as long as we stick with the 1.4 version, we should be OK.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Bob,

I'm not very competent in UNIX or Java so I am wondering if it will be
possible to get the Windows RXTX API code from the jmri download site.
I am interested in trying it out if I can get it. I have 2 PCs and
neither supports setting the required rate for the MS100. One is a
generic P133 machine with W95 and the other is an IBM Thinkpad T20
with WIN2K.

Dale.

--- In jmriusers@y..., Bob Jacobsen <Bob_Jacobsen@l...> wrote:

At 9:58 AM +1200 6/4/02, Alex Shepherd wrote:

If we go down this path does it mean that we will have to migrate

the

current JMRI port access from using the SUN CommAPI to this RXTX

API or does

the RXTX api fit under the existing SUN commAPI and implement the

same

driver interface. Guess it will become clear to me after I dig into

it a

bit...

The RXTX folks have two versions of their library, called 1.4 and
1.5. The member function names and arguments, classnames,
functionality, etc, are identical between the two. Version 1.4,
which is what Mike used on Linux if I recall correctly, implements
the same API as Sun's javax.comm, so it works without any changes to
JMRI. That's nice, because we can use RXTX on some machines, and
other implementations on other machines. Right now we use RXTX on
Linux & MacOS X, Patrick Beard's implementation on MacOS classic,
Sun's on Windows, and IBM's on OS/2.

The RXTX version 1.5 puts all the classes in an "org.gnu.io" package
tree, instead of the javax tree. Apparently this is important for
certain uses which are intended to be 100% "free" software.

So as long as we stick with the 1.4 version, we should be OK.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@l..., 510-486-7355, fax 510-495-2957)

--- In jmriusers@y..., "greggeeca" <ggee@g...> wrote:

Well, I installed JMRI on my 1 year old laptop and it says that my
COM port can only be set to 9600. I don't understand the reasons
why. Anyway, if this is true for JMRI, what about other loconet

apps?

Will any software work on my laptop, such as pr1dos, ... with an
MS100 or PR-1?

If I get a Locobuffer, will that work either?

Thanks,
Greg

The problem is that the javacomm package uses the serial driver's
list of valid baud rates which doesn't include 16457. You can get
around this under windows (don't know about unix) by getting hold
of the handle used to open the com port and then using jni to call a
C function to set the baudrate to 16457. Use something like:

DCB dcb;

FillMemory(&dcb, sizeof(dcb), 0);
if (!GetCommState(hComm, &dcb)) // get current DCB
// Error in GetCommState
return FALSE;

// Update DCB rate.
dcb.BaudRate = 16457;

// Set new state.
if (!SetCommState(hComm, &dcb))
// Error in SetCommState.

This is great!

We've been hacking around in some quite complicated code trying to fix this. It's only (so far) a problem on Windows, and I've be very happy to add the JNI code to call that function.

Would you be willing to compile it and send me a library? I don't have any build tools on my test windows machine. Or perhaps somebody else could do that?

Thanks!

Bob

--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Would you be willing to compile it and send me a library? I don't
have any build tools on my test windows machine. Or perhaps somebody
else could do that?

I downloaded all the RXTX development package and tried to build it but it
looks like it is intended to be built using a Linux system that maybe cross
compiles for win32. So I didn't get very far with it on my Win2K system -
sorry

Alex

Just out of curiosity, did anyone try setting the windows port option
as I posted on this thread on 6/1? I've no successful experience with
Java yet, but IMHO it would help to try to reset the windows default
value. I've not worked with Win2K or XP, but it does apply for '98,
'95, and 3.1
Harlan

Harlan,

I have Win2K and I tired your suggestion. I set the port speed to
57600 and when I started DecoderPro I got 2 messages, one saying
it couldn't set 16600 and the second saying it was trying to set
16457. then the pop up window appeared saying for the serial port
speed error. So no go.

Dale.

--- In jmriusers@y..., "Harlan Warden" <hdwarden@n...> wrote:

Just out of curiosity, did anyone try setting the windows port

option

as I posted on this thread on 6/1? I've no successful experience

with

Java yet, but IMHO it would help to try to reset the windows default
value. I've not worked with Win2K or XP, but it does apply for '98,
'95, and 3.1
Harlan


----- Original Message -----
From: "Alex Shepherd" <ashepherd@w...>
To: <jmriusers@y...>
Sent: Wednesday, June 12, 2002 4:11 PM
Subject: Re: [jmriusers] Re: Serial port too slow? Can anything

work.

Would you be willing to compile it and send me a library? I

don't

have any build tools on my test windows machine. Or perhaps

somebody

else could do that?

I downloaded all the RXTX development package and tried to build

it

but it

looks like it is intended to be built using a Linux system that

maybe cross

compiles for win32. So I didn't get very far with it on my Win2K

system -

sorry

Alex


------------------------ Yahoo! Groups

Sponsor ---------------------~-->

Will You Find True Love?
Will You Meet the One?
Free Love Reading by phone!

--------------------------------------------------------------------

-~->

To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@y...



Your use of Yahoo! Groups is subject to

--- In jmriusers@y..., "Harlan Warden" <hdwarden@n...> wrote:

Just out of curiosity, did anyone try setting the windows port

option

as I posted on this thread on 6/1? I've no successful experience

with

Java yet, but IMHO it would help to try to reset the windows default
value. I've not worked with Win2K or XP, but it does apply for '98,
'95, and 3.1
Harlan

Same problem here as with the javacomm package. Setting the port
options (on windows---don't know about unix) uses the driver supplied
list of valid baud rates which doesn't include 16457. Same problem
with anyone trying to use MSCOMM in VB. However, using the Win32 API
functions GetComm/SetComm, you can set the baud parameter in the
device control block (dcb) to 16457.

Scott Goodwin

It's not quite so simple. I'm not completely fluent in Java so I'll
only sketch the theoretical solution to the problem and hopefully
someone can fill in the Java details.

Here's the problem. The windows serial driver has a built in
function/dialog that allows you to configure the serial port.
If you use the port settings under the device manager, you will see
that you are presented with a dialog that has a dropdown list for
setting the baud rate. The list doesn't include 16457. And you can't
type in 16457. So there's no way to set it to 16457 through the
device manager. If you use MSCOMM in VB, you can use the settings
property to set the baud rate, etc. Again, it won't accept 16457 for
the same reason. The package javax.javacomm apparently has the same
problem---it just won't accept 16457 because it is using the serial
driver's list of valid baud rates.

Of course, programs like LocoNetMon, RR&Co, and Winlok work just fine
on the same computers that MSCOMM,javax.javacomm, etc don't work. Why?
Well, if you look at the source code for LocoNetMon (available from
the loconethackers group), you will see that it opens the Com Port
using Win32K's CreateFile function wich returns a file handle/file
descriptor. This file handle is used in the function GetComState
which gets the current device control block (dcb). You can then set
the baud rate in the dcb to 16457. Then use SetCommState to apply the
new settings.

So the theoretical solution to the problem of not being able to set
the baud rate to 16457 through javax.javacomm is:
1) get hold of the file handle/file descriptor
2) use JNI to call a C/C++ function which uses GetCommState,sets
dcb.BaudRate = 16457, and calls SetCommState

Now come the parts of the puzzle I don't completely know.

First, for part (1), how do we get hold of the file descriptor that
javax.javacomm is using? I've scoured the docs and I don't see
anywhere where it gives access to the file descriptor. However, you
will see that comportidentifier has two forms of Open. One form has a
file descriptor as it's parameter. So, it might be possible to first
create a file handle/file descriptor, use the second form of open and
then pass the file descriptor to the C/C++ function to update the
baud rate. Java folks: in the comportidentifier's open method, is the
file descriptor parameter call by value like in C/C++ (i.e., in only)
or call by reference (i.e., if the method changes the value of the
file descriptor, do we get it back so we can pass it to the C/C++
function?)

If so, then all is well. Otherwise, we need another way of gettig
hold of the file descriptor. Again, it might be obvious for someone
more fluent in Java but here's my next guess:

Probably the InputStream you get from CommPort in javax.javacomm is
actually a FileInputStream. If so, where you getInputStream in
LnPacketizer (I think), you could cast it to a FileInputStream and
use the method getFD() which returns the underlying file descriptor.
If so, then bingo, you can now can the C/C+ function and pass the
file descriptor.

Well, that's it. Can anyone fill in the missing pieces?

Scott Goodwin


--- In jmriusers@y..., Bob Jacobsen <Bob_Jacobsen@l...> wrote:

This is great!

We've been hacking around in some quite complicated code trying to
fix this. It's only (so far) a problem on Windows, and I've be

very

happy to add the JNI code to call that function.

Would you be willing to compile it and send me a library? I don't
have any build tools on my test windows machine. Or perhaps

somebody

else could do that?

Thanks!

Bob

--- In jmriusers@y..., "greggeeca" <ggee@g...> wrote:

Well, I installed JMRI on my 1 year old laptop and it says that

my

COM port can only be set to 9600. I don't understand the

reasons

why. Anyway, if this is true for JMRI, what about other loconet

apps?

Will any software work on my laptop, such as pr1dos, ... with an
MS100 or PR-1?

If I get a Locobuffer, will that work either?

Thanks,
Greg

The problem is that the javacomm package uses the serial driver's
list of valid baud rates which doesn't include 16457. You can get
around this under windows (don't know about unix) by getting hold
of the handle used to open the com port and then using jni to call

a

C function to set the baudrate to 16457. Use something like:

DCB dcb;

FillMemory(&dcb, sizeof(dcb), 0);
if (!GetCommState(hComm, &dcb)) // get current DCB
// Error in GetCommState
return FALSE;

// Update DCB rate.
dcb.BaudRate = 16457;

// Set new state.
if (!SetCommState(hComm, &dcb))
// Error in SetCommState.

--
--------------
Bob Jacobsen (Bob_Jacobsen@l..., 510-486-7355, fax 510-495-2957)

I've tried to put together people's suggestions on how to improve the process of selecting a decoder for DecoderPro. Robin, sorry, but I just couldn't get pop-down menus to work well.

I'd like your opinions on whether this is an improvement, what should be changed, and even whether we should go back to the old one.

To try it, download



then install it by copying the unzipped files to your existing directory (you should probably keep your old files just in case).

The decoder selection panel is now two lists: on the left, a list of all manufacturers, and on the right a list of decoders. It starts with all decoders we know about listed. If you pick a manufacturer, the right list becomes just those decoder models. The ident button works basically as before.

There's new logic for handling unknown manufacturer codes, unknown decoders from known manufacturers, and certain errors. The status at the bottom of the window is much more verbose, and hopefully more informative.

I'm looking forward to comments.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Bob,

Tried out 0-9-3-2 today. Sorry if these comments seem overly critical, and
of course they are just one person's opinion. And no I'm not just miffed
because the flyouts weren't possible :-) As always I am very appreciative
of all your efforts and for the opportunity you have provided for us to
provide input and voice opinions.

Ok. First I think the programmer display is too busy now. Could the
Manufacturer name list be converted to a combo box? That might help. The
mfr list is quite long, but many don't have any decoders available. Perhaps
suppressing those would make it easier to get through the list. In any
case, I would suggest making the mfr default to the one that was selected
the last time the programmer was used would be a good thing.

It looks like the decoder family names show up in the decoder list. I found
this very confusing. This might be ok if there was a way to see that there
were two distinct types of items in the list - family names and decoder
names. For example indenting, bolding, or something else might make it
more apparent, especially if the app would prevent the user from selecting a
family name (but I fear that would not be easy to implement). I was able to
open a programmer with a family name selected, but the config did not match
any of the members of that family for the Throttle-Up decoders I checked.
(maybe this is really a problem in the throttle-up decoder files I made?)

In the case where there is only one decoder in the family it was especially
confusing since it seemed unclear which name to select. For example, under
Throttle-Up there is "Soundtraxx DSD Diesel decoders" on one line followed
by "DSD Diesel" on the next line. Maybe changing the word "decoders" to
"family" would help, but I don't think that will be enough to eliminate all
confusion. (Selecting the DSD diesel family name produces a programmer with
only 4 columns in the function map, while selecting the DSD diesel decoder
name produces the correct function mapping with 12 columns.)

Other stuff

Would it be possible to update the mfr and decoder list selections when the
user selects an item from the "Use locomotive settings for" combo box? This
would be a handy way of checking roster entries to see what decoder types
were used.

I was able to open more than one programmer setup window at the same time.
Hadn't noticed this before. Wouldn't think you would want this for
programming track use. If Ops mode programming gets supported this might be
good, but you would probably want to supress programming of the loco ID in
this case?

The mfr name list was scrambled when I first ran the update. After
reindexing it appeared in alphabetical order.


Robin