automated noise check for gearbox continued

[engineheat]

Hi, this is regarding the noise check quality test automation project I talked about in another thread. I was able to use FFT to differentiated between a bad motor and gear motor. However, I originally thought about implementing this test on the production line, which has too much random noise. The FFT/microphone approach worked much better in a quieter setting.

Once the gearbox come off the production line, they get put into open top boxes, 100 per box, so 10 rows and 10 columns. The box is roughly 0.5 m by 0.5 m.

I'm thinking about building an apparatus that once place on top of the box, and it will turn on each handle via a servo or stepper motor, and a microphone can feed the sound to a processor. The whole thing can be placed in a quiet setting. So the requirement is:

1. A device that carries the microphone needs to move in a grid like fashion to examine each motor 1 by 1. The servo to physically turn the motor on/off will need to move in a grid like fashion too.

2. I'm not sure if the processing unit will need to move. If the CPU is stationary, then signal from the microphone will have to be wirelessly transmitted (please advise). I don't want wires since that'll get tangled up quickly in the grid like movement. Or I can use something like an Arduino to move along with the microphone. It might just have enough processing power to do some simple FFTs...

3. What's the easiest way to implement this grid like movement? How can I ensure the moving part moves a fixed distance each iteration? I'm thinking about building a 10 by 10 "track" that gets placed on top of the box. But that still doesn't solve the issue how setting the stopping points. Perhaps mark each point with a black dot and use an optical sensor?

4. I also need a way to display which motors are bad after the run. This can be a simple screen that display the row numbers and columns numbers. But if I place a 10 by 10 track on top of the box, it'll be awesome if we can light up a LED for each position a bad motor is found. This is much easier to locate bad products than reading row/column numbers.

What are your suggestions? I prefer quick and dirty, off-the-shelf solution as possible. If needed, I can also fabricate parts.

Thanks a lot.

[Ian.M]

So now you want to test the motors/gearbox assemblies *after* they are packed? You do like making life hard for yourself.


A more rational approach would be to design a test jig as part of the production line using resiliently padded clamps with a contact microphone embedded in one of them.  It will be much less sensitive to background acoustic noise.  The tesst jig should be mounted to a heavy concrete slab on resilient mounts to isolate it from vibration sources on the production line.  If that's still not good  enough, the test station may need a sound-dampening cover, that closes over it during the test.

[engineheat]

I cannot put the sound check on the line. The way the production machine is designed, it's too difficult to build a sound barrier. It's also deemed too much of a risk to put a custom solution like this to the actual production line.

[Ian.M]

In that case, you are looking at an xyz gantry system.  You've still got to deliver power and control to the head so one more cable (or an extra balanced pair + grounds either side) in a ribbon cable for the output of the contact microphone preamp isn't going to make much difference to your moving cable management.

The gantry and head will be need to be retracted for good access while the guard on the machine cell is open, so indicating failed units by LED isn't really an option.  Probably the best choice would be a paint dotting system on the head for go/no-go marking, combined with a monitor displaying red and green squares + a machine vision system checking  the operator has removed the correct reject parts.  The machine vision system can also confirm the presence and correct placement of the part at each grid location, preventing expensive head crashes.

[engineheat]

In that case, you are looking at an xyz gantry system.  You've still got to deliver power and control to the head so one more cable (or an extra balanced pair + grounds either side) in a ribbon cable for the output of the contact microphone preamp isn't going to make much difference to your moving cable management.

The gantry and head will be need to be retracted for good access while the guard on the machine cell is open, so indicating failed units by LED isn't really an option.  Probably the best choice would be a paint dotting system on the head for go/no-go marking, combined with a monitor displaying red and green squares + a machine vision system checking  the operator has removed the correct reject parts.  The machine vision system can also confirm the presence and correct placement of the part at each grid location, preventing expensive head crashes.

An xyz gantry system offer the advantage that one can change the movement via programming easily. In my case, since the positions of the points of interest are always fixed, would it be easier to hard code the movement along some kind of "grid-like track cover" that I can place on top of the box? This way, at least the xy movement is hard coded or at least constrained in a way that might make it technically easier. I'm not sure how hard/expensive it would be to make a xyz gantry that is of the right size for the box. On the other hand, I can easily machine a custom track out of plastic.

I plan to just use a LCD display to shows the positions of the bad ones.

thanks

[Ian.M]

There's not a lot of difference in the mechanism for an XYZ gantry vs a track system on top of the box.   You'll still need full length rails carrying a bridge with rails for the other axis, and a drive for each axis.   You might be able to get away with a steel cable drive or high tensile toothed belt drive rather than ball screws if you are happy to sacrifice precision to lower the cost.   Its probably easier to just have home and limit sensors for each axis, use steppers to drive them and programmed positions rather than having to precisely set the positions using pins to actuate sensors.  Its certainly more convenient if you ever need to make any adjustments.

An XYZ gantry system could accommodate many different box sizes, up to its x and Y travel limits and up to its Z axis clearance, so will be much quicker to get set up and far more futureproof.   You should be able to order something suitable from stock from many automation equipment supplier, that will only need mounting to pillars on a baseplate with a locating frame for the base of the box.   If you roll your own, its almost certainly going to take far far longer to fabricate, set up, debug and document it, and you'll be stuck as the only guy that knows the mechanism well enough to maintain it.   You are still going to have to design and build the testing head and do the systems integration, and IMHO that's quite enough work for one person, with management breathing down your neck for a completion date!

A further thought  A set of rails/tracks that lifts on top of the box is far far more likely to get damaged, e.g. knocked out of alignment than a gantry on an independent framework.  Also you are going to have to keep OSHA happy, and designing the mechanism to avoid potential pinch points and stop if a foreign object is detected  is probably more hassle than setting up a guarded work cell round the gantry.

IMHO you need to get costings for an off-the-shelf XYZ gantry system, and if its not viable in the budget, discuss with management how much longer it will probably take if you have to scratch-build the XYZ mechanism, andd how much its likely to reduce the probability of success.

A good place to start with this project would be with a hand-held test head with an extra plastic guide round it designed to fit into one cell of the box, do the test and give immediate pass/fail indication.  The same test head could easily be mounted to an XYZ gantry, so they have the choice of paying minimum wage for manual inspection or paying the automation costs.

[gildasd]

Why not use a SPM based solution (did not read all answers, sorry if allready proposed)?
It is used in engine rooms to check generators bearings/gearboxes/crankshafts etc. Ambient sound levels are never below 115dB.
The big problem with SPM is differences linked to users (sensor position/angle, pressure, tongue positioning etc) but by doing an automated system, you do away with that.

[engineheat]

There's not a lot of difference in the mechanism for an XYZ gantry vs a track system on top of the box.   You'll still need full length rails carrying a bridge with rails for the other axis, and a drive for each axis.   You might be able to get away with a steel cable drive or high tensile toothed belt drive rather than ball screws if you are happy to sacrifice precision to lower the cost.   Its probably easier to just have home and limit sensors for each axis, use steppers to drive them and programmed positions rather than having to precisely set the positions using pins to actuate sensors.  Its certainly more convenient if you ever need to make any adjustments.

An XYZ gantry system could accommodate many different box sizes, up to its x and Y travel limits and up to its Z axis clearance, so will be much quicker to get set up and far more futureproof.   You should be able to order something suitable from stock from many automation equipment supplier, that will only need mounting to pillars on a baseplate with a locating frame for the base of the box.   If you roll your own, its almost certainly going to take far far longer to fabricate, set up, debug and document it, and you'll be stuck as the only guy that knows the mechanism well enough to maintain it.   You are still going to have to design and build the testing head and do the systems integration, and IMHO that's quite enough work for one person, with management breathing down your neck for a completion date!

A further thought  A set of rails/tracks that lifts on top of the box is far far more likely to get damaged, e.g. knocked out of alignment than a gantry on an independent framework.  Also you are going to have to keep OSHA happy, and designing the mechanism to avoid potential pinch points and stop if a foreign object is detected  is probably more hassle than setting up a guarded work cell round the gantry.

IMHO you need to get costings for an off-the-shelf XYZ gantry system, and if its not viable in the budget, discuss with management how much longer it will probably take if you have to scratch-build the XYZ mechanism, andd how much its likely to reduce the probability of success.

A good place to start with this project would be with a hand-held test head with an extra plastic guide round it designed to fit into one cell of the box, do the test and give immediate pass/fail indication.  The same test head could easily be mounted to an XYZ gantry, so they have the choice of paying minimum wage for manual inspection or paying the automation costs.

Adafruit sells components that are geared for gantry, like this:

https://www.adafruit.com/product/1180


I think I'll try to build something myself to try. I will use timing belt and stepper motors.  There will have to be a small actuator attached to the "z axis tool" that the gantry will drive.

I guess the controller can stay fixed and the actuator will have to be driven using wires? Or how about attach the controller to the "z axis tool" and power it via battery? This saves the mess with wires, but it still needs to communicate with the main controller that drives the xy stepper motors (which are fixed).  Not to mention, the end tool will also have a microphone which needs to send signals.

Please advise on the easiest/most efficient way of doing this, from a electrical hardware perspective. Less is better. Thanks

[fossi]

Have a look in a search engine for "Early stage damage detection delta-ANALYSER"
This System and derivates work great in gearbox and engine analysing.
It is often used in massproduction as end of line test.
There is no microfon used. They use vibration detectors. When they must be cheap, use nocksensors from a car engine.
I have worked with this system for a long time with greta efforts.

greatings
fossi

[Ian.M]

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.

Depending on where you locate the controller, you'll have differing numbers and lengths of moving cables.   If you locate it on the sensor head, the X, Y and Z axes will have three, two and one moving cable sections respectively.  Its almost the same but in the reverse order if you locate it on the frame/baseplate, except you then have three moving sections in the signal cable.  However mounting it on the head makes the head *MUCH* heavier and bulkier, and you'll need bigger stepper motors and a much heavier mechanism for each axis to move it reliably.  Keeping the moving mass as low as reasonably possible is therefore a good design goal.  The trade-off is the need to get the sensor signal from the head to the controller.

If you are using cable chains (motion trunking), the signal cable is no problem - just put a preamp on the head and use high flexibility screened cable.  If however you are trying to make it cheaper and lighter weight, you may choose to take inspiration from the control and signal wiring to the head of an inkjet or dot matrix printer, which almost invariably uses a flat flex cable in a rolling U configuration terminated to the head and a location on the chassis in the middle of the head travel.  That allows a travel of slightly under twice the moving length of the cable. As the head moves, the cable rolls onto or back off a flat plate or guide half the length of the travel, with a large enough bend radius not to unduly fatigue it.

If you go for the rolling U flat flex solution, its difficult to screen the signal conductors - that would probably require a custom cable.  The way round that is to amplify it to a high enough level that noise pickup is not significant and drive the cable as a balanced pair.  However to get better cancellation of E fields and M fields, as a twisted pair is impractical, use four conductors in the cable, the two inner ones paralleled and the two outer ones paralleled, to get good cancellation of both E and M field pickup.  I would also suggest 'clean' grounds, connected to the preamp ONLY either side of the four conductors carrying the balanced signal.  For control, also use balanced signalling e.g. RS-485, but as its a digital signal, two conductors side by side should be sufficient.

Use off-the-shelf flat flex cables in standard lengths, and use padded clamps near the connectors so they don't flex at the connectors.  There must be no significant movement of the cable at the clamp on the moving side, or you'll get rapid cable fatigue, so the bend of the rolling U mustn't come too close to the clamps.  Design it for easy cable replacement - no complicated creased bends and with good access to the clamps and connectors.

I would also suggest a self-test mode at startup that checks the integrity of all the moving cables.  The stepper conductors can be checked by sensing the current through them.  The axis position sensors should be normally closed, opening at the limit and home positions.  If they are open at startup, a small movement towards mid axis should result in a closed indication.  If it doesn't a conductor has broken.  For the signal conductors, the best bet would be to include a test signal generator circuit in the sensor head and an analog switch or reed relay to disable the vibration sensor or contact microphone.  First get a baseline for the noise level with the sensor/microphone disabled, then enable the test signal and check its as expected, then disable the test signal and enable the sensor/microphone and you are good to go.   For power and control to the head, if it doesn't respond to commands to activate the self test mode, either the power or control conductors are broken.

[engineheat]

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.

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]

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).

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.

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?

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.

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.

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]

'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.

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. 

[gildasd]

I use a version of this at work.

https://www.spminstrument.com/Products/Portable-instruments/Electronic-Stethoscope/

Ours in integrated into a vibration checker (needs bearing data to determine if it within specs under load) but that is probably way overkill for your usage.

I would suggest using a contact probe microphone like this as they are usable even is very noisy environments.

[engineheat]

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.

I will use a USB sound card. Can you please provide a link to an example of a home sensor and smart controller so I can learn more about them?

thanks

[rhb]

I'm sorry to say this, but you are highly unlikely to succeed in your efforts which is a great disappointment to me.  I found it an interesting problem.

In the previous thread you imposed extreme limits upon the amount of time allowed for a test.  Now you are compounding it by demanding that the data collection period be even shorter.  And making the solution more complex and more expensive.

You are not an experienced digital signal processor.  You do not know how to analyze and process the data.  Despite repeated requests that you post some data you have not.

It is routine in reflection seismic processing to take data which is so noisy that the raw recordings look as if they are pure noise and produce beautiful, crisp images.  That is the job function of a seismic processor, dealing with the noise.  The rest of it can be done by a high school dropout.  But the noise suppression cannot.

The noise reduction requires understanding the noise characteristics and the signal characteristics and then  selecting from a very wide range of noise suppression techniques  a data space where the noise and the data are separable.   The noise is not a homogeneous entity.  "Noise" is the name given to all the things which are not information that is wanted.  There's an old saying in seismology, "That's not noise, it's signal we don't know what to do with."  Over the course of many years I have seen a wide variety of "noise" transformed into additional data that a simpler model does not describe.

A number of years ago when I still did Seismic Unix support a grad student at Scripps posted a query to the mailing list.  He had some very poorly acquired academic data over a seamount in the Pacific.  The "birds", which are movable wings mounted to the streamer containing the hydrophones and which maintain the streamer at the desired depth, were either broken or not being operated properly.

This condition  led to what is called "cable strum".   The birds are behaving as if they were picks plucking a string very rapidly.  This leads to  waves which travel up and down the cable and reflect off the ends.

Hydrophones are accelerometers, just as are contact piezoelectric microphones.  So the problem was that he was trying to detect motions of a millionth of an inch on a cable which was moving several inches due to the strum.  His data was extremely bad.  No oil company would have accepted it, but academic research vessels are mostly crewed by graduate students.  There is no budget for a reshoot, so "what you see is what you get".

Seismic Unix is a large body of code ranging from brilliant to awful.  Most of it has been written by scientists and students who do not now how to program.  So it's a pretty ornery beast.  Lot's of things don't work as they should.  For the student this was all new territory whereas I had been using and fixing bugs in SU for many years.

I thought I could do it in an afternoon, so I got a data sample and put together a work flow showing how you handle the problem.  Because the program that performed the particular filtering operation needed did *not* work the way the documentation stated it wound up taking me 4 days rather than 4 hours.  But I put together a basic workflow for him showing how to suppress the noise. What I gave him was not a solution.  It was a cartoon, a pebble tossed in the general direction of the solution.  After he understood how to suppress the strum there were many more operations needed.   And in addition  I provided him with some simple examples of how to produce an image from his data.

IIRC it took him a couple of months, but he sent me an image that knocked my socks off.  It was substantially better than what I thought could be achieved from looking at the data.  And this was a side job, not his dissertation project.  But he clearly put a huge amount of effort into experimenting with parameter choices until he found the right ones.   He later sent me images from his dissertation project which were as good as any I have ever seen produced with single streamer data and much better than a lot of commercial processing of similar data I've seen.

In summary, unless you provide pictures of the line and data, no one can tell what can or cannot be done.  Anything anyone says is just guessing based upon the description of an elephant by the four blind men.

One of the applications of sparse L1 pursuits which I have mentioned previously is called "blind source separation".  In a nut shell this consists of taking a handful of microphones scattered randomly around a room and then picking out any individual speaker anywhere in the room during a crowded cocktail party.

What you want do do can be done.  But you have to know how.  You don't.  Nor does anyone else on this list that I have encountered. If there were, my posts about sparse L1 pursuits would have gotten a response.  I do now how.  That has been the primary focus of my life for 37 years.

[engineheat]

Home sensing is essential, as the stepper motors aren't absolute positioners. 

I decided to use Nema 17 for the XY gantry, found a kit that I can buy for $200. Speaking of stepper motors, there's this:
https://www.applied-motion.com/products/series/str-stepper-drives?

and there's this:
https://www.pololu.com/product/1182

The first one is obviously higher quality and more robust and expensive. But aside from the obvious, what else set them apart?

Thanks

[JuanGg]

Just skimmed over the thread.
I recommend you make a list of requirements, drawings, block diagrams etc.
Upon designing the gantry, take into account sizes, forces and speeds involved. Knowing that, you can decide on the linear slides and stepper motors to use. For your application, ground rods and linear bearings, using belts and NEMA17 steppers would do.
Take a look at CNC software, such as grbl. That will take coordinates via a serial port and handle all homing, positioning and acceleration.
(Although for something this simple, just moving over a fixed grid, you could very well code it yourself from scratch).You can often purchase ready-made CNC kits with steppers and stepper drivers. And I can't emphasize drawing a diagram enough.
Just my two cents.
    Juan