Keypad control not working

@will I changed this. I will also upload a tx doc with the original overview.

@kobusven95 

In your video example the stepper motor is not actually turning in response to a key input?

I attach a video as well.

Posted by: @kobusven95

@will @robotbuilder

Feeling stupid...

In this code as below - is my logic twisted? a 0 digital read means to me that there is no or very little input on the IRA sensors, (IRA sensor lights OFF) while a > 0 means to me that there is an input (IRA sensor lights ON) from the sensors? However, seems my logic is swapped around? The println output indicate that the input, while the IRA sensors lights are off, seems to be high?

The sensor output value depends the sensor. You'll need to read the specs for the module to see which condition causes HIGH and which causes LOW.

Posted by: @robotbuilder

@kobusven95 

In your video example the stepper motor is not actually turning in response to a key input?

Maybe that's because the turn is too small to detect ? Since the turns are now based on angles (instead of steps) then a turn of 30 is only 30/2048 = 1.46 % of a rotation and may therefore appear unnoticeable.

Ok, I found now that, when I increase the steps, it works. However, it is completely inconsistent. Seems it moves the number of steps that was indicated.

shedSteps[10] = {100,200,400,600,800,1000,1200,1400,1600,1800}

@kobusven95 

Seems it moves the number of steps that was indicated.

Because you are using the absolute positions of the sheds as step values which is what I was going on about earlier. You have to use those absolute positions in the stepPositions array to compute the number of steps and the direction to move from the current position to the desired position.

You called them step positions but they are actually absolute positions not the steps needed to move there.

Posted by: @kobusven95 FYI @robotbuilder

Ok, I found now that, when I increase the steps, it works. However, it is completely inconsistent. Seems it moves the number of steps that was indicated.

shedSteps[10] = {100,200,400,600,800,1000,1200,1400,1600,1800}

That's because it's been told to do that. The code for calculating the new position and rotating to that point has not yet been written. There's sort of a stub with StepMot.step(blah) which turns the motor but not the correct distance (nor direction).

Posted by: @kobusven95 FYI @robotbuilder

@will I changed this. I will also upload a tx doc with the original overview.

TurnTableManage_Keypad_Stepper_InfraRed_LEDs.txt

 

I read the document and it seems to me that he bridge has an identifiable "front" and "back" end so that no turn optimization is possible.

By that mean that if the bridge is currently aligned so as topping to, say 170 degrees (where 0 degrees is NORTH) and we need to turn to NORTH, that we cannot just turn the bridge +10 degrees. That would line the bridge up in the same direction as turning it backwards to NORTH but would not be acceptable because the "front" ion the bridge is pointing the wrong direction (i.e. SOUTH instead of NORTH).

This is probably a stupid question, but I've never worked with trains before so I'm trying to wrap my head around track operation.

@robotbuilder FYI @kobusven95.

Looks good, but I would introduce a few points for discussion, so please take a look and see if any of them seem worthwhile. I like the name rotateTable.

1) declare a global int value position which holds the current absolute stepper rotation in steps, let's call it "currentAngle" to match the value used in your code here.

2) change the name "STEPS_PER_OUT_REV" to stepsPerRevolution to match the name already in the sketch

3) where did 1020 come from ?

if (abs(desiredAngle-currentAngle)>1020){

4) please use stepsPerRevolution/2 instead of the raw number for this test in case we need to change stepsPerRevolution in the future. We don't want to have to waste time looking for "magic numbers" if we can always be right by using the variable containing the value required.

5) I'd prefer to see "void rotateTable( int newShedNo) {" with the argument being the new shed number as selected by the keypad. That'll lock all of the angle<->step counts into this module so we'll only ever have to mess with that here instead of in the main loop somewhere. Let the loop pick the shed and this module generate the proper direction and step count and orients the bridge as requested.

6) I think that this suggests that the current shedSteps array should be changed to absolute step counts so that rotateTable can then just set desiredAngle to shedSteps[newShedNo]. 

7) I'd rather see Direction2 be called something like direction instead. The rationale is that as soon as you see Direction2 you start wondering where is Direction1 and what's the difference between them. 

8) move the declarations for the stepCount and direction variables inside the module because they'll never be used outside of it and don't need to be global.

Please let me know what you think

@will 

@kobusven95

Looks good,

It works as I have the stepper motor to test it with.

I do have to modify it to conform with kobusven95's requirements.

1020 is the half way point like the 180 value when measuring in degrees.

I changed shedSteps[] to shedPos[] so it is not confused with "steps to be taken" to get to the shed position.

Choosing meaningful labels that reflect the use of a variable or function is (as you probably know) called self commenting and makes for more readable code.

Yep needs some cleaning up...

Essentially I see three main modules,
1. num = ReadKeyPad()
2. moveTurnTable(steps)
3. Display()

Although I will have to use the Arduino IDE Monitor for 1. and 3. the internal code of the modules can be modified to use the keypad and LCD display instead.

Posted by: @robotbuilder

@will 

@kobusven95

1020 is the half way point like the 180 value when measuring in degrees.

No, it's not. stepsPerRevolution/2 is half way around and that's currently 1024

I changed shedSteps[] to shedPos[] so it is not confused with "steps to be taken" to get to the shed position.

I'm in the process of changing shedPos to use the angles specified in the document supplied by kobusven95 and will be expressing them as fractions of 360 degrees. These values will need to be multiplied by stepsPerRevolution to turn them not valid absolute step values. That's why I suggested calling rotateTable with the new shed number and converting it to generate the absolute step address inside the module.

Choosing meaningful labels that reflect the use of a variable or function is (as you probably know) called self commenting and makes for more readable code.

Yep needs some cleaning up...

Essentially I see three main modules,
1. num = ReadKeyPad()

Agreed,

2. moveTurnTable(steps)

I'd till prefer to see that as newShedNo instead of steps. Move the step calculation inside the module to keep that future clutter out of the main loop.

3. Display()

Although I will have to use the Arduino IDE Monitor for 1. and 3. the internal code of the modules can be modified to use the keypad and LCD display instead.

I thought all the display stuff was complete (except maybe for the I/R train sensing) ?

@will 

No, it's not. stepsPerRevolution/2 is half way around and that's currently 1024

🙂 ok typo. Will change it. The code just happened to work anyway.

In one online example the positions are set by manually controlling the steppers to move the rails to the exact position required and pressing a button to record the value for that shed.

I'd till prefer to see that as newShedNo instead of steps.

Well the stepper function requires steps not a shed number.  But sure if used within a routine it makes sense to call the routine moveToShed(x);

I thought all the display stuff was complete (except maybe for the I/R train sensing) ?

The display stuff is not implemented in the code I posted nor the command to flash leds and so on ...