Host updated PHP from 7.0.2 to 7.0.33 and error_logs disappeared. Opened a Ticket.
The hardware delay between issuing a command to change a track switch/turnout, and when the turnout is fully changed is ~4 seconds. From a software view this is an issue. After issuing a software command, when can a train cross the turnout? Just inserting a 4 second delay in the Lap Top processing is not that elegant and creates timing problems. Using feedback from the hardware to know the turnout state, (THROWN, in motion/unknown, CLEARED) would be better. Several alternate possible solutions considered to obtain feedback were:
Use one of the two SPDT switches in the Tortoise to provide turnout position feedback. (see Tortoise Wiring) {The second SPDT is used to control polarity of the turnout frog.}
Due to the mechanical linkage between the slow motor and the SPDT switch(es) there is a ~1 second delay between motor start and switch opening. The other side of the SPDT switch closes ~1 second before the motor stalls in the other position.
Would need to move the current RED/GREEN LED or lose the on-board turnout status. The 3v3dc from the Raspberry Pi 3 (3A) GPIO would not provide enough power for a very bright signal. Placing the LEDs in the Wabbit/Tortoise wiring as suggested by the manufacture, would need different bi-color LED (colors wired front to back) and slow the Tortoise even more.
With the delay between command sent and switch open, the software could scant the turnout several times before seeing that the turnout is changing.
Use two reed switches and rare earth magnets on the Tortoise to detect when the Tortoise stops in the new turnout position.
This requires a bracket to hold the reed switches in place with the ability to adjust their location/closing timing.
Assuming an adjustable bracket, there still would be a latency between command & switch opening and between switch closing & stop motion. This is not that different that #1 above and requires design & building brackets.
Use Wabbits w/feedback to identify changes in switch status.
There are 2 outputs for each turnout controlled by the Wabbit, one for THROWN and one for CLEARED state. The output reflects the last command (or manual input) given. The states change when a command is received NOT when the Tortoise finishes responding to the command. When a DCC command is received both outputs toggle at the same time.
The Raspberry Pi 3 (3A) could report the "off" state immediately and delay the "on" state to create the actual three states of the turnout.
The intent of these status outputs is to inform controlling software of any manual/auto control commands. For example toggle switch or push button inputs or using the auto switch feature of the Wabbit - All feature not us by the TrainThing.
Insert circuitry between the Wabbit and Tortoise to detect the current change when the Tortoise motor stalls in the new switch state.
Was thanking about using the PVT312 that I used with the fan to use a 3v3dv GPIO to control 5vdc for the fan. In this case it would be ~8v to pull down a 3v3dv GPIO. However, the documentation says the IC is linear which doesn't help.
An addition to the circuit between the Wabbit and Tortoise reducing the voltage seen by the Tortoise slows the response time of the Tortoise/turnout.
Add a delay in the Raspberry Pi 3 (3A) software between when a command is received and returning status that command is completed.
The Raspberry Pi 3 (3A) could capture a copy of the DCC++ command to the Arduino (2) to trigger returning status. This would work for simple commands. However, using the Wabbit smart-route capability would require programming the Raspberry with all the smart-route information.
The simple/expensive answer is to replace the current 6 Wabbits with Wabbits w/feedback, as in #3 above.
