Jump to content
 

Robin2

Members
  • Posts

    1,362
  • Joined

  • Last visited

Everything posted by Robin2

  1. If you Google "YouTube gear hobbing" you will find lots of examples. I'm not sure if either of these is the exact one I watched but from the first few seconds they seem typical https://www.youtube.com/watch?feature=player_detailpage&v=J0o3W4_LRBw https://www.youtube.com/watch?feature=player_detailpage&v=-umcQtrn1CQ ...R
  2. Thanks for the link. It looks good. By the way those are worm gears not planetary gears which would be very much harder to make in such a small space. I saw a YouTube film about simple gear hobbing so I have been wondering if I could cut a plastic (maybe even brass) gear using (say) an M4 or M5 bolt tap as a hob. And then another piece of the same sized bolt could be used as the worm. It wouldn't be high precision engineering but it may be good enough. I also have some gears from some very small servos that I dismantled to use the motors and those gears seem to mesh nicely with small bolts (I've forgotten the exact size). ...R Edit to correct a silly mistake. Hope it hasn't confused anyone. ...R
  3. Could you post a link, please. ...R
  4. Thanks Simon, a few thoughts ... If you write an Excel spreadsheet that can test your locking sequence then it should be a simple matter to have it present the requirements so that copy and paste would put them into the Arduino function. As things stand my code uses 2 pins per lever. One for the "lever" switch and one for the output. I have an LED for the output for demo purposes and I guess that could stay for a working version. If the LED lights it means the lever is ON. I just use one flashing led (pin 13, the onboard led) to indicate all errors. I think in practical use the flashing will start before you get your finger off the switch/lever so it will be obvious which one is wrong. The only way I can think of to reduce pin requirements is to use a PC screen for inputs instead of physical switches. You may be able to use something like a couple of 74HC595 chips to reduce the output pin requirement, but I think that's only an option with coloured light signals. Of course an Arduino Mega has more pins, or cheap breadboard Atmega328s could be used to provide local locking. ...R
  5. I have written an Arduino program to mimic the interlocking in the example in the May 2014 Railway Modeller article. I have put it in its own Thread to facilitate discussion about interlocking. ...R
  6. The question of using an Arduino to manage signal and point interlocking was raised in a few posts (16-20) in this Thread. In the latest (May 2014) edition of Railway Modeller there is an article about interlocking using the Modratec lever frame. I used it as a basis to develop an Arduino program to do the same thing. The full code (for an Uno, and should also work on a Mega) is attached for anyone that is interested. Comments are very welcome. The code for actually testing for approved movements is short. void checkValidMove() { if (numErrors > 0) { return; } // we want to see if this move is allowable numErrors = 0; for (byte n = 1; n <= numLevers; n++) { if (lever[n].leverPosition != lever[n].lastValidPosition) { // only check levers that have moved // test if the OFF requirement is met byte offTest = curOffStatus & lever[n].offReq; // offTest represents all the relevant levers byte errVal = 0; if (offTest != lever[n].offReq) { // do the relevant levers match the requirement? errVal = 1; } // repeat for the ON requirement byte onTest = curOnStatus & lever[n].onReq; if (onTest != lever[n].onReq) { errVal = 1; } numErrors += errVal; } } } One of the problems with using software is that there is nothing physical to prevent a user moving the wrong switch or lever. In my code a wrong move won't have any effect except to cause the onboard LED to blink. Two or more wrong moves cause the LED to blink faster. The function checkValidStartingPosition() exists to allow the user the opportunity to set the levers back to a valid position. I have tried to devise a system that allows the locking requirments to be specified easily. For any lever you need to tell it what other levers must be OFF and what other levers must be ON. The default is to require nothing. As faar as I know the following implements the scheme in the RM article. The values lvr1, lvr2 etc are defined to be unique to each lever. In effect each lever is represented by one bit in a byte. void setLockRequirements() { // set the locking requirements - tedium here is unavoidable lever[1].onReq = lvr3 + lvr4 + lvr8; // lever[1] should only move if 3,4 and 8 are ON lever[3].onReq = lvr4; // lever[3] should only move if 4 is ON lever[3].offReq = lvr1; // and 1 is OFF lever[4].offReq = lvr1 + lvr3; // lever[4] should only move if 1 and 3 are OFF lever[8].offReq = lvr1; // lever[8] should only move if 1 is OFF } My code requires two Arduino pins for each lever - one for the lever switch and one for the output. In the sketch the output just lights an LED to illustrate the workings but it would be relatively easy to modify the code to manage servos for point or semaphore signal movement. In case anyone is confused I have created an array of 9 levers (numbered 0 - 9 ) and I have ignored lever[0] completely so that there is a simple corresondence between the lever index and the physical lever number. Getting interlocking to work is complex enough without continually having to remember that lever[4] really means the 5th lever. I know little or nothing about signal interlocking. I think my code properly matches the RM article but I won't be surprised if someone points out a flaw. ...RInterLock.ino
  7. Nice Picture - looking forward to the movie. I would be inclined to install the tracks so that they align with convenient motor steps. ...R
  8. I'm not sure if this is relevant to your comments but, here goes ... The purpose of the sensor is not only to provide precise alignment but also to enable the software to detect when the turntable is back at the Zero position in the event that the position gets lost. For example when the system is started there is no other way for the software to know whether someone moved the turntable by hand. And once there is a functioning Zero position detector it can also be used to eliminate the need for manual positioning. ...R
  9. I have been delving into the "black box" that is the DCC code detection process and I have written what I hope is a simple Arduino program to illustrate the process. I have put it in the Arduino Thread so as not to confuse things here. http://www.rmweb.co.uk/community/index.php?/topic/82978-arduino-applications-and-programs/page-2&do=findComment&comment=1400617 Its at Reply #33. ...R
  10. Although I have moved on from DCC to battery powered radio control (BPR/C) I have been following the Thread about a DCC controlled turntable because of my interest in the Arduino microcontroller system. I still have a Hornby Elite DCC controller. It seemed to me that the code concerned with getting the data from the DCC system was unnecessarily complex so, just out of curiosity, I started to investigate it further. I downloaded the DCC library from mynabay.com and was disappointed to discover absolutely no documentation apart from a couple of example sketches - one of which has been incorporated in the turntable code. (If there is documentation elsewhere that I have overlooked, I apologize). And I didn't make much headway trying to understand the internals of the library. I then found another DCC decoder library at http://mrrwa.org which was easier to figure out, although also written in a style that may appeal to dyed-in-the-wool C++ programmers. And, like the mynabay code it included some additional functionality that, for me, obscured the basics. I have now written a program that uses the pulse detection technique from the mrrwa library in a way that, I hope, will be easy to follow for anyone that is interested in what goes on inside the "black box". The code simply shows the DCC packets in the Arduino Serial Monitor and it should be a simple matter to extend the code to make use of the packets to control stuff. I have divided the code between 3 files as I think it makes it easier to follow. All the files should go in a directory called ReadDccPackets which is the name of the main Arduino sketch. The Arduino system loads the othe .ino files in alphabetical order which is why the file names begin with A_ and B_. The overall approach of the program is as follows ... The file B_dccDetectBits.ino has the code that detects the data in the DCC signal and it stores the bits into a circular buffer that can be accessed by the code in A_dccGetPacket.ino. The system for detecting bits is actually very simple. In the DCC system a 1 is represented by pulse with a half-wavelength of about 58 microseconds and a 0 is represented by a pulse with a half-wavelength of about 100 microseconds. The code uses an interrupt to identify the rising part of a pulse and then takes a reading of the pin 80 microseconds later. If the pin is still high the pulse is a 0, otherwise it was a 1. The code in A_dccGetPacket.ino draws from the buffer containing the bits and examines them. Each packet comprises a preamble followed by an address byte, some data bytes and a checksum byte. The code saves the packet where it can be accessed by the code in ReadDccPackets.ino. I have actually described the process backwards. In reality the process begins with by the code in ReadDccPackets.ino which starts the continuous process of detecting DCC bits (beginBitDetection()) and calls for a packet to be extracted (getPacket()) and then displayed (showValidPacket()) in the Serial Monitor. If you want to see all of the packets the function getPacket() must be called sufficiently often - but I haven't tested how often. If data is not drawn from the buffer containing the bits it will fill up and then additional bits will be lost until the getPacket() function draws more bits from the buffer to make space for new ones. The physical mechanism (using an opto-isolater) for connecting the DCC signals that is described in the Turntable should be used to connect to Arduino Uno pin 2. I didn't have an opto-isolator so I made a crude breadboard circuit using a diode and a voltage divider. However I didn't have any train motors running which might cause higher voltage pulses and the opto-isolator would be a safer way to isolate the DCC from the Arduino. I am presenting this for the benefit of anyone who might share my curiosity for what underlies the DCC library. Enjoy or ignore as it suits you. ...R ReadDccPackets.ino A_dccGetPacket.ino B_dccDetectBits.ino
  11. A very simple way to do this would be to show the positions on the Serial monitor as you adjust the settings. Make a note of them and put them into the program code. ...R
  12. @estreetcar, may I be permitted to make a few observations on your code. Please feel free to ignore them. These comments are presented as they occurred to me 1. If all of the "int A = 150;" were changed to "const int A = 150;" they will work the same but the compiler won't waste memory on them since they never change. 2. The way the stuff is readied for Accelstepper seems strangely complex, but I don't know enough about the Adafruit_MotorShield yo know if it is unavoidable. 3. "int TrackPos[13]={A,B ..." etc doesn't seem to be used anywhere. Try commenting it out and if that causes no problem you could delete it. 4. The long suite of SWITCH CASE statements is duplicated. They (one copy of them) should be moved to a function that can be called for use by the DCC commands and the POT commands. Duplication on this scale is a recipe for more coffee when you change one and not the other. 5. This is probably my most significant comment. The DCC library is a black box. We have no idea what DCC.loop() does except that it has been told to call BasicAccDecoderPacket_Handler (presumably whenever it gets a new address sent to it). While the only input was from the DCC device putting all the Switch/Case stuff into the ..._Handler was a reasonable approach. Now, however, when you want to use the DCC info as just one source of input I would shorten the ...Handler routine so it also produces a number from 0-12 just the same as your POT. Then your code can take charge of which source you wish to respond to. In other words, things won't move inappropriately just because a DCC command arrives. Just my 2 cents. Organizing it like this should make it easier to figure out how to do the remaining pieces ...R
  13. I don't know enough about the code to give better advice than this. (There is a lot of code !) ...R
  14. @estreetcar, once you can resolve the pot reading into position values (0-12) it should be simple to get the rest of the code to move to the appropriate location. I wouldn't try to use the pot to get the actual degrees - just the number of the position you want to get to. Then, elsewhere, you can have the actual degrees that correspond to each position. That way you can have two separate simple processes. @pixie, if there is a possibility of the turntable going too far and causing damage I would put a limit switch (perhaps a microswitch) at each end of the travel - to be sure to be sure. On the other hand if the only problem is that the turntable will stall the motor and miss steps (it won't harm the motor) I would just have a routine that re-establishes position by moving to the "home" detector. ...R
  15. Using the code tags (the <> icon above the edit window) just makes the code easier to read. You can edit your post, select all the text that represents the code and click the icon. This is an example using your setup function. void setup() { Serial.begin(9600); AFMStop.begin(); // Start the shield //configure pin3 as an input and enable the internal pull-up resistor pinMode(3, INPUT_PULLUP); //configure pin4 as an input and enable the internal pull-up resistor pinMode(4, INPUT_PULLUP); //configure pin5 as an input and enable the internal pull-up resistor pinMode(5, INPUT_PULLUP); //read the sensoron Dig I/O #3 (open collector type) value into a variable int sensorVal = digitalRead(3); //set stepper motor speed and acceleration stepper2.setMaxSpeed(80.0); stepper2.setAcceleration(10.0); // if near reference point move away while (sensorVal == LOW) { sensorVal = digitalRead(3); forwardstep2(); delay(50); Serial.println("Stepper Home"); } // step backrward to sensor index point while (sensorVal == HIGH) { sensorVal = digitalRead(3); backwardstep2(); delay(50); } DCC.SetBasicAccessoryDecoderPacketHandler(BasicAccDecoderPacket_Handler, true); ConfigureDecoder(); DCC.SetupDecoder( 0x00, 0x00, kDCC_INTERRUPT ); } Having said that, I prefer to download long pieces of code and study them in my text editor rather than in the browser so it is helpful to include a copy of the code as a downloadable file. ...R
  16. @estreetcar, it is more usual to put the pinMode(5, INPUT_PULLUP);statements into setup() so they are only called once rather than hundreds or thousands of times per second. (And see what putting the code into code tags - the <> icon - does). @gcodori, stepper motors can easily work with gears. The problem is that any backlash in the gear train will make the alignment less precise. There are various ways to deal with that. ...R
  17. I'm not good on the exact terminology, I call them all functions in my Arduino code. The ones that start with void such as void loop() { } don't return values and if they return a value they must be defined with the type of value they return, for example byte myDemo() { return(65); } ...R
  18. Dave, may I respectfully suggest for the future that you keep the code in loop() to a few lines (3 to 6, perhaps) and move all the content into separate functions to make the code easier to follow. For example void loop() { readButtons(); readSwitches(); setupServos(); moveServos(); } ...R
  19. Very nice, and a great deal more sophisticated than my simple programs. Do you know if the builder has published his code and wiring diagrams? ...R
  20. I had also been thinking of causing an LED to flash to warn of an erroneous movement. You could also have the LED for a locked point flash in a suitable way. I don't know enough about interlocking to suggest how the locking requirements might be recorded. It would be nice if it could be in a table - a bit like the way I have presented the angles for the servos - but it may be too complex for that. Perhaps if someone could describe a reasonably complex locking arrangement for one set of points and signals we would have something to get our teeth into. ...R
  21. Thanks Simon, Yes interlocking (and as complex as you like) should be possible. One idea might be to define meaningful names for each servo such as #define downMain 3 meaning that the servo in the 3 position is for the downMain. Then the code for point 5 could be something like this (assuming it is in the existing for loop) if (n == 5 && servoPos[downMain] == LOW) { do something } ...R
  22. I have written a couple of simple Arduino sketches to control servos using an Arduino Uno. They may be helpful to people you are new to Arduinos. One of the sketches can control 9 servos with 9 toggle switches. The other sketch can control 6 servos with 6 toggle switches an also light 2 LEDs per servo to indicate point setting. I have also prepared a simple wiring diagram. I haven't tested the sketches with all the servos connected but I have no reason to believe they won't work. Please ensure that the servos have their own power supply as the Arduino can't provide enough current for a servo. Let me know if anything isn't clear. ...R TrainServos9.ino TrainServos6WithLeds.ino
  23. Hi Simon, As requested this is an attempt to upload a .ino file It seems to work. Readers should realize that the Arduino IDE expects .ino files to be in a directory with the same name. In other words you need to create a directory called "HelloWorld" and place the attached file "HelloWorld.ino" into it. (By the way I hadn't realized the file type mattered - I would have been lazy and changed it to a .txt file ) ...R HelloWorld.ino
  24. For the purposes of this thread attaching would probably be more useful as it makes it easier for people to download. Its possible to edit existing posts to enclose the code within code tags. ...R
  25. It would be very useful for all concerned if code was enclosed within code tags like this (using the <> icon) void setup() { Serial.begin(9600); Serial.println("Hello World"); } void loop() { } ...R
×
×
  • Create New...