Electronics > Beginners
automated noise check for gearbox continued
engineheat:
--- Quote from: Ian.M on February 12, 2019, 09:46:12 am ---OK, solely considering *electrical* hardware, + its impact on the mechanical design, you'll need four or five wires per axis just for the stepper motors, + at least three more wires for home and limit sensors. The sensor head is going to need power, control and signal wiring.
--- End quote ---
Thanks for the detailed response. I guess wired (not wireless) is the way to go, and my processor/controller should be at the "base" (fixed position).
Can I do away with the home and limit sensors if I have the stepper motor return to the "home" position after it has iterated thru all the positions? Since I can keep track of the number of steps in each axis, why not just return it to step 0 position rather than use home/limit sensors?
As for the processor, will Arduino have the sufficient processing power to do FFT if I keep the sample rate "low"? I plan to take a certain amount of samples per time period (say, 2000 per 1/10 sec), do FFT on it, and average the FFT over perhaps 3 seconds.
Also, I guess one of the "main" axis (the axis which other axis builds upon) will need 2 stepper motors, one on each side to create stability and balance/support? This is if I use a slide rail system (one on each side), and if only one side is driven, it would create unwanted torque. Perhaps a way to solve this is to NOT use a rail on the other side, and just use a wheel to provide support?
Ian.M:
Home sensing is essential, as the stepper motors aren't absolute positioners. Any axis could get bumped while power is off, and without some sort of sensing, your controller has no way to correct. You can get away without actual discrete sensors if the axes have resilient mechanical stops and the drivers support stall sensing, by driving slowly into the stop till the stepper stalls. If not it would be foolish to omit the limit sensors (one of which doubles as the home sensors), as repeatedly crashing into the mechanical limit of the travel will over-stress the mechanism, possibly resulting in jamming or failure.
'Arduino' covers a wide range of boards and processors. I certainly wouldn't want to calculate FFTs on an 8 bit AVR based Arduino. Make sure that whatever you choose has enough RAM for the number of samples your sampling rate and sampling window require.
If you put rails on both sides of the bed or frame for the main X/Y axis,linked by a rigid beam for the other Y/X axis, they will need to be absolutely parallel to a very high accuracy or the mechanism will jam. Its also likely to jam if there's a large temperature change. One way to avoid jamming is to resiliently mount the beam at one end. You could use a wheel at the far end, but if you do that, you'll need some way to constrain it from lifting too far off its track if the mechanism is mishandled, e.g. run it inside a flat bottom U on its side, a little wider than the wheel diameter. It also may be worth coupling the stepper motor for that axis to a shaft the full width of the bed or frame so you can have a toothed drive belt on each side driven together.
ejeffrey:
--- Quote from: engineheat on February 12, 2019, 02:28:57 pm ---Thanks for the detailed response. I guess wired (not wireless) is the way to go, and my processor/controller should be at the "base" (fixed position).
--- End quote ---
Wired is always going to be simpler and more reliable. Since you have to have wires anyway for your motors and so forth, it doesn't seem to make sense to economize them. You need to be careful with cables going to moving heads, but it is a well solved problem.
--- Quote ---Can I do away with the home and limit sensors if I have the stepper motor return to the "home" position after it has iterated thru all the positions? Since I can keep track of the number of steps in each axis, why not just return it to step 0 position rather than use home/limit sensors?
--- End quote ---
If your stepper hits something and stalls it will loose steps. With out at the very minimum a home switch, it will be pretty hard to recover from that. Also you need to home on power up.
--- Quote ---As for the processor, will Arduino have the sufficient processing power to do FFT if I keep the sample rate "low"? I plan to take a certain amount of samples per time period (say, 2000 per 1/10 sec), do FFT on it, and average the FFT over perhaps 3 seconds.
--- End quote ---
As IanB said, depends on what arduino you are using. But is that even needed? Do you need to activate a pass/fail lamp directly from the micro, or are you going to communicate the reading back to some central inventory tracking computer? If the latter, you might as well just send the raw sample data, and do the FFT on the main computer. A nice advantage of this is that you can record the vibration spectrum as a test result you can provide to the customer or log vs. time for internal tracking purposes, rather than just a pass/fail. This could be really useful if, for instance, you get a bunch of returns. You can go look up the serial number in your testing database and figure out if your pass/fail critera are bad or if maybe something happened to the devices in shipping.
engineheat:
--- Quote from: Ian.M on February 12, 2019, 03:00:36 pm ---
'Arduino' covers a wide range of boards and processors. I certainly wouldn't want to calculate FFTs on an 8 bit AVR based Arduino. Make sure that whatever you choose has enough RAM for the number of samples your sampling rate and sampling window require.
--- End quote ---
How about the Raspberry Pi? It is 700Mhz and has way more storage (via SD card) and RAM. It also use linux so I might install Python on it to do FFT?
Ian.M:
That would be reasonable idea from the point of view of doing the signal analysis, high level control and logging, but the Pi doesn't have any ADC inputs ant it isn't great at realtime control (see http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RaspberryPi ). Add a USB soundcard for the signal capture, and an external smart controller for the steppers and to monitor the limit and home sensors for each axis and it would be viable. I would recommend logging to USB stick, not to its own on-board SD card, as the more you write to it the more likely it is to go bad, and as it holds the OS and your user application, its a PITA to recover from a corrupted card.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version