Output Technologies

[Asbelos]

TPL refers to outputs by simple id. the technology is separated from the automation.

Current technologies are

1. Direct CPU pin
   2. I2C extender pin

Do we need any more technologies here?

[davidcutting42]

I would add:

3. Layout bus pins
4. DCC Accessory decoder pins

[marada1]

If I may throw out a thought. To me there would normally be 3 pieces of information needed when communicating. The first would be what or function. Are you going to control a turnout, Are you looking to turn on an accessory. The second would be the assigned ID of the device. That eases the state for the 3rd piece. On/Off, Thrown/closed.

[Asbelos]

There are many possible solutions here... Some systems transmit unique id messages with no meaning attached.. then any listening device can say " oh that means throw turnouts 6, 7,9 and another can set the signals and another close the crossing gates.... On 22 Nov 2020 10:49, marada1 notifications@github.com wrote: If I may throw out a thought. To me there would normally be 3 pieces of information needed when communicating. The first would be what or function. Are you going to control a turnout, Are you looking to turn on an accessory. The second would be the assigned ID of the device. That eases the state for the 3rd piece. On/Off, Thrown/closed.

—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[marada1]

Is there an API that would see if there was a command for turnouts or accessories or whatever that would route the command to say serial2 on a mega and then listen for a reply back. That would allow external devices to have 2 way communication

[Asbelos]

Anything that listens for response coming back needs to handle async command processing and know what is expected back .. this gets complicated because the first response you get may not be for the last command sent. Making up protocols isnt as simple as it first appears.... On 22 Nov 2020 12:52, marada1 notifications@github.com wrote: Is there an API that would see if there was a command for turnouts or accessories or whatever that would route the command to say serial2 on a mega and then listen for a reply back. That would allow external devices to have 2 way communication

—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[marada1]

If the response back includes the 3rd piece of information such as turnout or accessory the order would not matter. My thinking is to connect to an external device whether it's ethernet, wireless network, whatever. Less load on Command station then. Then look into using an SD Card to hold data. So if you get a command to move a turnout, CS looks at the turnout file, finds the turnout ID and state, then sends a command to serial2 to activate turnout(ID) !state. After the external device moves the turnout it responds back, turnout -- ID -- state. CS then writes the new state to the corresponding turnout ID in the turnout file.

[Asbelos]

Just remember that reading/writing serial or wifi or ethernet is often much more work than actually doing the job...  Dont assume that this will reduce the load on the CS, if anything it could increase it to the point of collapse. Just remember you cant wait but you must poll the serial buffers frequently enough to never allow them to overflow. We also need to keep the simple stuff simple and not compromise that.On 22 Nov 2020 13:34, marada1 notifications@github.com wrote: If the response back includes the 3rd piece of information such as turnout or accessory the order would not matter. My thinking is to connect to an external device whether it's ethernet, wireless network, whatever. Less load on Command station then. Then look into using an SD Card to hold data. So if you get a command to move a turnout, CS looks at the turnout file, finds the turnout ID and state, then sends a command to serial2 to activate turnout(ID) !state. After the external device moves the turnout it responds back, turnout -- ID -- state. CS then writes the new state to the corresponding turnout ID in the turnout file.

—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[marada1]

You are correct and is why I was looking to go external. Polling the inputs would have to happen no matter when was added to CS. But if CS does not have to carry out the actual work then in my mind that is less overhead. And the SD Card would not use much. I'll attach a text file of the code needed to initialize a SD Card. And the file is only open when it is needed. SDCode.txt

[marada1]

Hey all, in thinking some more I would like to ask a question. When a command comes in from Engine Driver it is received by the WiFi board I believe. From there is is parsed to the CS over a serial line. Is it also parsed to the serial monitor? And if it is parsed to CS over a serial line could it not in fact be parsed to a second serial line as well?

[grbba]

@marada1 if you consider to connect a WiThrottle client only directly connected to the CS indeed the command flows through the ESP over serial into the WiThrottle parser for execution and the result flows back. WiThrottle clients can also be connected via an AP to the CS then it depends how the CS is hooked up with the AP which maybe WiFi or Ethernet. If it's WiFi the same as above is happening and the command gets from serial to the parser. If it's Ethernet then Serial is not involved at all as the command goes then from the EthernetClient to the parser..

[grbba]

@marada1 when you say it's parsed to the serial monitor what do you expect to see get or do ? You can already switch on DIAG for WiThrottle whose output goes to the serial monitor. The serial monitor has no role in processing incoming commands from WiFi or Ethernet.

[Asbelos]

Please be aware of 2 points

1. The withrottle protocol is completely different to the <> commands and at no time do we translate from one to the other. Both parsers call the DCC packet layer directly. Look at DCCEXParser.cpp and Withrottle.cpp

2. The traffic over the wifi serial contains all the Es AT command interfacing messages and only a small part of that is the command data. Look at WifiInterface.cpp and WifiInboundHandler.cpp

It aint as simple as i look ...

[marada1]

The reason I am asking is because of what I see as great potential. I realize that we are talking two different protocols but to me, the bottom line is for CS to do something other then control engines it has to do one or both of two things. Sent a DCC signal to a DCC decoder with information on what to do or send a AP signal to another device that contains the information on what to do. That signal is going to come from one of 2 places, either the WiFi shield or the serial monitor. CS receives the information the same from either one. As a serial signal. Let me say that my level of coding is not near the level of what is present here. But I do understand logic and I understand I feel can work and be in demand. The team came together as a result of so many people trying to use Greggs original work and that work trying to be adapted and modified to work for them With various levels of success. The effort being expended here I feel is going to really bring the hobby home for many a modeler. Because of what I have learned from my association with the hobby I am asking a lot of questions because in my mind I have a flow chart of what can be. And I actually feel it could be a new standard.