Hello Paul,

JMRI Operations adds 4 feet to the length of each car to account for the couplers.? Make sure the spur length is long enough to hold both cars.? Hope this helps.

Cheers, Dennis Drury
Dayton, NV

What you want to do requires the location/spur to allow 4 moves.
The act of dropping a car is a move the act of picking up a car is one move so it takes 2 moves to drop and pick up a car
2 cars = 4 moves

Frank

I use three printers during a session. All my paperwork is Excel generated so I use the "fast draft" setting as to print quality. However, if I forget and do not change that to normal when printing out my car locations after a session, the printed area will exceed the width of the paper.

Just a thought

Dave
Trempealeau WI

Hello,

This email message is a notification to let you know that a file has been uploaded to the Files area of the [email protected] group.

File: Test Bed Dale Trial.xml

Uploaded By: peter.s.drury

Description:
The Dale Panel for query

You can access this file at the URL:
/g/jmriusers/files/Test%20Bed%20Dale%20Trial.xml

Cheers,
The Groups.io Team

Hi Dave. Many thanks for your help re editing connections. Got the hang of it now and started to create a panel including part of the layout. I have used MERG parts only and entered these as hardware addresses within the tables as a first step. I then used these addresses when creating the panel.
JMRI and the panel are working together but, try as I may, I find that the positioning of the toggle switches I am using do not align with that displayed in the editor. I have tried to correct this by resetting the Servo drives by reversing the ON and OFF events in my servo driver module but this seem to have no impact on the result in the editor. I must be missing something and wonder if you can help.
I shall upload my panel to the group slot when I can find out how to do this.
Best wishes
Peter

开云体育

Hi. Yes the PDF printed fine so I guess it is a printer issue. I just wonder why the results would be different? Interesting. I cannot find any setting on the printer to ?do something that can correct it.?

THANK YOU Dan?

Mark asked:
"Has anyone used the Configure Command Station tool on a DCS240 and discovered it did not work ?"

While I have used the tool with a DCS240 on a number of occasions, it has worked without any obvious failures. The DCS100 is my command station of choice, so my DCS240 usage of the tool is rather limited.

Be aware that the Configure Command Station tool cannot access OpSw settings beyond OpSw 47, which are conveyed via a different LocoNet message, and the DCS240 has a few settings at OpSw numbers higher than 47. For the DCS240 (and DCS210 and DCS52, I will generally use the Roster-based mechanisms instead of Configure Command Station because the Roster-based mechanism is able to access all of the OpSw settings for these command stations.

Regards,
Billybob

Cliff wrote:

"What can be clearly observed is that the status reports for some OpSw values cannot be depended upon to be correctly reported. From here, my only record of the questionable status is that OpSw14 consistently is reported as THROWN, but my untrustworthy recollection claims that there are others."

I have not seen any inconsistencies when using the "Configure Command Station" tool. This behavior report is entirely surprising to me.

A quick perusal of the "Configure Command station" tool code does not reveal any special-casing of OpSw14 or any other OpSw.

I wonder if perhaps you happen to have huge quantities of LocoNet traffic when the tool is started. The tool tries to read the command station OpSw values when it is started. If it does not see a reply from the command station, _all_ of the tool's "radio buttons" are left at their default states (i.e. un-clicked). If you then simply click OpSw36 to the "closed" setting and perform a write, _all_ of the other OpSw settings will default to "Thrown", even though the window's radio buttons have not been "clicked" to either the "Thrown" or the "Closed" setting.

Perhaps as an exercise in "fault-tolerance", the tool could choose to treat the case where any OpSw's radio buttons are both "unchecked" to be a case where the tool refuses to perform a write. In such a case, the user could simply perform a "read", then re-modify the desired OpSw(s) then perform the "Write".

The one time when I have seen "misbehavior" of the Configure Command Station tool once. The group's layout was misbehaving in general, with poor or no loco control. Configure Command Station returned unexpected OpSw settings. After much debugging, it was determined that this was caused by having two active command stations on LocoNet, rather than one. A DB150 had decided to become a command station, after having worked just fine for days. The plug was incorrectly inserted into the DB150 on a slight vertical angle - presumably the GND or CFG connection did not conduct reliably even though the other connections were adequate. So the DB150 booted as "command station" and we had two command stations. Fully seating the plug solved the problem. Curiously, this occured about 90 minutes before the Digitrax public announcement for the DCS240, which included a feature which tries to find the case of multiple boosters on LocoNet and issue a beep-code to inform the users of the problem!

Regards,
Billybob

Thanks, Breezly

I will look into this today and let you know how I made out.
However, the program is moving both cars, from staging to staging or to a yard. It's just not giving me the two moves at that spur when the moves are possible.

I'm confused but hopefully the build report will shine some light on it.

Thanks
Paul

开云体育

Don

OK good to know. Today (Sunday) my layout was on a Layout Tour with 11 other layouts. 10.00 am to 4.00 pm - now it is over. I had a problem with my phone - unable to drive a train, it showed on the computer screen as being under the control if the phone, the command monitor showed that the commands were? being sent no response from the loco with a WOW v3 decoder. Tried to drive from the screen - nothing.

Under edit, in defaults, the throttles and power had reverted to Sprog. Changed them back to Easydcc and every thing worked.

Tomorrow I will set up the LE103 - (I threw 5 of these in the trash about 3 months ago) and the similar NCE 102 and the Wangrove 102 - all three are 1998 vintage - I will run your tests with the three of them.

Doing the tests before? I get back installs for others.

Gerry

Gerry,

The EasyDCC Command Station has V629 firmware.

According to EasyDCC Tech Support, that should work fine. The latest is V631. The only change, I was told, is that now the Command Station remembers what DCC addresses (Locos) its front panel throttles were controlling when power is removed. Thus, they don't need to be reentered when the Command Station is powered?up. No change to handling of commands from the serial port.

Don

-- 
Gerry Hopkins MMR #177 FNMRA
Great Northern Downunder




NMRA Australasian Region
Contest & AP Chairman
Web Administrator

Mark,

While I have your attention.. Read and ran your script. You need to explain why you go to the trouble of setup the Purge time to 600 secs,? have PURGE set loco speed to 0? but then turn OFF PURGING (OPSW 14).?? Makes no sense, your locos NEVER get PURGED.

The Purge time setting was an attempt to sidestep what we now believe to be a repair problem with the DCS200 on our workbench. We now know that some conversation with the Digitrax repair department is in order. Even with both OpSw13 and OpSw14 set, that command station give us 3 beeps after 90 seconds and leaves either the Digitrax throttle or the JMRI throttle unable to control the loco. Difficult for the member trying to understand speed matching, or a number of other normal decoder tweaking tasks. It has never occurred on the main layout.

When things go wrong with DCC, mostly, the member who discovers the problem just yells my name from across the room.

It was only Thursday that we had a meeting and agreed to treat this a repair issue. Someone else in the club has probably been on the phone negotiating a vacation in Florida.

As to Jacques original question, all I can offer is that the problem described is probably is not new to DCS240 Command Stations. Certainly our script is a clumsy workaround and nothing more. The only advantage for our club is that for both the main layout and the workbench, we start up with a clean slate each session. Prior to using the script, every heavy operating session would leave a lot of Slot memory clutter for the next session.

Hopefully someone in this group has better insight than I can. When that happens, we can convince our members to purchase some new Command Stations.

Cliff

okay so..

When I do the delete paths routine, save, reload, and generate signal pairs.. the S01 to S08 path works, SML shows the blocks used etc.

I save the file, close JMRI, re-load and then check, and that is the ONLY SML that loses its blocks, and creates the null error as described before. Panel S01 also shows red when should be green for S08, proving the point.
So delete paths works
Create new paths works when retarted because the SML works when first created..
and as soon as the XML is saved, it stops working after a restart.
--
Thanks
Mitch

That worked a treat! Thank you!

The issue with crashing trying to change the section stopping sensor is still persistant, though.
--
Thanks
Mitch

Paul,

Set the build report option to "Very Detailed" (Info available here: ). Then build the train.

Browse the build report and do a find on the car number you think should have moved but didn't. You may have to repeat the find several times, but the build report WILL tell you why Ops isn't moving the car.

HTH,
Steve
"Breezlys"

Mitch,

I was able to get the SML from S01 to S08 to work.

If you have been making a lot of block changes, the block routing can get confused. The unique double crossover at LT2-3-4-5 and its blocks appear to have contributed.

In the Block table menu, select Paths >> Delete Paths. Acknowledge the prompt. Save the panel xml file, stop and restart JMRI. This rebuilds the block paths.

You may want to delete and rediscover the SML if you have been trying different things.


Dave Sand

Haha no worries!

Let me kow what you find, im still siving through things.
--
Thanks
Mitch

Mitch,

Don’t worry about BR-2003-WE. The internal name for BR-2003 turns out to be BR-2003-WE.

Dave Sand

dave,

That should be uploaded now.

I'm struggling to find the BR2003-WE signal definition.
The folder of definitions just shows BR2003 but when i go to add a signal, im only shown BR2003-WE.

I have uploaded my BR2003 folder anyway
--
Thanks
Mitch

Mitch,

You can upload the session.log file. It is at the settings location/logs. See Help >> Locations.

Dave Sand