¿ªÔÆÌåÓý

  1. Jmriusers
  2. Messages
Expanded Topics Messages Polls
Date
Locked Re: layout editor continuing route signal help needed

 

Dave,

Appreciate the response. I can certainly flip the driven turnout position on the layout and flip the feedback. Not sure how to fix the Turnout Table though. To simplify my remaining question, I used Loconet Sim and just assigned a DIRECT Feedback loconet turnout to the panel. When I set the Continuing Route Turnout State to THROWN in Layout Editor, the Turnout Table shows THROWN when the layout editor panel shows CLOSED. Checking "Inverted" in the Turnout Table does not resolve this. What do I need to do so that the Layout Editor Panel and the Turnout Table agree?

Robin

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Dave Sand
Sent: Monday, September 23, 2019 10:35 AM
To: [email protected]
Subject: Re: [jmriusers] layout editor continuing route signal help needed

Robin,

The secret is to treat turnout closed/thrown as closed/thrown everywhere except in the continuing route setting and the wiring at the switch machine. If feedback is enabled it needs to wired accordingly. This works perfectly with Tortoise style machines and two sensor feedback. If the machine moves the wrong way, flip wires 1 and 8. If the feedback is wrong, reverse the feedback wires OR reverse the feedback sensors in the turnout table entry.

The feedback process might be different for EXACT.


Dave Sand


On Sep 23, 2019, at 10:59 AM, Robin Becker <rbgroups@...> wrote:

Hi. I have a panel with signals set up in Layout Editor and generally everything works fine. The only issue so far is with 2 turnouts where the main line takes the diverging (THROWN) route. On the main approaching each turnout is a double head searchlight signal mast. In order to get the top head on the mast to represent the main (diverging) route, I have set ¡°Continuing Route Turnout State¡± to THROWN. That works as desired on the panel diagram ¨C when the turnout is shown on the panel as aligned for the diverging route, the signal shows Green over Red (for example), and when the turnout on the panel is shown aligned for the normal route the signal shows Red over Green (for example).

The problem is with the relationship of the state of the turnout on the panel with the physical turnout state on the layout and as shown in the Turnout Table. It appears that setting ¡°Continuing Route Turnout State¡± to THROWN causes the displayed turnout state on the panel (and the turnout state used for calculating the signal aspects) to be _opposite_ the state of the physical turnout. So now when the turnout on the layout is set to CLOSED, the turnout on the panel is shown as THROWN and signals are set as if the turnout is THROWN.

If I now check the ¡°Inverted¡± checkbox for the turnout in the Turnout Table then the turnout state on the panel matches the turnout state on the layout. The Turnout Table now shows the opposite state from the physical turnout however. This means that anyone using the Turnout page in Engine Driver sees the wrong state. This is very confusing but perhaps could be managed.

There is a second reason I¡¯d like to avoid inverting the turnout if at all possible. These physical turnouts have EXACT feedback. When the turnout is actuated, the feedback state in JMRI changes to INCONSISTENT while the turnout is in motion. This INCONSISTENT feedback state is useful since it causes all signals around that turnout to go to RED until the turnout reaches its final position. Unfortunately the INCONSISTENT state disappears when the Invert option is selected: turnouts with Invert checked only show CLOSED and THROWN.

Am I missing something in setting up Layout Editor for this condition? Would appreciate guidance if you are familiar with this case. Thanks.

(FYI I was running 4.16 but updated to the latest test build and see no change in this behavior.)

Robin

Robin Becker
San Diego, CA
Locked Re: Layout editor - connecting slips to turnouts #layouteditor

 

Update
Photo uploaded into folder MERG - JMRI Test?
Locked Re: Layout editor - connecting slips to turnouts #layouteditor

 

Hello Fraser, thanks for your reply.
My bench test setup
I have a rather long break from this exercise in combining MERG with JMRI. I decided right from the start NOT to attempt to? incorporate JMRI on the layout proper until I understood what I am doing. I have extended my asic Bench Test facilty of CANGIZMO, CANPAN and Activity Monitor to include new build CANUSB4 and CANCMD.with a piece of Test Track for Programming and test running. These items can be seen on the small board at the top of the photo. I realised that individual modules might create quirks when interfacing with JMRI so I have built and installed the following modules on the larger board in the foreground. 2 * CANACE8C (for the toggle switches), 2 * CANACC8 (for 6 home made test signals) 1 * CANMIO-SVO (for 8 * servos representing turnouts on the main layout) and a CANDISP (for use for mixed Common Cathode signals).
Getting back to the issue at hand
I can confirm that the CANMIO is fitted with a resnet and not the ULN 2803. I was not aware of the option to fit the ULN 2803 and shall check if this is an easy remedy.
I do no longer install microswitches on the servo mounts, although some there are some on my test servos. I have gone for the servo crossing switch module as a more reliable interface than the microswitches.
The photo will be uploaded to the JMRI photo folder as soon as I can.
Best wishes
Peter
Locked Re: layout editor continuing route signal help needed

 

Robin,

The secret is to treat turnout closed/thrown as closed/thrown everywhere except in the continuing route setting and the wiring at the switch machine. If feedback is enabled it needs to wired accordingly. This works perfectly with Tortoise style machines and two sensor feedback. If the machine moves the wrong way, flip wires 1 and 8. If the feedback is wrong, reverse the feedback wires OR reverse the feedback sensors in the turnout table entry.

The feedback process might be different for EXACT.


Dave Sand

On Sep 23, 2019, at 10:59 AM, Robin Becker <rbgroups@...> wrote:

Hi. I have a panel with signals set up in Layout Editor and generally everything works fine. The only issue so far is with 2 turnouts where the main line takes the diverging (THROWN) route. On the main approaching each turnout is a double head searchlight signal mast. In order to get the top head on the mast to represent the main (diverging) route, I have set ¡°Continuing Route Turnout State¡± to THROWN. That works as desired on the panel diagram ¨C when the turnout is shown on the panel as aligned for the diverging route, the signal shows Green over Red (for example), and when the turnout on the panel is shown aligned for the normal route the signal shows Red over Green (for example).

The problem is with the relationship of the state of the turnout on the panel with the physical turnout state on the layout and as shown in the Turnout Table. It appears that setting ¡°Continuing Route Turnout State¡± to THROWN causes the displayed turnout state on the panel (and the turnout state used for calculating the signal aspects) to be _opposite_ the state of the physical turnout. So now when the turnout on the layout is set to CLOSED, the turnout on the panel is shown as THROWN and signals are set as if the turnout is THROWN.

If I now check the ¡°Inverted¡± checkbox for the turnout in the Turnout Table then the turnout state on the panel matches the turnout state on the layout. The Turnout Table now shows the opposite state from the physical turnout however. This means that anyone using the Turnout page in Engine Driver sees the wrong state. This is very confusing but perhaps could be managed.

There is a second reason I¡¯d like to avoid inverting the turnout if at all possible. These physical turnouts have EXACT feedback. When the turnout is actuated, the feedback state in JMRI changes to INCONSISTENT while the turnout is in motion. This INCONSISTENT feedback state is useful since it causes all signals around that turnout to go to RED until the turnout reaches its final position. Unfortunately the INCONSISTENT state disappears when the Invert option is selected: turnouts with Invert checked only show CLOSED and THROWN.

Am I missing something in setting up Layout Editor for this condition? Would appreciate guidance if you are familiar with this case. Thanks.

(FYI I was running 4.16 but updated to the latest test build and see no change in this behavior.)

Robin

Robin Becker
San Diego, CA
Locked Re: Unsupported decoder: Uhlenbrock 74120

 

Hi Charles,
On the Uhlenbrock website, it says:?The 74120 Decoder replaces the existing Decoder 76425 with NEM 652 plug.
That one happens to be in JMRI, and IntelliDrive2 I added for other models last Spring.

If you can send me the CV tables for this decoder (by Private message, use the button below on the groups.io web interface), I will check if I can work something out for you next month.

Egbert
Locked layout editor continuing route signal help needed

 

¿ªÔÆÌåÓý

Hi.? I have a panel with signals set up in Layout Editor and generally everything works fine.? The only issue so far is with 2 turnouts where the main line takes the diverging (THROWN) route.??? On the main approaching each turnout is a double head searchlight signal mast.? In order to get the top head on the mast to represent the main (diverging) route, I have set ¡°Continuing Route Turnout State¡± to THROWN.? That works as desired on the panel diagram ¨C when the turnout is shown on the panel as aligned for the diverging route, the signal shows Green over Red (for example), and when the turnout on the panel is shown aligned for the normal route the signal shows Red over Green (for example).

?

The problem is with the relationship of the state of the turnout on the panel with the physical turnout state on the layout and as shown in the Turnout Table.? It appears that setting ¡°Continuing Route Turnout State¡± to THROWN causes the displayed turnout state on the panel (and the turnout state used for calculating the signal aspects) to be _opposite_ the state of the physical turnout.? So now when the turnout on the layout is set to CLOSED, the turnout on the panel is shown as THROWN and signals are set as if the turnout is THROWN.

?

If I now check the ¡°Inverted¡± checkbox for the turnout in the Turnout Table then the turnout state on the panel matches the turnout state on the layout.? The Turnout Table now shows the opposite state from the physical turnout however.? This means that anyone using the Turnout page in Engine Driver sees the wrong state.? This is very confusing but perhaps could be managed.? ?

?

There is a second reason I¡¯d like to avoid inverting the turnout if at all possible.? These physical turnouts have EXACT feedback.? When the turnout is actuated, the feedback state in JMRI changes to INCONSISTENT while the turnout is in motion.? This INCONSISTENT feedback state is useful since it causes all signals around that turnout to go to RED until the turnout reaches its final position.? Unfortunately the INCONSISTENT state disappears when the Invert option is selected: turnouts with Invert checked only show CLOSED and THROWN.

?

Am I missing something in setting up Layout Editor for this condition?? Would appreciate guidance if you are familiar with this case.? Thanks.

?

(FYI I was running 4.16 but updated to the latest test build and see no change in this behavior.)

?

Robin

?

Robin Becker

San Diego, CA

?

?
Locked Re: Layout editor - connecting slips to turnouts #layouteditor

 

Peter
Does your MIO have a ULN2803 chip beside the servo connections or an 8-way resnet? If it's a resnet then that probably explains your output reversal. I believe the default is the ULN2803 and that reverses the PIC output to operate correctly with active to reverse the switch (point blades) and inactive to return the switch to the normal position. The resnet does not do that inversion so active is normal and inactive is reverse.
By far and away the best way to sort these things out is to create a small demo board with just a few bits of track and a point or two and get all the switching, block detection, tie bar position detection, servo orientation etc all working before attempting to start on the layout proper. All the bits will be transferrable to the final layout once confidence in the interaction between CBUS and JMRI is gained. It sounds like wasted work but I can assure you it's exactly the opposite. Changes to things are MUCH, MUCH easier done on the demo rather than the final layout.
Another question, do you actually have two sensors or micro switches to monitor the tie bar position of all your switches?
Fraser
Locked Re: Operations - Question from a beginner #operationspro

 

Paul,
I have been following this thread and one possible solution might be to set the train build mode to "aggressive mode".? This allows the software to take two (or more) looks at the siding.? It might help your situation.
Dave...
Locked Re: Control number of lines going to printer per page-OPERATIONS

 

It is there on my Macs.?
?
Click on print and it a box that shows the printer comes up that does not have the scale box on it then click on the show details box.?
Yes, that's my experience too. The mac print dialog has a "simple" box which can be "expanded" by clicking a little arrow. The expanded dialog has several scaling options including "fit to sheet".

Note that the dialog allows you to set the startup printing setup including an option to "use last settings" which is handy when you do find the combination of settings which does what you want.

Jan
Locked Re: Control number of lines going to printer per page-OPERATIONS

 

¿ªÔÆÌåÓý

It is there on my Macs.?

Click on print and it a box that shows the printer comes up that does not have the scale box on it then click on the show details box.?

It is not part of the printer drive software , it is in the apple driver software.?

I have also had very bad luck with Epson printers over the years on any computer and finally swore off of them.?


HP work flawlessly for me.?

I can alwasy get my Macs to print like I want. I have 2 Windows boxes that will not print corectly to anything no matter what I do.?



Jim



On Sep 23, 2019, at 9:32 AM, Frank in Houston <upitrr@...> wrote:

NEW INFORMATION...(First, THANKS to ALL who tried to help)

I borrowed a friends Apple computer and installed my JMRI files thinking a totally fresh start might help....same result... when I tried to print my manifests on his Apple I got the same problem as I have on mine. ?That is, every page of my manifest was about two lines too long and does not get printed. ?I could not find an OPTION called something like "Size to fit" or "Scale to fit" on either Apple computer. ?

So I installed the latest release 4-17-4 on a Windows 7 machine and used it to print my manifest and ALL WORKED JUST FINE. ?

I looked at the "OPTIONS" on the Windows 7 machine and found an option titled "FIT TO SIZE". ?(This kind of option is what I need on the Apple computer). ?I went to the EPSON Workforce WF3720 Website and Downloaded the very latest updates and drivers for the APPLE computer to my APPLE computer. ?However that still did not fix the problem. ?My page by page manifest is still about two lines too long for the APPLE computer to print everything. ?The print is beautiful but not complete.

Since the OPTION "FIT TO SIZE" is not provided by the printer software, Is there a built in feature in the Windows 7 print routine that proves the ?"FIT TO SIZE" Option? ?AND IF SO, how can I get this OPTION (or something similar) installed in my APPLE Computer? ?

THANK YOU AGAIN...Frank in Houston
Locked Re: Control number of lines going to printer per page-OPERATIONS

Frank in Houston
 

NEW INFORMATION...(First, THANKS to ALL who tried to help)

I borrowed a friends Apple computer and installed my JMRI files thinking a totally fresh start might help....same result... when I tried to print my manifests on his Apple I got the same problem as I have on mine. ?That is, every page of my manifest was about two lines too long and does not get printed. ?I could not find an OPTION called something like "Size to fit" or "Scale to fit" on either Apple computer. ?

So I installed the latest release 4-17-4 on a Windows 7 machine and used it to print my manifest and ALL WORKED JUST FINE. ?

I looked at the "OPTIONS" on the Windows 7 machine and found an option titled "FIT TO SIZE". ?(This kind of option is what I need on the Apple computer). ?I went to the EPSON Workforce WF3720 Website and Downloaded the very latest updates and drivers for the APPLE computer to my APPLE computer. ?However that still did not fix the problem. ?My page by page manifest is still about two lines too long for the APPLE computer to print everything. ?The print is beautiful but not complete.

Since the OPTION "FIT TO SIZE" is not provided by the printer software, Is there a built in feature in the Windows 7 print routine that proves the ?"FIT TO SIZE" Option? ?AND IF SO, how can I get this OPTION (or something similar) installed in my APPLE Computer? ?

THANK YOU AGAIN...Frank in Houston
Locked Re: Layout editor - connecting slips to turnouts #layouteditor

 

Dave
Thanks for your feedback. I fully agree with you that I should ensure the conditions are correctly set up in MERG and to avoid using JMRI to inverting anything. Spent some time last night checking through my application and found that I need to get further information on the MERG sensor inputs to jmri. I found that the P1a sensors conflicted when trying to set the turnout to the OFFl (closed) position. This was due to the MERG CANMIO SVO output events simultaneously providing a high to both Events 1 & 2 resulting in both being active at the same time in the sensor table. Not surprisingly, The Turnout on the panel showed the correct movement and then reverted back to the ON (thrown) position. Both Sensors at this time were 'Active'.
More work to do in MERG to resolve this before applying the other sensors inputs from the turnouts.
In the mean-time. Can you please remind me of how I was able to set the sensors to provide feedback for the other turnouts? I have a still have a bit more time to continue with this before other things get in the way. I am determined to try to ensure I can do this in a concentrated way and avoid the long delays between sessions.
One other thing, I have left the default ' No Pull Ups/Down' in the JMRI sensor settings.
Best wishes
Peter?
Locked Re: Possible roster problem #zimo

 

Bob

Yes you are right - 3F .

Gerry

On 23/09/2019 5:15 pm, Bob Jacobsen wrote:
The problem is that decoder doesn¡¯t do 128 speed steps, so it doesn¡¯t respond when it receives them.

As to the comparison:

Watching the command monitor wind up the speed on screen throttle

? cmd - Q C7 DO 3F 85 AD
? speed to "0" - Q C7 DO 37 80 A8
Using the phone to do exactly the same thing

? cmd - Q C7 DO 76 61
? speed to "0" - Q C7 DO 60 77
NO response from the decoder.
Let me organize these a bit differently to make the comparison easier:

screen ? cmd - Q C7 DO 3F 85 AD
phone ? cmd - Q C7 DO 76 61
The Q C7 D0 means ¡°send a command to loco 2000¡±. Then they differ:
3F is a 128 step command to set the speed; the 85 is forward in the 5th step
76 is a 14/28 speed step command in forward. If it¡¯s 14 step, the headlight is on.

? speed to "0" - Q C7 DO 37 80 A8
? speed to "0" - Q C7 DO 60 77
They differ in the command
37 is a 128 step command to step 0 in forward (I would have expected 3F for that, though; could you confirm 3F?)
60 is a 14/28 step command to stop. If it¡¯s 14 step, it¡¯s headlight off.

So the reason the screen and phone are behaving differently is that the screen thinks it¡¯s supposed to be sending in 128 step mode, and the phone in 14/28.

Bob
--
Bob Jacobsen
rgj1927@...




--
Gerry Hopkins MMR #177 FNMRA
Great Northern Downunder




NMRA Australasian Region
Contest & AP Chairman
Web Administrator
Locked Re: Possible roster problem #zimo

 

The problem is that decoder doesn¡¯t do 128 speed steps, so it doesn¡¯t respond when it receives them.

As to the comparison:

Watching the command monitor wind up the speed on screen throttle

? cmd - Q C7 DO 3F 85 AD
? speed to "0" - Q C7 DO 37 80 A8
Using the phone to do exactly the same thing

? cmd - Q C7 DO 76 61
? speed to "0" - Q C7 DO 60 77
NO response from the decoder.
Let me organize these a bit differently to make the comparison easier:

screen ? cmd - Q C7 DO 3F 85 AD
phone ? cmd - Q C7 DO 76 61
The Q C7 D0 means ¡°send a command to loco 2000¡±. Then they differ:
3F is a 128 step command to set the speed; the 85 is forward in the 5th step
76 is a 14/28 speed step command in forward. If it¡¯s 14 step, the headlight is on.

? speed to "0" - Q C7 DO 37 80 A8
? speed to "0" - Q C7 DO 60 77
They differ in the command
37 is a 128 step command to step 0 in forward (I would have expected 3F for that, though; could you confirm 3F?)
60 is a 14/28 step command to stop. If it¡¯s 14 step, it¡¯s headlight off.

So the reason the screen and phone are behaving differently is that the screen thinks it¡¯s supposed to be sending in 128 step mode, and the phone in 14/28.

Bob
--
Bob Jacobsen
rgj1927@...
Locked Re: Possible roster problem #zimo

 

¿ªÔÆÌåÓý

Don

Did some testing today here is what I found.

LE103 number 2000. Decoder set up -

14SS; CV2=1; CV3=1; CV4=1

  • Command Station set up to 14SS as default.
  • Using JMRI throttle on screen in 28ss mode - motor runs.
  • Using JMRI throttle on screen in 128ss mode - motor does not runs.
  • Command station set up to 28ss as default.
  • Using JMRI throttle on screen in 28ss mode - motor runs.
  • Using JMRI throttle on screen in 128ss mode - motor does not runs.
  • Command station set up to 128ss as default.
  • Using JMRI throttle on screen in 28ss mode - motor runs.
  • Using JMRI throttle on screen in 128ss mode - motor does not runs.

LE103 number 2000. Decoder set up -

28SS; CV2=1; CV3=1; CV4=1

Same results as above for 14SS.

Watching the command monitor wind up the speed on screen throttle

  • cmd? -?????????????? Q C7 DO 3F 85 AD
  • speed to "0" - Q C7 DO 37 80 A8

Using the phone to do exactly the same thing

  • cmd -??????????????? Q C7 DO 76 61
  • speed to "0" - Q C7 DO 60 77

NO response from the decoder.

The commands to the command station are different when sent from the phone than when sent from JMRI screen.

The answer for this is above my pay grade!

My answer - scrap the decoder and use one from this century.

I tried both the NCE and System One decoders of the same vintage - they ran every time.

Gerry


On 22/09/2019 8:42 am, Don Weigt wrote:
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

Virus-free.

Locked Re: SECTIONS TABLE NEW BUG

 

Mitch,

I have uploaded my two crossover solution. It may have other issues but it works for S01 to S08.

/g/jmriusers/files/ProblemsBeingWorkedOn/dsand/Concept%2010%20DS.xml

Dave Sand

On Sep 22, 2019, at 8:20 PM, Mitchell via Groups.Io <mitchell.scott93@...> wrote:

Thank you Dave,

I thought I was going crazy!

That all makes total sense, and I¡¯m glad the sensor fix will be in the next update. I¡¯ll backdate to the production release and fix up the sensors side of things, and then wait for 4.17.5.

As for the layout, I¡¯m totally fine with manually doing the SML to S08 and deleting the S04 destination.

if you are able to, could you upload your revised XML with the change in pointwork?
I won¡¯t use it, but hopefully I can learn from it and it may spark some inspiration in ways I can improve.

--
Thanks
Mitch
Locked Re: SECTIONS TABLE NEW BUG

 

Thank you Dave,

I thought I was going crazy!

That all makes total sense, and I¡¯m glad the sensor fix will be in the next update. I¡¯ll backdate to the production release and fix up the sensors side of things, and then wait for 4.17.5.

As for the layout, I¡¯m totally fine with manually doing the SML to S08 and deleting the S04 destination.

if you are able to, could you upload your revised XML with the change in pointwork?
I won¡¯t use it, but hopefully I can learn from it and it may spark some inspiration in ways I can improve.

--
Thanks
Mitch
Locked Re: Layout editor - connecting slips to turnouts #layouteditor

 

¿ªÔÆÌåÓý

Hi,

While developing my DIY turnout servos I discovered something that should have been obvious... the servo direction, ie.
push to close vs. pull to close, depends on which side of the turnout (main vs. diverging) the servo is mounted on.
I had to make the connector for the 2 feedback switches allow swapping to avoid any JMRI inverting.? I tried a few
software solutions first, but they got kinda' messy.? I second Dave's policy.

Steven


On 09/22/2019 04:48 PM, Dave Sand wrote:

Peter,

You need to change the mode in the turnout table from DIRECT to TWOSENSOR. ?Also, when Sensor1 is active, that indicates Thrown while sensor2 is used to indicate Closed. ?For slow motion switch machine, a turnout goes from one state, to Inconsistent, to the other state.

My policy that is that I never invert anything in JMRI. ?I manipulate the hardware as needed to get the proper input into JMRI.

Dave Sand


On Sep 22, 2019, at 5:34 PM, peter.s.drury via Groups.Io <peter.s.drury@...> wrote:

Hi Dave

Sorry for the confusion. I take it that you have seen my panel file.
I am using toggle switches on the layout and these are entered in the sensor table: Node 262. Events 1 - 8
I have also entered two feedback entries (more to follow) for P1a to indicate this turnout is at the closed (Servo Off end) or thrown (Servo at ON end).
The turnouts are all in the turnout table and controlled by a CANMIO SVO Node 257.
With the above setup, The panel Editor showed the operation of the toggle switches acting on the turnouts but, I operate the toggles with the OFF?position forward and the ON position with the toggle switch pulled. I adjust this sense by setting up each servo within the CANMIO SVO. The conflict I?have is that the toggle switch settings seem to be reversed in JMRI.
Hope this helps
Best wishes
Peter
Locked Decoder Pro Loco Sequence

Charley Goddard
 

I'll give that a try Marc, thank you.


Charley
Locked Re: Layout editor - connecting slips to turnouts #layouteditor

 

Peter,

You need to change the mode in the turnout table from DIRECT to TWOSENSOR. ?Also, when Sensor1 is active, that indicates Thrown while sensor2 is used to indicate Closed. ?For slow motion switch machine, a turnout goes from one state, to Inconsistent, to the other state.

My policy that is that I never invert anything in JMRI. ?I manipulate the hardware as needed to get the proper input into JMRI.

Dave Sand


On Sep 22, 2019, at 5:34 PM, peter.s.drury via Groups.Io <peter.s.drury@...> wrote:

Hi Dave

Sorry for the confusion. I take it that you have seen my panel file.
I am using toggle switches on the layout and these are entered in the sensor table: Node 262. Events 1 - 8
I have also entered two feedback entries (more to follow) for P1a to indicate this turnout is at the closed (Servo Off end) or thrown (Servo at ON end).
The turnouts are all in the turnout table and controlled by a CANMIO SVO Node 257.
With the above setup, The panel Editor showed the operation of the toggle switches acting on the turnouts but, I operate the toggles with the OFF?position forward and the ON position with the toggle switch pulled. I adjust this sense by setting up each servo within the CANMIO SVO. The conflict I?have is that the toggle switch settings seem to be reversed in JMRI.
Hope this helps
Best wishes
Peter
76881 - 76900 of 240568