Topics

Configuring Feedback Breaks DCC++ Output #sensors #arduino #turnouts #dccpp


Chuck Bade
 

Using DCC++ Configuration Manager, I set up an output that I can use to drive a turnout from the Arduino, and I can toggle it back and forth using the turnout table.  But after I configure a sensor to provide feedback, the output will no longer toggle.  When I check the DCC++ monitor, I can see that JMRI is sending output commands ( ) to toggle the output, but after I configure feedback, it starts sending DCC commands as if it was sending to an accessory decoder.  If I delete the output from the turnout table and let JMRI recreate it, then it will work again.
Am I doing something wrong?  Can this be fixed?


Chuck Bade
 

Forgot to include this information:
I'm running JMRI version  4.18+R37ad3d0, Java version 1.8.0_111, on Ubuntu version 16.04.6 LTS.


Randall Wood <rhwood@...>
 

Can you verify this is or is not an issue in JMRI  version 4.19.8?

Randall

On Jun 30, 2020, at 21:28, Chuck Bade via groups.io <chuck.bade@...> wrote:

Forgot to include this information:
I'm running JMRI version  4.18+R37ad3d0, Java version 1.8.0_111, on Ubuntu version 16.04.6 LTS.


Chuck Bade
 

I tried it on 4.19.8 and got the same result.  After setting feedback, JMRI sent a decoder message.


Chuck Bade
 

Could someone please review and try to give me an answer?  I'm a recently retired software engineer and I could try to look at the code myself, but it would take a lot longer for me to find it than for one of you guys.  Plus, if I find it and suggest you accept my change, I would lack the credibility for you to do so.
Thanks,
Chuck


FlightRisk
 

Not sure how much I can help, but I am the team lead for DCC++ Classic and DCC++ EX. DCC++ handles turnouts as an accessory decoder as far as DCC packets go and it uses the address, subaddress format. So if you use the normal turnout command, JMRI sends <a address subaddres 1> and that throws the switch. If you save turnouts in the Base Station (we are going to start calling this Command Station in the future) then you assign an ID and they can be saved in EEPROM. Now the command to DCC++ will be <T ID 1> to throw the switch. Internally, we look up the ID and then send <a Address Subaddress 1> . So they are the same thing. The third way is using inputs and outputs which of course just turns pins on and off as you know and uses the <Z> command . JMRI should send <Z ID PIN IFLAG> to set it and the control it with <Z ID STATE>. If you save settings to EEPROM, JMRI looks for the to load the into the table instead of using its internal database.

Looking at the JMRI code, you would need to click on the "show feedback" checkbox at the bottom of the turnout table screen and select the correct value from the dropdown. Internally the EXACT mode maapped to BSOUTPUT in the dropdown.  That will generate the <Z> command. If you set BSTURNOUT, that selects the  MONITORING mode which will use the <T> command and if you select DIRECT which is DIRECT or RAW mode, it will use the <a> command. For BSTURNOUT you need to make sure you have saved the turnouts and sensors to the Base Station. You may want to save them to EEPROM.


Chuck Bade
 

On Wed, Jul 8, 2020 at 09:58 PM, FlightRisk wrote:
The third way is using inputs and outputs which of course just turns pins on
This is what I'm doing.  I use the Output column in DCC++ configuration to create the output numbers I want, but when they automatically show up in the turnout table and I set feedback, it changes something and my output "pin" is no longer treated like a pin but becomes a decoder output with address and subaddress.  Does this make sense?


robteed
 

If anyone can shed some light on this it would be greatly appreciated. I’m kind of beta testing this system and this is the only bottleneck he has run into.