On-site Integration

[peter]

Terry
we have lubricated the lighting tracks and run the train using DC control and the train moves considerably faster as a result
have not tried it on the Pi as were unsure of what you had done and Geoff didnt want to try it

Geoff said he would go in on Tuesday am if he knew you would be there. Can you confirm please?
Peter

[TerryJC]

I will definitely be there on Tuesday morning. I will also be going in on Monday afternoon to re-install the Bells system and will have a quick look at the 'new improved underground railway' if I have time.

I'm intrigued as to what you can use to lubricate the tracks and still maintain the electrical connection?

[TerryJC]

Sitrep3:

This morning I added an extra PSU (12 V) to independently power the IRDOT Sensors, because I realised that the PWM on the rails was being reflected through the power supply and probably affecting the sensor outputs. This seemed to help, but didn't completely cure the false triggering.

This afternoon I changed the code to make it less susceptible to problems caused by noise and managed to eradicate the false triggering. However, I'm now having problems detecting the event in some cases. This is probably fixable by tuning the code a bit; tweak it one way to improve detection and risk false triggers, tweak it the other way to reduce false triggers! It all comes down to how many measurements the Pi makes in a single second. At the moment it's four and the original code was making hundreds every second.

I believe it should be fixable, but I now need some help. I tried fixing the sensors to the side of the track with masking tape, but was missing the train. If the sensors are underneath the track, where they're intended to be, I think that would help because it would only see the train as it passes over and not the sides of the tunnel, etc.

If that doesn't work, then we have to dream up a routine that works and doesn't smash the engine against the buffers at the door end when the sensor is missed. It might be OK if we can slow the train down a little.

I'll be in tomorrow morning about mid-morning and will be available to work on this PM and on Friday.

[TerryJC]

Sitrep4:

This afternoon, Geoff and I worked through most of the remaining problems. We eliminated the false triggering and managed to get all four sensors reacting to a hand pass. Geoff has now fitted all four and the two end ones (Sensor A and D) are detecting the train reliably, which means that if all else fails we can run an end-to-end display as a minimum.

Sensors B and C are currently not reacting to the train (B does occasionally) and Sensor A is too far away from the buffer, so we may have to relocate them to get them to work properly.

Tomorrow morning I intend to run the train repeatedly to identify any remaining problems and tune the speed and delays setup in the software. Tomorrow afternoon, we'll have another go at getting Sensors B and C working and Sensor A correctly located. Once these activities are finished, I'll need to copy the software onto a Read-only SD Card (so the system won't be damaged each time the power is removed at the end of the day). I will then configure the program to run at boot-up and take a copy of the SD Card for the archives.

See you tomorrow!

[TerryJC]

Sitrep5:

This morning's news is mostly good. I managed to get all the sensors working! What I realised was that they had mostly been working all along (apart from Sensor B which was behaving very strangely). What was wrong was that the software was still accelerating or decelerating the train when the sensor was passed. By studying the behaviour over a large number of loops, I was able to get the system to work both when the motor is cold and when it was hot. (There were some instances of the train stopping short of the station, but I think we can fix those.) If the train is run repeatedly, it eventually reaches the optimum stopping places.

So what happens now is that I get through the acceleration phase with plenty of room to spare and then let the train run for more time than is needed to reach the sensor, even when the motor is cold. (Again, there are some occasions when it doesn't quite get to the sensor in time.)

So what is left for this afternoon, (apart from the clearing up), is to move Sensor A a bit closer to the buffers and finish up the fine tuning. I will then configure the program to run at boot-up and take a copy of the SD Card for the archives.

See you later!

By the way. I left the system on and running, so if anyone gets in before me they can press the button to get a single cycle.

[TerryJC]

Sitrep5:

Yesterday afternoon all of the team attended WMT and we managed to complete the tuning of the software and assembly of the layout. The only thing outstanding at close of play was the Read-only version of the SD Card, which I couldn't complete because the pre-prepared SD card that I had taken with me was missing a Python Library Module. Last night I prepared another and tested it here at home (as best I could without the hardware).

Earlier today, before the WMT opened for business, I went in and swapped the SD Card for the Read-only version and the system is now working.

There was one problem while I was there. I was running the system repeatedly to promote warm-up and the train got stuck in the tunnel. I could hear the motor running but the train wasn't moving. At first I thought that a coach had derailed, but after a short while, the train got moving again and I was able to demonstrate it to Greg before I left.

I will spend a little time today archiving the software and producing up-to-date documentation. See viewtopic.php?f=22&t=123&p=1857#p1857 and <Documentation>. (The <Documentation> Sub-Forum is currently being created. I will edit this post when I have created an all-encompassing Design/Installation/User Manual.)

[TerryJC]

The railway team reported false triggering of the Guard Rail Button this morning. I have modified the Guard Rail Button detection code to combat this. See viewtopic.php?f=22&t=123#p1857.

[TerryJC]

I went into WMT this morning ro install the modified software mentioned in my last post. It ran OK, but the train was stopping far too early

I initially suspected noise again, because the problem manifested itself in exactly the same way as last week when we were getting false triggering.

I didn't have my scope with me, so I initially just measured the voltage on the Sensor inputs and got 0 V on all of them all the time I then measured the voltage going into the sensors and got 0 V there too I then completely disconnected the 12 V PSU from the system and confirmed that it was not providing any voltage.

I then measured across the power rails going to the sensors with my Multimeter on Ohms and got a reading of 0 Ohms alternating with about 3 -4 kOhms at a rate of about once per second or so. I was now very confused. Penri then joined me to try to work out what was going on and we again connected the Multimeter across the power rails, this time on Volts and measured +5 V (This is with no voltage connected to the Sensor power rails.) We then removed the Sensor wires (A, B, C and D) one by one and when the last one was removed the voltage across the power rails fell to 0 V. Finally we connected the black terminal of the Multimeter to the system 0 V at the Pi and the red terminal to the yellow wire going to the sensors and got -5 V! (if we connected to the red wire going to the sensors we got +5 V.)

We then assumed that there was a short or wiring cross somewhere in the sensor wiring and tried to find out where, but got lost in the different circuits underneath and gave up (for the time being). Our suggestion is that perhaps Geoff could strip out the current set of wires and rewire all the sensors again, to ensure that they are fully isolated from other elements of the layout. I can come in tomorrow if needed to lend a hand, otherwise could this job be done on Thursday morning and I'll go in on Thursday afternoon to re-instate the sensors.

The good news is that with the sensor circuits completely disconnected the system works on timing only, so it is acceptable, but not as it should be.

[TerryJC]

Sitrep 6:

Penri and I went in this morning and ran a pair of wires from end to end with chocolate block connectors at each Sensor location. We then connected the Sensors to the choc-block. We checked for stray voltages but found nothing. Penri had brought in his Bench Supply, so we connected it to the end of the supply lines and got a current of about 30 mA. So far so good.

We then connected the Sensor signal wires back to the Pi and rechecked the current; still about 30 mA. Finally, we linked the 0 V from the Pi to the 0 V on the Sensors; again, about 30 mA. Finally we linked the Traffic Lights return to the Sensors return; about 30 mA.

We then tried running the train, and everything seemed to work OK (more about that later).

After lunch we did a bit more testing. Penri had noticed the current consumption on his Bench Supply flick up, so we spent some time investigating that. We added a Multimeter in the Sensor supply line set to Amps and measured the current directly. We found the the current did generally increase from 30 mA to about 40 mA when the train went over the sensor, but that was to be expected because the 1 k pull-up on the open-collector outputs would draw around 10 mA when the electronic switch in the sensor went low. However, we also noticed that the current increased significantly more than that (to as much as 150 mA) when the train stopped in the tunnel, but not always! That bears watching, but it shouldn't cause the PSU to fail and we certainly don't have the 0.5 V across the PSU lines when there is no power connected. (We never got to the bottom of that.)

Also, Sensor A seems to have stopped working. It's not the Pi not detecting it, it simply doesn't trigger when the train (or my hand) goes over it. We didn't pursue that because the train stops at the track-break anyway.

We connected a new PSU into the system (hopefully this one will survive) and when we left the system was working fine apart from Sensor A.

Geoff, Could you have a look at what we've done and tidy it up as necessary? We feel that the old wiring should be stripped out and the new wiring loomed in (you might even spot what was wrong when you take the old stuff out )

I can't get in tomorrow, but if you have any queries, Penri will be in for gardening duties.

[TerryJC]

I understand that Penri suggested a 'fall-back' run cycle while at WMT this morning, eg, if the Underground train isn't run for some time, then the software automatically sets it going for a set number of cycles; the object being to keep the engine warm.

From what I've seen, the engine performance drops off quite markedly when the train has been standing for more than about 10 minutes. Once it is cold, it seems to take around four cycles to warm up. If you guys are all in agreement, I would propose that I provide a modified program that sets a timer on start-up and if the Guard Rail Button isn't pressed within (say) 10 minutes, then the train is run automatically for at least (say) four cycles. Once the run cycle is complete (whether triggered automatically or by a button press), then the timer will be reset.

Please respond and tell me:

1. If you want this change?
2. How many minutes to wait after a run cycle is complete?
3. How many run cycles you would like to see over an automatic trigger cycle?

I already have a software solution for this, but I don't want to invest too much time in it until we have a consensus on what we want it to do.