开云体育

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

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

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

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)

--- 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,

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)

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)

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

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

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)

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...

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!!!

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)

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)

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)

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

My hunch is that this is an operating system rather than a hardware issue. PC
serial ports have been doing 56K for man years. I assume you're using
Windows. I know nothing about Windows so I can't help other than to suggest
looking at Windows rather than the laptop hardware. You might look at the
CMOS configuration too.

cheers,
Mike

Bob:

Would "Typical" work for "General"?

Jim Hanna

One way to solve this is to show the results in a more verbose

widget. Maybe a scrollable list of decoder names, with up to 10
showing? That would make it clear that there are multiple choices,
because you could see the alternatives. The scroll bars would make
it clear what to do to see the rest of them if the list is too long.
You'd select one by highlighting it.<

Sometimes these problems can be solved with instructions and/or
training. As I think my clinic proved just a little time with DecoderPro
and it becomes very easy to use. The concept between trying to identify
what is in the engine vs just selecting the decoder doesn't become a large
problem. Of course if you just bought an engine and want to know what's in
it then that becomes a different matter.
The problem of the famous 255 reading (and other happenings) is not
unique to DecoderPro even throttles will do that. I think instructions or
text can work here. Of course I'm like everyone and don't read stuff
either<VBG>.
The small group that was at my house quickly adapted to which list to
pull down. Maybe I'm getting a little political here but it seems to me
that the time needs to be spent on areas that tend (and here is where IMHO
comes in) to need a lot of help. Having DecoderPro work with the MS100,
which I think is probably not an easy job. Getting more decoders in the
list. Tying the decoder listings to families.
Now I'm sounding like a ***! Seriously though, thoughts
on this. It's ok to tell me to go back to my cage!

Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS

I think there are several causes of confusion that are really different. Maybe it would help to think about them seperately?

a) "The Ident button picked the wrong decoder!"

Some of these are problems in the definition files, and we just have to fix that.

Some of these are due to the way that we present the results of the attempted identification. The result of the identify operation is a list of decoder types, sometimes a really long list. With the current user interface, only one shows unless you click that one to extend it. Some people don't know there are more values there, and get confused.

One way to solve this is to show the results in a more verbose widget. Maybe a scrollable list of decoder names, with up to 10 showing? That would make it clear that there are multiple choices, because you could see the alternatives. The scroll bars would make it clear what to do to see the rest of them if the list is too long. You'd select one by highlighting it.

b) "My decoder isn't on the list!"

That's really two cases, which I think it important to separate:

b1) "My decoder isn't on the list! And you identified this other one instead!"

That's a lot like case (a) above. The happens when the manufacturer has a lot of similar models, and uses the same CV version number to identify several, and we haven't added the specific decoder model to the definition file.

Generally, you can still program successfully if you just tell the program to use the similar decoder that has the largest number of outputs. This is where the idea of the "family" comes in. Digitrax has a number of "FX decoders" that differ in size/shape, current capacity, number of outputs, etc. But the CVs are really the same (except for those that don't matter when certain outputs are not present).

If the user knows the basic type ("Oh, this is an NCE Silent Running decoder, that will do!") and has a way to select that, things will go OK. We don't have to have any confusing "family" terminology appear, we just need to give them a way to understand that their decoder will probably program OK.

So I suggest that the top entry in the list of identified models be something like "General <name here> decoder", e.g. "General Digitrax FX decoder", "General Lenz BEMF decoder", "General SoundTraxx DSD Steam decoder", etc. That would then be what's selected when the list pops up after an identify. The user can look for a more specific model number, and if it's not found just go with the general one. (Maybe somebody can think of a better word than "general"? "Generic" sounds too medical, "Basic" might give the wrong impression, and those were the only ideas I had)

That would also allow us to make the entries in the decoder list alphabetical (within manufacturer). Right now, I put the "most general", usually the one with the most outputs, at the top of the list, and I agree that's confusing.

b2) "My decoder isn't on the list! In fact, you didn't identify any model at all!"

This means that we really don't know much about this decoder, as the CVs didn't match any file. And I'm not sure what to do here. The user might want to try the standard NMRA CVs, or another decoder from this manufacturer.

In this case, I'd like to gather some information from them. I think it would be useful to know what the CV7/CV8 values are, and what (if anything) the user knows about this decoder. So it might be fun to pop a little window that requests permission to send an email with the CV values, and gives the user a little box to enter what they know about the decoder. We could send the mail to a sourceforge alias that accumulates them so we know what decoders are missing, and gather the CV values to make things work better.


c) "It didn't find anything at all!" This can happen if there's a problem reading, in which case wierd stuff happens. That's something that I just have to make more robust in the code. Mark suggested a button above the two Ident buttons called "Check loco connection" or similar that reads CV3 to make sure we _can_ read CVs. If a value of 255 or 0 is found, or the command station reports an error, it's clear that Bad Stuff Has Happened, and we can prompt them through some troubleshooting steps...


Are there other cases?

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