Jump to content
Non-Gold users will see a video pop-up ad on most screens. This is a test. It should not appear on mobiles etc. ×

Ray H

RMweb Gold
  • Posts

  • Joined

  • Last visited


About Ray H

Profile Information

  • Location
    Milton Keynes

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Ray H's Achievements



  1. Can we quote you on that Andy?
  2. Have a look at the start voltage CV3 (I think). Increase the value a fair bit (think the default is 0) and see if that does anything, then slowly lower the value back down until the problem re-appears then increase the value again slowly until the problem goes. We had a loco at our club that was a lumpy runner at low speed. Doing as indicated above all but erased the problem. The good thing is (?) once you know (and record) the first value of any CV you wish to alter you can alter that CV using Programming On the Main - but don't forget to keep a note of any changes. Saves a lot of faffing about using the Programming Track.
  3. Try slightly loosening the screws that hold the motor in place and then manually move the blades, first to one side and then the other and check whether the loco will pass over both ways. That should show if the alignment is slightly adrift and the reason for moving the blades manually is that the SEEP's exert a fair force that can move the body of the point slightly. If you can get it working properly when operating manually, carefully tighten the fixing screws if you can whilst holding the motor tightly to try and prevent it moving again.
  4. I'd suggest the point motor's switch then. SEEPs are notorious for dodgy switches unless their alignment is 100% relative to the tiebar.
  5. Are you switching frog polarity with the point motor, either with its in-built switch or by a switch that is operated by the tie-bar (or the lever controlling the (assumed) point motor?
  6. Simon Thanks once again for the suggestion which, as it's club night, I can discuss with those present.
  7. Simon I'd agree with you if it was a private layout. I'm not so sure with a club layout and what happens if someone forgets the second press of the button? Surely that leaves a potential for unwanted derailments/contact(s) and the like.
  8. Apologies for the poor quality of the attached but I'm hoping that I can use it to demonstrate what I'm attempting to do. At the bottom right of the above image are two carriage sidings. The lower one (like most of the others) has a push button (shown in blue) and an LED (shown in green). The rectangle to their left is the servo operating the point. There could be trains shunting in the Goods Yard (under the control of a separate operator) and there may also be a train approaching platform 1 of the station when we want to move a train out of the carriage siding. As a result we can't do a blanket reset as I believe was suggested earlier. One of our members is dyslexic so we have to take that into account. The only way a train can leave the carriage siding is to pass over two further points, the prior status of which cannot be guaranteed so all three servos will potentially need operating. There also three LEDs associated with the move. The need to illuminate the one in the (bottom) siding is a given. However, once again, the status of the other two LEDs is not guaranteed so one or both may need setting. Issuing a command to illuminate an already illuminated LED costs nothing whereas retaining its status so that it can be checked and a decision then made as to whether it needs illuminating or not has a processing overhead which is why I don't plan to store the status. We don't need the LEDs in the other carriage siding or the platform three track illuminating so they will need to be turned off if they are on (which we may not know). That's one move sorted and in time executed. Imagine then if you will that the next movement in this small area is a move from the other carriage siding. The relevant push button will be depressed and the relevant servo will be operated and the siding's LED will be turned on. However, I don't need the LED in the lower carriage siding illuminated - leaving it be (illuminated) would be confusing - so that needs to be turned off . Hopefully this shows why (for any push button operation) I need to store data that tells me which LEDs need to be on and which need to be off (to avoid confusion). Likewise which points need to be in the reverse and which need to be normal. I know we could add more push buttons to reduce the data storage but why make the system less user friendly just to save some data storage?
  9. Simon Thank you for the suggestion. Unfortunately a blanket "Unset/Reset" wouldn't work as, for example, there may be a train travelling along one route that is controlled from the same control panel that we don't wish to stop whilst there is a train on an adjacent route that we need to change the route of without affecting any other movement. I'm just trying to find a way to reduce the data storage required which I would have thought should also reduce the amount of processing time taken and how quickly the system can be available to respond to the next push button activity. One of the MEGAs would have to hold a 27 records (in four tables with a combined total of 20 fields).
  10. Many thanks for your response Don. One of the Arduinos will have some code to prevent conflicting movements being set but none of the others require that much detail. There will be around 30 push buttons connected to a couple of the Megas. When anyone of them is pressed it will be necessary to set some points normal and some reversed and for some of the LEDs to be illuminated and others not. The Control Panels will be of the mimic style with push buttons and LEDs affixed to the relevant part of the panel's track diagram. Imagine a crossover in the middle of an otherwise pointless length of double track. There will be a servo attached to each point and there will be three push buttons and three LEDs on the diagram. There will be a LED and a push button on each of the two main running lines and a third of each on the crossover track. Pressing the mid crossover push button will cause the two servos to operate, the LED on the crossover track to illuminate and the other two LEDs to be "turned off". Pressing either of the other two push buttons will cause the reverse to happen. That's fairly straight forward. But I need to hold data for each push button's operation. I need to know which point(s) need to be reversed or normalised and likewise for the LEDs turning on and off so I see the need for four data fields in each (push button's) data record. Some of the layout areas are more complicated than this with up to 8 LEDs needing to be turned on or off as the result of a single push button's operation. There won't be as many servos needing to be operated but even there for one bush button there might be five - the plan is to ensure any subsequent trailing points are also set correctly. In order to cater for the above I could use four distinct data tables - servo/points normal, servo/points reverse, LEDs On & LEDs off. Therefore I need to have each record/row capable of having sufficient fields to accommodate the maximum required on any one record. I'd estimate that around 80% of the fields will be "empty". Another idea that I had was to combine all four tables into a single table. Merging all that data and still allowing for the maximum number of fields for each of the four distinct data sets in each record won't save any data storage space. There are a known number of data field item entries required for each record - e.g. an individual (push button) record may need to operate (say) 2 servos normal, 1 reverse, 3 LEDs on and 2 LEDs off, a total of eight fields. Throw in a separator between each group pushes that number up to 11. Other records may require more or less data fields (but I can work out the maximum for any one record and only allow for that. Subject to checking, this arrangement will reduce the data storage required by 15% (or 45% if I could avoid an allocation for section separators). Does that clarify what I'm trying to do? Can you suggest any other way of reducing the data storage area required?
  11. Our club has four control areas on its O gauge layout. One area is a small subset of a second area and the remaining two areas are largely independent of the others. We're planning to use servos to operate the points and have LEDs on the associated control panels with the selection of a route by push button causing a number of LEDs to be illuminated and a number of other LEDs not being illuminated (to avoid confusion over which route has actually been selected). There will be four "tables" for each control area: one table indicating which points will be normalised and another indicating which points will be reversed to set the required route. The other two "tables" will indicate which (control panel) LEDs will be illuminated and which LEDs must not be illuminated. I plan to have a direct correlation between a push button's Arduino input pin and the requisite row in each of the four tables. e.g. If a push button is connected to input pin 20 and the relevant "row" in the tables is row 4, I can set the table index as pin number minus 16 to point at the required table "row" to access the data. Each of the "tables" will have several rows/records containing several fields as in the following example: const int rows = 2; const int columns = 3; int array1[ rows ][ columns ] = { { 1, 2, 3 }, { 4, 5, 6 } }; int array2[ rows ][ columns ] = { 1, 2, 3, 4, 5 }; int array3[ rows ][ columns ] = { { 1, 2 }, { 4 } }; Is there a compact way to set up the tables or will I have to repeat each rows' fields one line at a time for each table? Two of the tables will (ideally) be alphabetic, the other two numeric. Some fields will be empty as will some of the rows if I am to maintain the correlation to speed up the table searching process. Presumably I can omit an empty row in the definition stage. Is it acceptable to separate empty fields using two commas without spaces in between? I can reduce the number of tables by increasing the number of fields in each row and using a separator in a field between the different areas of the table. For example, I could have the first two fields of a record to indicate which LEDs are to, be lit then a separator and then fields with the LEDs to be unlit. The sketch code would re-act to the separator and know that it has to process what follows in a different way. I reckon this could reduce the data storage area by at least 50%. Finally - for now at least - there will be more than 10 push buttons, LEDs and servos. Could I convert a field's content to be the ASCII code for the number it represents? For example, if I need to store 65 as the servo number in a field can I substitute the letter A instead as this would reduce the field sizes. Thanks in advance.
  12. Marcway have their own way of arranging the "wiring" of their points. It relies heavily on the point blade making (electrical) contact with the stock rail as this avoids any need to switch frog polarity. Personally I've always modified the points by adding further cuts in the copper surface so that they don't rely solely on that physical contact. I think I've also bridged some of the cuts Marcway put in and (although I can't swear to it as it's a while since I did one) I also cut what are effectively the closure rails to totally isolate the frog.)
  13. And I'd imagine that after lunch you'd have needed a well earned kip!
  14. Does it do the same when running light engine? The NCE PowerCab will most definitely indicate the current draw as an alternative to the time display. Press the Esc key followed by the number 6 key and then press 1 to get it displayed.
  • Create New...