Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Jmriusers
- Messages
Search
Locked
Re: Serial port too slow? Can anything work.
dale_gloer
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 portoption as I posted on this thread on 6/1? I've no successful experiencewith Java yet, but IMHO it would help to try to reset the windows defaultwork. don'tWould you be willing to compile it and send me a library? I itsomebodyhave any build tools on my test windows machine. Or perhapselse could do that?I downloaded all the RXTX development package and tried to build but it--------------------------------------------------------------------looks like it is intended to be built using a Linux system thatmaybe crosscompiles for win32. So I didn't get very far with it on my Win2Ksystem -sorrySponsor ---------------------~--> -~-> |
Locked
Re: Serial port too slow? Can anything work.
Harlan Warden
Just out of curiosity, did anyone try setting the windows port option
toggle quoted message
Show quoted text
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@...> To: <jmriusers@...> Sent: Wednesday, June 12, 2002 4:11 PM Subject: Re: [jmriusers] Re: Serial port too slow? Can anything work. somebodyWould you be willing to compile it and send me a library? I don't but itelse could do that?I downloaded all the RXTX development package and tried to build it looks like it is intended to be built using a Linux system thatmaybe cross compiles for win32. So I didn't get very far with it on my Win2Ksystem - sorrySponsor ---------------------~--> Will You Find True Love?-~->
|
Locked
Re: Serial port too slow? Can anything work.
Alex Shepherd
Would you be willing to compile it and send me a library? I don'tI 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 |
Locked
Re: Serial port too slow? Can anything work.
This is great!
toggle quoted message
Show quoted text
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 myapps? --
-------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) |
Locked
Re: Serial port too slow? Can anything work.
--- In jmriusers@y..., "greggeeca" <ggee@g...> wrote:
Well, I installed JMRI on my 1 year old laptop and it says that myapps? Will any software work on my laptop, such as pr1dos, ... with anThe 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. |
Locked
Re: Serial port too slow? Can anything work.
dale_gloer
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:theIf we go down this path does it mean that we will have to migrate API or doescurrent JMRI port access from using the SUN CommAPI to this RXTX samethe RXTX api fit under the existing SUN commAPI and implement the it adriver interface. Guess it will become clear to me after I dig into bit...The RXTX folks have two versions of their library, called 1.4 and |
Locked
Re: Serial port too slow? Can anything work.
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 theThe 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) |
Locked
Re: Serial port too slow? Can anything work.
Mike Davison
I'm not an expert on this topic, but I did do some related work for Linux and
toggle quoted message
Show quoted text
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 On Monday 03 June 2002 02:58 pm, Alex Shepherd wrote:
The code comes from . It's what Mike Davison setI've downloaded both the RXTX stuff and the MinGW package that appears to be |
Locked
Re: Serial port too slow? Can anything work.
Alex Shepherd
The code comes from . It's what Mike Davison setI'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 |
Locked
Re: Serial port too slow? Can anything work.
At 8:51 AM +1200 6/3/02, Alex Shepherd wrote:
> There's an alternate library (RXTX) for which the source code isThat would be _great_!available, and it may well be possible to modify it so that it works.Got a URL for this one - I may be able to have a look, we have the MSDN kit 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 theThe 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) |
Locked
Re: Change the way we present decoder names?
Alex Shepherd
At 9:27 PM +0000 5/31/02, jondavis76051 wrote:I have got a long custom HotSync cable for my Palm to do something with JavaOne thing I am interested in trying is to port JMRI over to the PalmOSSounds like an interesting project. 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... |
Locked
Re: Serial port too slow? Can anything work.
Alex Shepherd
There's an alternate library (RXTX) for which the source code isGot 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!!! |
Locked
Re: Serial port too slow? Can anything work.
dale_gloer
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: apps?Well, I installed JMRI on my 1 year old laptop and it says that my this.Will any software work on my laptop, such as pr1dos, ... with anThe LocoBuffer will almost certainly work. It uses standard serial Some hardware can do it, and some can't.works. But this is going _really_ slowly, as I keep having to learn new |
Locked
Re: Change the way we present decoder names?
At 9:27 PM +0000 5/31/02, jondavis76051 wrote:
One thing I am interested in trying is to port JMRI over to the PalmOSSounds 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) |
Locked
Re: Serial port too slow? Can anything work.
Well, I installed JMRI on my 1 year old laptop and it says that myThe 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) |
Locked
Re: Serial port too slow? Can anything work.
Harlan Warden
Greg,
toggle quoted message
Show quoted text
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 ----- Original Message -----
From: "greggeeca" <ggee@...> To: <jmriusers@...> Sent: Saturday, June 01, 2002 3:14 PM Subject: [jmriusers] Serial port too slow? Can anything work. Well, I installed JMRI on my 1 year old laptop and it says that myapps? Will any software work on my laptop, such as pr1dos, ... with an |
Locked
Re: Serial port too slow? Can anything work.
Mike Davison
My hunch is that this is an operating system rather than a hardware issue. PC
toggle quoted message
Show quoted text
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 On Saturday 01 June 2002 01:14 pm, greggeeca wrote:
Well, I installed JMRI on my 1 year old laptop and it says that my |
Locked
Re: decoder id and naming confusions
Jon Miller
One way to solve this is to show the results in a more verbosewidget. 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 |
Locked
Re: decoder id and naming confusions
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) |
to navigate to use esc to dismiss