search

mrrwa / LocoNet

An embedded Loconet interface library for Arduino family microcontrollers
Other
68 stars 32 forks source link

LocoNetClass::reportSwitch does not take switch state as parameter #13

Closed positron96 closed 4 years ago

positron96 commented 4 years ago

What this method is supposed to do (right?) is to send a switch state to LocoNet. However the method takes only 1 argument, switch address. It should also take 2 arguments, dir and on to fully fill loconet packet. I can provide a pull request for that.

devel-bobm commented 4 years ago

The LocoNetClass::reportSwitch method's name is misleading, and you have assumed a different type of functionality than what it actually does.

This method IS NOT creating a "state report" message for the status of a "turnout" implemented by the device implementing this functionality. Instead, this method is a creating a "what is the state" request message, using the LocoNet "OPC_SW_STATE" opcode. That message uses ONLY the switch number.

Some other LocoNet device which implements the turnout number is responsible for seeing that request message and replying with an OPC_LONG_ACK message which contains an indication that the long_ack is a "switch status report" and a bit to define the switch position and a bit to define the switch power state (on/off).

Note that the library does not include the necessary code to allow a device using this library to implement all of the requrired LocoNet "Turnout" functionality.

You might want to ask users on the "Arduini" list on groups.io to see if someone has a sketch or a library update for such functionality.

positron96 commented 4 years ago

Huh, shame on me then to not read the docs carefully. I was fooled by methods reportSensor and reportPower, which, to my understanding, do send their respective statuses; and OPC_SW_STATE which is poorly documented in Digitrax Personal edition. But what do you mean by this library not including the necessary tools for turnouts? I got the impression that I can receive the the packet and after matching its opcode, do whatever I want. This evening I've implemented track current and voltage sensing via OPC_EXP_RD_SL_DATA opcode for JMRI and love the library for that universality.

devel-bobm commented 4 years ago

@positron96, what I mean is that the library does not impelement everything needed for a complete implementation of a Turnout device:

This makes it very challenging for a LocoNet device or software product to determine the current state of a LocoNet Turnout when implemented with this library. In my mind, that's a bad thing.

And, in my mind, these omissions make any implementation of a "turnout" device using this library to be "incomplete".

kiwi64ajs commented 4 years ago

Hi Guys,

A few comments:

1) You’re right the method name LocoNetClass::reportSwitch would have been better to be something like: LocoNetClass::requestSwitchState() - I probably did it in a hurry but from memory there are a number of awkwardly defined switch interaction messages and OPC Codes in the LN spec and that was my attempt at coherance at the time…

We could rename it to that but keep the old method around with a #define or some other means to alias it to the new name. Need to ask the C++ guru’s at work for the best way to handle this.

2) In terms of the missing functionality relating to "respond with Switch Status” - write the missing code and submit a PR.

However, you might want to check with someone like Bob Jacobsen and/or look at the JMRI LocoNet Message Logging code as that whole group of "Switch Messages” is thwart with inconsistency and confusion as to what actually is the right is the right thing to do. That’s kinda why it is what it is and not complete.

My general solution to all this was to simply write the NmraDcc library as that seemed to avoid most of the complexity and delivered an outcome of making Turnout/Switch control easier and more consistent across vendors, instead of a LocoNet only solution.

However it you’ve got access to test gear like the DS54/64 and the other LocoNet devices that respond to those commands then feel free to write/fix the missing functionality and submit a PR.

HTH

Alex Shepherd

On 20/05/2020, at 8:39 AM, Bob Milhaupt notifications@github.com wrote:

@positron96 https://github.com/positron96, what I mean is that the library does not impelement everything needed for a complete implementation of a Turnout device:

There is NOTHING in the mrrwa/LocoNet library that watches for the query message (like the one generated by the method you originally asked about), and respond with the appropriate variant of OPC_LONG_ACK, giving the position and power on/off state of the individual turnout. For example, this means that a Digitrax throttle (with a display!) will NOT be able to report the current switch state when in "SWITCH" mode and the turnout number is "dialed up".

There is no code to watch for LocoNet "Interrogate" messages, and therefore no code to respond to such messages.

This makes it very challenging for a LocoNet device or software product to determine the current state of a LocoNet Turnout when implemented with this library. In my mind, that's a bad thing.

And, in my mind, these omissions make any implementation of a "turnout" device using this library to be "incomplete".

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mrrwa/LocoNet/issues/13#issuecomment-631069430, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5Y53NHX7UIJXXP2UBXL7DRSLU7TANCNFSM4NFCDUPQ.

positron96 commented 4 years ago

@positron96, what I mean is that the library does not impelement everything needed for a complete implementation of a Turnout device:

  • There is NOTHING in the mrrwa/LocoNet library that watches for the query message (like the one generated by the method you originally asked about), and respond with the appropriate variant of OPC_LONG_ACK, giving the position and power on/off state of the individual turnout. For example, this means that a Digitrax throttle (with a display!) will NOT be able to report the current switch state when in "SWITCH" mode and the turnout number is "dialed up".
  • There is no code to watch for LocoNet "Interrogate" messages, and therefore no code to respond to such messages.

This makes it very challenging for a LocoNet device or software product to determine the current state of a LocoNet Turnout when implemented with this library. In my mind, that's a bad thing.

And, in my mind, these omissions make any implementation of a "turnout" device using this library to be "incomplete".

Actually, I have no complaints about the library in this regard, and like it even more that the library does not think for me and lets me parse messages myself. Does not seem too hard to add a thin layer of parsing and dispatching required messages. So I actually think that I could implement a proper turnout decoder with this library. There is code to handle OPC_SW_REQ, handling OPC_SW_STATE Am I missing something?

What I do complain about, is quality of Loconet Personal documentation that makes it difficult to understand the semantics of messages.

BTW, there is parsing of OPC_SW_STATE inside processSwitchSensorMessage and it's extracting dir and state from packet, while reportSwitch sends this packet without this information. The library seems somewhat inconsistent in this opcode. This is probably because documentation is severely lacking. There is also parsing of OPC_LONG_ACK inside processSwitchSensorMessage but it seems incomplete.

positron96 commented 4 years ago

Guys, let me ask you a broader question here. I am doing an all-DIY layout (well, except locomotives and their decoders) and want to do a proper two-way communication with stationary decoders and sensors. I don't want to use DCC for them because its feedback mechanisms are kind of hackish and also I've read that it's better to separate track DCC from stationary decoders. I also would like to bind together wiThrottles, wired throttles, command station and a PC with JMRI. At the moment I have a DCCpp command station (DCC + JMRI) with ESP8266 (wiThrottles, DCCpp over WiFi), nrf24 (a homebrew wireless protocol for sensors and turnouts). I want to ditch nrf24 and replace all that with a common bus for all devices (preferably). Can you advise on what protocol is better for the task? So far I know of these:

kiwi64ajs commented 4 years ago

Hi Pavel,

On 20/05/2020, at 6:26 PM, Pavel Melnikov notifications@github.com wrote: Guys, let me ask you a broader question here. I am doing an all-DIY layout (well, except locomotives and their decoders) and want to do a proper two-way communication with stationary decoders and sensors. I don't want to use DCC for them because its feedback mechanisms are kind of hackish and also I've read that it's better to separate track DCC from stationary decoders.

Mostly the separation of DCC Accessory Decoders from the track is because of DCC Packet bandwidth usage and people wanting to reserve all bandwidth for loco control to minimise latency as on larger systems this can be an issue.

I’ve not really experienced it but I’m probably not been on a layout with more than 20 locos running at the same time.

It was an issue for the Fremo guys in Germany so they created their own multi-command station solution to spread the DCC Packet Generation load over several command stations, but still just have a single LocoNet for the throttles. See: http://dcc-mueller.de/switch/loconete.htm http://dcc-mueller.de/switch/loconete.htmI also would like to bind together wiThrottles, wired throttles, command station and a PC with JMRI. At the moment I have a DCCpp command station (DCC + JMRI) with ESP8266 (wiThrottles, DCCpp over WiFi), nrf24 (a homebrew wireless protocol for sensors and turnouts). I want to ditch nrf24 and replace all that with a common bus for all devices (preferably). Can you advise on what protocol is better for the task? So far I know of these:

LocoNet - I wanted to use this, achieved some results in the process discovered that it's poorly documented. Also, it's proprietary, only personal part is published. LCC - open, but requires CAN bus with more expensive chips. NCE - don't know anything Bidib - don't know anything Well I know quite a bit about both LocoNet and LCC and have hardware for both systems.

I have only dabbled with NCE and borrowed some gear to write a simple RS485 NCE Slave device Arduino library that supports the AIU and the so-called dumb throttle protocols. A few people have had success using this NCE library.

LocoNet is pretty widely used and has a mature DIY community. The LocoNet issues and limitations are pretty well known and have reasonable work-arounds.

LCC (OpenLCB) is much newer and has much more capacity and is arguably better than LocoNet (depending on your opinion and measure…) but is not as mature.

I hve both on my small modular layout at home.

What size is the layout and how many locomotives will you run concurrently and how many turnouts, signals etc will you control? I’m picking that because its running on DCC++ its less than 10 locos, so I’d suggest that LocoNet is probably still a good solution for what you sound like you’re interested in.

LCC despite being designed to operate over multiple networking technologies, is mostly only running on CAN Bus still as that was a commonly available "off-the-shelf” networking technology that provided simple and robust networking without much complication. Also it was supported by 8-bit micros back when we started in 2008 and availability has only improved since then. There’s good CAN Bus support in the ESP32 and STM32 micros, compared to the older AVR AT90CANxxx chips we used for OpenLCB prototypes.

HTH

Alex Shepherd

devel-bobm commented 4 years ago

Perhaps this discussion should be moved to the "arduini" or "locoNet-Hackers" groups.io list, as it seems to be more "what if" than "here's a concrete problem with the library" or "here's a concrete feature I would like to see in the library".

positron96 commented 4 years ago

@devel-bobm you are definitely right. Thank you very much for all the information! Not only I got some intel on message buses but also links to relevant discussion communities that I could not find myeslf.