Hi!
I'm working to an personal project for automatic gate. For this i use two actuators that have Hall sensor to count number of rotations. To control direction i use an pair of relays.
My problem is that after few cycles open/close became visible that gates don't come back at initial positions.
In loop function only check for remote control command, nothing more. So when gate are in move, there is nothing to disturb the loop function.
To count number of rotations and control position i use signal from a Hall sensor. For this i implemented PIN CHANGE INTRERRUPT for two pins (A0 and A1). Into ISR routine is incremented or decremented counter value for each motor depending on the direction of rotation. Still here is decide when to stop the motors when the upper or lower limit is reached.
Some clarifications:
_cM1, _cM2 are counters for motors. They control positions.
mc is instance of an class witch control motors (forward, revers, stop). Basically here are manipulated 4 bits in PORTB register to control 4 relays ( two for each motor).
_limitM1, _limitM2 are maximum value for counter. Control max extended position for each actuator.
I know that is a little more for an ISR routine but i don't think that here is the problem. Anyway, hall sensors give me very fast pulses. When i make an simple test using Serial.print i see approximately 500 counts/s.
I want to say that both motors are identical.
So where is the problem?
Do you know if your code is reliably counting revolutions?
I would greatly simplify the ISR code if that was my project - perhaps down to the point where it just increments (or decrements) the count variable and sets a flag to say there is a new value.
Then I would do the rest of the computation in the main code whenever the flag shows there is new data.
It would also allow you to print the count as it happens for debugging purposes.
How many sensor pulses do you get per revolution?
I am doing something a bit similar to read the speed and count revolutions of a small DC motor in a model train - but using a reflective optical sensor. I don't need to "measure" direction because I will know that from the code that drives the motor.
But here's my dilemma. Supposing that ISR routine can't capture each pulse from both sensors witch is very probable. But this should not affect the working time of the motors. For example, if the pulses are recorded only 8000 from an real of 10.000, this happens in both directions and finally the motor should return to the same position. Stop command is given only when count number reaches a certain value.
Maybe something i don't understand right.
I suspect another problem but need to check that. Maybe motors don't have same speed in both directions witch will be strange but.... . If is extending a little faster than when is retracting then in extend move are captured less "real" pulses and in retracting movement are captured more pulses witch in effect lead to a closing of the gates earlier than it should.
If this is happens i see two solutions:
dirty solution, simplest but imprecise: add an correction when gate reverse to close position.
simplify ISR routine to only increment counters so can capture each pulse. In this case motor speed will not affect anymore open/close position.
Anyway, solution 2 i don't think that will change so match because still need to check witch pin got the pulse and after that increment right counter.
Maybe an better option is to use external interrupts but here i have another problem. Because i use RCSwitch library to decode signal from remote, one pin is occupied by this task. Maybe an alternative to RCSwitch that work to an regular digital pin. But I do not know such a variant.
But here's my dilemma. Supposing that ISR routine can't capture each pulse from both sensors witch is very probable.
This is very improbable. The reason for using interrupts is to make sure you don't miss any when they are occurring at high speed (hundreds or thousands per second.) If the analog circuitry is OK - no glitches from RFI interference - then the count should be very reliable.
If there are glitches, then there's no reason to say that the number of glitches will be the same going forwards or in reverse. So you can't rely on that.
I make today some test.
First, i use PinChangeInterrupt library to configure an single pin (A0). In handler function i put an simple incremental instruction.
Motor have limit switches so I left to go through the whole interval on both directions.
I found aprox. 20.700 pulses for about 58s of working time. I got same value with small variations (few counts) because switches don't close at exact same moment. Also i got same number of pulses in both directions.
Second test i use my implementation for pin change interrupt witch is an simplification of what is in library. I got same number of pulses in both directions.
Third test: now i use my implementation for pin change interrupt to count pulses for both motors working simultaneously. I obtained same number of pulses like in previously cases.
So, in conclusion, i don't see any difference between using simple incremental in ISR routine and something more complex like increment or decrement two counters with some conditional inside.
Later i will make another test, but this time i will use one external interrupt to see if got some differences.
@Robin2: so i have about 340 pulses/s. I don't know if these correspond to real number of rotation because inside are some gears, but i don't think that is very important at this moment. More important is how many pulses come into one second.
If you want to reliably determine position from a shaft you must use quadrature, simple pulse
generation doesn't cope with change in direction, and specifically goes completely wrong if
the mechanical stop position happens to be on the boundary of a pulse then you get lots of
spurious counts from vibration and so forth.
Quadrature sensors are immune to this if counted properly, since only one signal changes at once
and every transition implies a direction.
@Robin2: is not relevant or me. Practically these counter is like an simple and convenient alternative for using time interval. Also should be better than the use of time because it is independent of the load on each motor.
@TomGeorge: i want to control independently how much each gate it's open.
@MarkT: thanks for suggestion but is hard to implement these sensors because each motor is well assembled. Also i don't know if I open open one of these motor how could such a sensor be mount. Anyway, few counts error should not produce an important effect. I need 340 counts for each second of move, so 5-10 count difference would not be noticeable.
I think that i have an conclusion. Maybe is not an programming problem but more an electric problem.
It's possible that is counted "false" pulses that coming from wrong electric isolation. An complete cycle open-close have about 30.000 pulses. I make some measurements and a little math and i found that on each cycle i have about 25 false pulses which is great considering how looks my assembly.
Next i will try to make some measurements using an oscilloscope to correct electrics problems.
A diagram of your device would certainly help. Are the motors directly moving the gate? How? Are the motors on the gate and moving as well? Is there any vibration of the hall sensor?
@Robin2: using limit switches is not an very good solution because:
hard to have adjustable switches inside an actuator. Maybe little easy on other variants
hard to implement in software. If i give command for open, when i know that motor are stopped? Need to monitor current that pass through each motor. Is complicated.
@Paul_KD7HB schematic is very simple. I need to make an schematic in these days to make an pcb Maybe i will use fritzing. But in something very basic at this stage. Each motor is controlled by an bridge with two relays.
I am tempted to ask WHY? What value is the knowledge of how much a gate is open?
In my own projects I have found that I usually never use the more esoteric features after the first few days.
Yes, u are right. But in my particular case, I need that half a gate to be opened a little more than other half. Sometime, gate is need to be closed in specific order. In this case is better (and simplest ) that half of gate to open a little more than other half. So ... is more to deal with code, but sometimes is necessary.
hard to have adjustable switches inside an actuator. Maybe little easy on other variants
They don't have to be on the actuator, in fact put them on THE GATE.
If one gate needs to close before the other to ensure they close properly, then you use an extra switch on the later closing gate.
As the gate closes, when it gets to the earlier switch if the other gate has not closed then it stops the later gate until the earlier has closed.
An absolute encoder would be ideal for your purposes, but as you say, physically not possible.
Is complicated from practical perspective. Ned to have at least two switches n each gate, make an mechanical system in order to operate, wires ..... If you have a picture of such an implementation, I would like to see.
