Nothing to do with Arduino, but I like remembering this:
-Steve Jobs
If you'd like to subscribe to this blog, please click here.
So you prototyped your grand design using Arduino and some peripherals and shields you bought online. Everything’s debugged and works. Customers are lined up. Now what? Should you continue to wire together Arduinos, external boards, sensors, etc.? Or should you invest in a Printed Circuit Board (PCB) that ties it all together.
It’s not a simple decision. Hopefully this post can help you sort things out.
The “pro’s” of a fully integrated PCB version are
But like everything, there are negatives. Here are some of the “con’s”
It’s not a simple decision to make on its own. At volumes over 100/year it can start to make sense. Or if you need something in a size and form factor that doesn’t exist off the shelf, then building it yourself is a great alternative. My gut feeling, however, is that for most people, buying off the shelf hardware makes the most sense. Also, if you’re reading this, it’s a fair bet that designing and building electronic hardware isn’t your core competency so it may be bet to leave that up to someone who does it for a living. This gives you the option of having them deal with the problems of manufacturing hardware while you can focus on your application of the hardware.
If you'd like to subscribe to this blog, please click here.
If you’ve been around the Arduino ecosystem for any length of time, you’ve probably heard about stepper motors. We won’t go into the electromechanics of what makes them tick, but we’ll dive into what they are and some of the things you need to bear in mind when using steppers with your Arduino.
Stepper motors are pretty much designed for our digital age. What sets a stepper motor apart from other DC or AC motors is that they are controlled by sending them electrical pulses. Each pulse causes the motor to move a discrete distance known as a step. The motors in common usage typically move 200 steps per revolution. That works out to 1.8 degrees per step. Now, the step size can be changed depending on how the motor pulses are arranged, so it’s common to run these motors in half steps to achieve 0.9 degrees per step.
Stepper motors excel at positioning. Since they can be moved a fixed number of steps without any additional hardware, they make great positioners as long as you stay within the motor’s limits. Where the positioning can fail is when an external load that’s more than the stepper can hold is applied. Motors are rated by their holding or running torque, which is the amount of force at a certain distance from the center of the shaft. Holding torque is the torque that the motor provides at rest. It’s usually much higher than running torque, which is the torque provided as the motor is moving. Running torque typically drops off at higher speeds.
As your program sends steps to the motor, it’s normal to keep track of the number of steps, since that tells you exactly where the motor has moved to. If you apply force that exceeds the motor’s torque, then the shaft will move and the motors position will become unknown. So your software may believe that the motor is at position 1547 and perhaps this means it moved 203mm, but since the load was forcibly moved (perhaps it jammed), the real position may only be 194mm.
Homing
Since the motor’s position can be changed by external forces, it stands to reason that at startup, we don’t know what position it’s in at startup. To figure that out, we need to move to a known, or Home, position. It’s typical to have a sensor at the home position and a “flag” is attached either to the motor shaft or to the axis that drives the load. The home position is usually at the extreme end of motion. This means that although the motor may not know where it is, it will always know that direction Home is in. To home the system, we slowly move the motor in the home direction until the home sensor is activated by the flag. Home is normally the zero position, so we reset our axis position to zero at this point.
Common drive settings
Many manufacturers provide stepper motor drives to the Arduino community. The more sophisticated ones allow you to set the step size (full, half, etc). Some offer current feedback to run the motor at a fixed current. Limit switch inputs are another common feature.
Running faster
Most Arduino motor tutorials tell you to run the motor at the voltage on its end plate. This is fine: it will make sure that the motor will never overheat, but it’s not the way to get the most performance out of the motor.
The primary limit on a stepper motor isn’t the voltage it’s run at, it’s the current allowed. You also need to consider temperature. Most medium size steppers are rated to run up to about 150 degrees F.
The stepper motor speed is directly proportional to the rate at which it receives the step pulses. Now, at a certain point, you’ll notice that the motor isn’t moving faster as your step rate increases. In a nutshell, this is because the voltage can’t get high enough to keep driving the motor faster. We can easily rectify this by increasing the voltage. Now, if we increase the voltage, we will increase the power that the motor dissipates and that increased power makes it hotter. Remember, we don’t want it to get too hot.
There are two main ways around this problem of wanting to apply a high voltage, but keep the power low. As we mentioned above, some motor drives have a feedback setting so they limit the current to the motor, alternately you can place a high power resistor in line with the motor power input and that will limit the current. The higher voltage applied will allow the motor to respond at higher step rates and provide greater running torque.
Microstepping
You may have heard of microstepping, where you can move a stepper a small fraction of a step. Quarter, eighth, or sixteenth or even finer steps are possible. However, it’s important to note that reducing the step size is typically done to achieve a smoother motion. The motor is not usually designed to be accurate at such small step sizes, so an eighth of a step will not necessarily move a consistent distance.
If you'd like to subscribe to this blog, please click here.
Retroreflective sensors are pretty convenient. They consist of an LED emitter that sends a (usually infrared) beam of light and a light sensor integrated in the same package. The LED is aimed at a reflector (hence the retroreflective name) and the reflector bounces the light beam back to the sensor. Do this on a conveyor belt, and every time an object on the belt blocks the beam, it causes a signal change that can be counted. This is more convenient than a through-beam sensor that requires the LED emitter on one side and the sensor on the other. That additional cabling can be a hassle. Using the reflector means that cabling is only needed on one side and that simplifies installation.
One problem with retroreflective sensors is when you need to detect a shiny object. Say you have a production line that packages product in reflective Mylar bags. The count sensor may not be able to distinguish between a reflection from the retroreflector or the bag. This means that a reflection caused by the bag gives exactly the opposite state than you want. The bag is obviously present, but it being reflective means the sensor “thinks” there is nothing in front of it.
A possible solution is to use polarized light. By polarizing the light and using a corner-cube reflector, only changes caused by the light being blocked will be detected, so the shiny Mylar packaging is no longer an issue.
Another approach is to debounce the signal. The bag moving past the sensor causes multiple fast transitions (the problem with counting reflective objects is often that a single object causes too many counts). Debouncing is a technique where the fast, multiple transitions are ignored in favor of a slower change. We have used this technique to assist a customer who needed to count shiny objects moving on a conveyor belt and it made a great improvement in the situation.
If you'd like to subscribe to this blog, please click here.
An optoisolator, a.k.a. optocoupler (opto), is a device that sends a signal from its input to its output using a beam of light. They are typically used when the input and output must be isolated electrically from each other. Generally this is because one of the devices at either end of the opto can’t handle the voltage at the other end. e.g., an input signal of 100 volts that must be detected by an Arduino that can only accept 5 volts. In this case, the opto offers a safer voltage interface than using a voltage divider. Voltage dividers mean that one leg of the input voltage must be connected to the Arduino and this can lead to an unsafe circuit. Using an opto means that the only connection between the input and output is a beam of light inside the opto.
Optocouplers are rated by their isolation voltage. e.g., the isolation voltage for an inexpensive and common 4N26 optocoupler is 5000 volts! This means that the input voltage in the previous paragraph would have to be greater than 5000V before damage would be caused to the Arduino.
A useful application for an optocoupler is in driving an output to a higher voltage than an Arduino can handle. A 4N26 opto can be controlled by a 5V-tolerant Arduino and can switch up to 70 volts. This means that if you want to control e.g., a PLC (Programmable Logic Controller) by sending it a 24V control signal, your Arduino can be used to control the optocoupler which is switching the 24VDC signal. This provides isolation and a higher drive capacity to the Arduino. Some of you may realize that the same thing can be done with a relay. The benefit in this case is that an optocoupler is (a) less expensive than a relay, (b) much smaller than a relay and (c) can be driven directly from the Arduino digital output without additional drivers or inductive protection. The drawback is that only very small signals can be switched, but for the right application it’s perfect.
In short, the optocoupler is a very useful addition to the toolbox of available interface components that can be utilized by the Arduino.
If you'd like to subscribe to this blog, please click here.
A recurring task that comes up in machine control or experimenting with Arduino is turning an output on for a fixed time, then shutting the output off. In electronics, the circuit that does this is called a One-Shot Multivibrator. A multivibrator is a circuit that switches between two states – On (or High) and Off (or Low). A one-shot multivibrator does this once. Its normal state may be off, but when triggered, it switches on for a period of time and then back off.
We use the same name to describe code or an Arduino sketch that performs this one-shot function. Typically there is an input like a pushbutton that is monitored and a digital output that will execute the one-shot function when the pushbutton is active.
A retriggerable one-shot is a version where triggering it again before the time is up causes the time to be extended. So, say the one shot output would be on for 10 seconds, pushing the button in our example three times would result in a total output On time of 30 seconds. A non-retriggerable one-shot ignores the triggering input while the output is active.
Here is code for a basic non-retriggerable one-shot Arduino timer.
// Project sponsor: N/A
// Email: sales@cedarlakeinstruments.com
// Creator: Cedar Lake Instruments LLC
// Date: April 2018
//
// Description:
// Demonstrate one-shot logic with Arduino
//
// Arduino pins
// 2 - Digital trigger input. Pull LOW to trigger one shot
// 3 - Cancel one shot timer (output goes LOW)
// 13 - One shot output (goes HIGH for one shot time)
//
#define TRIGGER 2
#define CANCEL 3
#define OUT 13
// *********************************** U S E R A D J U S T M E N T S **************************
// One shot time in milliseconds
#define DELAY 6000
int _timeout = 0;
void setup()
{
pinMode(TRIGGER, INPUT_PULLUP);
pinMode(CANCEL, INPUT_PULLUP);
pinMode(OUT, OUTPUT);
digitalWrite(OUT, LOW);
}
void loop()
{
// One shot triggers on high->low transition of TRIGGER pin
if ((digitalRead(TRIGGER) == LOW) && (digitalRead(CANCEL) == HIGH))
{
_timeout = DELAY;
digitalWrite(OUT, HIGH);
}
// Hold output High until timeout or cancel pressed
while (_timeout-- > 0 && (digitalRead(CANCEL) == HIGH))
{
delay(1);
}
digitalWrite(OUT, LOW);
// Hold here until inputs inactive
while ((digitalRead(TRIGGER) == HIGH) && (digitalRead(CANCEL) == HIGH));
}If you'd like to subscribe to this blog, please click here.
Any business producing an item needs to count the numbers put into inventory. However, counting items in production can provide far more benefits than just stock quantity. One of the main points of tracking the production of any item you make is knowing how efficient your process is.
To answer these questions, you first need to track how many widgets you make and when you make them.
You don’t need a complicated, expensive MRP (Manufacturing Resource Planning) system to this. More than anything, you need data! Whether that data is collected manually with pencil and paper or electronically, by automated counters is up to you.
One of the simplest methods of automated counters is sensing the product on a belt. Your item passes by a sensor that is an input to the counter and each unit is counted.
Alternately, tally counters can be used to do manual counts. Tally counters can be simple handheld mechanical or electrical counters that have a push button to advance the count. PC versions are also available. An advantage of a PC counter is the ability to easily track the time of day when each item was counted.
If you'd like to subscribe to this blog, please click here.
We recently made a modification for a customer that was such a great idea, I thought I’d post it here. They wanted to use our PRT-232 counter with RS232 serial interface but it was needed to interface to a legacy control software package. The software was originally designed to read data from a different serial measuring device. We modified the output of the PRT-232 to provide the text string the control software wanted to see on its serial port and the integration went smoothly.
It was such a useful concept we decided to offer it to anyone who requests. We will now customize any of the output strings the device generates for a nominal charge. That means that on an input switch transition, or specific level, we can output a string. e.g, input 1 goes active, it can send “Pump On” or if it goes inactive “Pump Off”
Or after counting to a certain value, we can output “Limit Reached” etc. It’s only limited by your imagination!
Of course, the normal behavior of the counter is unchanged: it will still count and report data as normal.
If you'd like to subscribe to this blog, please click here.
The menu example in a previous post can easily be modified to conver the raw A0 analog reading into voltage. Since the Analog Devices AD592 converts temperature into a current proportional to absolute temperature, we can convert this to a voltage using a single resistor. By taking advantage of the Arduino’s 10-bit analog input, we read this voltage and convert to a temperature.
Here’s the updated code:
// Description:
// Simple menuing system for Arduino
// Demonstrates a menu with controls and
// data readback
//
// Communicates with PC at 115,200 bps 8N1
//
#define LED1 2
#define LED2 3
void setup()
{
pinMode(LED1, OUTPUT);
pinMode(LED2, OUTPUT);
Serial.begin(115200);
menu();
}
void loop()
{
int m = readMenu();
switch (m)
{
case 1:
digitalWrite(LED1, HIGH);
break;
case 2:
digitalWrite(LED1, LOW);
break;
case 3:
digitalWrite(LED2, HIGH);
break;
case 4:
digitalWrite(LED2, LOW);
break;
case 5:
{
// VT100 reset cursor to end of menu (row 15, column 1)
char resetCursor[] = {27,'[','1','6',';','1','H',0};
Serial.print(resetCursor);
double temp = analogRead(A0) * 4.9 / 10.0 - 273.1;
Serial.print("Temp: ");
Serial.print(temp);
Serial.println("C");
break;
}
default:
break;
}
}
// Waits in a loop until key is pressed
// then returns digit selected
int readMenu()
{
while (!Serial.available())
{
delay(100);
}
return Serial.read() - 48;
}
// Displays menu
void menu()
{
// Clear
char buf[] = {27,'[','2','J',0};
Serial.print(buf);
// Print menu
Serial.println("\n\n\n\n\n");
Serial.println("1....LED1 on");
Serial.println("2....LED1 off");
Serial.println("3....LED2 on");
Serial.println("4....LED2 off");
Serial.println("5....Read A0");
Serial.println("\n\n Select 1..5");
}
If you'd like to subscribe to this blog, please click here.
Although the Arduinos are great little controllers, sometimes you need to connect them to a PC to transfer data or control. One of the simplest ways of using a PC to control your Arduino is with a menu.
Menus have been used on computers pretty much forever. Back in the 80’s the green screen (green text on a black background) text menu was very popular. They persist to this day in some specialized applications.
In a nutshell, your PC will run a simple terminal program. Putty.exe is a great choice. It’s free, works great and supports the popular VT100 terminal control characters we will need.
The Arduino serial parameters are set to 115,200 bits/second, 8N1. Make sure your terminal program is set up similarly.
The example program turns on and off two LEDs and displays the raw data read back from the Analog0 port
Here’s the program:
// Description:
// Simple menuing system for Arduino
// Demonstrates a menu with controls and
// data readback
//
// Communicates with PC at 115,200 bps 8N1
//
#define LED1 2
#define LED2 3
void setup()
{
pinMode(LED1, OUTPUT);
pinMode(LED2, OUTPUT);
Serial.begin(115200);
menu();
}
void loop()
{
int m = readMenu();
switch (m)
{
case 1:
// Turn on LED 1
digitalWrite(LED1, HIGH);
break;
case 2:
// Turn off LED 1
digitalWrite(LED1, LOW);
break;
case 3:
// Turn on LED 2
digitalWrite(LED2, HIGH);
break;
case 4:
// Turn off LED 2
digitalWrite(LED2, LOW);
break;
case 5:
{
// VT100 reset cursor to end of menu (row 15, column 1)
char resetCursor[] = {27,'[','1','6',';','1','H',0};
Serial.print(resetCursor);
Serial.print("A0: ");
// Read Analog 0 input and display data
Serial.print(analogRead(A0));
break;
}
default:
break;
}
}
// Waits in a loop until key is pressed
// then returns digit selected
int readMenu()
{
while (!Serial.available())
{
delay(100);
}
return Serial.read() - 48;
}
// Displays menu
void menu()
{
// Clear screen
char buf[] = {27,'[','2','J',0};
Serial.print(buf);
// Print menu
Serial.println("\n\n\n\n\n");
Serial.println("1....LED1 on");
Serial.println("2....LED1 off");
Serial.println("3....LED2 on");
Serial.println("4....LED2 off");
Serial.println("5....Read A0");
Serial.println("\n\n Select 1..5");
}
When you run this, you will get a menu with 5 options. We demonstrate how to position the cursor on the screen using escape commands. Look at the code that prints the value of A0 on the screen for an example.
Menuing is a simple but effective way to get your PC and Arduino talking to each other.
If you'd like to subscribe to this blog, please click here.