Help required for model railway project

@davee

Posted by: @davee

↑

Hi Ian @imillard,

  From the data sheet you provided as a reference, I can see:

-- attachment is not available --

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.

Hi Dave,

Yes, that sounds exactly what I was thinking how it would work.  When you say 'software', I'm presuming you are referring to the coding for the ESP32.

Posted by: @davee

↑

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):

-- attachment is not available --

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.

No worries at all.  I understand how confusing it can be to a non-railway person.

You can still attempt to move an incorrect staff form L to R, but it won't be able to engage with the tumbler unless the rings line up and allow it to fully engage.  Hence if I locate the switch correctly, it won't trigger unless the staff has fully engaged in the tumbler.

And I've just noticed in one of my posts above describing the movement of the 'inserting' staff as being R to L, it should have read L to R.  I can't seem to edit my post to correct that.

Posted by: @davee

↑

I hope that helps, at least a little, to clarify my suggestions, with apologies for any confusion I may have added.

All the responses I've had from everyone have been most helpful.  It's just been a matter of me trying to convey to everyone my requirements.  It looks like @tfmccarthy is on the right track and has apparently started on a coding sketch.

Cheers,

Ian

@imillard 

Ok.  Based on the exchanges so far this is my current suggestion.

I would stick to using sensors in the module you suggested.

And I would monitor the areas I suggested earlier and illustrated again below.

Rx1 monitors the first part of the tumbler and Rx2 monitors the second part of the tumbler.

If the staff moves from Rx1 to Rx2 the tumbler has been turned anti clockwise and if the staff moves from Rx2 to Rx1 it has moved clockwise. If the staff vanishes from the Rx2 sensor without going to the Rx1 sensor than it has been removed to storage and both machines can be locked. If it appears at Rx2 after insertion from outside the machine then the machines can unlock. However if it vanishes from Rx2 but doesn't show up at Rx1 then the machines are locked again as the staff must have been removed again without rotation. If it does show up at Rx1 and then vanishes without showing up at Rx2 then it has been stored and the machines can remain unlocked.

Or something like that.

I can work out the electronics and coding if you want unless someone comes up with it first or you decide on the mechanical solution.

The mod would only require cutting or fileing out some plastic to fit the tx LED and the Rx1 Diode.

@imillard 

Experimenting with some code it seems that the best place to place sensors is where you anticipated placing them. If the staff moves right into the tumbler the machines unlock. If it moves left out of the tumbler the machines should lock. I have worked out some code that seems to work so when you get your switch or sensors installed ...

Thanks @robotbuilder.

Posted by: @robotbuilder

↑

@imillard 

Experimenting with some code it seems that the best place to place sensors is where you anticipated placing them. If the staff moves right into the tumbler the machines unlock. If it moves left out of the tumbler the machines should lock. I have worked out some code that seems to work so when you get your switch or sensors installed ...

-- attachment is not available --

 

I was about to reply to your previous post when I saw this one.

I was going to give the mechanical switch a try rather than using sensors.  I presume your code will work with the type of switch I mentioned earlier placed in the one location at S2?

I don't see the need for the S1 sensor.  I only have to detect the movement of the staff, L or R, just prior to engaging with the tumbler wheel.  The problem with the S1 position is when a staff is placed into the machine from the front, this will trigger the unlock, which I don't want it to do.  As discussed with @tfmccarthy, sensing within the 'parking slot' as he called it, means that any staff will trigger the unlock, even it's not for that machine.

Make sense?

I would be interested to see your code  and compare it to what @tfmccarthy is apparently working on.

Stay tuned.

Ian

@imillard

I don't see the need for the S1 sensor.

The mechanical switch gives an input for moving left and another input for moving right. The need for s1 is to duplicate this action using sensors. It moves from s1 to s2 (right) or s2 to s1 (left).

After your switch has clicked left the staff is out of the tumbler. After it has clicked right the staff is in the tumbler ready to turn. The two sensors duplicate this information. Your switch has two outputs (left/right) whereas a single sensor does not.

Yes if s2 is on then the staff has engaged with the tumbler and both machines would be unlocked and if at that exact time someone tries to remove a staff from the other machine they would be successful. (This is why I was thinking of putting a sensor at the exit of the storage area.) I don't see how the mechanical switch would be any different? The assumption is that after moving the staff back into the machine it would be moved to storage in one move. If it was pulled out of the tumbler without turning the tumbler and returning the staff to storage the machines would lock again.

Both methods (sensors or MOM switch) require the last action (left/right) to be remembered in code.  A physical toggle switch would remember which way it was pushed by being on or off and the software only duplicates that. 

@imillard 

Wasn't able to source the type of switch you intend using at the local Jaycar but I can simulate it with two push buttons to test code. If that doesn't work well (wear and tear on plastic staff?) and you decide on non mechanical sensors this ZD1901 photo encoder might be a simple solution.

https://www.jaycar.com.au/photo-interrupter/p/ZD1901

You could cut it in two if the staff cannot fit the gap and move them apart.

I will test out the directional code using the encoders and a staff that will fit in the gap.

Status Update: Just a quick note to show current  status.

This feels like the final circuit, but don't put money on that. Resistors are 220K.  I will provide a more detailed description when I finish but the wizard dronebots will recognize much of this and can give folks an idea of what to expect.

Posted by: @robotbuilder

↑

@imillard 

Wasn't able to source the type of switch you intend using at the local Jaycar but I can simulate it with two push buttons to test code. If that doesn't work well (wear and tear on plastic staff?) and you decide on non mechanical sensors this ZD1901 photo encoder might be a simple solution.

https://www.jaycar.com.au/photo-interrupter/p/ZD1901

You could cut it in two if the staff cannot fit the gap and move them apart.

I will test out the directional code using the encoders and a staff that will fit in the gap.

 

Hi @robotbuilder,

Yes, I had looked at that type of sensor myself early on in the project.

As for wear and tear on the plastic staff, I doubt that will be an issue as the switch actuator appears to be plastic as well.

May I ask, are you located in Australia, since you referenced Jaycar?

Cheers,

Ian

Posted by: @tfmccarthy

↑

Status Update: Just a quick note to show current  status.

This feels like the final circuit, but don't put money on that. Resistors are 220K.  I will provide a more detailed description when I finish but the wizard dronebots will recognize much of this and can give folks an idea of what to expect.

-- attachment is not available --
-- attachment is not available --

That looks great @tfmccarthy.

I presume you'll add the switches and servos for the left hand ESP as well to do a complete test simulating the pair of machines?

Cheers,

Ian

@imillard 

May I ask, are you located in Australia, since you referenced Jaycar?

Yes. I live in the mallee country on the Murray River.

Although I assume you want to learn how to use the ESP32 I wondered if you need a lot of controllers maybe a PIC is another option.

https://www.siliconchip.com.au/Shop/9/6906

What I assume is a non functional model train electric train staff instrument.

https://www.modelu3d.co.uk/product/2814/

Closest to finding a circuit details for the actual machines.

https://www.jonroma.net/media/signaling/railway-signaling/1915/Electric%20Train%20Staff%20Installation.pdf

Posted by: @imillard

↑

I presume you'll add the switches and servos for the left hand ESP as well to do a complete test simulating the pair of machines?

That's one way to do the testing and would be a definitive test. And I may do that in the end. Just keep in mind, my workbench (aka my office desktop) has limited resources and there's not much real estate left on the breadboard (or my messy desktop.) One other thing to keep in mind is that flashing the program to the ESP is time consuming. My ESP's use a micro D USB connector and, sadly, I only have one cable. So I need to be frugal about switching cables and flashing the program.

So I had to think about how the testing is done. One criteria of the simulator is that each ESP is running the identical program (with one small, vital exception). There's no concept of "master-slave"; each ESP talks to a clone of itself.

Now, the two ESP's shown are currently talking to each other via ESP-NOW.The left one is running a hybrid version of the DBWS "one way initiator/responder" sketches I wrote called "full-duplex." Its purpose in life is to serve as a stand-in for METS simulator (on the right). It can receive message packets from the METS simulator and send packets to the simulator. Just like the DBWS initiator sketch, the full-duplex sketch sends out a stream of packets and, like the responder sketch, it can receive packets. Similarly, the METS simulator will send out METS packets and receive METS packets. That's what I'm working on now, the METS packets and the response to received METS packets. Doing this minimizes switching the cable and flashing the second ESP. I defer it until later.

Once I have the messaging done I'll flash the ESP on the left and, "By the power of Grayskull" everything should work. It's not necessary to duplicate all the components on the left ESP because they would behave exactly like the ones on the right. Again, there's no concept of "master-slave."

"But," sez you, "how could you be sure?

Ahhh, you overlooked the LED lights, didn't you? Your model don't have no lights. You don't need no stinkin' lights. (I'm fond of movie references.)

But I do. The LEDs represent the track section state; green for AVAILABLE, red for INUSE, and the blue for a train in-transit. For the protocol to work, both ESPs must be in synch on the track section state. If they ever disagree, Casey Jones will meet his maker. That is, after all, the purpose of METS, right? The LEDs on the left are connected to the ESP on the left. Without the LEDs, the hardware replication is probably necessary and very time consuming. With the lights, it isn't and visually verified.

One other test I was planning to do before deciding if I would replicate the hardware is simply swap the ESPs. The ESPs are mated with each other as siblings; they talk to each and no one else. They use identical hardware so I can swap them.

Finally, this is a preliminary simulation, not the final one. You and others will offer modifications and corrections, etc. It's unthinkable that won't happen. You may even reject the whole thing. There are changes to fine tune the setting/parameters or replace a component that will be needed. When I'm finished, it's in your hands. If you want to perform additional testing, you should do so.

Posted by: @robotbuilder

↑

@imillard 

May I ask, are you located in Australia, since you referenced Jaycar?

Yes. I live in the mallee country on the Murray River.

Although I assume you want to learn how to use the ESP32 I wondered if you need a lot of controllers maybe a PIC is another option.

https://www.siliconchip.com.au/Shop/9/6906

What I assume is a non functional model train electric train staff instrument.

https://www.modelu3d.co.uk/product/2814/

Closest to finding a circuit details for the actual machines.

https://www.jonroma.net/media/signaling/railway-signaling/1915/Electric%20Train%20Staff%20Installation.pdf

Thanks @robotbuilder.

The PIC is not required for what I'm doing, as all I need is to be able to control a pair of staff machines, then replicate that for however many pairs I need.

Yes, the Modelu3d item is indeed a non-functional item.

That article on the staff machines is interesting, and I have similar for the NSW stuff.

Cheers,

Ian

Posted by: @tfmccarthy

↑

Posted by: @imillard

↑

I presume you'll add the switches and servos for the left hand ESP as well to do a complete test simulating the pair of machines?

That's one way to do the testing and would be a definitive test. And I may do that in the end. Just keep in mind, my workbench (aka my office desktop) has limited resources and there's not much real estate left on the breadboard (or my messy desktop.) One other thing to keep in mind is that flashing the program to the ESP is time consuming. My ESP's use a micro D USB connector and, sadly, I only have one cable. So I need to be frugal about switching cables and flashing the program.

So I had to think about how the testing is done. One criteria of the simulator is that each ESP is running the identical program (with one small, vital exception). There's no concept of "master-slave"; each ESP talks to a clone of itself.

Now, the two ESP's shown are currently talking to each other via ESP-NOW.The left one is running a hybrid version of the DBWS "one way initiator/responder" sketches I wrote called "full-duplex." Its purpose in life is to serve as a stand-in for METS simulator (on the right). It can receive message packets from the METS simulator and send packets to the simulator. Just like the DBWS initiator sketch, the full-duplex sketch sends out a stream of packets and, like the responder sketch, it can receive packets. Similarly, the METS simulator will send out METS packets and receive METS packets. That's what I'm working on now, the METS packets and the response to received METS packets. Doing this minimizes switching the cable and flashing the second ESP. I defer it until later.

Once I have the messaging done I'll flash the ESP on the left and, "By the power of Grayskull" everything should work. It's not necessary to duplicate all the components on the left ESP because they would behave exactly like the ones on the right. Again, there's no concept of "master-slave."

"But," sez you, "how could you be sure?

Thanks @tfmccarthy.

That all sounds great.  And I definitely don't want to presume to tell you how to do your testing!  It was just my observation. 😀 

Posted by: @tfmccarthy

↑

Ahhh, you overlooked the LED lights, didn't you? Your model don't have no lights. You don't need no stinkin' lights. (I'm fond of movie references.)

But I do. The LEDs represent the track section state; green for AVAILABLE, red for INUSE, and the blue for a train in-transit. For the protocol to work, both ESPs must be in synch on the track section state. If they ever disagree, Casey Jones will meet his maker. That is, after all, the purpose of METS, right? The LEDs on the left are connected to the ESP on the left. Without the LEDs, the hardware replication is probably necessary and very time consuming. With the lights, it isn't and visually verified.

I did notice the LEDs and assumed they were there to aid in testing.  That sounds a logical way of doing it.

Posted by: @tfmccarthy

↑

Finally, this is a preliminary simulation, not the final one. You and others will offer modifications and corrections, etc. It's unthinkable that won't happen. You may even reject the whole thing. There are changes to fine tune the setting/parameters or replace a component that will be needed. When I'm finished, it's in your hands. If you want to perform additional testing, you should do so.

Not a problem.  I am very grateful for what you are doing so far.  I can't wait to see a video of the simulation!

Once you have confirmed you have a working prototype, I would be grateful then to know what ESP's I need to buy.

Cheers,

Ian

@imillard 

Clearly you have the ability to design and 3d print objects as your staff instrument case looks pretty good!

After reading the last @tfmccarthy posts and then going back over the all the posts I realise I will probably be of little help. I imagined a much simpler solution and missed the bit at the start that your main desire was to learn to use two ESP32's to 'talk' to each other via ESP-NOW which is something I have never used. The coding I was working on was simply the logic of detecting the direction of the movement of the staff from two sensors and assumed all the instruments would be controlled from a single controller.

I did find it an interesting problem but was coming from a different direction. Sorry for wasting your time.

@robotbuilder 

After reading the last @tfmccarthy posts and then going back over the all the posts I realise I will probably be of little help.

Do not take counsel from your fears.

We're not past the concept stage here. We're looking at proof of concept. After that there's a ton of work yet to do.

I imagined a much simpler solution...

Simple solutions are the best kind. Present your idea. It may be or develop into a better solution.

...to use two ESP32's to 'talk' to each other via ESP-NOW which is something I have never used.

Sounds like an opportunity.

The coding I was working on was simply the logic of detecting the direction of the movement of the staff from two sensors and assumed all the instruments would be controlled from a single controller.

Well, that's not wrong. That's right. That sensor is a part of the solution; a rather important part, at that. Being able to detect the direction would be a valuable improvement over simple presence detection. It actually might simplify things.