Model Train-related Notes Blog -- these are personal notes and musings on the subject of model train control, automation, electronics, or whatever I find interesting. I also have more posts in a blog dedicated to the maintenance of the Randall Museum Model Railroad.

2023-04-05 - Conductor 2: Maps

Category Rtac

Right now we load a single map via the Conductor script. That SVG map is displayed on the remote tablet and also on the automation computer’s main screen.

I want to change this to have different maps displayed in the Conductor Ui2 on the larger screen versus on the tablet’s remote status display. The original map data exchange format over KV Server was designed to allow sending more than one map to the tablet. The original design for RTAC was to have a list of map fragments in the tablet’s horizontal pager. Then users could just swipe to show different maps, each one highlighting one part of the layout. The initial implementation took the shortcut of displaying just one map. Same goes for the Conductor Ui.

I have no immediate desire to support multiple maps, so I’m going to continue ignoring that part of the original design. For now a single map on each device is good enough. What we could use though is different maps per type of device. This can be accomplished by adding a “target type” or similar field to the map info used to load the maps.

Here’s a potential specification:

Conductor 2 DSL:

SvgMap {

    val name: String

    val svg: String

    val displayOn: SvgMapTarget

}

SvgMapTarget enum { Conductor, RTAC }

A map with a “Conductor” target displays only in the conductor software. These are simply not exported via the KV Server.

A map with an “RTAC” target displays only in the RTAC tablet software. These are exported via the KV Server.

Since the field is a basic enum, only one type is supported (i.e. this is not a bitfield). If a specific map is to be used for both kinds, we still need two entries. The map names need not be unique (they are actually purely informational and never used as keys).

Additionally we should have checks ensuring that only one such map can be declared per type when loading the script.

For now I do not plan to change the map format. That means the remote tablet maps still do not handle trailing blocks. That change, if done, is orthogonal and unrelated to this one. Showing trailing blocks on the map is just a debug tool for me, it’s not critical for operators to know the details of the engine. At the contrary, I need to keep it as simple as possible, so no trailing blocks are shown on the tablet.


 Generated on 2024-08-06 by Rig4j 0.1-Exp-e7e2d73