Menu
▾
▴
jmri-developers
|
From: <pau...@ac...> - 2003-10-26 17:39:42
|
Hi All, After checking out a few things for Jack Shall today, I'm wondering if should make some changes to how the programmer front end displays things when we're working in register mode. According to NMRA RP9.2.3, we should only be able to access CV 1,2,3, 4,7,8, and 29 in register mode (these correspond to registers 1,2,3,4, 7,8,and 5 -- register 6 is reserved for "paged registers"). Reading from or writing to other CVs does cause an error to be generated (at least with the Lenz back end, it generates an incorrect Timeout talking to Command Station). What I am specifically wondering, is should we grey out everything but these values, since these are the only things we should be able to write to or read from? This may require changes to the "Read all... " and "Write all..." button handlers as well (so they only try to read or write the specific values). Thanks, Paul -- ______________________________________________________________________________ "Quality is a Characteristic of thought and statement that is recognized by a nonthinking process. Because definitions are a product of rigid formal thinking, quality cannot be defined." Robert M. Pirsig Zen and The Art of Motorcycle Maintenance |
|
From: Bob J. <Bob...@lb...> - 2003-10-26 22:17:34
|
At 12:30 PM -0500 10/26/03, pau...@ac... wrote: >Hi All, > > After checking out a few things for Jack Shall today, I'm wondering if >should make some changes to how the programmer front end displays things >when we're working in register mode. > > According to NMRA RP9.2.3, we should only be able to access CV 1,2,3, >4,7,8, and 29 in register mode (these correspond to registers 1,2,3,4, >7,8,and 5 -- register 6 is reserved for "paged registers"). > > Reading from or writing to other CVs does cause an error to be >generated (at least with the Lenz back end, it generates an incorrect >Timeout talking to Command Station). > > What I am specifically wondering, is should we grey out everything but >these values, since these are the only things we should be able to write >to or read from? This may require changes to the "Read all... " and >"Write all..." button handlers as well (so they only try to read or >write the specific values). Unfortunately, I didn't know anything about register mode when most of the basic code was written, so it ended up as a _major_ afterthought. And it shows it. The "CV" code always refers to CV numbers, which are only converted to register numbers (usually by jmri.jmrix.AbstractProgrammer.registerFromCV() ) when a Programmer is asked to read/write them in register mode. The upstream stuff doesn't really know the difference between registers and CVs, instead thinking it's always using CVs. The CV objects do know about the programmer they are to use, so could ask for the mode and then have an activated/deactivated mode. That could then be used by the Variable objects (which currently use the CVs) to activate/deactivate. But it's possible to change the programming mode during operation, so there would need to be some notification. The Variables and CVs are already exchanging state information (that's how the coloring is done in the GUI, for instance), so perhaps the best way would be to provide a new "State", e.g. "Not available" or something, and have the state-handling also handle disabling read/write for those. E.g. "If disabled, don't read or write" This sounds like a bigger job than I'd like to take on right now, but I'd be happy to help. Fixing the "timeout" you're seeing, and converting it to a nicer error, might be a simpler first step. Bob -- -------------- Bob Jacobsen (Bob...@lb..., 510-486-7355, fax 510-495-2957) Am likely to be behind for next week or so. If it's urgent, please call! |
|
From: <pau...@ac...> - 2003-10-26 23:14:40
|
On 26 Oct, Bob Jacobsen wrote: > Unfortunately, I didn't know anything about register mode when most > of the basic code was written, so it ended up as a _major_ > afterthought. And it shows it. well, we can't think of everything we might need. > This sounds like a bigger job than I'd like to take on right now, but > I'd be happy to help. That was my thinking too. It might be a project for December, but I have so many of them lined up already I'm not sure I will get to it. Unfortunatly, making the modifications to the front end is probably the right way to correct the problem. > Fixing the "timeout" you're seeing, and converting it to a nicer > error, might be a simpler first step. I know that would be. I see registerFromCV throws a ProgrammerException, so we could probably catch that earlier and send a different error message. (It doesn't appear to be caught in the Lenz code - but something is obviously catching it, and claiming it's a timeout error). The only problem with this approach is if you happen to do a read/write all sheets. The way the programer is currently written, it retries when an error occurs, instead of just skipping to the next entry. Paul -- ______________________________________________________________________________ "Quality is a Characteristic of thought and statement that is recognized by a nonthinking process. Because definitions are a product of rigid formal thinking, quality cannot be defined." Robert M. Pirsig Zen and The Art of Motorcycle Maintenance |
|
From: Alex S. <al...@aj...> - 2003-11-23 09:57:03
|
Hi Guys, Just started working with JMRI again to implement the LocoNetOverTCP protocol and noted the following issues when I do a rebuild. Looks like someone is sitting on some uncommitted changes or my local copies are somehow broken. Any suggestions Cheers Alex "SystemInfoFrame.java": cannot resolve symbol: variable LI_VERSION_RESPONCE in class jmri.jmrix.lenz.XNetConstants at line 118, column 43 "SystemInfoFrame.java": cannot resolve symbol: variable CS_SERVICE_MODE_RESPONCE in class jmri.jmrix.lenz.XNetConstants at line 124, column 47 "LZV100Frame.java": cannot resolve symbol: variable LI_MESSAGE_RESPONCE_HEADER in class jmri.jmrix.lenz.XNetConstants at line 182, column 39 "LZV100Frame.java": cannot resolve symbol: variable LI_MESSAGE_RESPONCE_SEND_SUCCESS in class jmri.jmrix.lenz.XNetConstants at line 183, column 39 |
|
From: <pau...@ac...> - 2003-11-23 13:51:48
|
On 23 Nov, Alex Shepherd wrote: > Just started working with JMRI again to implement the LocoNetOverTCP > protocol and noted the following issues when I do a rebuild. Looks like > someone is sitting on some uncommitted changes or my local copies are > somehow broken. > > Any suggestions ooops... I made some spelling corrections, and missed making them in the SystemInfoFrame.java and LZV100Frame.java files. I got the same unresolved symbol messages you were getting once I did an `ant clean` followed by an `ant build`. Corrections are now in CVS. Paul -- ______________________________________________________________________________ "Quality is a Characteristic of thought and statement that is recognized by a nonthinking process. Because definitions are a product of rigid formal thinking, quality cannot be defined." Robert M. Pirsig Zen and The Art of Motorcycle Maintenance |
|
From: Alex S. <al...@aj...> - 2003-11-23 19:58:02
|
> ooops... > > I made some spelling corrections, and missed making them in > the SystemInfoFrame.java and LZV100Frame.java files. > > I got the same unresolved symbol messages you were getting > once I did an `ant clean` followed by an `ant build`. > > Corrections are now in CVS. All is well again. I have seen situations where CVS does screw up and two people can update from the same archive and yet get different code. The checkout clean copy function usually sorts this but it is strange... Alex |
|
From: Alex S. <al...@aj...> - 2003-11-23 22:26:58
|
Hi Guys, I've just finished the first cut of the LocoNetOverTCP protocol support and committed the code changes. Bob, I had to play around with access to various members of LnPacketizer to get access from the new classes so you might want to have a look and adjust things to how you prefer them. Also code formatting might need a clean-up with your tools. Anyway we need to get a few people to pound on it for a while to see if it is stable. Cheers Alex |
|
From: <pau...@ac...> - 2003-11-24 21:46:44
|
HI Alex, On 24 Nov, Alex Shepherd wrote: > I've just finished the first cut of the LocoNetOverTCP protocol support > and committed the code changes. Before you get too far into this, shouldn't we be making this a much more generic package than the existing RMI implementation? If you step back and take a look for a minute at what we want to accomplish, we really want to make a generic server interface that knows how to send commands to any of the abstract functions that JMRI has. The client would just send data to the server, and the server would send the data to the layout. There is no reason why the client should have to know what type of interface the layout is using. Implementing things this way will allow the TCP functionality to work properly for ALL implementations, and not just with Loconet, which is the main problems with the RMI implementation. Paul -- ______________________________________________________________________________ "Quality is a Characteristic of thought and statement that is recognized by a nonthinking process. Because definitions are a product of rigid formal thinking, quality cannot be defined." Robert M. Pirsig Zen and The Art of Motorcycle Maintenance |
|
From: Alex S. <al...@aj...> - 2003-11-24 22:01:06
|
Yes you are right, but I think these are two different problems: 1) I want to be able to share a single LocoBuffer connected to my laptop with JMRI and other C/C++ applications and using the LbServer is a convenient way to do this. 2) Being able to have a JMRI client/server protocol that supports all protocols generically via RMI not just LocoNet. Which is what I believe you are talking about. I agree option 2) would be a good thing and Bob and I spoke of it about a year ago when I did the initial RMI stuff. However there are issues unless we add another generic layer above the current API's and perform all these networkable operations generically and push the system specific idiosyncracies down into system specific drivers - which is doable. What I primarily want to be able to do is develop my EmbeddedLocoNet library code using Borland C++Builder in Windows first and then port to the AVR microcontroller. I do this now with a C++ windows wrapper application that provides the same LocoNet Send/Receive calls as my AVR project that actually communicate via TCP/IP to a LbServer so I can develop and debug the logic much more easily than trying to guess what is going on in the microcontroller! Cheers Alex > -----Original Message----- > From: jmr...@li... > [mailto:jmr...@li...] On > Behalf Of pau...@ac... > Sent: 25 November 2003 10:46 a.m. > To: jmr...@li... > Subject: Re: [Jmri-developers] First cut of the > LocoNetOverTCP protocol has been committed > > > HI Alex, > > On 24 Nov, Alex Shepherd wrote: > > I've just finished the first cut of the LocoNetOverTCP protocol > > support and committed the code changes. > > Before you get too far into this, shouldn't we be making this > a much more generic package than the existing RMI implementation? > > If you step back and take a look for a minute at what we want > to accomplish, we really want to make a generic server interface that > knows how to send commands to any of the abstract functions that > JMRI has. > > The client would just send data to the server, and the server > would send the data to the layout. There is no reason why > the client should have to know what type of interface the > layout is using. > > Implementing things this way will allow the TCP functionality > to work properly for ALL implementations, and not just with > Loconet, which is > the main problems with the RMI implementation. > > Paul > -- > ______________________________________________________________ > ________________ > > "Quality is a Characteristic of thought and statement that > is recognized by a nonthinking process. Because > definitions are a product of rigid formal thinking, > quality cannot be defined." > Robert M. Pirsig > Zen and The Art of Motorcycle Maintenance > > > > |
|
From: Alex S. <al...@aj...> - 2003-12-02 05:39:51
|
Hi Bob, I've looked over the FreeHEP plug-in API and it looks reasonable straight forward, but no doubt there will be some tricks in there somewhere. Could you commit (or email me the files) the work you have done so far so I can see what you have done and try and merge in some of the ideas from the FreeHEP package. Cheers Alex |
|
From: Bob J. <Bob...@lb...> - 2003-12-02 07:32:58
|
At 12:57 PM +1300 12/2/03, Alex Shepherd wrote:
>Hi Bob,
>
>I've looked over the FreeHEP plug-in API and it looks reasonable
>straight forward, but no doubt there will be some tricks in there
>somewhere.
>
>Could you commit (or email me the files) the work you have done so far
>so I can see what you have done and try and merge in some of the ideas
>from the FreeHEP package.
I've committed them. It's just one new file (jmri/JmriPlug.java),
plus a line to invoke it in apps/Apps.java
For people wondering what this is about: Alex suggested that a
plugin mechanism be added to JMRI apps. I wrote up a simple one
(appended), and Alex is working on a more flexible approach to
locating the JAR files.
Bob
The original goal of the JMRI project was to produce a library upon
which people
could use to build their own applications. Although some people do that, more
use the existing applications such as DecoderPro, PanelPro, LocoTools and
JmriDemo. We want to make this more flexible by providing a way to extend
those programs without having to rebuild them from scratch. This note proposes
mechanisms for that which could be included in JMRI version 1.4.0
1) CLASSPATH
DecoderPro et al are run via a java command which sets the CLASSPATH and
various options. How that's actually done varies with the platform: csh
scripts on Unix, bat files on Windows, application bundles on MacOS X, etc.
To make it easy to add plug-ins, these will include the files "jmriplugins.jar"
and "lib/jmriplugins.jar" in their CLASSPATH.
If you use that name for the jar file including your code, it will
automatically
be found. You can also put your classes in the "classes" directory of the
startup directory, which is searched first.
If some other jar file is necessary, you'll have to edit the startup as needed.
2) Replacement of existing classes
Note that you can directly replace any of the files in the jmri.jar
distribution
with your own versions by putting them in a jar file that's searched first.
For example, including a modified version of a .properties file in the
jmriplugins.jar file would allow you to include customized versions of menu
strings. This can also be done with a .class file, for example changing
the order of menu items by replacing the DecoderPro class.
3) Plugin classes
Replacing a class can cause extra work in the long term, as the replaced
class may be modified as JMRI evolves. So we also provide a hook on which
to hang new code. After initialization is complete, the programs will
attempt to invoke a static member of the form:
class JmriPlugin {
static void start(JFrame mainFrame, JMenuBar menuBar) {}
}
Note that the JmriPlugin class is not in any Java package! This method
can modify the menubar by inserting, modifying or removing menus or menu
items, add buttons to the main panel, etc.
As people use this capability, we'll probably want to refactor some existing
classes to make them easier to extend. For example, a monolithic formatting
class like llnmon should be broken up into smaller pieces to make it easier
to add new formats.
--
--------------
Bob Jacobsen (Bob...@lb..., 510-486-7355, fax 510-495-2957)
|
Thanks for helping keep SourceForge clean.
X