[Aldarion]

Both are interesting for my project in the national railway museum in Portugal in wich I have a full cab sim working. But if I had to choose I'd go with the capacity to control the sim through a smartphone or any other device so I could alter rain, fog, and even simulate faults by altering readings on brake pipes ( or any other OR variable loaded into memory)...

[Weter]

Yes. A student uses drive-stand with its controls and gauges, while an instructor have full control on whole program, including options and debugging functionality via, say tablet.

[cesarbl]

Well, that's beyond what I had in mind.

The idea is to control cabview controls with external hardware, not just limiting to RailDriver (say potentiometers, buttons, etc.)

[Weter]

so, only train controls, analog - looking (e.g. Levers with continues range)
Custom-built, or factory-serial?

[Laci1959]

Helló.

https://kephost.net/p/2022/44/4337_f4dccf21987d.jpg

Version for raildriver. Made from disassembled V43 parts. It was originally created for the EU 07 Maszyna program, but can now also be used for OR.
Since then, the owner has also used 3D printing for the TAURUS locomotive.

Sincerely, Laci 1959

[Aldarion]

Weter, on 31 October 2022 - 08:07 AM, said:

Yes. A student uses drive-stand with its controls and gauges, while an instructor have full control on whole program, including options and debugging functionality via, say tablet.

Yes something like that only in my case, visitors would use the drive-stand and me, with a side control on my smartphone, to play some tricks on them :rotfl:

[cjakeman]

Hi Cesar,

cesarbl, on 31 October 2022 - 05:17 AM, said:

Technical details: I'm re-using HandleUserInput() function of CabViewDiscreteRenderer, substituting ChangedValue() by the value given by the API. Therefore, minimal code changes are needed to support all existing cab controls.

Any ideas or suggestions?

This is going to be a significant extra functionality for Open Rails. Very happy to see it going ahead.

I am hoping that we can re-factor the code just a bit and pull some common code out of CabViewDiscreteRenderer.HandleUserInput() which can then be called by both the new API and HandleUserInput().

I'm hoping to take a look and see what's possible. Send me a PR if you want to discuss this in detail.

[cesarbl]

Hi Chris,
I'm waiting before uploading the changes because I'm basing them on the cruise control branch, as CC creates a variety of new controls that would otherwise conflict with my changes.

Quote

I am hoping that we can re-factor the code just a bit and pull some common code out of CabViewDiscreteRenderer.HandleUserInput() which can then be called by both the new API and HandleUserInput().

Yes, my idea was to reuse it as much as possible to avoid duplications. Almost all the controls work with the HandleUserInput(), except precisely some of the cruise control levers. I also reused parts of the RailDriver code.

Another thing that might need discussion is the protocol. I'm currently using HTTP POST requests, and sending data in JSON format, which is not really fast. From my tests speed seems OK, but somewhere in the forum it was suggested to use WebSockets instead. Maybe both protocols can be implemented in the future, but I think that if speed is an issue then serializing and deserializing JSON every 50ms is not the best idea, so for WebSockets another protocol would be needed. I think we can stick to HTTP POST at the moment, which can be easily implemented using Python scripts.

[cjakeman]

cesarbl, on 07 November 2022 - 12:44 PM, said:

I think we can stick to HTTP POST at the moment, which can be easily implemented using Python scripts.

I'm starting to look at this now. I've no objection to using WebSockets if speed becomes an issue, but I'm using HTTP POST and JSON for now, as you are.

[Genma Saotome]

I've always thought this was a great idea with huge potential. I don't now recall if the output will just be text or whether there will be some structure (f4 and f9 come to mind)? Is .css plausible?

[Bill]

After developing my own interface using the Raildriver interface as a starting point, the less data transmitted, the better. I sent my data in the Raildriver format with the embedded control data, using the Windows Messaging process between programs. But a Web Socket would be best.

The only behavioral change I made with my interface in OpenRails was to remove the automatic reset of the Alerter when a packet comes in. Not every control change resets the alerter. For example, moving the Camera should not reset the Alerter. What I did instead was to set the Alerter bit in the packet if I wanted the Alerter reset with the control change. Since we are talking about people developing external code, I don't see this as a problem for them to include the Alerter reset with the control change packet.

Attached thumbnail(s)

• 

[joe_star]

Am currently using webserver read to get the state of regulator, cutoff and brake, and matching that to a 3-axis saitek flight throttle quadrant. An autohotkey script takes the quadrant axis values, and by sending keystrokes attempts to match the throttle, regulator and brake values in OR. It works quite well, although a direct input method would be much more responsive and accurate

[cjakeman]

cesarbl, on 07 November 2022 - 12:44 PM, said:

Yes, my idea was to reuse it as much as possible to avoid duplications. Almost all the controls work with the HandleUserInput(), except precisely some of the cruise control levers. I also reused parts of the RailDriver code.

I've been playing with your new PR Web interface to control cab controls with external hardware and it seems to be working very well.

I've added some slider controls to a copy of the webpage Content/Web/CabControls/index.html so it can post changes to your new API and I was able to drive a train using the sliders, which greatly pleases me.

I shall submit a PR for this in a few days when I've polished it.

[cjakeman]

cjakeman, on 27 November 2022 - 02:10 PM, said:

I shall submit a PR for this in a few days when I've polished it.

The new PR is at "Extends CabControls for user input" and requires Cesar's PR 751 to be in place first, otherwise the sliders do nothing.

[cesarbl]

It seems cab controls are a critical part of the code regarding merge conflicts. I tagged my PR 'not for unstable' because it depends on 'Unlimited TCS Controls' which itself conflicts with 'Extended door functionality'. The conflicts are easy to solve by hand, but they are too much for the Code Bot.