Notifications
Clear all
Project Corner
229
Posts
9
Users
12
Reactions
3,641
Views
Topic starter
2024-08-08 4:51 am
"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.
I think I may have come up with a solution that uses a mechanical switch rather than sensors.
I'll reply to a few other peoples' posts then write a post at the end outlining my idea.
Cheers.
Ian Millard
Port Macquarie, NSW, Australia
ESP32/Arduino etc novice
Topic starter
2024-08-08 5:08 am
Hi Dave, @davee
Thanks for your very comprehensive replies. It's certainly making me think more about how the system will work.
See my replies to certain parts of your post.
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:
- 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.
- 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.
1. I don't think loss of status on power down will be an issue. I can envisage at the beginning of a running session on the layout, I would ensure that all staffs are in place in their respective machines ready to go.
2. I think I may have come up with a solution that uses a mechanical switch rather than the IR sensor, so I'm hoping this will alleviate any issues there. See my following post where I describe my idea.
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.)
See reply above to your point 1.
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'.
Again, hopefully this won't be an issue if my mechanical switch idea works.
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 totally agree about re-creating the 'real thing', however, as I've mentioned previously, the real staff system is very complex and I just wanted to re-create it in the most simplest form to provide a bit more realism to running trains.
Cheers,
Ian
Ian Millard
Port Macquarie, NSW, Australia
ESP32/Arduino etc novice
Topic starter
2024-08-08 5:28 am
See my replies to your post below.
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.
You are absolutely correct here. I may have another solution that will use a mechanical switch. See my post below.
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.
Totally agree. I don't want to over complicate things.
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 tumbler only needs to be locked once a staff has been removed from a machine, to prevent another staff being removed for the same section. When all staffs have been returned, the system is known to be 'balanced', therefore the tumbler remains unlocked ready for a staff removal when required.
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.
Yes, there is a 'detent' (for want of a better term) that keeps the tumbler always at a 90 degree position, ready to accept a staff for removal or insertion.
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.
As mentioned above, once a staff is out of a machine, the tumbler is locked. Remember that a removed staff is not just reinserted into the same machine. It is returned to it's 'mate' at the other end of the section.
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.
I'm not quite sure what you mean here. If you mean once a train has reached either staging yard, what happens, well that will be just part of how the layout operates.
Say if you are travelling from Up staging through to Down staging via the four stations shown. Along that journey you will 'exchange' staffs a total of four times. Once you reach the last machine at Down staging, the staff is returned then a sequence just starts all over again, either in the same direction or the opposite.
I hope that makes sense.
Cheers,
Ian
Ian Millard
Port Macquarie, NSW, Australia
ESP32/Arduino etc novice
Topic starter
2024-08-08 5:31 am
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
Hi Bill @wild_bill,
The staff system only allows one train to be in a section at any one time, either in the same direction or opposite.
It also operates totally independent of the trains, just like the real version.
Cheers,
Ian
Ian Millard
Port Macquarie, NSW, Australia
ESP32/Arduino etc novice
Topic starter
2024-08-08 5:47 am
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.
Hi @robotbuilder,
The layout does not use PC control. I don't believe I need a central controller as each pair of staff machines have nothing to with the others. That is why I envisaged a small ESP32 at each machine with enough outputs to drive the two servos.
After reading everyone's posts today, and I think in particular one of yours, I got to thinking, do I really need a sensor to detect the staff. So I did some Googling and found a small spring loaded actuator switch with a MOM-OFF-MOM arrangement. Referring to the images below, I think if I place the switch where the horizontal movement of the staff will make contact with the actuator, it should solve the issue.
The switch has a centre off position, with movement available both sides and spring return to the centre.
Now, I'm presuming this switch, when connected to an ESP32 input, only needs to receive a momentary 'CLOSED' pulse to be used in any programming. Please correct me if I'm wrong.
The switch should allow bi-directional detection of the staff.
And just to confirm again, I'm not really concerned about objects other than staffs being inserted to potentially trigger the switch.
Cheers,
Ian
Ian Millard
Port Macquarie, NSW, Australia
ESP32/Arduino etc novice
2024-08-08 1:11 pm
Hi Ian @imillard,
re: Again, hopefully this won't be an issue if my mechanical switch idea works.
Sorry, I am not clear what signals your proposed switch will send to the controller.
If the switch sends a pulse to GPIO Port "A" when the staff moved (right to left) into the 'parking' slot, and a pulse to GPIO Port "B" when staff moved (left to right), out of the 'parking 'slot', (plus at power up, the state is always the same, as you discuss above), then it should be resolvable. (Obviously, Ports A and B refer to any two suitable, available GPIO pins.)
By contrast, I think you will find it more difficult to make a 'reliable' system, if the controller cannot distinguish if a pulse is due to the staff moving into the 'parking slot' from one moving out of the 'parking' slot, as this will be replicating the problem with the previously described LED and photodiode system.
--------------
However, from programming and usage of the final system viewpoints, life might be easier if you directly sense, whether or not the staff is in the 'parking slot', albeit it probably requires a bit of redesign of the 'housing structure' to mount a sensor in this position. The sensor can be virtually any one of your choice, including LED + photosensor, switch/microswitch, etc.
I am not clear about the physical size of the staff, but if it is large enough to attach a small magnet, then either Hall Effect or reed switch might be considered to detect its presence, albeit you would need to do some prototyping to determine the detection range, before committing to the approach and mechanical design, to find both the magnet 'always detected' and 'never detected' distances.
If you are changing the plastic structure, you might even build your own switch from springy metal, which would be deflected by the staff locking into the slot.
Just some suggestions to consider.
Good luck and best wishes, Dave.
2024-08-08 2:58 pm
Do you have a link to the website for the MOM switch?
It would be helpful for future reference and inspiration.
2024-08-08 9:26 pm
Actually I was thinking of a simple toggle switch. Turns on when you remove a wand and turns off when you insert a wand. A toggle switch "remembers" its last state. The on/off state depends how it is wired. It could be wired to lock and unlock both devices with a bit of logic wiring no microprocessor required.
There is the issue of wear on the wand (plastic?).
By the way I mean a three pin toggle switch.
Actually giving it more thought the toggle switch would be in one position on the first machine and the other position on the other machine. Maybe a relay would be required and a MOM switch. I will figure out the wiring.
2024-08-08 10:49 pm
Preface:
I've gone through the DBWS ESP-NOW example to confirm ESP-NOW is suitable for the simulation. I have enough information to do a preliminary sketch however I'm not completely clear about the process. I'm not trying to "solve" a problem that has been solved, I'm trying to understand how it behaves. This is a working system. So it's a case of me not understanding something or assuming something.
The criteria I'm using for the METS simulation:
It is a bi-directional system used on single lines to ensure that only one train at a time can occupy a section of track.
Prior to a train entering a section, the signalman sends a bell code to the other signal box to confirm he is ready to remove a staff. If so, a staff is then withdrawn from the machine ... and handed to the driver of the train.
The possesion of a staff insures that the train may safely proceed into the section ahead knowing that it is the only train on that section.
When the staff is removed, both machines at each end of the section are electrically and mechanically locked to prevent the removal of another staff until the staff is placed into the machine st the section end.
When the train reaches the end of the section, the staff is placed in the staff machine which essentially resets the system. Now a staff is available to be removed from either end of the station.
The following image is adapted from the track layout you provided.
The image shows a single-track section layout from Karkool (1) to Pangela (4). There are trains heading eastbound (T1 and T2) and westbound (T3) into the section. There are 2 Staff machines (M1 and M4) at each end of the section. By following the protocol the trains can safely pass through the track section:
Staff Extraction:
Both M1 and M4 start as locked and agree a staff key is AVAILABLE.
- T1 requests a staff extraction from M1
- M1 signals M4 asking if a staff may be extracted. M4 must agree with the request.
- M1 unlocks
- T1 extracts the staff from M1.
- M1 locks.
Both M1 and M4 are locked and agree a staff key is INUSE. T1 has the Staff key.
T1 travels eastbound to M4 at Pangela.
Staff Return:
Both M1 and M4 start as locked and agree a staff key is INUSE.
- T1 inserts the Staff key into M4
- M4 detects the staff insertion and unlocks.
- M4 signals M1 that the key has been returned. M1 must acknowledge the signal. This is notification to M1 that extractions are allowed.
- M4 locks
At this point T1 has completed its passage, M1 and M4 are locked and agree a staff key is AVAILABLE, and T2 or T3 can start the protocol. The protocol will work for T2 heading eastbound (like T1) or T3 heading westbound using M4.
We can extend the system by either adding a new section or subdividing a section into one or more subsections. The image below is based upon the track layout provided. It subdivides Staff Section B into two sections: (B and C) and adds two Staff Machines: (2 and 3).
The protocol is identical for all the machines and they communicate in pairs. The the video of the protocol shows what takes place at Ardglen station.
The image differs from the criteria in that it shows the track section from Kankool (1) to Pangela (4) divided into two subsections, Kankool (1) to Ardglen (2) and Ardglen (3) to Pangela (4). What this means is that a section can be safely subdivided so long as each subsection also follows the protocol. (There are other implications of this subdivision but we can get to them later.) We're simulation the machine and want each machine to follow the same protocol so that we can replicate them to easily expand a section and the entire track.
The image has 3 trains (T1, T2, and T3). T1 and T2 are east bound trains, and T3 is west bound. The track section between Kankool and Pangela is a single track that is subdivide into two subsections at Ardglen.
There are 4 Staff machines in the image; two for each section or subsection.
Nota Bene: this matches the video showing the protocol in action. The video is what would happen at the Ardglen station.
If you follow the protocol that I've outlined I think a logjam develops. If you change the protocol so that the return machine (M2 above) doesn't signal that starting machine (M1) of a return, I don't see how M4 can allow M1 to extract a staff. You's need a central hub or something.
From the video, what happens when the signalman inserts the staff into the return machine? When is M1 made aware of this?
I am hoping I can use use a small ESP32 board at each machine to drive the two servos and power whatever detector is suitable. The two ESP32's would then 'talk' to each other via ESP-NOW, so that a staff removal or insertion at one machine, operates all four servos.
I think I can do a preliminary simulation of this using ESP-NOW, a servo, a MOM push button button, some LEDSm, and two ESP32.
The tumbler only needs to be locked once a staff has been removed from a machine, to prevent another staff being removed for the same section. When all staffs have been returned, the system is known to be 'balanced', therefore the tumbler remains unlocked ready for a staff removal when required.
I have a "Snidley Whiplash" scenario about this, but I don't want to bring it up yet. I'd like to get a preliminary simulation running first.
Topic starter
2024-08-08 10:52 pm
Hi Dave @davee,
re: Again, hopefully this won't be an issue if my mechanical switch idea works.
Sorry, I am not clear what signals your proposed switch will send to the controller.
If the switch sends a pulse to GPIO Port "A" when the staff moved (right to left) into the 'parking' slot, and a pulse to GPIO Port "B" when staff moved (left to right), out of the 'parking 'slot', (plus at power up, the state is always the same, as you discuss above), then it should be resolvable. (Obviously, Ports A and B refer to any two suitable, available GPIO pins.)
By contrast, I think you will find it more difficult to make a 'reliable' system, if the controller cannot distinguish if a pulse is due to the staff moving into the 'parking slot' from one moving out of the 'parking' slot, as this will be replicating the problem with the previously described LED and photodiode system.
From what I can gather from the specs on the switch (I have posted a link to the specs PDF below), I should be able to use it to detect the direction of travel of the staff ie left or right, as the switch will close the corresponding contacts, therefore sending the appropriate signal to the controller IO port to drive the servo to either lock (staff movement R to L) or unlock (staff movement L to R).
Does this not sound correct? Or have I totally misunderstood what the ESP32 can do?
https://industrial.panasonic.com/cdbs/www-data/pdf/ATB0000/ATB0000C18.pdf
However, from programming and usage of the final system viewpoints, life might be easier if you directly sense, whether or not the staff is in the 'parking slot', albeit it probably requires a bit of redesign of the 'housing structure' to mount a sensor in this position. The sensor can be virtually any one of your choice, including LED + photosensor, switch/microswitch, etc.
Sensing whether the staff is in the 'parking slot' won't work, because as mentioned earlier, all staffs have the same diameter rings, so you can't have an incorrect staff being sensed if placed in the 'parking slot', especially when returning a staff. The 'unlock' trigger must be done after the staff has moved L to R out of the 'parking slot', just prior to it engaging with the tumbler wheel, which has the corresponding 'slots' to line up with the rings on the staff. Does that make sense?
Referring to the diagram below showing a top view looking down inside the staff machine. The staff is shown in the 'parking slot'. The blue line indicates the centreline of the switch actuator. You can see there is a greater distance from the RH edge of the main staff shaft to the edge of the tumbler wheel compared to a lesser distance from the outside edge of the rings on the staff to the edge of the tumbler wheel. The staff should only activate the switch (moving L to R) once it is proven it's the correct staff by attempting to engage the staff with the tumbler wheel. If the staff is correct, it will continue to move right to engage with the wheel and trigger the switch to unlock the wheel.
I am not clear about the physical size of the staff, but if it is large enough to attach a small magnet, then either Hall Effect or reed switch might be considered to detect its presence, albeit you would need to do some prototyping to determine the detection range, before committing to the approach and mechanical design, to find both the magnet 'always detected' and 'never detected' distances.
The staff is 110mm long and 6mm diameter, with the rings 11mm diameter.
I did look at a magnet inside the staff and a reed switch in the body, but couldn't get it to work successfully.
I'm hoping all that makes sense.
Cheers,
Ian
This post was modified 2 months ago by codecage
Ian Millard
Port Macquarie, NSW, Australia
ESP32/Arduino etc novice
Topic starter
2024-08-08 10:54 pm
Do you have a link to the website for the MOM switch?
It would be helpful for future reference and inspiration.
https://industrial.panasonic.com/cdbs/www-data/pdf/ATB0000/ATB0000C18.pdf
Ian Millard
Port Macquarie, NSW, Australia
ESP32/Arduino etc novice
2024-08-08 11:46 pm
Sorry for all the thought bubbles!!!
The tumbler only has to be prevented from turning clockwise when a rod has been removed. There is no reason to block it turning the other way which is only possible if the correct rod is inserted. There is only ever one correct rod outside the machines. So my suggestion is the lock is a ratchet lock on the tumbler. If a rod is IN the tumbler it can always be turned anticlockwise. One 90 degree anticlock wise turn can turn off the lock.
I suspect the real machines do not use a microprocessor which I see as a solution looking for a problem.
I also suspect turning the tumbler clockwise 90 degrees causes a mechanical drop of some ratchet lever to prevent any more rods being removed. Turning it anticlockwise 90 degrees releases the mechanical ratchet. There would be an electrical switch that turns on when it is turned clockwise 90 degrees to set the ratchets on both machines.
The lock could be implemented by a simple solonoid rather than a complex servo motor.
Topic starter
2024-08-08 11:47 pm
Wow! A very comprehensive post! I think you're understanding what I want to achieve.
See below my observations/corrections/comments.
Preface:
I've gone through the DBWS ESP-NOW example to confirm ESP-NOW is suitable for the simulation. I have enough information to do a preliminary sketch however I'm not completely clear about the process. I'm not trying to "solve" a problem that has been solved, I'm trying to understand how it behaves. This is a working system. So it's a case of me not understanding something or assuming something.
The criteria I'm using for the METS simulation:
It is a bi-directional system used on single lines to ensure that only one train at a time can occupy a section of track.
Prior to a train entering a section, the signalman sends a bell code to the other signal box to confirm he is ready to remove a staff. If so, a staff is then withdrawn from the machine ... and handed to the driver of the train.
The possession of a staff insures that the train may safely proceed into the section ahead knowing that it is the only train on that section.
When the staff is removed, both machines at each end of the section are electrically and mechanically locked to prevent the removal of another staff until the staff is placed into the machine at the section end.
When the train reaches the end of the section, the staff is placed in the staff machine which essentially resets the system. Now a staff is available to be removed from either end of the station.
The following image is adapted from the track layout you provided.
The image shows a single-track section layout from Kankool (1) to Pangela (4). There are trains heading eastbound (T1 and T2) and westbound (T3) into the section. There are 2 Staff machines (M1 and M4) at each end of the section. By following the protocol the trains can safely pass through the track section:
Staff Extraction:
Both M1 and M4 start as locked and agree a staff key is AVAILABLE.
- T1 requests a staff extraction from M1
- M1 signals M4 asking if a staff may be extracted. M4 must agree with the request.
- M1 unlocks
- T1 extracts the staff from M1.
- M1 locks.
Both M1 and M4 are locked and agree a staff key is INUSE. T1 has the Staff key.
T1 travels eastbound to M4 at Pangela.
Firstly, the above scenario would work with just the Kankool to Ardglen section. The system is then replicated for Ardglen to Pangela and Pangela to Staging. Remember, that each pair of staff machines for a section has no interconnection or need to communicate with any other pair of machines.
I like your thinking here. It's very close to how the real system works, However, I don't want this complexity. If a section is unoccupied by a train (readiness to extract a staff), I don't require the replica machines to be locked. That is, a staff is free to be removed from either M1 or M4 depending on which train wants to occupy the section.
I really didn't want to employ the use of the 'bell' key to signal an extraction request. That scenario would work if, in a running session on the layout, I would need all four locations to be manned to be able to accept extraction requests. If I am purely running trains on my own, this will not be possible. I just want to be able to extract a staff for a section, drive the train to the next signal box, insert the staff and take the one for the next section and keep moving.
I realise this is not what the prototype does, but as mentioned before, I want to have the most simplest method. Machines are unlocked normally (section unoccupied), a staff is removed from either end depending on direction of travel, this locks both machines until that staff is returned at the other end.
Staff Return:
Both M1 and M4 start as locked and agree a staff key is INUSE.
- T1 inserts the Staff key into M4
- M4 detects the staff insertion and unlocks.
- M4 signals M1 that the key has been returned. M1 must acknowledge the signal. This is notification to M1 that extractions are allowed.
- M4 locks
At this point T1 has completed its passage, M1 and M4 are locked and agree a staff key is AVAILABLE, and T2 or T3 can start the protocol. The protocol will work for T2 heading eastbound (like T1) or T3 heading westbound using M4.
Yep, this 'return' scenario is correct, apart from "M1 must acknowledge the signal". I don't think this is required. Unless, you are talking about the M1 ESP32 'acknowledging the signal'.
We can extend the system by either adding a new section or subdividing a section into one or more subsections. The image below is based upon the track layout provided. It subdivides Staff Section B into two sections: (B and C) and adds two Staff Machines: (2 and 3).
The protocol is identical for all the machines and they communicate in pairs. The the video of the protocol shows what takes place at Ardglen station.
The image differs from the criteria in that it shows the track section from Kankool (1) to Pangela (4) divided into two subsections, Kankool (1) to Ardglen (2) and Ardglen (3) to Pangela (4). What this means is that a section can be safely subdivided so long as each subsection also follows the protocol. (There are other implications of this subdivision but we can get to them later.) We're simulation the machine and want each machine to follow the same protocol so that we can replicate them to easily expand a section and the entire track.
The image has 3 trains (T1, T2, and T3). T1 and T2 are east bound trains, and T3 is west bound. The track section between Kankool and Pangela is a single track that is subdivide into two subsections at Ardglen.
There are 4 Staff machines in the image; two for each section or subsection.
Nota Bene: this matches the video showing the protocol in action. The video is what would happen at the Ardglen station.
If you follow the protocol that I've outlined I think a logjam develops. If you change the protocol so that the return machine (M2 above) doesn't signal that starting machine (M1) of a return, I don't see how M4 can allow M1 to extract a staff. You's need a central hub or something.
From the video, what happens when the signalman inserts the staff into the return machine? When is M1 made aware of this?
As mentioned above, in your scenario, there is no need to make M4 allow M1 to extract a staff. Remember, that each pair of staff machines for a section has no interconnection or need to communicate with any other pair of machines.
I am hoping I can use use a small ESP32 board at each machine to drive the two servos and power whatever detector is suitable. The two ESP32's would then 'talk' to each other via ESP-NOW, so that a staff removal or insertion at one machine, operates all four servos.
I think I can do a preliminary simulation of this using ESP-NOW, a servo, a MOM push button button, some LEDSm, and two ESP32.
That sounds great. Don't forget that each machine has two servos and a switch to trigger the unlocking and locking. I am envisaging an ESP32 for each machine.
The second servo is to simulate the galvanometer needle on the real thing. This of course does not do the same job in model form. It's purely there to indicate when there is a staff IN or OUT of the machines. This second servo would operate at the same time as the locking servo.
See pics below.
I hope that clarifies things. Looking forward to see a preliminary sketch.
Cheers,
Ian
Ian Millard
Port Macquarie, NSW, Australia
ESP32/Arduino etc novice
Topic starter
2024-08-09 12:01 am
Sorry for all the thought bubbles!!!
Not a problem at all. It has been a great discussion and no doubt many people are learning more about a railway safeworking system!!
The tumbler only has to be prevented from turning clockwise when a rod has been removed. There is no reason to block it turning the other way which is only possible if the correct rod is inserted. There is only ever one correct rod outside the machines. So my suggestion is the lock is a ratchet lock on the tumbler. If a rod is IN the tumbler it can always be turned anticlockwise. One 90 degree anticlock wise turn can turn off the lock.
I suspect the real machines do not use a microprocessor which I see as a solution looking for a problem.
I also suspect turning the tumbler clockwise 90 degrees causes a mechanical drop of some ratchet lever to prevent any more rods being removed. Turning it anticlockwise 90 degrees releases the mechanical ratchet. There would be an electrical switch that turns on when it is turned clockwise 90 degrees to set the ratchets on both machines.
The lock could be implemented by a simple solonoid rather than a complex servo motor.
Yes, the real machines do not use microprocessors, however, as I'm using servos, I needed something to drive the servos, and to keep the system as simple as possible.
There are a few problems with your scenario above.
1. I have limited space inside the head of the model for more mechanical devices. I did have ideas about locking the tumbler with a ratchet and pawl arrangement, but that leads to the second problem.
2. The tumbler must be able to rotate more than 90 degrees in either direction. For example, a staff is withdrawn for a section, turning the tumbler 90 degrees clockwise. The train proceeds through that section and returns the staff at the other end. The next train due in that section is travelling in the same direction, so the tumbler at the 'extraction end' needs to rotate clockwise again another 90 degrees from when the previous staff was removed.
If there are another two trains due in the same direction, there would be another two turns of 90 degrees clockwise required. Make sense?
Cheers,
Ian
Ian Millard
Port Macquarie, NSW, Australia
ESP32/Arduino etc novice
2024-08-09 12:55 am
Hi Ian @imillard,
From the data sheet you provided as a reference, I can see:
I suspect you have already figured out, how to use it, but in case of any doubts, perhaps this will help.
To tell whether the staff is moving from "left to right", or "right to left", then this switch should be successful if:
- Start with two GPIO pins, each pulled "High" with its own resistor (say 10kOhm) to ESP32 3.3V rail.
- Connect the first GPIO pin to Switch pin 1, and the Second GPIO pin to Switch Pin 2
- Connect Switch Pin C (common) to ESP32 0V (Gnd)
Then,
- When the switch is in the middle 'not pushed' position, both GPIO input pins should be held 'high'
- When the switch is pushed to the left (b in the diagram), the switch contact 2 should connect to switch contact C, connecting the switch contact 2 to 0V (Gnd) and hence the Second GPIO pin input will become low
- When the switch is pushed to the right (a in the diagram), the switch contact 1 should connect to switch contact C, connecting the switch contact 1 to to 0V (Gnd) and hence the First GPIO pin input will become low
Hence, you will need software to detect these 'go low' pulses. Note that switches often give multiple contact operations on a single mechanical operation, due to 'contact 'bounce'.
However, in your situation, you should probably arrange the software so that it only 'looks' at one of the GPIO inputs, and hence one of the contacts will be 'watched' at any one time.
When a 'go low' is first detected on the 'watched' contact, then this should be acted upon ,as the staff 'status' has just changed, so that the 'watch' action must be changed to the other contact.
This way you should only get a signal when the staff is entered or removed, and be able to know whether it is an 'entry' or 'removal', depending on which GPIO pin saw the 'go-low' event.
-------------------
As for "Sensing whether the staff is in the 'parking slot' won't work", then I confess to struggling as to what the various mechanical interlocks will 'allow'.
I was simplistically looking at the picture (without understanding the rest of the machine):
I was assuming that the staff could only mechanically pass from right to left, (incidentally clicking the switch lever), if it was the 'right' type of staff (ie not one from another location), AND the protected resource (section of track) had not already been allocated by another staff (at either end of the track).
However, if it is physically possible to insert a staff so that it moves into the left side of this slot, when either it is the wrong type of staff, or when another staff, presumably at the opposite end of the same protected piece of track is already in position, then sorry, but I haven't spent enough effort trying to understand the mechanism, so that chunk of my previous message will be irrelevant.
-----------
I hope that helps, at least a little, to clarify my suggestions, with apologies for any confusion I may have added.
Best wishes, Dave