Help required for model railway project

@imillard

Are you all still with me? 😆

It took a while to figure it out!!

So you come to the start of a section of track. If the track is free (devices at both ends are unlocked) you can withdraw a staff from the device. On removing a staff from the device the devices at both ends of the section are locked. On arrival at the other end of the section you insert the staff into the device and the devices at both ends of the track are unlocked.

It is unclear who inserts and removes the staff (key) in a model railway setup?

https://en.wikipedia.org/wiki/Token_%28railway_signalling%29

Interesting. I think I have a pretty clear idea of the process (a relay race) but I have a few questions to clarify the goal you're shooting for.

There's only one of these in your project, right? You're controlling just one section of track, yes? Otherwise you'll have a room full of Staffs.

How will the HO model interact with the full scale Staff model? Assuming there's only one section being controlled, you'll need 3 ESP32's; one for each staff and a third for the HO model. The conversation between the ESP32s can be simple state ACK-NACK. The HO ESP waits for a state change request and does not generate one. The Staff ESP generates a state change request, i.e., it generates a LOCK request when the state is UNLOCK and generates UNLOCK request when the state is LOCK. Each ESP has a copy of the Staff state and changes it after each state change request when the other two ESPs return an ACK. Each ESP will ACK a request if the current state is the inverse of the request. Otherwise, they NACK the request.

You're simulating the Staff locking device, right? i.e., there are no lock tumblers involved. The Staff keys are unique to a station, but your model isn't verifying them. Anything that breaks the IR signal (i.e., a pencil) would unlock the device and generate the request.
I notice a process difference in the video from @robotBuilder.

There are two Staffs per station endpoint, one to returning a key and one to get a key.
When returning a key on the first Staff, the conductor doesn't need to manipulate anything. He simply inserts the key and drops it in. But to get a key from the second Staff he must tap the telegraph key to unlock the tumblers so he can extract a key.

This is peculiar. First, it would seem those returned keys are unsecured and free for the taking. But why doesn't the "return" Staff require some sort of manipulation? Returning a key means you're at the end of the station, doesn't it? Once returned, trains heading in the opposite direction can get the key and go on the track. I don't understand giving up the key before the end of the section. And it's important that the end of the station Staff records returning the key. And the keys should always be locked.

I want to review Bill's ESP-NOW video to see how it might fit.

Posted by: @robotbuilder

↑

@imillard

Are you all still with me? 😆

It took a while to figure it out!!

So you come to the start of a section of track. If the track is free (devices at both ends are unlocked) you can withdraw a staff from the device. On removing a staff from the device the devices at both ends of the section are locked. On arrival at the other end of the section you insert the staff into the device and the devices at both ends of the track are unlocked.

It is unclear who inserts and removes the staff (key) in a model railway setup?

https://en.wikipedia.org/wiki/Token_%28railway_signalling%29

 

@robotbuilder

Your assumption is correct!

In the model railway setup, the person who has control of the model train does the safeworking with the staffs.  It is purely there to provide realism to the model railway and nothing more.

Posted by: @tfmccarthy

↑

Interesting. I think I have a pretty clear idea of the process (a relay race) but I have a few questions to clarify the goal you're shooting for.

There's only one of these in your project, right? You're controlling just one section of track, yes? Otherwise you'll have a room full of Staffs.

How will the HO model interact with the full scale Staff model? Assuming there's only one section being controlled, you'll need 3 ESP32's; one for each staff and a third for the HO model. The conversation between the ESP32s can be simple state ACK-NACK. The HO ESP waits for a state change request and does not generate one. The Staff ESP generates a state change request, i.e., it generates a LOCK request when the state is UNLOCK and generates UNLOCK request when the state is LOCK. Each ESP has a copy of the Staff state and changes it after each state change request when the other two ESPs return an ACK. Each ESP will ACK a request if the current state is the inverse of the request. Otherwise, they NACK the request.

You're simulating the Staff locking device, right? i.e., there are no lock tumblers involved. The Staff keys are unique to a station, but your model isn't verifying them. Anything that breaks the IR signal (i.e., a pencil) would unlock the device and generate the request.
I notice a process difference in the video from @robotBuilder.

There are two Staffs per station endpoint, one to returning a key and one to get a key.
When returning a key on the first Staff, the conductor doesn't need to manipulate anything. He simply inserts the key and drops it in. But to get a key from the second Staff he must tap the telegraph key to unlock the tumblers so he can extract a key.

This is peculiar. First, it would seem those returned keys are unsecured and free for the taking. But why doesn't the "return" Staff require some sort of manipulation? Returning a key means you're at the end of the station, doesn't it? Once returned, trains heading in the opposite direction can get the key and go on the track. I don't understand giving up the key before the end of the section. And it's important that the end of the station Staff records returning the key. And the keys should always be locked.

I want to review Bill's ESP-NOW video to see how it might fit.

@tfmccarthy

I realise now that I probably left out some information in my initial post.  My apologies.

On my model railway, I have four separate sections of single line track.  See track schematic below.

Each of these sections will have a pair of staff machines, one at each end, connected electrically (via ESP32 hardware).

In each machine, there will probably be room to hold three staffs for that particular section ie, a total of six staffs per section.

Each adjoining staff section is a different type of staff.  As I demonstrated in my video, a staff has four rings on it, and for each different type of staff, these rings are spaced apart slightly differently.  The staff 'drum' inside each machine is made to suit a particular type of staff.  This means that an 'A' type staff cannot be inserted into a 'B' type machine.

What I am trying to achieve here is to add more realism to my model railway than just 'running trains'.  There is no correlation between the staff machines and the physical running of trains.  In other words, I can choose not to use the staff system but can still run trains.

The prototype (real world) staff system is quite complex as to how the machines are locked and unlocked, both mechanically and electrically.  I am only replicating a basic version of this.  All I want is to remove a staff from either end of a section and have both machines for that section lock so another staff cannot be removed until the original one is placed into the machine at the other end.

To answer your final paragraph, once a staff is returned to a machine, it is not just available again.  On the prototype, the signalman at each location must go through a specific process of using the bell key to ascertain that the line is clear.  And, yes, the withdrawal and return of staffs to machines was all recorded by the signalmen.  I will not be replicating that.

As far as the ESP32 controlling goes, once I work out what is required for ONE pair of machines, it can then be just duplicated for as many pairs as I need.

To answer your question about the possibility of just a pencil being inserted into the machine to break the IR beam, I had thought of that.

Where the IR beam will be placed, it will only be triggered as the staff is being engaged with the internal drum.  Theoretically a pencil could probably be used, but it will most likely never happen.  It is not a critical consideration of the model.

I hope I have answered your questions sufficiently and clarified a few things for everyone.

Cheers.

Hi Ian @imillard,

   I am only skimming this discussion, and I find it difficult to completely visualise the mechanical operation from photos, so apologies if I have this completely wrong, but I have a concern.

Is your detection system (IR source and detector) able to continuously sense that the staff is in position, or is it limited to a momentary beam operation interruption whilst being inserted and removed?

If it is able to sense continuously, then please forgive my misinterpretation ... I quietly offer my apologies, and retreat.

However, if the light interruption is momentary, then I am concerned you might have a problem roughly analogous to electrical switch bounce, in which a single insertion or removal appears as more than one interruption to a microcontroller that is potentially able to sense light level changes at the microsecond time scale, and hence confusing the system as to whether the staff is present or absent.

Is this a possibility?

Best wishes, Dave

@imillard

@davee

@tfmccarthy

A google search didn't come up with the actual internal workings of actual staff machines which would have given the solution used in such machines.

In order to remove a staff the tumbler has to rotate clockwise by 90 degrees and detecting that could be used to lock both machines. In order to insert a staff (only one exists outside a machine at any given time) the tumbler has to rotate in an anti clockwise direction by 90 degrees and detecting that could be used to unlock both machines.

Posted by: @davee

↑

Hi Ian @imillard,

   I am only skimming this discussion, and I find it difficult to completely visualise the mechanical operation from photos, so apologies if I have this completely wrong, but I have a concern.

Is your detection system (IR source and detector) able to continuously sense that the staff is in position, or is it limited to a momentary beam operation interruption whilst being inserted and removed?

If it is able to sense continuously, then please forgive my misinterpretation ... I quietly offer my apologies, and retreat.

However, if the light interruption is momentary, then I am concerned you might have a problem roughly analogous to electrical switch bounce, in which a single insertion or removal appears as more than one interruption to a microcontroller that is potentially able to sense light level changes at the microsecond time scale, and hence confusing the system as to whether the staff is present or absent.

Is this a possibility?

Best wishes, Dave

Hi Dave @davee,

Firstly, did you watch the video I linked to in my initial post?  It showed how the staff interacts with the internal wheel/drum.

The detection system will most definitely be a momentary beam interruption, but I was hoping there was some way of coding the microcontroller to only act on the initial break of beam and 'latch' it in some way.

If this is not possible with coding, then I may have to look at some other form of detecting the staff.

I am open to any and all suggestions.

Cheers,

Ian

Posted by: @robotbuilder

↑

@imillard

@davee

@tfmccarthy

A google search didn't come up with the actual internal workings of actual staff machines which would have given the solution used in such machines.

In order to remove a staff the tumbler has to rotate clockwise by 90 degrees and detecting that could be used to lock both machines. In order to insert a staff (only one exists outside a machine at any given time) the tumbler has to rotate in an anti clockwise direction by 90 degrees and detecting that could be used to unlock both machines.

 

Hi @robotbuilder ,

As I have mentioned, the internal workings of a real staff machine are quite complex and would be near impossible to replicate in the scale I have designed the replica machine.

In saying that, perhaps detecting the tumbler is a better idea.  That would possibly work to allow the removal of a staff, however, when it comes to inserting it into the other machine, the tumbler needs to be unlocked when the staff is inserted into the top part of the machine, thus allowing it to be placed into the tumbler, turned 90 degrees anticlockwise and deposit the staff in the slot below the tumbler.

As I mentioned in my reply to Dave above, I am open to any and all suggestions on how I could get all this to work.

Cheers,

Ian

@imillard 

"when it comes to inserting it into the other machine, the tumbler needs to be unlocked"

Yes I hadn't thought that through.

You can easily debounce a switch with hardware or software.  Not sure you even need a microcontroller for your project it could all be hardware.

Maybe two beams instead of one can be used to determine the direction the staff is moving? If it moves right then unlock the machines and if it moves left lock them again.

Hi Ian @imillard,

 I did watch the video, and looked at the photos, but I am naturally cautious, as to whether, I have interpreted them correctly.

However, as you confirm, "The detection system will most definitely be a momentary beam interruption,", it seems my interpretation was correct in this case.

-----------------

In terms of fixing it in software, I suspect you will find there are (at least) two issues, and whilst it is possible to, at least, ameliorate them, whether the result is acceptable is a decision for you. I just thought you might like to think about it, before committing a significant amount of effort. It is entirely plausible and reasonable, that you will consider the result is acceptable.

The issues are:

1. When a microcontroller is powered down, unless it is provided with some form of 'Non-volatile' memory, it usually 'forgets everything', so that on power up, it will not know whether a staff is present or not.
2. When a staff is being inserted or removed, it is likely that there will be more than one interruption, especially if the staff 'sticks' slightly, and the user automatically 'jiggles' it pass that point, in the same way that commonly occurs when operating a key in a lock.

----

Given that this is a model system, so there are no safety risk implications if the 'protection' implied by the system is faulty, then the first issue might be overcome, if the user always sets each staff in the same position at power up, and this initial state is coded within the power up software. (Of course, if there are (say) 4 of these systems in action, then all 4 must be set accordingly, etc.)

Alternatively, you might consider the possibility of using a 'non-volatile memory' approach to record each change of 'staff state', but this is unusual with common microcontroller projects, and may require extra hardware design, and/or unusual software. (I haven't checked to see the implications -- it is certainly feasible, but I am not clear how easy it will be.)

----

An amelioration of the second issue may be encoded into software, by deciding that only one interruption is possible within a period of time, say 5 seconds. Thus, an interruption will cause the software to assume that the staff is changing from its present state of 'present' or 'absent', to the opposite of those two states. As soon as an interruption is detected, it also 'blinds' itself to any further interruptions for a chosen period, of (say) 5 seconds, giving the user up to 5 seconds to complete the single operation.

Note, that I said it was 'roughly analogous' to electrical switch bounce', it is not the same as it depends more on the decisions and timing of the human user, whilst electrical switch bounce is usually dominated by the switch design, so although here are similarities, there are also differences in the solution.

 For the system to stay 'in sync', each interruption which occurs outside of a 'blind' time, must be a successful transition from 'present' to 'absent', or vice-versa. Depending on the exact interlocks, and placement of the detection path, it might be easy to 'fool' the system into acting on an interruption, by attempting to use a staff with different interlocks or an object like a screwdriver blade, or by starting to extract a staff, to the point where it has caused a light interruption, and then reversing, back in to the 'present position, whilst the system is still 'blind'.

------------------------

For me, modelling is usually about attempting to recreate the 'real thing'. These ameliorations seem to detract from the realism, but deciding if that is acceptable is a personal choice.

-------------------------------------------------------------------

I hope this discussion is useful, whichever choice you make.

Best wishes, Dave

@imillard 

I think photo 2 holds the answer to the IR question. The observation is that only a matching staff can be placed in the rightmost position; all other keys will be blocked by the tumblers. The result is that the IR sensor only needs to detect a key in that position. Since this is a physical connection, not an electrical one, the bounce issue isn't in play. In IR sensor time, this isn't momentary.

But this is why I asked my pencil question. You can defeat the mechanism with a rod that has a smaller diameter than a valid staff. What this means is that a second check is would be needed to verify a valid staff. This would check a property that the smaller rod doesn't have.

But this gets "bogged down in the weeds" of the system. This is a simulation of the lock, not Fort Knox. My sense is the simulation doesn't need to go to that level of detail. Simply detecting the insertion of a staff is sufficient. If later on, additional security is needed, the design can be modified to provide the additional check.

This means the IR sensor needs to detect a Staff rod in the rightmost position. The output of the sensor is a Boolean state: TRUE if a Staff is detected; FALSE otherwise. IIRC, and IR sensor detects objects in units of centimeters, so it should be sufficient.

That would possibly work to allow the removal of a staff, however, when it comes to inserting it into the other machine, the tumbler needs to be unlocked when the staff is inserted into the top part of the machine, thus allowing it to be placed into the tumbler, turned 90 degrees anticlockwise and deposit the staff in the slot below the tumbler.

I think the tumbler is always locked. It's unlocked when the IR detects the Staff is inserted. The state is the correct Staff in the matching tumbler. Retract the plunger and unlock the tumbler.

The faceplate controls the direction the inserted Staff can rotate the tumbler. When the Staff is in the top position (return at end station), it rotates counterclockwise. When inserted in the bottom position (extract at station start), it rotates clockwise. It's not clear from the video if there's a ratcheting system in place that controls this but, again, that's "down in the weeds" and can be differed.

What's still not clear to me, and the video doesn't clarify, is the Staff return detection. The video simply identifies it as a "machine for section just left" and it looks like the Staff is simply inserted, with the tumbler unlocked, and it drops down due to gravity. The conductor guides it slightly but there's no effort involved.

Now this is for a subsection of a longer section, similar to the track layout you provided. I don't want to get bogged down in the process here as I think it will emerge as the system evolves, but I do think it's vital that, at least at the last station of a section, the Staff return has to be detected. Otherwise, I don't see how trains at the start of the section can get a Staff to enter the section.

@imillard 

An alternative sensor to the IR sensor just occurred to me. A spring-loaded, button switch controlled by one Staff tumbler disks at the ends of the Staff. When Staff is inserted, the disk is over the switch and depresses the button and closes the circuit. When the Staff is removed, the spring opens the circuit.

You can still "pick the lock" but this isn't the bank vault.

@imillard 

This is just spitballing, could you not, as I think one person suggested they were looking at, use esp now and/or depending on the layout, wires, and a relay to make a pinch mechanism for the rod? My understanding is that a second train can get onto the same track section provided it's going the same way as the first. This is to prevent head on collisions. You might want to look at laser ToF measuring devices hidden in things on track side that would detect a train coming or going to do the triggering or release? I don't know enough about your setup but I know those are small, 25mm incl mounting holes by 15mm, and only requires a small aperture unlike an HR type. mine is a CJVL53LOXV2. The actual "Sensor" is 5mm wide by 3mm high

@imillard 

Does your railway layout have pc control?

Seems a single controller could control the logic of all the devices rather than each needing its own ESP32?

I think with two sensors and a bit of logic you can resolve the problem?

Red discs are position of sensors.

To enlarge image, right click image and choose Open link in new window.