This is a place for temp files, other than administrative files. Either they are to be added to the next release, added to the Documents or will have a short life span. Groups.io has free subscription storage limit of 1 GB! The following are counted towards the storage limits for the group: - Files - Photos - Images in databases - Images in wiki pages - Message attachments 1. Please put files into the correct folders. - If there is not an appropriate folder, feel free to create one. 2. If you are working on a problem and want to load info for others to look at, create a folder within the 'Problems Being Worked On' folder using the Msg number or you name as the folder name. When the problem is resolved please delete the folder. 3. All files and photos are subject to removal at the moderators discretion. Your Moderators -- Peter Ulvestad JMRI Users Group Moderator - http://www.jmri.org ( http://www.jmri.org ) Tam Valley Group Moderator - https://tamvalleydepot.com/ ( http://tamvalleydepot.com/ ) Sprog-DCC Group Moderator - http://www.sprog-dcc.co.uk/ ( http://www.sprog-dcc.co.uk/ ) Edmonton Model Railroad Association - http://www.emra.club/

ADMIN: Copied from a post by Bob Jacobson This looks like a good moment to describe the thinking behind JMRI’s releases more generally. Twice a year, we create something called a “production” release. These have names like 4.16, 4.18, etc. These are the ones that we encourage people to use, particularly new users, because they’re a good balance of new features and annoying bugs (new and unfixed) Any development process can create bugs; sometime even properly-working new features are considered bugs by some users! So how do we get from “new code” to “production release”? *) About once a month we create a “test” release. These have names like 4.17.1, 4.17.2, etc leading up to 4.18; after that, a new series starts with 4.19.1, 4.19.2, leading to the next production release. These have new features, like “rotation of Layout Editor”. We encourage as many people as possible to download these and _test_ them, so that new problems can be found ASAP. The test release process doesn’t work unless people do that. Generally, all the small numbered test releases are made with all the contributed changes up to that point; they’re meant to be inclusive. Toward the end of the sequence, though, the risk-reward ratio changes: We don’t want to introduce a new bug in the last test release before a production release. Partly that’s because the test process isn’t perfect; partly that’s because such big changes can often wait a little bit anyway. People working on new features and fixes really do try to not break things. We’ve got lots of automated and manual testing in place. But JMRI is large, complicated, and has lots of interacting features: We need users to check things to make sure that JMRI still works for _them_. So it’s very helpful for people to install and check a test release or two between production releases. At a minimum, we request that people download and use a new production release once a year or so: The further behind a layout is, the bigger the step forward when it has to be updated, and the more likely that unexpected issues will arise. If that happens at the same time as a new computer, or a change to the layout, or multiple issues are present, then it can be really complicated and time-consuming to resolve. *) Between test releases, during that month of accumulation, there are “development” release available. These are called names like 4.17.1-ish, 4.17.2-ish, and they’re built several times a day if changes have been made. They are truly the latest and greatest. A few hours after a change is made, it can be gotten from one of those (the change mentioned here has already been built into these: http://builds.jmri.org/jenkins/job/TestReleases/job/development/) People can download and install these to check new features of interest to them. If problems are found and reported, the whole process moves along even better. Bob -- Peter Ulvestad JMRI Users Group Moderator - http://www.jmri.org ( http://www.jmri.org ) Tam Valley Group Moderator - https://tamvalleydepot.com/ ( http://tamvalleydepot.com/ ) Sprog-DCC Group Moderator - http://www.sprog-dcc.co.uk/ ( http://www.sprog-dcc.co.uk/ ) Edmonton Model Railroad Association - http://www.emra.club/

====================== HOW to ask your question ====================== One of the most common questions about JMRI is "How do I get it to work?". This isn't really a problem with JMRI itself in most cases, but there are HUGE numbers of possible configurations for DCC systems, and Windows, Linux, and Mac computers out there. Just asking "How do I get it to work" is NOT going to get you any useful help. When asking ANY question, you should >>>utilize a meaningful subject line<<< that indicates the problem and include the following information in the body of the message: + If JMRI has started copy and paste the System Console into the body. (its under help on the start screen) + Has JMRI worked before on this computer? + JMRI version + Previous version if you just upgraded + Java version + Previous version if you just upgraded + Computer make and model + if you have just upgraded, from which version + Any other DCC devices in use + Specific details of your difficulty including error messages if any, or what you would like to do with JMRI. Decoder Programming, Signals, Automation, etc. Depending on the nature of the problem, you may need to supply even more information, but this is the absolute required for anyone to give you accurate answers. Signing you post helps keep the group friendly and personable! Your moderators and trouble shooters.

Please use "meaningful subject lines" when starting topics. We are getting lots of subject lines that don't give much if any idea of what the topic is about. By providing a meaningful subject line you may get the attention of someone that can provide you assistance with your issue. It also give others the chance to skip the topic if it is not of interest to them. -- Peter Ulvestad JMRI Users Group Moderator - https://www.jmri.org ( http://www.jmri.org ) Tam Valley Group Moderator - https://tamvalleydepot.com/ ( http://tamvalleydepot.com/ ) Sprog-DCC Group Moderator - http://www.sprog-dcc.co.uk/ ( http://www.sprog-dcc.co.uk/ ) Edmonton Model Railroad Association - http://www.emra.club/

We would like to point out that this list is for discussions related to JMRI, and is intended to be a place that people, particularly beginners, can turn to for help with their JMRI problems from more experienced JMRI users. General DCC and model railroading topics should be taken to a more appropriate forum and NOT be posted here. SPAM of any kind, politics, legal issues, and other off-topic matters should NOT be posted to the list and will be subject to deletion by the moderators, as will any responses to such off-topic matters. New members still on moderated status will find that off-topic posts will not be approved for posting, and old members making such posts may find themselves back on moderated status. BUY / SELL and ADVERTISING is NOT PERMITTED Let's keep things simple for all of us, and keep the discussion here on-topic. Your moderators

In a recent correspondence, I was asked about Bounced(ing) emails. If you are not receiving emails from groups.io you may be bouncing or you may have received an email from gio to reconfirm. Not that group owners and moderators can do nothing to help. Below is copied from the groups.io help pages: https://groups.io/helpcenter/membersmanual/1/understanding-groups-io-accounts/handling-a-bouncing-account Handling a bouncing account When you are receiving group messages by email but group messages cannot be delivered to you for some reason, the nondelivery events are called bounces. Such events put your Groups.io account into a bouncing state that affects all the groups you belong to with that account’s email address. Groups.io tries to notify a bouncing member by sending an email message that has the subject line “Your Groups.io Account is Bouncing.” Also, when a bouncing member logs in to the Groups.io website, a red banner at the top of the page informs them that their account is bouncing. Note: Even if your Groups.io account is bouncing, you can still log in to group websites and read and post messages there. Bouncing affects only email delivery; it does not affect your ability to use group websites. If you have not received an email notification that your account is bouncing but you realize that you have not received any group email messages for a while, you can check your account to see whether group messages are bouncing. For instructions, go to "Setting account preferences and viewing account information" and scroll down to Checking recent email bounces. When your Groups.io account is bouncing, you can try to “unbounce” your account using either of these methods: If you received a “Your Groups.io Account is Bouncing” email notification, click the link in the email to unbounce your account. Go to the Groups.io website (and log in if necessary). In the red banner at the top of the page, click the link to unbounce your account. ! Important: Group owners and moderators cannot do anything to unbounce accounts of their group members. When your account is bouncing, you must address the underlying problem yourself, which might involve contacting your email service provider for assistance or investigation. -- Peter Ulvestad JMRI Users Group Moderator ( https://www.jmri.org ) Tam Valley Group Moderator ( https://tamvalleydepot.com/ ) Sprog-DCC Group Moderator ( http://www.sprog-dcc.co.uk/ ) Edmonton Model Railroad Association ( http://www.emra.club/ )

[The announcement below is also available for re-distribution as a PDF in the Files section: https://groups.io/g/jmriusers/files/JMRI%2025th%20Anniversary%20Announcement%20Oct%202024%20%28FOR%20PUBLICATION%29.pdf. Thanks every for your participation in the JMRI Community! From JerryG and BobJ on behalf of all of us] Announcement from the JMRI community: October 3, 2024 The Java Model Railroad Interface (JMRI®) community announces two major milestones: the 25th anniversary of the first use of JMRI and the 10,000th update to the Java Model Railroad Interface software used by almost 50,000 model railroad hobbyists for managing and operating today’s digitally controlled model railroads. With over 300 developers worldwide having contributed, the “community sourced” JMRI project began in 1999 to provide a way for model railroaders to manage the complexity of train engines fitted with digital decoders. Today, model railroaders worldwide use the greatly expanded JMRI system for everything having to do with the development and enjoyment of modern model trains and layouts. Bob Jacobsen, a member of the original team and still a senior developer, said “JMRI has helped bring the sophistication of modern electronics and computers to thousands of model railroads - all based on open source software.” Not only model railroad hobbyists, but millions of people of all ages have seen JMRI in operation at holiday train displays, hobby shows, and train exhibits at multiple museums around the world. “JMRI was one of the key steppingstones in the wide adoption of Digital Command Control across the model railroading community by making the process of implementation easier, visual, and common across all manufacturers,” noted Peter Ely, a founding member of the NMRA DCC Working Group. “JMRI itself grew in complementary directions to allow the typical model railroader to do things at the system-wide railway level only dreamed about by the original working group.” Jacobsen said that JMRI development continues to keep pace with changes in technology and that another 10,000 updates are likely over the next decade. It is through the continued interest and contribution of time and effort of the community members that JMRI feature are expanded and technology updated. Interest in JMRI extends over dozens of user forums and social media platforms, with over 8,000 users participating in the primary user forum on groups.io, asking questions and contributing answers and suggestions that are used to expand and improve JMRI capabilities. Congratulations and thanks to all who have participated in using and improving JMRI, now and into the future. About JMRI The Java Model Railroad Interface project was initially a modest undertaking of some dozen model railroad hobbyists who wanted to bring their computer skills to the emerging field of digitally controlled model trains. Forming an open source software development project, their first output was called DecoderPro® and provided easy-to-use screens for managing “configuration variables” in the small computers that manufacturers and hobbyists were installing in train engines. The effort expanded to create PanelProTM with features for controlling all types of electronic devices and automating train operations by monitoring sensors around the layout. Unfortunately, the community was soon embroiled in a copyright and patent dispute that resulted (after seven years of litigation) in the landmark Jacobsen v. Katzer case that helped establish the legal basis for today’s open software movement. The Electronic Frontier Foundation cites this case as one that has allowed the internet to flourish and find its way into millions of computers in homes, offices, and businesses. JMRI today provides functions including management of Digital Command Control decoders in train engines, cars, and other devices, graphic display of small and large train layouts, on-line real-time operational monitoring of sensors and other devices, automation of train operations, and management of realistic train operation scenarios. JMRI also provided t

Welcome to the JMRI user's discussion group. This the place to ask questions, make suggestions, complain and complement. There's more information available on the main JMRI web page: http://jmri.sf.net and the main page for DecoderPro: http://jmri.sf.net/DecoderPro Decoder Pro is a program to make it easier to program DCC decoders. -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

The 0.9.2 update to the DecoderPro program and JMRI libraries is available for download. The update file is in .zip format, and should be usable on Macintosh, Windows, Linux and OS/2. You can download it from SourceForge by following this link: <http://sourceforge.net/project/showfiles.php?group_id=26788&release_id=84662> This update contains only updated files; you need the entire 0.9 distribution to use the program. If you don't have that, please see the JMRI and DecoderPro README files for how to download and install it: http://jmri.sourceforge.net/demoFiles/DecoderPro.README.html http://jmri.sourceforge.net/demoFiles/JMRIdemo.README.html To install this update, copy the "jmri.jar" file and the "xml" directory to your existing DecoderPro or JmriDemo directory. That's all that's needed! New features in this update: Updated Soundtraxx DSD/DSX Diesel definitions to fix a programming error Cleaned up LocoIO programmer interface New features in the 0.9.1 update, also included here: Additional decoder definitions: Many Lenz decoders, courtesy Debbie Ames and Lenz USA Updates to Soundtraxx decoders, additional types New EasyDCC support in DecoderPro and the JMRI tools LocoIO programmer for both early (1.3.2) and later (1.3.4) LocoIO PIC code. Initial support in JMRI libraries for: Remote LocoNet server and client CTC panel edit, store, load C/MRI serial attachment Note that these are still in development, and should not be considered ready for general use. Various minor bug fixes and updates, including reduced memory usage and improved error logging. -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Hi Bob: I have the program in my PC but it is far from the train room so I don't get to use it except when one of my operators brings over a laptop. My question is sort of basic(dumb)but I would like some information on what to look for in a laptop if I were to go out and buy one. Most models I have seen on the internet start at about $1500 and go up from there. I can probably equip my entire fleet of engines with Soundtraxx decoders for that kind of money so I need info on the very most basic laptop that I can expect to use successfully with Decoder Pro and not have it cost an "arm & a leg"...am I just dreaming or is this a possibility? I am probably talking about a used instrument and also wonder if this is a reasonable possibility? Thanks in advance for any pointers you can give me. Jim Hanna El Cajon, CA

The 0.9.3 update to the DecoderPro program and JMRI libraries is available. The update file can be downloaded from: http://prdownloads.sourceforge.net/jmri/JMRI.0.9.3.update.zip It is in .zip format, and should be usable on Macintosh, Windows, Linux and OS/2. The update contains only updated files; you need the entire 0.9 distribution to use the program. If you don't have that, please see the JMRI and DecoderPro README files for how to download and install it: DecoderPro: http://jmri.sourceforge.net/demoFiles/DecoderPro.README.html JMRI demo: http://jmri.sourceforge.net/demoFiles/JMRIdemo.README.html To install this update, copy the "jmri.jar" file and the "xml" directory to your existing DecoderPro or JmriDemo directory. If you haven't written your own decoder files, that's all that's needed! If you have your own decoder files, you need to remake the index by starting the program and selecting "Create index file" from the tools menu. New features in this update: * EasyDCC support has been tested, and should now be working well. * Additional Soundtraxx, Lenz and NCE decoders. * You can now select register, paged or direct mode for programming if your command station supports them. This lets you program MRC and other register-mode-only decoders. * Improved automatic identification of decoders, especially cases where the version number isn't unique or isn't recognized. * Programmer window will no longer appear behind the Start Bar on Windows. * Can now build the libraries and application with the Ant command line tool. * Now properly handles older locomotive files with newer decoder files, which lets us update definitions in place. New features in the 0.9.2 update, also included here:</h3> * Updated Soundtraxx DSD/DSX Diesel definitions to fix a programming error * Cleaned up LocoIO programmer interface New features in the 0.9.1 update, also included here:</H3> * Additional decoder definitions: Many Lenz decoders, courtesy Debbie Ames and Lenz USA Updates to Soundtraxx decoders, additional types * New EasyDCC support in DecoderPro and the JMRI tools * LocoIO programmer for both early (1.3.2) and later (1.3.4) LocoIO PIC code. * Initial support in JMRI libraries for: Remote LocoNet server and client CTC panel edit, store, load C/MRI serial attachment Note that these are still in development, and should not be considered ready for general use. * Various minor bug fixes and updates, including reduced memory usage and improved error logging. -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

The 0.9.3 update is out, so after I catch my breath, it's time to think about what to do next. I'd like to get a "complete" DecoderPro version out by early July, but I'm not certain what should be considered the most important things to put in it. I've got a long list of little updates, fixes and cleanups to include, and I'll probably get to most of them. Big features are a little more problematic, as I don't often have the large chunks of time they require. I've already promised to add Lenz XpressNet support to JMRI and DecoderPro, and C/MRI support to JMRI itself. So those will be happening. I've got some other stuff I'm playing with on the layout-control side of the house, and I'll probably keep doing that too. But beyond those, I'd like to see what people think are most important. What would you most like to see? Some of the items that have been suggested include: a) Ops mode programming b) Better programming GUI, for example making it possible to have some variables control whether others display, etc. Break some parts (roster pane, function mapping) into smaller parts so you could create a programmer that walks you through one item at a time (e.g. a "step 1" pane that handles the address, then a "step 2" pane that saves the file, then a "step 3" pane that sets momentum, etc) c) Much smarter speed-table support, with various tools for smoothing curves, resetting the curve to a standard one, adjusting it to the contents of Vstart/VMid/VEnd, etc d) Improvements to the roster - being able to copy & delete locomotives, better editing, import/export to various common formats, etc. e) Fix the long-standing problem with many PCs not being able to connect at the MS100 baud rate. (This is a LocoNet-only problem, and I'll need help from somebody who speaks windows) f) Integrated installers, esp. for Windows. The current multi-step install process is getting in the way. It would be pretty simple to create a two-step install process of the form "Run this Java installer, then run this DecoderPro installer", perhaps with an updater that makes future updates quicker downloads. g) Lots more decoders h) Add a progress bar when programming. This is not trivial, unfortunately, because the program doesn't really have any idea how long the programming will take, or even how many CVs are left to do. It would take a little effort to get that right-enough to be useful (nobody likes a progress bar that gets shorter, then longer, then shorter) i) Get the "confirm" button working. This is really only faster on LocoNet command stations right now, as all others need to do a complete read to implement it. But it's still a useful thing to have when working with problematic decoders, e.g. you wonder whether the decoder's been changed, etc. j) Make the programmer GUI more bullet-proof. Now, if you type letters in a decimal field, enter a too-large or negative number, etc, Bad Stuff happens. It would be good if that were more robust. What do people think? Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Bob, Looks like when you create a roster entry and save it the filename is not display on the Roster Entry screen. Might lead a new user to conclude that the file had not been created/saved. In fact I don't think there is ever feedback that the file save has succeeded? Maybe a message on the status bar would be worth considering. BTW I think I saw a comment from someone suggesting you could clone a loco by just changing the ID and doing a save. Didn't work when I tried it. Robin

>Hi Bob, thanks for answer. > >>That's what I originally set out to do last summer, before getting >distracted by a bunch of other uses. The program now has some >limited capabilities to do that; it can throw and track turnouts, >animate a little track plan as things change, etc. But it will >probably never be in the same "point&click" league as the commercial >products such as WinLok and RR&Co; it's more aimed at being a library >you can use to write your own programs more easily.< > >OK, and what about monitoring of track/block occupation (from >detectors)? That's part of it. It turns out that's a little more complicated than throwing turnouts, as there are _lots_ of different ways that information comes into the system. So the basic code has to be pretty flexible. > >>What practically mean your plan "Lenz XpressNet support to JMRI"?<< >>First, make it possible for DecoderPro to program decoders with an >XpressNet command station (Lenz or Atlas Commander) via a LI100 >interface. Then add turnout control, throttles, etc.< > >I am not sure, but XpressNet and Li(F)100 with PC communication is >separate and different things (programs, protocols...)? The XpressNet itself is not something that can be easily done with a PC serial port. It requires some timing & bit-banging that's beyond my capabilities. So the first thing I'm working on for Lenz command stations is communication through a LI100. The messages are pretty-much the same as XpressNet itself, but the serial port control is much simpler. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

At 10:31 AM -0700 5/14/02, Mike Davison wrote: > > >Lots more decoders< >> Of course the really best would be convince manufactures that DecoderPro >> is the (only) way to go and they would create the files. > >Perhaps if 'we' created a standard XML format (schema?) to describe decoders >and created a central Internet-accessible DB of those XML definitions we >could get more buy in. A common format would allow the central DB to be used >by all decoder programming tools and would allow decoder manufacturers to >produce a single description file. I'd like to see manufacturers providing comprehensive info on their decoders. Even if we still have to make up the files, having good info would really help. For example, Debbie Ames of Lenz has been very helpful in getting me info on the current Lenz decoders, and Jim Scorse of NCE has promptly answered every time I needed clarification. With that kind of help, making the files is a reasonable task. I've backed off a little in my hopes that people would make decoder files for all the decoder they're interested in. There are a few people who've done that, including some on this list, but it's harder than I originally imagined it would be. It's taken some really dedicated people to succeed with new files. In part this is because there are just _so_ _many_ options in modern decoders; some of them have over 100 settings to encode! In part it's because the XML format is so verbose & redundant; it's hard to work on the files with just an editor. In the long term, we need a tool to make creating those files easier. I'm not sure how to do it, but something where you can just sit down and fill out some forms. The problem is providing enough flexibility to map all the possibilities we see in the marketplace. This might be a good project for somebody who'd like to play with some Java code... In the shorter term, I'd like to find some time to lobby manufacturers for more information. I'm hoping to track down some of the people involved at the NMRA convention & train show this summer; maybe talking in person will help. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Thanks for all the good ideas. I suspect that getting the roster-management features working is going to take a couple of go-rounds, so I should probably get started on that first. So the next question is: what needs to be there, and how should it look? My original idea was that the "update roster" button would remake the index, so any files you've inserted or deleted in the prefs/roster directory would be known. That seems way too simple now. It sounds like people want that, plus: a) A way to delete an entry b) A way to duplicate an entry (so they can make a new loco that's "the same except ...") c) Import and export of roster files, so you can carry them around with the locomotive itself. d) Starting values for specific decoders, so when a new file is created its default contents are what you'd like as a starting point for that model of decoder. e) A way to copy an entry ("Make this one like the other one that I just updated ..."). I'm not sure how to actually use that, so I'd appreciate it if somebody could walk me through what you have in mind. The tricky bit seems to be updating just part of the contents; which part? f) Clearer documentation, esp. the connections between files, filenames and the roster contents. That seems like enough to start. I'll probably create a "Roster" window that has buttons to do all these things, along with a (scrolling) list of defined locomotives. Or maybe a small table where you can edit things directly? Suggestions are always welcome! Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

I didn't mention that I have an Empire Builder II. After reading Robin Beckers reply to the last message, I wonder if I'm screwed at this point? This simple project is getting out of hand. (G) I originally started to build the LocoBuffer and get the other pieces together, because I understood the DecoderPro would give me the R/W capability. There's no fool like an old fool still applies, I guess. If I understand correctly, this means that I have to shelve the LocoBuffer, KeySpan etc. or buy a Chief Controller. Is that correct? Thanks for the help. At least, if I have to shelve this stuff, maybe the iMac will start accessing the Internet again. (VBG) Mike

Group, Another plus for our beloved DecoderPro. I bought a group of CVP AD4 accessory decoders for switch motors. Not wanting to do these by throttle I first used PR1DOS connected through the MS100. I already knew the PR1 'standalone' wouldn't work from another report. I could not get the PR1DOS through the MS100 to work at all. Many tries. I connected up DecoderPro through LocoBuffer and used the single CV programming tool. Worked each and everytime. While I did have to put in numbers for the CV's it's quite easy as they are explained in the AD4 instructions. So another que for DecoderPro. I think a pane for the AD4 would probably be easy but that's another one for the tomorrow file! Jon Miller AT&SF For me time has stopped in 1941 Digitrax DCC owner, Chief system NMRA Life member #2623 Member SFRH&MS

I've added a "Roster" menu to DecoderPro that let's you copy, delete, export and import locomotive configurations. The first draft of a web page describing this is at http://jmri.sourceforge.net/PaneProg/Roster.html If you'd like to try this out, I posted a test file at: http://prdownloads.sourceforge.net/jmri/jmri.jar Just replace your previous jmri.jar file with this one. I haven't had time to give this file the usual set of tests, so you might want to keep your old jmri.jar file around until you're sure it's working OK. Sorry this took so long; I had to clean the cobwebs off a few parts of the code that really needed cleaning. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Hello: I have just completed the assembly of John Jabours LocoBuffer Kit and it tested out okay. I built a 9 pin to 25 pin cable. Intalled a Keyspan PDA Adaptor between a USB port and the LocoBuffer. Hooked up a 12 volt, 200 mA WallWart. Turned on the iMac and clicked on DecoderPro. Set preferences: LocoBuffer; 19700 baud; Basic. So far, so good! Entered the programmer mode, entered some data regarding the SoundTraxx equiped engine that I have just completed. It (DecoderPro) seems to work okay, until I attempt to "write". Then I get a message: "Programming error: timeout talking to command station" which then alternates with the message: "Writing CV29" That's all folks. I haven't a clue what to do next. Any suggestions? One other thing that is driving me nuts: since I hooked this up, the iMac's internal modem won't dial up the Internet without my going into the control panels and changing it back to "Internal Modem, 56K". It will be changed to "Infrared Modem", which I don't now and never have had. It must be related, it's never happened before, and if I reset the Control Panel, I can dial up the Internet just fine. I do disconnect the LocoBuffer from the USB Port, however. Thanks for the help. Maybe I should be asking John, but I have bugged the poor guy to death while building the LocoBuffer, so hate to bother him further. (VBG) Mike Van Hove