The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
1. Maybe it is... They have told me mechanically they can put the senors in the same plane than the parts.
2. No, I can't. I need too much precision. And I would need a metrology machine to check that... something the customer doesn't want. They are interested on a solution that could survive a mechanical maintenance.
3. Sensors only read the distance between the sensor to the part.
4. No, the precision I need is 3 micro meters... Really don't know how to move that part with that precision.
I really hope the mechanical engineers will be capable to put all the sensors in the same plane than the part itself, if this is not happening, then I'm afraid the solution will be much more harder.
Hi, You get good distance measurement ( I expect worse case error to be less than double the sensors if you don't have an angle ( beam to cl ) over 45deg. _that's a guess_ ).
Note, ( don't know scale ) at 3 uM, you're in the breath on it and it moves range.
You have a known 2 diameters "perfect" standard, you want to measure part diameter but part to measure may not be exactly located.
Try - draw this and check, I didn't - place your standard. Take 3 measurements, think about 3 arcs from the standards axis, move your standard, repeat, you have 8 unknowns ( x,y for each sensor, x,y for the standard ) and 3 measurements for the first location, 10 unknowns, 6 measurements for the second, 12 and 9, 3rd, 14 and 12 4th, 16 and 15 5th, 18 and 18 6th, at 17 you get a solution. Note that the error bars could be horrible depending on the setup. I suspect that placing the sensors in an approximately equilateral triangle helps, adding a 4th sensor should help, adding measurements will, I'd try a 3 x 3 grid of "target" points that covered most of the between sensor area.
But you will have to work on error analysis and see.
The problem with getting a good value for theta is that cos(theta) is going to be very close to 1.0000 for any small value of theta. So even a tiny measurement error will result in a incommensurately large error in theta. And cos(theta) may even come out to be greater than 1, in which case theta is undefined. However, it seems like a good bet that you can get by with just an estimate of cos(theta) for your calibration, since given a measurement m you can use the law of cosines to find the distance from the center.
I guess I have a broader question. What is the end goal of this measurement? in other words is the end goal of the analysis, measurement and calculation to:
a.) determine the angles and position for each of the three measuring devices?
b.) determine the difference in radii between the inner and outer rings of the three masters?
c.) measure the radii between the inner and outer rings of random test devices?
d.) test that an introduced device has an inner and outer radii that falls within a given tolerance?
The approach to the calculation will most likely vary depending on the answer to this question.
This maybe a simplistic view but looking at the problem of determining the angle at which the sensor strikes the master seems to be as follows:
Consider a Right Triangle with the base labeled AB, the hypotenuse labeled AC, and the following being defined:
1. Line AB is the difference between inside and outside radii of the Master.
2. Line AC is the difference in distances measured by the sensor between outside and inside edges of Master
3. The angle at A formed by Line AB and line AC is the sensor angle.
A first approximation of the angle A is therefore the arcCos of AC/AB. A more accurate determination could be found if you consider the length of Line AC is adjusted by the curvature of the master.
One final note: If you are only interested in determining if the radii of test devices placed in the measurement tool fall within some acceptable tolerance, you could avoid all the messy calculations simply by maintaining the master measurements and comparing acceptable results against new measurement values to determine if the new values are within an acceptable range. This may mean the masters are designed to define maximum and minimum acceptable radii.
It seems to me that you need a test rig and calibration procedure if variation is the issue keeping you from knowing the position of the sensors. Just because the mechanical engineers can't guarantee the position, doesn't mean you can't measure it after manufacturing.
It's a very Victorian name for a ship, isn't it? "An Implacable-class aircraft carrier" is rather Victorian as well, if you know what I mean - kinda makes you wonder how we actually won WWII sometimes ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
Yes I do and the performance is god awful. This is for a compound regular expression rather than a web browser, so this is more than a little excessive. Normally the machine will spawn like 2 or 3 while it's doing normal character scans, but when it has to split it quickly grows.
The reason it spawns more than one is disjunctions in the regex, like foo|bar - it spawns a fiber to scan each one. In truth it spawns slightly more than 1 fiber on average because save points spawn a fiber. Plus each fiber only lives for the duration of one character.
They're already allocated since they're simple structs sitting inside an array. The only field that gets set are two simple 32 bit fields on the struct =) Since they're allocated this way, at least unless .NET sucks in this arena (i haven't checked the IL) they don't need to be recycled - they're permanent instances.
Furthermore, the fibers get used at maximum - they are never idle, ergo, a threadpool won't benefit me.
Ah yes, the rarely appropriate Thread Per Request pattern. Almost always better is a work queue served by a single thread, or a pool if blocking is an issue. Threads eat up memory, add context switching overhead, and introduce critical regions. I recently discovered how often Windows schedules a new thread, and I'm still flabbergasted.
Fibers, being lighter weight, shouldn't be as bad, but evidently it's still plenty bad.
honey the codewitch wrote:
each fiber only lives for the duration of one character
Last Visit: 22-Feb-20 14:20 Last Update: 22-Feb-20 14:20