I was making a safecracking puzzle in which you had to rotate a potentiometer until it starts buzzing, at which point you had to press a button to lock the number in. You then had to repeat this action three times until a motor activated, opening a box. I created the entire thing in an emulator (Tinkercad) because I didn't want to buy all the parts only to completely lose all motivation to do it for the next month. My problem is my vibration motor isn't running at full power, instead running at a 1.5V.
How do you mean it is “using” only 1.5V? Do you mean it is only supplied with 1.5v? Schematic and pictures would be required. Also, do yourself and others a favour and name your pins something nice like buttonPin and motorPin etc. Magic numbers are hard to follow
Sorry, posted before adding the schematic. My code is setting pin 11 to high, which I believe should cause the vibration motor to use 5V. However, when set to high it only runs at 1.5V, but when you hit the button to lock the number in it briefly sets to 5V before turning off.
Yes, you are powering everything from the uC so you are likely overloading it. It will be heating up as it tries to push too many pixies through its voltage regulator. Even if this is not your stated problem it is a problem.
I don't think the pin can provide enough power to run the motor, but it can sink more than it can source so you might try hooking the other side of the motor to 5v instead of gnd.
You might be able to parallel some outputs together to get more power but be careful of exceeding the package power dissipation.
I am very interested in your results as I have a project that would benefit from being able to drive these directly.
"It worked before but doesn't work now" is telling me you destroyed that pin's output buffer.
NEVER power a motor directly from an Arduino's output pin. Assuming you're using an Uno, an ATmega328P is only rated for 20 mA output per pin, and realistically you should stay a healthy amount away from that. The vibration motors I found advertised as "low current" are still 9mA - 25 mA (operating at 3V), easily in the danger area for a microcontroller output. Motors also have the inherent danger of "inductive kick" causing voltage spikes when they are turned off, further increasing the damage they can do to a circuit that is not designed to deal with them.
Use the output to trigger another circuit to switch the motor on and off. The easiest power switch to use is an NPN transistor with a base resistor and a flyback diode. You can find tons of examples for how to use a transistor switch for loads that the pins can't handle directly, especially for motors.
Thanks! While I don't believe this is the problem since I was using an emulator, it will still be useful when building it IRL. I'll try this in a simulation to see if it works.
Tinkercad does have some knowledge of overloading, but I don't know how realistic it is. If you (for example) use an led on an IO pin without a resistor, it warns that the current is too high. But the message is more concerned about the led not the Arduino, so not sure how smart the simulator is.
For what it's worth, when I use the vibration motor in Tinkercad, it "measures" the dis-connected resistance at 50 ohms (top right, not sure how it would know that, presumably a built in simulation parameter of the motor?... it does know that wire has no resistance bottom right so components must declare their resistance to the meter somehow?). There would be a start-up current of 5/50 = 100mA and the simulator doesn't seem to worry about that being 5x the pin's safe value, nor does it worry about what it measures as the motor's 50mA running current.
I looked at your code - and gave up because its unreadable.
I'd suggest you start again - and consider
1: using sensible variable and constant names to make your code self-commenting; and
2: using a "state machine" approach with a switch-case structure as explained here
Sorry about my spaghetti code. After some testing, I determined it was defiantly my code that was the problem, since I made a separate simulation of just a motor with an NPN transistor and it worked fine. Just from a quick look at your article and it looks pretty helpful. I'll restart my project using it and get back if it helps. Thanks!
It is an improvement. But the game you're playing with adding up variables to feed the switch statement is very obfuscated and indirect. I suggest unravelling that, the way you're using it, you're better off just using 'if' statements based on measurement ranges and boolean logic.
It looks like your button is a digital device. Read it digitally, don't use analog and convert it to digital unless you have a really good reason.
You can use digitalRead() on A5. Leaving out the dial line for clarity, the below is identical and will work much better in real life:
int button = digitalRead(A5);
if (button == 1) {
button = 1000;
}else{
button = 0;
}
Assuming that S1 is your button, it would be better to wire it between the input pin and ground; to use pinMode INPUT_PULLUP; and to invert the sense of "pressed" so that a reading of logical zero LOW would mean the switch is closed:
int button = digitalRead(A5);
if (button == 0) {
button = 1000;
} else{
button = 0;
}
I'll leave off just wondering about how the values 0 and 1000 derived from the button being presst are used in your code.
And it looks like Tinkercod leaves some things to be desired as a simulation tool. Be very careful IRL, as things are, well, real.
Also, you never use 'digit'. If you do, your switch statement will probably expand to many more lines than it has now - making it all the more confusing. Change your approach now, while it's easy.
as has already been said, you should use a digital read on A5; just because it CAN be an analog input doesnt mean it HAS to be.
Also your "dial" is declared as an integer , then you INTEGER divide by a magic number (102).
A comment would help here!
Ah - its around a tenth of 1024. Shouldnt it be 103?
dial = dial/102; //convert dial value to a single decimal
for me the switch-case can be more readable, and works well for a state machine - but the process for generating the control value needs to be clear.