Please use the URL supplied under additional information for a proper documentation.
Ingame-Screenshot
Functionality explained
Summary
Whenever an available path in one direction, hits a path request in the other direction the module will attempt to open the door.
To avoid lag and impacting the server on a long and complicated network of doors, it has a built in sequencer, controlled by the feedback of the door. So putting some type of detection/feedback contacts on the door allows controlled serial operation. (Set feedback closed when the door is halfway closed to have always two doors at a time operating. Signal when it is fully cycled to make it “one door moving at any given time” only per possible path.
Wiring the Door
The door is connected via the GPIO 5 (OUT_ACT), a true signal should open the door, while false closes it. In case you do not want to use the feedback signals (GPIO 4 and 6) set them to true (by default), and the logic will ignore them.
Above example contains a the wiring from the demo
Automatic Mode (GPIO 1)
In this mode is operates as described in summary, doors open and close sequential.
Manual Open (GPIO 3)
This input overrides the automatic open, and can optionally open the door even if no automatic reason is there. This can be used by a rail-vehicle to open the door it approaches without disturbing any other setting or special requirement to emulate an available path request.
Lock the Door (GPIO 2)
In this mode the door closes, regardless of manual or automatic settings.
Also the path will be immediately invalidated. This can be used to link an alert or emergency closing without needing to adjust another input.
Pathing Signals (optional)
As we use traffic lights to display available paths and docks in our base, the modules optionally transmit different signals along the line.
Those are located in signals 3-6 in every front and back port of the bus.
3. (PC_??) path closed / red light
4. (PO_??) path open / green light
5. (PP_??) path to public dock
6. (PF_??) path to faction dock
Example picture:
Purple references a “Public Dock”, and Blue shows there is a “Faction Dock” available.
Yellow is a result of “NOT closed AND (Public OR Faction) AND NOT Open”.
However their use is optional and the three bits (PO, PP, PF) can be used for any purpose, they are not delayed or altered in any way by the module. They are passed or not, and this is signaled by “Path closed”.
Simple operation
In the most reduced setup you only wire
GPIO 4-6,
Bit 1 (RP) and
Bit 2 (PA)
on the front and back slots.
Manually set GPIO 1 (EN_A) to True, and GPIO 2 + 3 to FALSE.
You may even skip the Bit 2 (PA) and set it manually TRUE on all exit points, so only Bit 1 (RP) is needed for the operation.
Schematic/Picture
Size
7 length, 5 width, 3 height
Type
Rail Docked wireless module for automatic pathing control and operating a door.
Ingame-Documentation
IO-Definitions
Port Naming
top left: output red ??_OR
top right: input red ??_IR
bottom left: Output green ??_OG
bottom right: input green ??_IG
Signals
simplified overview about signal routing
Sending path available
Case 1) Door automatic OR Open
An available path is passed through all door controllers that are either manually open, or set to automatic operation.
Case 2) Door manual OR locked
In case the path is blocked by a setting on the local GPIO, like a lockdown or the module is in manual mode, and the door is not open, it won't be passed through.
Requesting a path
Case 1) Door automatic OR Open
Request path will be passed through once the door is opened. (Sequential opening on a line of doors)
Case 2) Door manual OR locked
Request path will be repelled in the line and notify a clear “blocked” situation whenever the local settings make the controller to be either closed manually or being locked from operation in some way.
Practical use cases
Reference on how pathing negotiation is done
Straight path
Description:
Y-Type intersection
Description:
This type of wiring may require customization to handle full functionality, as a path request from door 1 may be filled by door 2 but rejected by door 3, resulting in an open path and a rejection message. However, requesting a path along a line down a path-available line should ignore any feedbacks and repels.
3-Way intersection
Description:
This type of wiring may require customization to handle full functionality, as a path request from door 1 may be filled by door 2 but rejected by door 3, resulting in an open path and a rejection message. However, requesting a path along a line down a path-available line should ignore any feedbacks and repels. However, keep this in mind when reading the RP-feedbacks to process them with some type of “try path 1” then “try path 2” options, to possibly read the “PA” feedback before sending the request at all.
Ingame-Screenshot
Functionality explained
Summary
Whenever an available path in one direction, hits a path request in the other direction the module will attempt to open the door.
To avoid lag and impacting the server on a long and complicated network of doors, it has a built in sequencer, controlled by the feedback of the door. So putting some type of detection/feedback contacts on the door allows controlled serial operation. (Set feedback closed when the door is halfway closed to have always two doors at a time operating. Signal when it is fully cycled to make it “one door moving at any given time” only per possible path.
Wiring the Door
The door is connected via the GPIO 5 (OUT_ACT), a true signal should open the door, while false closes it. In case you do not want to use the feedback signals (GPIO 4 and 6) set them to true (by default), and the logic will ignore them.
Above example contains a the wiring from the demo
Automatic Mode (GPIO 1)
In this mode is operates as described in summary, doors open and close sequential.
Manual Open (GPIO 3)
This input overrides the automatic open, and can optionally open the door even if no automatic reason is there. This can be used by a rail-vehicle to open the door it approaches without disturbing any other setting or special requirement to emulate an available path request.
Lock the Door (GPIO 2)
In this mode the door closes, regardless of manual or automatic settings.
Also the path will be immediately invalidated. This can be used to link an alert or emergency closing without needing to adjust another input.
Pathing Signals (optional)
As we use traffic lights to display available paths and docks in our base, the modules optionally transmit different signals along the line.
Those are located in signals 3-6 in every front and back port of the bus.
3. (PC_??) path closed / red light
4. (PO_??) path open / green light
5. (PP_??) path to public dock
6. (PF_??) path to faction dock
Example picture:
Purple references a “Public Dock”, and Blue shows there is a “Faction Dock” available.
Yellow is a result of “NOT closed AND (Public OR Faction) AND NOT Open”.
However their use is optional and the three bits (PO, PP, PF) can be used for any purpose, they are not delayed or altered in any way by the module. They are passed or not, and this is signaled by “Path closed”.
Simple operation
In the most reduced setup you only wire
GPIO 4-6,
Bit 1 (RP) and
Bit 2 (PA)
on the front and back slots.
Manually set GPIO 1 (EN_A) to True, and GPIO 2 + 3 to FALSE.
You may even skip the Bit 2 (PA) and set it manually TRUE on all exit points, so only Bit 1 (RP) is needed for the operation.
Schematic/Picture
Size
7 length, 5 width, 3 height
Type
Rail Docked wireless module for automatic pathing control and operating a door.
Ingame-Documentation
IO-Definitions
Port Naming
top left: output red ??_OR
top right: input red ??_IR
bottom left: Output green ??_OG
bottom right: input green ??_IG
Signals
- PO (path open / green light), PP (path to public dock), PF (path to faction dock)
will get passed through the controller
green IN (??_IG) >> green OUT (??_OG) and
red IN (??_IR) >> red OUT (??_OR)
if
OUT_ACT (Open Door) is TRUE AND
FB_OPEN (Feedback Open) is TRUE
- PC (path closed / red light) is set to TRUE
if
PO is FALSE AND
PP is FALSE AND
PF is FALSE
on the current port.
- OUT_ACT is set to TRUE
if
IN_MOPEN (Manually Open) is TRUE AND
F_LOCK (Force_Lockdown) is FALSE
OR
EN_A (Enable Automatic) is TRUE AND
F_LOCK is FALSE AND
RP_IG (Request path, input port green) is TRUE AND
PA_OR (Path available, output port red) is TRUE
OR
EN_A (Enable Automatic) is TRUE AND
F_LOCK is FALSE AND
RP_IR (Request path, input port red) is TRUE AND
PA_OG (Request available, output port green) is TRUE
- PA_OR and PA_OG will get set true according to input state (PA_IR and PA_IG)
if
EN_A (Enable Automatic) is TRUE AND
F_LOCK is FALSE
OR
OUT_ACT is TRUE
- PA_OR and PA_OG will get set false according to input state (PA_IR and PA_IG)
if
it is set to TRUE by above condition
OR
it is NOT set to TRUE by above condition AND
0,5s have passed AND
OUT_ACT is FALSE AND
FB_CLOSE is TRUE
(verbal: If door is closing, extend path available, until closed to avoid all closing together, delay only 0,5s otherwise)
- RP_OR and RP_OG will get set true according to input state (RP_IR and RP_IG)
if
OUT_ACT is TRUE AND
FB_OPEN is TRUE
- RP_OR and RP_OG will get set false according to input state (RP_IR and RP_IG)
if
FB_CLOSE is TRUE OR
IN_MOPEN (Manually Open) is TRUE
- RP_IR will get passed back to RP_OG
if
F_LOCK is TRUE
OR
EN_A is FALSE AND
OUT_ACT is FALSE
- RP_IG will get passed back to RP_OR
if
F_LOCK is TRUE
OR
EN_A is FALSE AND
OUT_ACT is FALSE
simplified overview about signal routing
Sending path available
Case 1) Door automatic OR Open
An available path is passed through all door controllers that are either manually open, or set to automatic operation.
Case 2) Door manual OR locked
In case the path is blocked by a setting on the local GPIO, like a lockdown or the module is in manual mode, and the door is not open, it won't be passed through.
Requesting a path
Case 1) Door automatic OR Open
Request path will be passed through once the door is opened. (Sequential opening on a line of doors)
Case 2) Door manual OR locked
Request path will be repelled in the line and notify a clear “blocked” situation whenever the local settings make the controller to be either closed manually or being locked from operation in some way.
Practical use cases
Reference on how pathing negotiation is done
Straight path
Description:
- doors open sequential and close sequential on signal changes
- Door controls and status are transmitted via PA (Path available) and RP (request path)
- PA get signaled even if no door is open, so the requesting logic can see if a path is available before actually cycling the door
Y-Type intersection
Description:
- Door 1 can request a path toward door 2 and 3.
- Door 2 can request a path toward door 1 only
- Door 3 can request a path toward door 1 only
This type of wiring may require customization to handle full functionality, as a path request from door 1 may be filled by door 2 but rejected by door 3, resulting in an open path and a rejection message. However, requesting a path along a line down a path-available line should ignore any feedbacks and repels.
3-Way intersection
Description:
- Door 1 can request a path toward door 2 and 3.
- Door 2 can request a path toward door 1 and 3
- Door 3 can request a path toward door 1 and 2
This type of wiring may require customization to handle full functionality, as a path request from door 1 may be filled by door 2 but rejected by door 3, resulting in an open path and a rejection message. However, requesting a path along a line down a path-available line should ignore any feedbacks and repels. However, keep this in mind when reading the RP-feedbacks to process them with some type of “try path 1” then “try path 2” options, to possibly read the “PA” feedback before sending the request at all.
