Add functions f9 f28

[heuriko]

Dear mrrwa team,

I would like to add support for functions F9-F28, currently not supported at all.

I implemented support for functions F9-F28 using Uhlenbrock opcode (OPC_UHLI_FUN) as described here: https://wiki.rocrail.net/doku.php?id=loconet:lnpe-parms-en

Also added support for reading some Digikeijs (DR5000 command station) function messages (OPC_DIGIKEIJS_FUN).

Summary:

• Added support for F9-F28 using OPC_UHLI_FUN (receive and transmit)
• Added support for F9-F12 (receive only) using OPC_DIGIKEIJS_FUN
• Tested using Digikeijs DR5000 command station
• Added a function LocoNetThrottleClass::resetAllFunctions to provide a quick way to reset a loco's functions.

Validation:

• I have already evaluated correct operations using Digikeijs DR5000 command station.
• Please find a test sketch in test/test_functions/test_functions.ino

Last but not least, I would like to give you my compliments on your LocoNet library. Used it to do some layout/staging yard automation (work in progress) and it works great.

Best regards, Enrico

[devel-bobm]

A personal opinion:

These Uhlenbrock-specific opcode usages could/should be made "conditional" upon some sort of a command-station-specific flag, since Digitrax uses different LocoNet Messaging for controlling F9 thru F28 than those used by Uhlenbrock command stations.

And, ideally, similar functionality would be provided for Digitrax command station support of F9 thru F28.

Again, this is simply my opinion.

[heuriko]

Thank you Bob!

Just hooked my Arduino to a Digitrax DCS50 command station to check. Unfortunately I do not have a throttle to make further checks, but according to my Serial monitor, setting functions works using the OPC_UHLI_FUN opcode.

So support should already be available on Digitrax systems even with this opcode. Maybe this is something one of you could check :-) Would be nice if someone could confirm correct operation :-)

If Digitrax specific messages were to be supported, and coming to your comment, there are some design questions to be addressed:

• Receive-side, there is no real need for a flag, the receiver could just look for the message format (except maybe to simplify storing received function values, cf. "myFunc9to11" etc.)
• Transmit-side a flag would be useful unless the message was to be send in both formats.

Looking forward to your feedback, Enrico

[pischky]

Hello Enrico,

AFAIK 0xD4-Messages (Uhlenbrock) do not work on DCS100. Also I also assumed that they did not work on DCS50 and DCS51.

Hmm...

Bob is correct that Digitrax (DCS200+ use other Opcodes).

To emulate a throttle you can use LocoNetMessageTester or JMRI.

http://loconetovertcp.sourceforge.net/Client/index.html#loconetmessagetester

Martin

Am 06.09.2021 um 10:33 schrieb heuriko:

Thank you Bob!

Just hooked my Arduino to a Digitrax DCS50 command station to check. Unfortunately I do not have a throttle to make further checks, but according to my Serial monitor, setting functions works using the OPC_UHLI_FUN opcode.

So support should already be available on Digitrax systems even when with this opcode. Maybe this is something one of you could check :-) Would be nice if someone could confirm correct operation :-)

If Digitrax specific messages were to be supported, and coming to your comment, there are some design questions to be addressed:

• Receive-side, there is no real need for a flag, the receiver could just look for the message format (except maybe to simplify storing received function values, cf. "myFunc9to11" etc.)
• Transmit-side a flag would be useful unless the message was to be send in both formats.

Looking forward to your feedback, Enrico

[devel-bobm]

Be very careful when using a DCS52, a DCS210, a DCS210+, or a DCS240 command station and interpreting its behavior as "standard". Those command stations support two different types of "slot" messaging - the "old" standard LocoNet slot/locomotive control messaging, and a "new" (what I call "enhanced") slot/locomotive control messaging. So the behavior you see will depend on whether the throttle and command station are using "new" or "old" slot messaging.

Older Digitrax command stations only support the "old" standard LocoNet slot/locomotive control messaging.

I suspect that your experiment has shown the DCS52 operating using the "new" slot control messaging, not the "old" slot control messaging! The "new" messaging does indeed use opcode 0xD4 for function control (and lots of other slot control messages).

But "new" slot control messaging cannot be used when the command station and throttle are using the slot in the "old" slot control messaging mode!

Mixing the two different types of LocoNet slot control messaging will result in unexpected behaviors.

• If you send the "new" type of slot control messages with a command station which only supports the old slot control messaging, the messages will be ignored by the command station.
• If you send the "new" type of slot control messages whith a command station which supports the new style, then either of two behaviors can occur: -- if the slot is being used in "new" mode, and the throttle ID number burried in the LocoNet message matches the throttle ID for the throttle which acquired the slot, then the command station will pay attention to the slot. If instead the throttle ID value is wrong, then it may cause the "StealZap" feature to be triggered. and therefore cause the controlling throttle to stop controlling the slot. -- if the slot is being used in "old" mode, I believe that the command station simply ignores the "new" slot control LocoNet messages.

To my way of thinking, the implementation depends on the library's current support for slot support messaging.

• Supporting Uhlenbrock messaging is fine - so long as the command station is one developed by Uhlenbrock.
• Supporting Digitrax' "new" slot control messaging for F9-F28 only makes sense if the library supports the other aspects of "new" slot control messaging.
• Since (so far as I know) the MRRwA LocoNet library supports "old" LocoNet slot control messaging, it would make sense to have support for "old"-style F9 thru F28 messaging. This was done by properly encoding the NMRA Function Control packet information in an OPC_IMM_PACKET LocoNet message.

Regards, Billybob

[heuriko]

Hey Martin and Bob,

Thanks for sharing those deeper insights. I do not have so much of a background with Digitrax and also cannot test on the hardware, especially since we don't have any material except the DCS50 (a gift :-).

Is there any chance the "old"-style F9 thru F28 messaging is the one listed here?

Have already had a look at this, but I was wondering if there should be support for short addresses or if long is enough?

Regards, Enrico

[pischky]

Hallo Bob, Hello Enrico

Thanks to Bob for explanation of "New Slot Format".

There are not really old style Digitrax messages :-) What Bob names "old"-style are really DCC-Pakages wrapped by OPC_IMM_PACKET. They should work on every command station supporting OPC_IMM_PACKET. In my opinion this is outdated and has some disadvantages.

You find these in on the rocrail page as OPC_IMM_PACKET. AFAIK JMRI can send these.

Martin