Re: [Emc-users] MTBF

[Gregg Eshelman]

On 12/3/2014 7:31 AM, Steve Stallings wrote:
> Traco appears to be a company whose main offices
> are located in German speaking areas.
>
> Mio is used as an abbreviation for Million, especially
> in German.
>
> The document that you linked seems to use a mixture
> of . and , as the symbol for the decimal point.

Then there's the American Billion 1,000,000,000
VS the Olde English Billion 1,000,000,000,000 or what we Yanks call a 
Trillion.

Anyone in Europe know anyone still calling a Million a Milliard?

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Gregg Eshelman]

On 12/3/2014 5:45 AM, andy pugh wrote:
> On 3 December 2014 at 12:42, alex chiosso  wrote:
>> You're right Rick . ;-)
>
> I still don't believe 1,500 x million hours.
>
> I suppose it could be a Euro-style decimal separator, and therefore
> 1.5 million hours, but that is still 171 years MTBF.
> (which would be ideal, but seems high)

Metric VS Imperial crashed a probe on Mars. What disasters have happened 
due to point VS comma? ;-)


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Measuring Mitsubishi resolvers

[Leonardo Marsaglia]

2014-12-04 0:11 GMT-03:00 Jon Elson :

> There are basically two ways to run resolvers.  You can
> excite the rotor and get two
> varying voltages from the stator coils.  These will
> generally be in phase with the
> excitation, or 180 degrees out of phase.
>
> Or, you can excite the two stator coils with signals that
> have some phase relationship,
> (usually 90 degrees) and measure the time of the zero
> crossing of the rotor signal,
> which will be roughly constant amplitude.
>
> it sounds like this system may be using the excite the
> stator scheme.
>

Hello Jon and thank you for the explaination!

So in theory I could use them as normal resolvers and output them to
LinuxCNC as several people did.

The problem is I don't know if it's worth to spend money on hardware just
to test if this is going to work, or if it's better to use encoders from
scratch which I know they will work.



-- 
*Leonardo Marsaglia*.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Measuring Mitsubishi resolvers

[Jon Elson]

On 12/03/2014 05:42 PM, Leonardo Marsaglia wrote:
> Hello to all again.
>
> We're defining the hardware for the Mazak conversion and yesterday my
> brother and I measured the resolver signals to identify what voltage and
> frequency they use. I've been reading some information about resolvers and
> it's not too difficult to understand the way they work, anyway I have a
> little doubt with respect to the measurements on the excitation part.
> Here's what we've got from them:
>
> Between Sin + and Sin - there's 12 volts and a 4.5 khz frequency. Same
> thing happens on Cos + and Cos - and there's the 90° phase shifting between
> the two of them.
There are basically two ways to run resolvers.  You can 
excite the rotor and get two
varying voltages from the stator coils.  These will 
generally be in phase with the
excitation, or 180 degrees out of phase.

Or, you can excite the two stator coils with signals that 
have some phase relationship,
(usually 90 degrees) and measure the time of the zero 
crossing of the rotor signal,
which will be roughly constant amplitude.

it sounds like this system may be using the excite the 
stator scheme.

Jon

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Jon Elson]

On 12/03/2014 02:19 PM, Ron Bean wrote:
> Jon Elson  writes:
>
>> One other place the military screwed up, is Tantalum
>> capacitors. These have the
>> bad characteristic that they can be VERY reliable if used
>> CONSTANTLY.  That means
>> either on all the time, or used every few days.  But, make
>> something with
>> tantalum caps, test it rigorously, and then put it in a
>> supply depot for a couple
>> years, and you will almost CERTAINLY find the caps short out
>> and blow (as
>> in fire and smoke) when you then put it into use.
>   
> Does that mean that unused tantalum capacitors have a limited
> shelf life?
>
> Also, Wikipedia says that some of them used to have a liquid
> electrolyte, does that affect the shelf life?
>
>
Yes, apparently the "wet slug" design is the one that has 
this failure mode.
I don't KNOW about the new-old stock thing.  My experience 
is with built
equipment, which presumably was run for at least a 
functional test before
going into storage.  It may apply specifically to gear that 
has run in
the field for thousands of hours before going into storage, 
I just
don't know.  I DO know that I have run into this a lot, and 
replaced
shot tantalum caps in gear I picked up surplus.

Jon

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Jon Elson]

On 12/03/2014 11:39 AM, Evan Foss wrote:
> While I agree with that rant I can say that a lot of higher end stuff
> does get environmental testing. My stuff lives in a hotter than
> average environment and so I have to consider this.
>
> Also my father has worked for a few different companies that for
> defense and enterprise level hardware had to do these tests. (One even
> had an earthquake simulator)
>
>
Yes, of course, various manufacturers test all sorts of 
stuff!  But, these PUBLISHED
MTBF numbers all seem to come from the old DESC scheme.  
When they show
250K hours MTBF for a hard disk drive, you KNOW they are 
using this methodology.
Anybody know of a hard disk drive that will run for a 
continuous 28 YEARS?
NOT very likely.

First, high-rel gear will be very hard to get realistic MTBF 
numbers on, if you build them
and they run for years without failure.  Extrapolating that 
experience will make for
wildly varying numbers.  So, I admit, fully, that getting a 
truly valid MTBF number
from accelerated life testing of high-rel systems is 
actually close to impossible!

All the makers of avionics stuff have to really beat on 
their gear, with thermal shock,
thermal extremes, condensation, electromagnetic torture, 
lightning resistance,
massive vibration, and so on, to be sure the gear won't 
break down at the worst
possible times.

There have been a number of incidents where software 
glitches, failure of
redundant components and wiring problems have come VERY 
close to bringing
down passenger aircraft.  There are apparently a few cases 
where such
problems at least contributed to fatal crashes.

Jon

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Przemek Klosowski]

On Wed, Dec 3, 2014 at 2:33 PM, Marcus Bowman
 wrote:
> Yeah; and as for those MTBF figures for small bearings... The last lot I used 
> in my lathe fixed steady lasted for ages; except for the one which failed 
> after 15 minutes ruining the job. It was small consolation to be told the 
> 'thousands of hours to failure' was an average...

An average human has one boob and one testicle, is what I recommend
remembering about statistical averaging.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Gene Heskett]

On Wednesday 03 December 2014 17:55:17 andy pugh did opine
And Gene did reply:
> I was pointed offlist to:
> http://www.epsma.org/pdf/MTBF%20Report_24%20June%202005.pdf
> Which contains the excellent example:
> 
> "25 year old humans have an MTBF of about 800 years, (خ» about
> 0.1%/year), but not many have a comparable “service lifeâ€‌."

So thats why so many of us were 10' tall & bulletproof at that age. ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Stuck on a G2 move (again)

[Gene Heskett]

On Wednesday 03 December 2014 12:26:16 John Thornton did opine
And Gene did reply:
> Gene,
> 
> Your confusing me LOL...

We're gonna need a bigger boat. :0
> 
> Here is a sample program to move in an arc in quadrant 1 from 0 degrees
> to 90 degrees. You only have to move to the start position then pass
> the radius of your arc. After the G90 it moves to a second location
> then does the same arc.
> 
> ; 90 degree cw arc in quadrant 1 0-90 degrees
Actually> 
> #1 = 0.250  (radius of the arc)
> ; move to first location
> G1 X0 Y0 F10
> G91
> G2 X#1 Y-#1 I0.0 J-#1
> G90
> ; move to next location
> G0 X1 Y-1
> G91
> G2 X#1 Y-#1 I0.0 J-#1
> G90
> 
> 
> M2
> 
Most of my problems were solved by arriving at the starting point, and 
issuing a G91.1 to assure that the IJK stuffs were relative.  Then my 
calculations seemed to work much better.  The rest of the code runs in G90 
mode.

So late this afternoon I went out & bought a 6' 1x12 that I can nibble 4" 
at a time from & use that as throwaway test pieces. Poor lumber though, 
flat sawn and the trees original central twig runs right thru the length 
of the board about2.5" from one edge, so the first thing I have to do is 
give it a drink of superglue & slap it in a 2 foot Bessey style F clamp 
for half an hour else it falls apart just trying to put it in the jig & 
get it clamped down.

I have a couple of them laying here, but the fit is too tight, so I need 
to add or sub, about 3 thou depending on which corner its carving in order 
to loosen the fit enough to actually drive it together.  But I am not yet 
done with the code that cuts the mirror in the end pieces so a true test 
fitting is not yet possible.

And my back is yelling so its done for the day. So I'll sit here and play 
with the code to widen the gaps about 5 thou for an easier to drive 
together fit. What I'll likely wind up doing is setting up a #<_fudge> 
variable set for a couple thou, subtract it from the length of the top 
run, and add it to the length of the bottom run. So a two thou change will 
actually make a 4 thou difference in the fit.  Whether tat will be 
sufficient when converted to Mahogany, I have no clue until I try it.

Final fitting of course will wait till the Mahogany gets here and I find 
out exactly how wide two 1x6 boards, edge glued together, actually are.  
They said they were s4s, 3/4"x 5.5" wide, which would be 11" total.  But I 
swear these guys use a rubber tape measure at times.

It's supposed to be 11.5" wide, but I wasn't able to find any '1"x12"' in 
anybody's web page.  So this chest is going to be 1/2" shorter vertically 
than the magazine version. I doubt it will be noticeable in the finished 
chest though.

Thanks for the hand holding John, you did make me look at it a hair 
differently.  I also printed out about 6 pages from the Usermanual.pdf, 
which had the coverage of G2 G3 in it, and which is not available in the 
wiki that I was able to find.  Wasn't there a search engine in the wiki at 
one time?  That printout answered _most_ of my remaining problems.

Thanks John.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Measuring Mitsubishi resolvers

[Leonardo Marsaglia]

Thanks Andy and Peter for the quick answer!

I'll be measuring these tomorrow so I can see if it happens as Peter says,
but I guess it will happen like that.

So these work like a resolver but insted of the excitation signal driving
the SIN and COS windings is the other way around? Because SIN and COS
signals are square signals and  0.3 volts signal is a sine wave signal.

I guess with HAL programming and an appropiate input circuit I could read
the signals and make it work , but I don't know if this is going to be
convenient
or if it's better to replace them with encoders and let this for a
experimentation project. I think about this because I would like the
machine to be running as quick as possible with LinuxCNC.


2014-12-03 21:22 GMT-03:00 Peter C. Wallace :

> On Wed, 3 Dec 2014, Leonardo Marsaglia wrote:
>
>  Date: Wed, 3 Dec 2014 20:42:29 -0300
>> From: Leonardo Marsaglia 
>> Reply-To: "Enhanced Machine Controller (EMC)"
>> 
>> To: "Enhanced Machine Controller (EMC)" 
>> Subject: [Emc-users] OT: Measuring Mitsubishi resolvers
>>
>> Hello to all again.
>>
>
> We're defining the hardware for the Mazak conversion and yesterday my
> brother and I measured the resolver signals to identify what voltage and
> frequency they use. I've been reading some information about resolvers and
> it's not too difficult to understand the way they work, anyway I have a
> little doubt with respect to the measurements on the excitation part.
> Here's what we've got from them:
>
> Between Sin + and Sin - there's 12 volts and a 4.5 khz frequency. Same
> thing happens on Cos + and Cos - and there's the 90ÿÿ phase shifting
> between
> the two of them.
>
> The weird thing is, when we measure the Excitation + and Excitation -, we
> get the 4.5 khz frequency but a voltage of about 0.3 volts.
>
> Whenever I move the axis none of this values change at all, at least that's
> what the digital scope showed. There's also a ground pin but I don't think
> that has anything to do. What I found weird is the almost none voltage on
> the excitation pins. I have to say the resolvers are fully functional and
> the machine is working ok.
>
> My doubt is why is this happening? The main goal is to measure the
> transformation ratio just to be sure that I can adapt these to LinuxCNC, I
> don't want to fit encoders because these resolvers are robust and they are
> working pretty well.
>
> Any ideas? Since there's a lot of people here that dealed with this before
> I'm sure you're going to know everything about this devices.
>
> Thanks as always for your help!
>
> --
> *Leonardo Marsaglia*.
>
> That sounds like a inductosyn (sp)
>
> These have sine and cosine exitation signals (constant amplitude) and the
> result is a constant amplitude signal (your .3V) that is phase shifted 360
> degrees every cycle (take a look at the .3V signal but sync the scope on
> one of the 12V signals while you turn the shaft)
>
> These have the advantage over resolvers that the interpolation can be done
> without a A-D converter (you just need to time the zero crossing of the .3V
> oulput signal relative to one of the 12V excitation signals)
>
>
> 
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&;
> iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>


-- 
*Leonardo Marsaglia*.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=

Re: [Emc-users] OT: Measuring Mitsubishi resolvers

[Peter C. Wallace]

On Wed, 3 Dec 2014, Leonardo Marsaglia wrote:


Date: Wed, 3 Dec 2014 20:42:29 -0300
From: Leonardo Marsaglia 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: [Emc-users] OT: Measuring Mitsubishi resolvers

Hello to all again.


We're defining the hardware for the Mazak conversion and yesterday my
brother and I measured the resolver signals to identify what voltage and
frequency they use. I've been reading some information about resolvers and
it's not too difficult to understand the way they work, anyway I have a
little doubt with respect to the measurements on the excitation part.
Here's what we've got from them:

Between Sin + and Sin - there's 12 volts and a 4.5 khz frequency. Same
thing happens on Cos + and Cos - and there's the 90?? phase shifting between
the two of them.

The weird thing is, when we measure the Excitation + and Excitation -, we
get the 4.5 khz frequency but a voltage of about 0.3 volts.

Whenever I move the axis none of this values change at all, at least that's
what the digital scope showed. There's also a ground pin but I don't think
that has anything to do. What I found weird is the almost none voltage on
the excitation pins. I have to say the resolvers are fully functional and
the machine is working ok.

My doubt is why is this happening? The main goal is to measure the
transformation ratio just to be sure that I can adapt these to LinuxCNC, I
don't want to fit encoders because these resolvers are robust and they are
working pretty well.

Any ideas? Since there's a lot of people here that dealed with this before
I'm sure you're going to know everything about this devices.

Thanks as always for your help!

--
*Leonardo Marsaglia*.

That sounds like a inductosyn (sp)

These have sine and cosine exitation signals (constant amplitude) and the 
result is a constant amplitude signal (your .3V) that is phase shifted 360 
degrees every cycle (take a look at the .3V signal but sync the scope on one 
of the 12V signals while you turn the shaft)


These have the advantage over resolvers that the interpolation can be done 
without a A-D converter (you just need to time the zero crossing of the .3V 
oulput signal relative to one of the 12V excitation signals)



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Measuring Mitsubishi resolvers

[andy pugh]

On 3 December 2014 at 23:42, Leonardo Marsaglia
 wrote:
> Between Sin + and Sin - there's 12 volts and a 4.5 khz frequency. Same
> thing happens on Cos + and Cos - and there's the 90° phase shifting between
> the two of them.

That actually surprises me. I would expect to see sine, cosine and
excitation all in phase, but with the relative amplitudes of the two
output signals varying with resolver rotation.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] OT: Measuring Mitsubishi resolvers

[Leonardo Marsaglia]

Hello to all again.

We're defining the hardware for the Mazak conversion and yesterday my
brother and I measured the resolver signals to identify what voltage and
frequency they use. I've been reading some information about resolvers and
it's not too difficult to understand the way they work, anyway I have a
little doubt with respect to the measurements on the excitation part.
Here's what we've got from them:

Between Sin + and Sin - there's 12 volts and a 4.5 khz frequency. Same
thing happens on Cos + and Cos - and there's the 90° phase shifting between
the two of them.

The weird thing is, when we measure the Excitation + and Excitation -, we
get the 4.5 khz frequency but a voltage of about 0.3 volts.

Whenever I move the axis none of this values change at all, at least that's
what the digital scope showed. There's also a ground pin but I don't think
that has anything to do. What I found weird is the almost none voltage on
the excitation pins. I have to say the resolvers are fully functional and
the machine is working ok.

My doubt is why is this happening? The main goal is to measure the
transformation ratio just to be sure that I can adapt these to LinuxCNC, I
don't want to fit encoders because these resolvers are robust and they are
working pretty well.

Any ideas? Since there's a lot of people here that dealed with this before
I'm sure you're going to know everything about this devices.

Thanks as always for your help!

-- 
*Leonardo Marsaglia*.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[andy pugh]

I was pointed offlist to:
http://www.epsma.org/pdf/MTBF%20Report_24%20June%202005.pdf
Which contains the excellent example:

"25 year old humans have an MTBF of about 800 years, (λ about
0.1%/year), but not many have a comparable “service life”."

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Multiple glade sub-panels

[Marius Alksnys]

Hi, Alex, hello Andy,

please read my answers inline.

On 2014.12.03 16:21, alex chiosso wrote:
> Hi Marius.
> Is the hal pins naming your problem ?
no, hal pin naming is not a problem.
> If it is maybe it is a no_problem .
> I mean because you can freely name the hal widgets that creates hal pins
> you can name i.e gladevcp.01_hal_pin_name for the "panel 1" ,
> gladevcp.02_hal_pin_name for the "panel 2" and so on.
> I would use the Notebook Container for this purpose to layout the panels .
I want to run three identical production lines of one machine. They have 
common frame, common hydro-pump, electric cabinet, electronics, e-stop 
chain, PC, monitor and keyboard, mouse. But each of them can run 
individually - start and stop, change parameters, load them from 
different files, have their own diagnostics.
I created custom hal component, which has almost everything needed to 
run the line in real time. I am using limit3 and one line runs 
successfully without need of axis gui or motion controller. I created 
python module for the interface.
They are not so simple, that's why I would like to make one change and 
have it on all of them.
> Why do you need three separate instances on the Python module ?
Because I want my changes to appear on all instances at once.
> Dou you use the persistence feature for the vcp panels ?
Yes, but not sure if I will use it later. It might be I will write my 
own code for loading and saving persistent parameters.
>
> Alex
>
> On Tue, Dec 2, 2014 at 10:42 PM, andy pugh  wrote:
> ...
> The other (harder) option would be to create them all programmatically.
This is what I want - to create, load or to reparent them all 
programmatically.
I found builder.add_from_file glade method, which might be handy. But I 
don't know how to use it yet.
More about it:
http://python-gtk-3-tutorial.readthedocs.org/en/latest/builder.html
http://stackoverflow.com/questions/1378582/using-multiple-glade-files-gtkbuiler




--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Evan Foss]

At some point water from the humidity in the air gets into molded
tantalum capacitors. Dipped tantalum capacitors fail because of other
mechanisms.

Moisture is the death of a lot of stuff. Sometimes before it is even
assembled. A lot of parts now are packed at the factory with descant
so that they will stay dry. Failure to dry them before soldering can
cause the parts to break like popcorn.

Electrolytic capacitors tend to dry out. The electrolyte evaporates or
reacts with the metal in the capacitor and the part becomes a resistor
or worse the electrodes react chemically.

I could go on but there are people who have said it better. NASA has
done extensive studies on MBTF and MBTT.

It is possible to make things that last for millions of hours. There
are design patterns you can use to make that happen.


On Wed, Dec 3, 2014 at 3:19 PM, Ron Bean
 wrote:
> Jon Elson  writes:
>
>>One other place the military screwed up, is Tantalum
>>capacitors. These have the
>>bad characteristic that they can be VERY reliable if used
>>CONSTANTLY.  That means
>>either on all the time, or used every few days.  But, make
>>something with
>>tantalum caps, test it rigorously, and then put it in a
>>supply depot for a couple
>>years, and you will almost CERTAINLY find the caps short out
>>and blow (as
>>in fire and smoke) when you then put it into use.
>
> Does that mean that unused tantalum capacitors have a limited
> shelf life?
>
> Also, Wikipedia says that some of them used to have a liquid
> electrolyte, does that affect the shelf life?
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Ron Bean]

Jon Elson  writes:

>One other place the military screwed up, is Tantalum
>capacitors. These have the
>bad characteristic that they can be VERY reliable if used
>CONSTANTLY.  That means
>either on all the time, or used every few days.  But, make
>something with
>tantalum caps, test it rigorously, and then put it in a
>supply depot for a couple
>years, and you will almost CERTAINLY find the caps short out
>and blow (as
>in fire and smoke) when you then put it into use.
 
Does that mean that unused tantalum capacitors have a limited 
shelf life?

Also, Wikipedia says that some of them used to have a liquid
electrolyte, does that affect the shelf life?


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Marcus Bowman]

On 3 Dec 2014, at 17:25, Jon Elson wrote:

> On 12/03/2014 07:40 AM, Marius Liebenberg wrote:
>> Andy
>> MTBF is obtained by testing a number of units over a period of time at
>> accelerated environmental conditions.
> MTBF CAN be evaluated this way, and it is a more truthful 
> way to do it, but it requires a LOT
> of units and long testing on hi-rel systems.  So, the DoD, 
> long ago, came up with this
> crazy scheme to do it ALL on paper, with not a single actual 
> test needing to be performed.

BS EN 61709:2001 is all about the mathematical projection of the probability of 
failure, and the prediction of the theoretical MTBF on the basis of the 
calculation. It's the recommended Standard...

> This was all worked out by the Defense Electronic Supply 
> Center back in the 1970's,
> and I watched in total shock and amazement when the trade 
> mags described how this
> all was to be done.  DESC no longer exists, and I think this 
> whole debacle had something
> to do with that.
> 
> You look up in a book published by DESC what the reliability 
> of a specific resistor, transistor,
> capacitor, etc. was, and then add up all of those parts and 
> put them into an equation
> that gives you a total reliability.  NO mechanical parts 
> need APPLY!  Motors, fans, bearings,
> disk drives, etc. are totally reliable!  Also, all 
> connectors, switches, and wiring are
> not prone to failure.

Yeah; and as for those MTBF figures for small bearings... The last lot I used 
in my lathe fixed steady lasted for ages; except for the one which failed after 
15 minutes ruining the job. It was small consolation to be told the 
'thousands of hours to failure' was an average...

> 
> The whole system is TOTAL BALONEY, but it is STILL used in 
> many industries, because
> it makes such WONDERFUL numbers, even though anybody who 
> cares KNOWS it
> is all FAKE!  (DoD knows the whole methodology is bogus, and 
> has gone back to
> more supportable methods of assessing reliability.)
> 
> Sorry, rant mode off for now.
> 
> Jon
> 
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Dave Cole]

On 12/3/2014 12:59 PM, andy pugh wrote:
> On 3 December 2014 at 15:46, Dave Cole  wrote:
>> I believe the super reliable Acopians are the Gold Box units.   But you
>> should contact them and ask them what is their most reliable power
>> supply design these days.
>>
>> http://www.acopian.com/
> In the UK the best source might be eBay, and those have all passed the
> infant-mortality phase too :-)
>

That is probably a good idea!  Acopian likely has a date code on their 
units so you should be able to figure out how old they are.

Dave

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[andy pugh]

On 3 December 2014 at 15:46, Dave Cole  wrote:
> I believe the super reliable Acopians are the Gold Box units.   But you
> should contact them and ask them what is their most reliable power
> supply design these days.
>
> http://www.acopian.com/

In the UK the best source might be eBay, and those have all passed the
infant-mortality phase too :-)


-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Evan Foss]

While I agree with that rant I can say that a lot of higher end stuff
does get environmental testing. My stuff lives in a hotter than
average environment and so I have to consider this.

Also my father has worked for a few different companies that for
defense and enterprise level hardware had to do these tests. (One even
had an earthquake simulator)

On Wed, Dec 3, 2014 at 12:25 PM, Jon Elson  wrote:
> On 12/03/2014 07:40 AM, Marius Liebenberg wrote:
>> Andy
>> MTBF is obtained by testing a number of units over a period of time at
>> accelerated environmental conditions.
> MTBF CAN be evaluated this way, and it is a more truthful
> way to do it, but it requires a LOT
> of units and long testing on hi-rel systems.  So, the DoD,
> long ago, came up with this
> crazy scheme to do it ALL on paper, with not a single actual
> test needing to be performed.
> This was all worked out by the Defense Electronic Supply
> Center back in the 1970's,
> and I watched in total shock and amazement when the trade
> mags described how this
> all was to be done.  DESC no longer exists, and I think this
> whole debacle had something
> to do with that.
>
> You look up in a book published by DESC what the reliability
> of a specific resistor, transistor,
> capacitor, etc. was, and then add up all of those parts and
> put them into an equation
> that gives you a total reliability.  NO mechanical parts
> need APPLY!  Motors, fans, bearings,
> disk drives, etc. are totally reliable!  Also, all
> connectors, switches, and wiring are
> not prone to failure.
>
> The whole system is TOTAL BALONEY, but it is STILL used in
> many industries, because
> it makes such WONDERFUL numbers, even though anybody who
> cares KNOWS it
> is all FAKE!  (DoD knows the whole methodology is bogus, and
> has gone back to
> more supportable methods of assessing reliability.)
>
> Sorry, rant mode off for now.
>
> Jon
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Stuck on a G2 move (again)

[John Thornton]

The same thing as a subroutine.

; 90 degree cw arc in quadrant 1 0-90 degrees

o100 sub
G91
G2 X#1 Y-#1 I0.0 J-#1
G90
o100 endsub

G1 X0 Y0 F10
o100 call [0.250]
G0 X1 Y-1
o100 call [0.50]

M2

JT
On 12/3/2014 9:39 AM, Gene Heskett wrote:
> On Wednesday 03 December 2014 07:34:59 John Thornton did opine
> And Gene did reply:
>> The default behavior for arc distance is incremental so for a given arc
>> you only have to change the start and end points to be correct.
>>
>> For example with the center of the arc at X0 Y0 and a 0.510 diameter
>> and starting at 180 and going CW to 90 the G code is:
>> G0 X-0.2550 Y0.
>> G2 X0. Y0.2550 I0.2550 J0.
>>
>> If I move the center to X1 Y1 then the G code is:
>> G0 X0.7450  Y1.
>> G2 X1. Y1.2550 I0.2550 J0.
>>
>> Notice that I and J remain the same and both the start point and the
>> end points change by the difference in center locations.
>>
>> JT
> That "center locations" is a different concept to me I guess.
>
> And maybe that why I have such a hell of a time with g2/g3.
>
> My theory I have been using is to drive the machine (g1) to the start
> point of the arc. Like:
> g1 xstarting xpoint
> g1 ystarting ypoint
> xpoint += tooldia
> ypoint += tooldia
> g2 Xxpoint Yypoint I or Jtooldia dependent on quadrant.
>
> I am intending to do 90 degree arcs to round corners.
> The y coords are always negative as I had to put the homing contacts as
> a brass corner screwed to a flip it out of the way after use, hinged
> stop that will locate the end of the board. Its located arbitrarily near
> the center of the table in the x direction, and the front of the 1/4"
> tool, when zeroed and driven to touch the board is y = -.323"
>
> what I have now, with the g2 moves commented out, and a move AFTER the
> arc callthat shows a 45 degree angle line to put the tool at the end of
> the arc, a useless line of code if the arc works because it will already
> be at the end of the arc when that move is executed successfully.
>
> So I have a right corner sub and a left corner sub.
>
> o sub
> ( to cut right corners )
> (debug,RightC x_tmp=#<_x_tmp>)
> (debug,RightC y_tmp=#<_y_tmp>)
> (debug,RightC J=tdia=#<_tdia>)
> ( arcbuddy = G2 X0.2550 Y0. I-0. J-0.2550 starting @ X0. Y0.2550 )
> (G2 X[#<_x_tmp> + #<_tdia>] Y#<_y_tmp>  J-#<_tdia>)
> o endsub
>
> o sub
> ( to cut left corners )
> (debug,leftC x_tmp=#<_x_tmp>)
> (debug,LeftC y_tmp=#<_y_tmp>)
> (debug,LeftC tdia=#<_tdia>)
> ( arcbuddy = G2 X0. Y0.2550 I0.255 J-0. starting @ X-0.2550 Y0. )
> (G2 X#<_x_tmp> Y[#<_y_tmp> - #<_tdia>] I#<_tdia>)
> o endsub
>
> With the G2 moves short circuited by (), the debugs are showing what I
> think should be the correct values, but it all goes boom with large errors if
> the G2 move is enabled.
>
> I'll step it to the first, right corner right now:
> Machine is at X-3.890 Y-.323
> x_tmp = -3.635 passed to right sub
> y_tmp = -.5780 ditto
> tdia  = .2550
>
> It draws a line in the correct locations to join the start and end
> positions of the curve wanted.
>
> Stepping to the first left corner:
> Machine is driven to X-2.6400 Y-.5780
> x_tmp = -2.385000
> y_tmp = -.323000
> tdia  = .255000
>
> But if I enable the G2 in RightC, and force step it, then the screen that
> LCNC was launched from will spit out this (reformatted for clarity):
>
> emc/task/emctask.cc 389: interp_error:
> Radius to end of arc differs from radius to start:
> start=(X-3.8900,Y-0.3230)
> center=(X-3.8900,Y-0.5780)
> end=(X-3.3800,Y-0.5780)
> r1=0.2550
> r2=0.5100
> abs_err=0.255
> rel_err=50.%
> Radius to end of arc differs from radius to start:
> start=(X-3.8900,Y-0.3230)
> center=(X-3.8900,Y-0.5780)
> end=(X-3.3800,Y-0.5780)
> r1=0.2550
> r2=0.5100
> abs_err=0.255
> rel_err=50.%
>
> Why it spit it out twice I have no clue but thats one attempt.
>
> So where have I failed in translating this to function anyplace the table
> can each?
>
> Is my start at curve start, goto end with what I tell G2, set radius at offset
> method AFU?
>
> FWIW, I also used the code straight out of arcbuddy but put a G91 in front
> of the G2, and a G90 after. Seemingly no effect on the error msg itself.
>
> [...]
>
> Thanks Big John.
>
> Cheers, Gene Heskett


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Stuck on a G2 move (again)

[John Thornton]

Gene,

Your confusing me LOL...

Here is a sample program to move in an arc in quadrant 1 from 0 degrees 
to 90 degrees. You only have to move to the start position then pass the 
radius of your arc. After the G90 it moves to a second location then 
does the same arc.

; 90 degree cw arc in quadrant 1 0-90 degrees

#1 = 0.250  (radius of the arc)
; move to first location
G1 X0 Y0 F10
G91
G2 X#1 Y-#1 I0.0 J-#1
G90
; move to next location
G0 X1 Y-1
G91
G2 X#1 Y-#1 I0.0 J-#1
G90


M2


JT
On 12/3/2014 9:39 AM, Gene Heskett wrote:
> On Wednesday 03 December 2014 07:34:59 John Thornton did opine
> And Gene did reply:
>> The default behavior for arc distance is incremental so for a given arc
>> you only have to change the start and end points to be correct.
>>
>> For example with the center of the arc at X0 Y0 and a 0.510 diameter
>> and starting at 180 and going CW to 90 the G code is:
>> G0 X-0.2550 Y0.
>> G2 X0. Y0.2550 I0.2550 J0.
>>
>> If I move the center to X1 Y1 then the G code is:
>> G0 X0.7450  Y1.
>> G2 X1. Y1.2550 I0.2550 J0.
>>
>> Notice that I and J remain the same and both the start point and the
>> end points change by the difference in center locations.
>>
>> JT
> That "center locations" is a different concept to me I guess.
>
> And maybe that why I have such a hell of a time with g2/g3.
>
> My theory I have been using is to drive the machine (g1) to the start
> point of the arc. Like:
> g1 xstarting xpoint
> g1 ystarting ypoint
> xpoint += tooldia
> ypoint += tooldia
> g2 Xxpoint Yypoint I or Jtooldia dependent on quadrant.
>
> I am intending to do 90 degree arcs to round corners.
> The y coords are always negative as I had to put the homing contacts as
> a brass corner screwed to a flip it out of the way after use, hinged
> stop that will locate the end of the board. Its located arbitrarily near
> the center of the table in the x direction, and the front of the 1/4"
> tool, when zeroed and driven to touch the board is y = -.323"
>
> what I have now, with the g2 moves commented out, and a move AFTER the
> arc callthat shows a 45 degree angle line to put the tool at the end of
> the arc, a useless line of code if the arc works because it will already
> be at the end of the arc when that move is executed successfully.
>
> So I have a right corner sub and a left corner sub.
>
> o sub
> ( to cut right corners )
> (debug,RightC x_tmp=#<_x_tmp>)
> (debug,RightC y_tmp=#<_y_tmp>)
> (debug,RightC J=tdia=#<_tdia>)
> ( arcbuddy = G2 X0.2550 Y0. I-0. J-0.2550 starting @ X0. Y0.2550 )
> (G2 X[#<_x_tmp> + #<_tdia>] Y#<_y_tmp>  J-#<_tdia>)
> o endsub
>
> o sub
> ( to cut left corners )
> (debug,leftC x_tmp=#<_x_tmp>)
> (debug,LeftC y_tmp=#<_y_tmp>)
> (debug,LeftC tdia=#<_tdia>)
> ( arcbuddy = G2 X0. Y0.2550 I0.255 J-0. starting @ X-0.2550 Y0. )
> (G2 X#<_x_tmp> Y[#<_y_tmp> - #<_tdia>] I#<_tdia>)
> o endsub
>
> With the G2 moves short circuited by (), the debugs are showing what I
> think should be the correct values, but it all goes boom with large errors if
> the G2 move is enabled.
>
> I'll step it to the first, right corner right now:
> Machine is at X-3.890 Y-.323
> x_tmp = -3.635 passed to right sub
> y_tmp = -.5780 ditto
> tdia  = .2550
>
> It draws a line in the correct locations to join the start and end
> positions of the curve wanted.
>
> Stepping to the first left corner:
> Machine is driven to X-2.6400 Y-.5780
> x_tmp = -2.385000
> y_tmp = -.323000
> tdia  = .255000
>
> But if I enable the G2 in RightC, and force step it, then the screen that
> LCNC was launched from will spit out this (reformatted for clarity):
>
> emc/task/emctask.cc 389: interp_error:
> Radius to end of arc differs from radius to start:
> start=(X-3.8900,Y-0.3230)
> center=(X-3.8900,Y-0.5780)
> end=(X-3.3800,Y-0.5780)
> r1=0.2550
> r2=0.5100
> abs_err=0.255
> rel_err=50.%
> Radius to end of arc differs from radius to start:
> start=(X-3.8900,Y-0.3230)
> center=(X-3.8900,Y-0.5780)
> end=(X-3.3800,Y-0.5780)
> r1=0.2550
> r2=0.5100
> abs_err=0.255
> rel_err=50.%
>
> Why it spit it out twice I have no clue but thats one attempt.
>
> So where have I failed in translating this to function anyplace the table
> can each?
>
> Is my start at curve start, goto end with what I tell G2, set radius at offset
> method AFU?
>
> FWIW, I also used the code straight out of arcbuddy but put a G91 in front
> of the G2, and a G90 after. Seemingly no effect on the error msg itself.
>
> [...]
>
> Thanks Big John.
>
> Cheers, Gene Heskett


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___

Re: [Emc-users] MTBF

[Jon Elson]

On 12/03/2014 07:40 AM, Marius Liebenberg wrote:
> Andy
> MTBF is obtained by testing a number of units over a period of time at
> accelerated environmental conditions.
MTBF CAN be evaluated this way, and it is a more truthful 
way to do it, but it requires a LOT
of units and long testing on hi-rel systems.  So, the DoD, 
long ago, came up with this
crazy scheme to do it ALL on paper, with not a single actual 
test needing to be performed.
This was all worked out by the Defense Electronic Supply 
Center back in the 1970's,
and I watched in total shock and amazement when the trade 
mags described how this
all was to be done.  DESC no longer exists, and I think this 
whole debacle had something
to do with that.

You look up in a book published by DESC what the reliability 
of a specific resistor, transistor,
capacitor, etc. was, and then add up all of those parts and 
put them into an equation
that gives you a total reliability.  NO mechanical parts 
need APPLY!  Motors, fans, bearings,
disk drives, etc. are totally reliable!  Also, all 
connectors, switches, and wiring are
not prone to failure.

The whole system is TOTAL BALONEY, but it is STILL used in 
many industries, because
it makes such WONDERFUL numbers, even though anybody who 
cares KNOWS it
is all FAKE!  (DoD knows the whole methodology is bogus, and 
has gone back to
more supportable methods of assessing reliability.)

Sorry, rant mode off for now.

Jon

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Jon Elson]

On 12/03/2014 07:38 AM, Marcus Bowman wrote:
> http://www.proz.com/kudoz/german_to_english/business_commerce_general/1072093-mio.html
> tells us it is Million hours.
>
> Interestingly, though, the term does not appear in BS EN 61709:2011 Electric 
> components - Reliability - Reference conditions for failure rates and stress 
> models for conversion.
>
> I don't believe 1500 Million hours. It is, in any case, a calculated value 
> (not that there's anything wrong with that). If the unit contains large 
> capacitors, 1500 hours is a much more realistic figure. Short; yes. But 
> realistic.
>
>
This whole system of evaluating MTBF came from some stupid 
US Defense Department
acquisition requirement that reliability of equipment be 
calculated by a VERY rigid
and methodical approach.  You use the highest temperature 
the equipment is rated
to operate at, then the lifetime of every electrical 
component is computed based on
temperature (including self-heating from power dissipation) 
and then the whole
system reliability is computed with an equation that 
combines all the parts.

It totally screws up because it does not include connectors, 
wiring, solder joints,
fan motors, drive motors, etc.  So, that is why disk drives 
have these multi-100K
hour MTBFs quoted.  Everybody knows if you run a typical 
hard drive for
5 years you are deeply into living on "borrowed time".  5 
years is 40K hours.

So, the whole system si so TOTALLY flawed as to be 
absolutely meaningless for any
real "system".  Certainly, anything that has aluminum 
electrolytic caps used in
a power supply has a lifetime in the 20 - 40K hours range, 
although this is at
least extended by periods where the equipment is off, and 
made worse by
high temperatures.

One other place the military screwed up, is Tantalum 
capacitors. These have the
bad characteristic that they can be VERY reliable if used 
CONSTANTLY.  That means
either on all the time, or used every few days.  But, make 
something with
tantalum caps, test it rigorously, and then put it in a 
supply depot for a couple
years, and you will almost CERTAINLY find the caps short out 
and blow (as
in fire and smoke) when you then put it into use.  The 
military pretty much
outlawed aluminum electrolytics.

Jon

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] CF drive load

[Viesturs Lācis]

2014-12-02 19:17 GMT+02:00 dave :
> Hi all,
> I'm trying to migrate from my ancient mb on the cinci to a D525MW.
> The system device is an 8 mb CF plugged into one of mesa's CF to SATA
> adapters. My linux install won't format it.  i.e. install sees my usb
> flash drive

I did the same few years ago - attached CF card through SATA adapter
(bought on ebay) to D525MW board. Installing 10.04 on it worked just
fine.

I would suggest checking, if BIOS recognizes it (checking boot device
list might be quickest way). What version of Ubuntu are you trying?
IMHO trying different version is an option.

Viesturs

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Dave Cole]

On 12/3/2014 9:27 AM, andy pugh wrote:
> On 3 December 2014 at 13:38, Marcus Bowman
>  wrote:
>
>> I don't believe 1500 Million hours. It is, in any case, a calculated value 
>> (not that there's anything wrong with that). If the unit contains large 
>> capacitors, 1500 hours is a much more realistic figure. Short; yes. But 
>> realistic.
> 63 days? That doesn't seem _that_ much more plausible than 170,000 years.
>
> Given that (statistically) only 38% of parts would be expected to get
> to the MTBF time it looks even worse.
>
> The background here is a 24V supply for a pulse clock. The clock has
> been running since 1957 and still would be were it not that the master
> clock was in a demolished building. I would like to think that the PSU
> I choose would last for 10 years or more. (I plan to put a
> hot-swappable replacement in the case too)

I buy and install and replace a lot of switcher power supplies.

I would expect a decent industrial 24 volt switchers to last over 10 
years, with some failing in the first few years and some making it to 15 
years but that is about it.

If you push it to near capacity expect it to have a much shorter life.. 
maybe 5 years.

The brand does seems to matter much.   Expensive Siemens switchers seem 
to last about as long as cheap Meanwell switchers.  They are all trying 
to sell to the same market and the downward price pressure is fierce.

If you want a power supply that you can install, power up and have a 
fair expectation of it lasting 25+ years I would go with an Acopian 
linear power supply.

Back in the 80's I was involved in a expansion of a distillery that had 
been in operation in the same location for over 150 years when I worked 
there.   Their perspective is that everything should last. Their 
buildings are all brick with copper flashing and many are over 100 years 
old and still in very good condition.That was 27 years ago.   That 
building that they put up 27 years ago is still considered the "new" 
tank room building.  I still do work at that distillery ocassionally and 
work and rework the same equipment that I helped install and program 27 
years ago.   When they put up the "new" building 27 years ago and 
installed new state of the art instrumentation and controls (since 
replaced 2 times) they installed Acopian instrument grade power supplies 
which were expensive and seemed like an over kill.  Although they have 
replaced the controllers twice since the build, the same Acopian linear 
power supplies power the controls and instruments.   NOW I understand 
why they spent the cash on the Acopian power supplies.  :-)They 
NEVER planned on replacing them.

I believe the super reliable Acopians are the Gold Box units.   But you 
should contact them and ask them what is their most reliable power 
supply design these days.

http://www.acopian.com/

Dave

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Stuck on a G2 move (again)

[Gene Heskett]

On Wednesday 03 December 2014 07:34:59 John Thornton did opine
And Gene did reply:
> The default behavior for arc distance is incremental so for a given arc
> you only have to change the start and end points to be correct.
> 
> For example with the center of the arc at X0 Y0 and a 0.510 diameter
> and starting at 180 and going CW to 90 the G code is:
> G0 X-0.2550 Y0.
> G2 X0. Y0.2550 I0.2550 J0.
> 
> If I move the center to X1 Y1 then the G code is:
> G0 X0.7450  Y1.
> G2 X1. Y1.2550 I0.2550 J0.
> 
> Notice that I and J remain the same and both the start point and the
> end points change by the difference in center locations.
> 
> JT

That "center locations" is a different concept to me I guess.

And maybe that why I have such a hell of a time with g2/g3.

My theory I have been using is to drive the machine (g1) to the start 
point of the arc. Like:
g1 xstarting xpoint
g1 ystarting ypoint
xpoint += tooldia
ypoint += tooldia
g2 Xxpoint Yypoint I or Jtooldia dependent on quadrant.

I am intending to do 90 degree arcs to round corners.
The y coords are always negative as I had to put the homing contacts as 
a brass corner screwed to a flip it out of the way after use, hinged 
stop that will locate the end of the board. Its located arbitrarily near 
the center of the table in the x direction, and the front of the 1/4" 
tool, when zeroed and driven to touch the board is y = -.323"

what I have now, with the g2 moves commented out, and a move AFTER the 
arc callthat shows a 45 degree angle line to put the tool at the end of 
the arc, a useless line of code if the arc works because it will already 
be at the end of the arc when that move is executed successfully.

So I have a right corner sub and a left corner sub.

o sub
( to cut right corners )
(debug,RightC x_tmp=#<_x_tmp>)
(debug,RightC y_tmp=#<_y_tmp>)
(debug,RightC J=tdia=#<_tdia>)
( arcbuddy = G2 X0.2550 Y0. I-0. J-0.2550 starting @ X0. Y0.2550 )
(G2 X[#<_x_tmp> + #<_tdia>] Y#<_y_tmp>  J-#<_tdia>)
o endsub

o sub
( to cut left corners )
(debug,leftC x_tmp=#<_x_tmp>)
(debug,LeftC y_tmp=#<_y_tmp>)
(debug,LeftC tdia=#<_tdia>)
( arcbuddy = G2 X0. Y0.2550 I0.255 J-0. starting @ X-0.2550 Y0. )
(G2 X#<_x_tmp> Y[#<_y_tmp> - #<_tdia>] I#<_tdia>)
o endsub

With the G2 moves short circuited by (), the debugs are showing what I 
think should be the correct values, but it all goes boom with large errors if
the G2 move is enabled.

I'll step it to the first, right corner right now:
Machine is at X-3.890 Y-.323
x_tmp = -3.635 passed to right sub 
y_tmp = -.5780 ditto
tdia  = .2550

It draws a line in the correct locations to join the start and end 
positions of the curve wanted.

Stepping to the first left corner:
Machine is driven to X-2.6400 Y-.5780
x_tmp = -2.385000
y_tmp = -.323000
tdia  = .255000

But if I enable the G2 in RightC, and force step it, then the screen that
LCNC was launched from will spit out this (reformatted for clarity):

emc/task/emctask.cc 389: interp_error: 
Radius to end of arc differs from radius to start: 
start=(X-3.8900,Y-0.3230)
center=(X-3.8900,Y-0.5780) 
end=(X-3.3800,Y-0.5780) 
r1=0.2550 
r2=0.5100 
abs_err=0.255 
rel_err=50.%
Radius to end of arc differs from radius to start: 
start=(X-3.8900,Y-0.3230) 
center=(X-3.8900,Y-0.5780) 
end=(X-3.3800,Y-0.5780) 
r1=0.2550 
r2=0.5100 
abs_err=0.255 
rel_err=50.%

Why it spit it out twice I have no clue but thats one attempt.

So where have I failed in translating this to function anyplace the table 
can each?

Is my start at curve start, goto end with what I tell G2, set radius at offset
method AFU?

FWIW, I also used the code straight out of arcbuddy but put a G91 in front 
of the G2, and a G90 after. Seemingly no effect on the error msg itself.

[...]

Thanks Big John.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Eric Keller]

So they tested a batch of parts and projected out to the point where 63
percent will have failed using some assumed distribution of failure times.
Not hard to get to 171 years using that methodology.  It ignores the common
case where there is a mode of failure that causes the failures to be
clustered, but at least it gives you a decent idea of what to  expect
relative to other, similar parts.  I'm sure they are not claiming their
MTBF is less than a year.  Just to recap, the test results would be used to
estimate the parameters of the assumed failure distribution.  From the
resulting statistical model, you would be able to determine the point at
which a given percentage would fail

I was dragged kicking and screaming through a semester of
reliability/probability/statistics sometime back in the '80s.  So it's been
a while since I knew exactly what they would be doing.  But that's the gist
of it.


On Wed, Dec 3, 2014 at 9:27 AM, andy pugh  wrote:

> On 3 December 2014 at 13:38, Marcus Bowman
>  wrote:
>
> > I don't believe 1500 Million hours. It is, in any case, a calculated
> value (not that there's anything wrong with that). If the unit contains
> large capacitors, 1500 hours is a much more realistic figure. Short; yes.
> But realistic.
>
> 63 days? That doesn't seem _that_ much more plausible than 170,000 years.
>
> Given that (statistically) only 38% of parts would be expected to get
> to the MTBF time it looks even worse.
>
> The background here is a 24V supply for a pulse clock. The clock has
> been running since 1957 and still would be were it not that the master
> clock was in a demolished building. I would like to think that the PSU
> I choose would last for 10 years or more. (I plan to put a
> hot-swappable replacement in the case too)
>
> --
> atp
> If you can't fix it, you don't own it.
> http://www.ifixit.com/Manifesto
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Steve Stallings]

Traco appears to be a company whose main offices
are located in German speaking areas.

Mio is used as an abbreviation for Million, especially
in German.

The document that you linked seems to use a mixture 
of . and , as the symbol for the decimal point.

I found many references to MTBF for power supplies
specified with a MTBF of between 1 and 5 Mio hours,
so my assumption would be that Traco intended the
specification to be one and a half million hours.

Steve Stallings

> -Original Message-
> From: andy pugh [mailto:bodge...@gmail.com] 
> Sent: Wednesday, December 03, 2014 7:21 AM
> To: Enhanced Machine Controller (EMC)
> Subject: [Emc-users] MTBF
> 
> Does anyone know how to interpret MTBF numbers?
> 
> http://docs-europe.electrocomponents.com/webdocs/0d17/0900766b
> 80d17a55.pdf
> 
> Specifically. 1500 hours doesn't seem very long,
> 
> -- 
> atp
> If you can't fix it, you don't own it.
> http://www.ifixit.com/Manifesto
> 
> --
> 
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and 
> Dashboards
> with Interactivity, Sharing, Native Excel Exports, App 
> Integration & more
> Get technology previously reserved for billion-dollar 
> corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/41
> 40/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
> 


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[andy pugh]

On 3 December 2014 at 13:38, Marcus Bowman
 wrote:

> I don't believe 1500 Million hours. It is, in any case, a calculated value 
> (not that there's anything wrong with that). If the unit contains large 
> capacitors, 1500 hours is a much more realistic figure. Short; yes. But 
> realistic.

63 days? That doesn't seem _that_ much more plausible than 170,000 years.

Given that (statistically) only 38% of parts would be expected to get
to the MTBF time it looks even worse.

The background here is a 24V supply for a pulse clock. The clock has
been running since 1957 and still would be were it not that the master
clock was in a demolished building. I would like to think that the PSU
I choose would last for 10 years or more. (I plan to put a
hot-swappable replacement in the case too)

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Multiple glade sub-panels

[alex chiosso]

Hi Marius.
Is the hal pins naming your problem ?
If it is maybe it is a no_problem .
I mean because you can freely name the hal widgets that creates hal pins
you can name i.e gladevcp.01_hal_pin_name for the "panel 1" ,
gladevcp.02_hal_pin_name for the "panel 2" and so on.
I would use the Notebook Container for this purpose to layout the panels .
Why do you need three separate instances on the Python module ?
Dou you use the persistence feature for the vcp panels ?

Alex

On Tue, Dec 2, 2014 at 10:42 PM, andy pugh  wrote:

> On 2 December 2014 at 21:31, Marius Alksnys 
> wrote:
> > Could someone point me the direction how to load three sub-panels from
> > the same glade file into one panel, using hbox or similar.
>
> I don't think that there are any short-cuts, you will probably have to
> create three identical sub-panels.
>
> (If you want a variable number, then you may need to create the max
> number and hide some).
>
> The other (harder) option would be to create them all programmatically.
>
> --
> atp
> If you can't fix it, you don't own it.
> http://www.ifixit.com/Manifesto
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Evan Foss]

I have used a lot of stuff from that company. While none of it was
this specific part I can say it was all very reliable.

On Wed, Dec 3, 2014 at 8:45 AM, Marius Liebenberg
 wrote:
> Normally it is quoted in hours of service.
>
> On 2014-12-03 15:11, andy pugh wrote:
>> On 3 December 2014 at 12:55, John Thornton  wrote:
>>> http://en.wikipedia.org/wiki/Mean_time_between_failures
>> I sort-of understand MTBF, what I don't understand are the units they
>> are quoting it in.
>>
>
> --
>
> Regards /Groete
>
> Marius D. Liebenberg
> +27 82 698 3251
> +27 12 743 6064
> QQ 1767394877
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Marius Liebenberg]

Normally it is quoted in hours of service.

On 2014-12-03 15:11, andy pugh wrote:
> On 3 December 2014 at 12:55, John Thornton  wrote:
>> http://en.wikipedia.org/wiki/Mean_time_between_failures
> I sort-of understand MTBF, what I don't understand are the units they
> are quoting it in.
>

-- 

Regards /Groete

Marius D. Liebenberg
+27 82 698 3251
+27 12 743 6064
QQ 1767394877


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Stuck on a G2 move (again)

[Marcus Bowman]

I guess that's why a complete circle does not require the X and Y values 
(because it already knows where the controlled point is) and just needs the G2 
I J command.

Marcus

On 3 Dec 2014, at 12:34, John Thornton wrote:

> The default behavior for arc distance is incremental so for a given arc 
> you only have to change the start and end points to be correct.
> 
> For example with the center of the arc at X0 Y0 and a 0.510 diameter and 
> starting at 180 and going CW to 90 the G code is:
> G0 X-0.2550 Y0.
> G2 X0. Y0.2550 I0.2550 J0.
> 
> If I move the center to X1 Y1 then the G code is:
> G0 X0.7450  Y1.
> G2 X1. Y1.2550 I0.2550 J0.
> 
> Notice that I and J remain the same and both the start point and the end 
> points change by the difference in center locations.
> 
> JT
> 
> 
> On 12/2/2014 4:18 PM, Gene Heskett wrote:
>> Greetings;
>> 
>> I have generated a couple bits of g2 code to cut a 90 degree arc corner
>> 
>>> From 180 to 90, with a .51000 diameter, arcbuddy spits out:
>> 
>> G2 X0. Y0.2550 I0.2550 J-0.
>> 
>> And from 90 to 0, same diameter it outputs:
>> 
>> G2 X0.2550 Y0. I-0. J-0.2550
>> 
>> No tool comp is in use
>> 
>> Tooldia and toolrad are defined as .255  and .255 /2 elsewhere
>> 
>> x_tmp and y_tmp are defined and diddled elsewhere in the code.
>> 
>> So, where do I plug these vars into the arcbuddy output you see above to
>> make it usable anyplace the table can reach just by adjusting the x_tmp
>> and y_tmp
>> But, I need this to be usable at anyplace along the x axis, with 2
>> different y locations depending on whether the last move was X or the last
>> move was Y, all of which also contains what is supposed to be tool
>> diameter offsets in the I & J stuff.
>> 
>>> From the above its obvious I can sub the Ioffset for I#<_tdia> in the
>> first example above and J-#<_tdia> in the second to make it self
>> compensating if I change the tools diameter, which will be used to control
>> the fit of the joints produced.  But even that is not working.
>> 
>> So, how does one go about plugging in his "offset" values in a G2
>> statement above and make it work?
>> 
>> I ought to be about ready for dinner, but Dee doesn't feel like going out
>> even if it is our 25th anniversary today.  COPD never gets better.
>> Dammit.
>> 
>> So I am working on this instead.
>> 
>> Thanks & Cheers, Gene Heskett
> 
> 
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Marius Liebenberg]

Andy
MTBF is obtained by testing a number of units over a period of time at 
accelerated environmental conditions. First the infant mortality of a 
product is determined and then the MTBF is deduced. Some suppliers have 
an MTBF based on the number of products produced compared to the number 
of returned or reported failures. Not always very scientific or even 
accurate. So 1700 hours could be correct for products that are subjected 
to sales over faults reports.

Doing MTBF and infant mortality tests are usually reserved for military 
or mission critical equipment and is very expensive to conduct as all 
the samples are usually tested to destruction in order to determine 
useful life expectancy.

On 2014-12-03 14:20, andy pugh wrote:
> Does anyone know how to interpret MTBF numbers?
>
> http://docs-europe.electrocomponents.com/webdocs/0d17/0900766b80d17a55.pdf
>
> Specifically. 1500 hours doesn't seem very long,
>

-- 

Regards /Groete

Marius D. Liebenberg
+27 82 698 3251
+27 12 743 6064
QQ 1767394877


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Marcus Bowman]

http://www.proz.com/kudoz/german_to_english/business_commerce_general/1072093-mio.html
tells us it is Million hours.

Interestingly, though, the term does not appear in BS EN 61709:2011 Electric 
components - Reliability - Reference conditions for failure rates and stress 
models for conversion.

I don't believe 1500 Million hours. It is, in any case, a calculated value (not 
that there's anything wrong with that). If the unit contains large capacitors, 
1500 hours is a much more realistic figure. Short; yes. But realistic.

I wonder how the manufacturer would respond to a direct question?

Marcus


On 3 Dec 2014, at 13:14, andy pugh wrote:

> On 3 December 2014 at 12:55, Stuart Stevenson  wrote:
>> Searching for 'probability Mio' yields some interesting papers.
> 
> It does, though very few related the subject at hand. (If using the quotes)
> 
> -- 
> atp
> If you can't fix it, you don't own it.
> http://www.ifixit.com/Manifesto
> 
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[andy pugh]

On 3 December 2014 at 12:55, Stuart Stevenson  wrote:
> Searching for 'probability Mio' yields some interesting papers.

It does, though very few related the subject at hand. (If using the quotes)

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[andy pugh]

On 3 December 2014 at 12:55, John Thornton  wrote:
> http://en.wikipedia.org/wiki/Mean_time_between_failures

I sort-of understand MTBF, what I don't understand are the units they
are quoting it in.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Stuart Stevenson]

Searching for 'probability Mio' yields some interesting papers.

On Wed, Dec 3, 2014 at 6:45 AM, andy pugh  wrote:

> On 3 December 2014 at 12:42, alex chiosso  wrote:
> > You're right Rick . ;-)
>
> I still don't believe 1,500 x million hours.
>
> I suppose it could be a Euro-style decimal separator, and therefore
> 1.5 million hours, but that is still 171 years MTBF.
> (which would be ideal, but seems high)
>
> --
> atp
> If you can't fix it, you don't own it.
> http://www.ifixit.com/Manifesto
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>



-- 
Addressee is the intended audience.
If you are not the addressee then my consent is not given for you to read
this email furthermore it is my wish you would close this without saving or
reading, and cease and desist from saving or opening my private
correspondence.
Thank you for honoring my wish.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[John Thornton]

http://en.wikipedia.org/wiki/Mean_time_between_failures

On 12/3/2014 6:45 AM, andy pugh wrote:
> On 3 December 2014 at 12:42, alex chiosso  wrote:
>> You're right Rick . ;-)
> I still don't believe 1,500 x million hours.
>
> I suppose it could be a Euro-style decimal separator, and therefore
> 1.5 million hours, but that is still 171 years MTBF.
> (which would be ideal, but seems high)
>


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[andy pugh]

On 3 December 2014 at 12:42, alex chiosso  wrote:
> You're right Rick . ;-)

I still don't believe 1,500 x million hours.

I suppose it could be a Euro-style decimal separator, and therefore
1.5 million hours, but that is still 171 years MTBF.
(which would be ideal, but seems high)

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[alex chiosso]

You're right Rick . ;-)

On Wed, Dec 3, 2014 at 1:27 PM, Rick Lair  wrote:

> It looks like " over 1500 'millions of hours' of 'Mean Time Between
> Failures' "
>
>
> Thanks
>
>
> Rick
>
>
>
> -- Original Message --
> From: "andy pugh" 
> To: "Enhanced Machine Controller (EMC)"
> 
> Sent: 12/3/2014 7:20:32 AM
> Subject: [Emc-users] MTBF
>
> >Does anyone know how to interpret MTBF numbers?
> >
> >
> http://docs-europe.electrocomponents.com/webdocs/0d17/0900766b80d17a55.pdf
> >
> >Specifically. 1500 hours doesn't seem very long,
> >
> >--
> >atp
> >If you can't fix it, you don't own it.
> >http://www.ifixit.com/Manifesto
> >
>
> >--
> >Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> >from Actuate! Instantly Supercharge Your Business Reports and
> >Dashboards
> >with Interactivity, Sharing, Native Excel Exports, App Integration &
> >more
> >Get technology previously reserved for billion-dollar corporations,
> >FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> >___
> >Emc-users mailing list
> >Emc-users@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[andy pugh]

On 3 December 2014 at 12:27, Rick Lair  wrote:
> It looks like " over 1500 'millions of hours' of 'Mean Time Between
> Failures' "

But that would be 170,000 years, which seems unlikely too.

Even 1500 x 1000 hours (170 years) seems unlikely.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Stuck on a G2 move (again)

[John Thornton]

The default behavior for arc distance is incremental so for a given arc 
you only have to change the start and end points to be correct.

For example with the center of the arc at X0 Y0 and a 0.510 diameter and 
starting at 180 and going CW to 90 the G code is:
G0 X-0.2550 Y0.
G2 X0. Y0.2550 I0.2550 J0.

If I move the center to X1 Y1 then the G code is:
G0 X0.7450  Y1.
G2 X1. Y1.2550 I0.2550 J0.

Notice that I and J remain the same and both the start point and the end 
points change by the difference in center locations.

JT


On 12/2/2014 4:18 PM, Gene Heskett wrote:
> Greetings;
>
> I have generated a couple bits of g2 code to cut a 90 degree arc corner
>
> >From 180 to 90, with a .51000 diameter, arcbuddy spits out:
>
> G2 X0. Y0.2550 I0.2550 J-0.
>
> And from 90 to 0, same diameter it outputs:
>
> G2 X0.2550 Y0. I-0. J-0.2550
>
> No tool comp is in use
>
> Tooldia and toolrad are defined as .255  and .255 /2 elsewhere
>
> x_tmp and y_tmp are defined and diddled elsewhere in the code.
>
> So, where do I plug these vars into the arcbuddy output you see above to
> make it usable anyplace the table can reach just by adjusting the x_tmp
> and y_tmp
> But, I need this to be usable at anyplace along the x axis, with 2
> different y locations depending on whether the last move was X or the last
> move was Y, all of which also contains what is supposed to be tool
> diameter offsets in the I & J stuff.
>
> >From the above its obvious I can sub the Ioffset for I#<_tdia> in the
> first example above and J-#<_tdia> in the second to make it self
> compensating if I change the tools diameter, which will be used to control
> the fit of the joints produced.  But even that is not working.
>
> So, how does one go about plugging in his "offset" values in a G2
> statement above and make it work?
>
> I ought to be about ready for dinner, but Dee doesn't feel like going out
> even if it is our 25th anniversary today.  COPD never gets better.
> Dammit.
>
> So I am working on this instead.
>
> Thanks & Cheers, Gene Heskett


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Mark Wendt]

On Wed, Dec 3, 2014 at 7:20 AM, andy pugh  wrote:

> Does anyone know how to interpret MTBF numbers?
>
> http://docs-europe.electrocomponents.com/webdocs/0d17/0900766b80d17a55.pdf
>
> Specifically. 1500 hours doesn't seem very long,
>
> --
> atp
> If you can't fix it, you don't own it.
> http://www.ifixit.com/Manifesto
>


Have access to IEC 61709?  Sounds like that's a European thing.  Maybe
something like Mega IO's per hour?
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] MTBF

[Rick Lair]

It looks like " over 1500 'millions of hours' of 'Mean Time Between 
Failures' "


Thanks


Rick



-- Original Message --
From: "andy pugh" 
To: "Enhanced Machine Controller (EMC)" 

Sent: 12/3/2014 7:20:32 AM
Subject: [Emc-users] MTBF

>Does anyone know how to interpret MTBF numbers?
>
>http://docs-europe.electrocomponents.com/webdocs/0d17/0900766b80d17a55.pdf
>
>Specifically. 1500 hours doesn't seem very long,
>
>--
>atp
>If you can't fix it, you don't own it.
>http://www.ifixit.com/Manifesto
>
>--
>Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>from Actuate! Instantly Supercharge Your Business Reports and 
>Dashboards
>with Interactivity, Sharing, Native Excel Exports, App Integration & 
>more
>Get technology previously reserved for billion-dollar corporations, 
>FREE
>http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>___
>Emc-users mailing list
>Emc-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/emc-users


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] MTBF

[andy pugh]

Does anyone know how to interpret MTBF numbers?

http://docs-europe.electrocomponents.com/webdocs/0d17/0900766b80d17a55.pdf

Specifically. 1500 hours doesn't seem very long,

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] WJ200 driver on 2.6

[andy pugh]

On 3 December 2014 at 03:22, Kirk Wallace  wrote:
>
> I looked at the manual:
> http://www.hitachi-america.us/supportingdocs/forbus/inverters/Support/WJ200_Instruction_NT325X.pdf
>
> and saw that there is no shortage of available registers. Starting with
> B-24, one can see that there are more than few registers (all the way to
> B-48) available for configuring, monitoring and running the VFD

If it is possible to use Modbus to know the actual motor speed then
that alone would be useful (especially for gear detection, if you have
a need for that)
If there is a thermistor connected then it would potentially be an
easy way to monitor motor temperature. (I haven't read the register
list in enough detail to be sure).

I think I am using a WJ200 myself, perhaps I ought to try my USB-modbus widget.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users