Beckhoff EtherCAT - Hardware or Vaporware?

RocketTester

Member
Join Date
Oct 2009
Location
Sacramento, CA
Posts
204
We selected Beckhoff's EtherCAT for our new rocket test sequencer design in 2004. At that time, they had only prototype FPGA modules w/ 2 chan analog. The final designs with ASIC chips were expected late 2005. We have been waiting patiently. The E-bus modules have been in the catalog for years. Some were just imaginary (EL3108 8 chan, 16-bit). Beckhoff is not alone. At the same time GE Fanuc showed a PAC system that was only drawings and apparently never existed.

In the interim, I had to field a system with older K-bus modules, but we need <1 ms response for some tests. We now have all parts but ES3104 modules. It appears all 16-bit analog in modules have slipped from 3rd to 4th qtr 2009. If true, no problem, but these slips have been regular since 2006. Last year, our salesman said they were available in Europe and UL approval was the delay. We said "don't need it, ship our stuff". Perhaps, not true of 16-bit. Has anyone seen these modules in Europe? Any word of a design hangup and we must accept 12-bit? We have received our 16-bit Analog Out modules.

Otherwise, no problems. Our software has been ready since 2005. The system works, we just need the speed. Until then, our very old and unreliable HP2100 computers still sequence most tests.
 
Oh boy, haven't we got those blues with Beckhoff modules...

It seems to be a trend with some European companies: to announce something way too early, get the prospective customers salivating - and not to be able to deliver for a long time. Frustrating.

KL3681 has been our bad boy. Still waiting for one, about a year since we saw it it had it designed in.
 
The Dutch Beckhoff site states "estimated market release 4th quarter 2009" for the EL3104, so I assume they are not released in Europe either.
 
It appears all 16-bit analog in modules have slipped from 3rd to 4th qtr 2009
According to their website, the EL3702/ES3702 is available. It is a 2 channel 16-bit +/-10V analog input module. The EL3104 you want is also a 16-bit +/-10V analog input module, only 4 channel, and without the "oversampling" of the 3702.
 
JesperMP, I believe you mean the EL3102. Those have been available since 2004 in an FPGA version (more cost & heat). If you look closely at past Beckhoff photos of EtherCAT installations, you will see only 2 chan analog modules. Indeed, I have a sequencer installed in one control room with 8 EL3102's. However, we eventually want at least 32 channels. While the current EL3102's shipping may be the final ASIC design, we can't fit 2 chan modules. Ditto for motion controllers, not the density needed plus an inelegant solution.

I bought a few of the EL3702 over-sampling modules you mention to play with. They can acquire at 100 kSps, though real-time response is ~0.1 ms. We would use those for frequency analysis from vibration sensors (turbopumps) or piezo pressure sensors (combustion oscillations). Beckhoff also plans the EL3632 w/ 40 kSps, but only for IEPE accelerometers (internal amp), whereas our temperatures often require charge-mode accels.

Why so many analog inputs? During a rocket firing, we might monitor and kill the test off signals from multiple pressure transducers, load cells, and thermocouples, with 3 out of 5 voting or whatever the test engineer designs. For most analog inputs, +/-10 V is fine since the signals are first conditioned by our data acquisition system (Pacific 6000).
 
Update,

6 mos later and still no ES3104 modules in sight. It seems all 16-bit analog modules are in the same boat, other than the FPGA 2 chan versions that were out years ago. In Nov 2009, our local salesman promised we would get them by end of Jan 2010 even if he had to fly to Germany. No deal, and he now says delivery slipped to 3rd qtr 2010 (website still shows 2nd qtr).

With customers waving money in Beckhoff's face and placing orders, they have a big incentive to produce. That makes me suspect they are dealing with design issues like packaging, heat, or noise. I have been taking the heat internally for several years since I am the one who selected Beckhoff. Others repeatedly ask "why not Allen-Bradly, we heard of them", though they are clueless about performance and other issues. I heard that Beckhoff will give us EL3102 loaner modules (2 chan) to tide us over. We have been using those in one system for years.

I'll post when we finally get the ES3104 modules and I can smile away the darts. On the plus side, others in my group are finally warming to Beckhoff and even have new ideas for applying the EtherCat fiber couplers. It takes time to convert people, especially ultra-conservative engineers.
 
At a point like this, it might be easier to get someone to design a part that does the same job as those modules, lol. They might finish design and production by the time the beckhoff part becomes available. If it ever does.
 
BTDT -- can help.

Update,

6 mos later and still no ES3104 modules in sight. It seems all 16-bit analog modules are in the same boat, other than the FPGA 2 chan versions that were out years ago. In Nov 2009, our local salesman promised we would get them by end of Jan 2010 even if he had to fly to Germany. No deal, and he now says delivery slipped to 3rd qtr 2010 (website still shows 2nd qtr).

I'm working on interfacing our own high-speed digitizers to EtherCat, so if all you need is a bunch of 16 bit +/-10V channels sampled reasonably fast (1-100kHz per channel), drop me a personal message. We could work out a deal.

The design I work with is simple: their ET1200 ASIC for bus access, Parallax Propeller for the multicore data pushing sweetness, and TI ADC(s). Probably can make it mimic any existing/planned Beckhoff module as long as the XML file is available. It wouldn't be certified in any shape or form, but it'd be certainly designed to meet applicable standards. No problem with getting any oversampling factor you want -- certainly not limited to 100, if you want slow bus cycles. The only limit is 1kB process data RAM -- so you can store only 512 samples, give or take. At 8 channels that's only 64x oversampling. Perhaps you could run the bus at a faster cycle than 1ms.

An easy workaround is simply stringing a couple ET1200 ASICs on the same PCB, connected internally via LVDS. ET1200s are easy to prototype with, I'm no fan of BGAs for quick 'hacks'. You get bonus 100BASE-TX ports that way, too. Otherwise you get only one 100BASE-TX port, but you can work around that with bus splitters that are not vaporware.

Also as far as accuracy is concerned: 0.3% TUE for EL3104 -- gimme a break. 12 bits worth of worst-case accuracy (10x better than 0.3%) is easy to get, across 0-50C. Can't Beckhoff calibrate those during automated testing?!

Also, if you'd need to interface with something other than +/-10V -- say strain gages, that can also be easily done. The frontend is already differential and low noise (AD8222-based), adding gain is no biggie. One resistor does it.
 
kuba,

Thanks for the info. Beckhoff is still showing the EL3104 as shipping by Dec. 31. We'll see. We have several systems assembled with EL3102 modules, which we will replace when the EL3104's come in, to double our channels in the same space. To fit something else in would be unbudgeted design labor.

We use Beckhoff for controls. The hardware you describe would be more applicable to our data acquisition systems. We use Pacific 6000 systems (www.pacificinstruments.com). Pacific was selected before I joined the test group. They are a small company that has marketed to propulsion testing for decades. Occasionally we acquire signals at 100 kSps, usually piezo-electric accelerometers and such, but normally 20 kSps or less. Data Acquisition is generally simpler than control since you can store readings in an array to download later. It doesn't face the real-time issues of controls.

I agree with you that the hardware is fairly straight-forward and Pacific's has changed little since we started with them, but software is another issue and probably 90% of the development. National Instruments has long claimed to focus on software.

Re strain signals, those are our most important measurements - forces and pressures, from raw Whetstone bridges. You need high-gain ~x300 to read the differential 30 mV FS signal. You also need to read the excitation voltage, or use a substitute like switch in a shunt resistor for scaling. We had Pacific design a custom shunt system to reproduce what has historically been done. I have different opinions on the value of shunt cals.

I have done only minor PCB design. Desiging with a BGA would be far beyond my abilities. When they first came out, there was a lot of work developing QA methods like X-raying to insure the balls melt correctly. Maybe old-hat today, but always hard to inspect what you can't see. I recall for prototyping there were fixtures that clamp each solder ball, similar to CPU sockets on motherboards. They were very expensive then, don't know if still true.

I recall the EL3102 shows only a few bits of noise, which is normal for 16-bit A/D's. Don't recall what Beckhoff specs, but most manufacturers are very conservative. I expect the EL3104 will be similar. Not critical for use since for control we use analog readings to kill a test and a little better than 12-bit is fine for that.
 
Here's my take on the status quo in this measurement world :)

We use Beckhoff for controls. The hardware you describe would be more applicable to our data acquisition systems.
I'm using Beckhoff for both controls and data acquisition. EtherCat solves the age-old problem you face when you mix different data acquisition vendors: how to synchronize them all. With EtherCat, you can sample things synchronously with jitter on the order of 10ns. That's either hard to do or impossible when you mix-and-match systems.

Data Acquisition is generally simpler than control since you can store readings in an array to download later. It doesn't face the real-time issues of controls.
For fixed-duration tests: sure. We're more into longer, open-ended experiments where you never know how long of a data run you take, so we simply stream everything as it happens. Then if you need to use it for control purposes, the data is there in the process image, ready for the pickin'.

Re strain signals, those are our most important measurements - forces and pressures, from raw Whetstone bridges. You need high-gain ~x300 to read the differential 30 mV FS signal. You also need to read the excitation voltage, or use a substitute like switch in a shunt resistor for scaling.
For a 30mV FS signal, with 300x gain you end up with 9V p-p. A well chosen modern ADC can have optimal noise performance at 3.3V full span voltage or less, so the gain can be 100x. Heck, there are ADCs that will have optimal performance around 1.8V reference voltage.

As for shunts: Cue in ratiometric measurements. The A/D output value then expresses a fraction of the excitation voltage by design. This works so well that we don't even use precision references: any half-decent low noise voltage regulator is stable enough. One A/D chip per channel, and you have 6 wires per bridge: 2 force, 2 sense, 2 signal input. Never had to use a shunt in my life. A switchable current source is available to check that the strain gage hasn't gone away, and that's it.

I recall the EL3102 shows only a few bits of noise, which is normal for 16-bit A/D's.
That's the problem with "industry leading" designs that get repeated ad nauseam. If you want to get all the value out of your expensive A/D chip, it should run at the maximum sampling rate, with appropriate fixed-frequency analog antialiasing filter preceding it. The DSP then band-limits and resamples the signal to whatever is your desired output sampling rate.

The theory for that has been around for half a century or more. Heck, you don't even have to code any DSP if you're not into it. Just get an off-the-shelf single-chip digital filter like SavFIRe and you're done. Bonus: you can apply an inverse finite impulse response linear model of your sensor/fixture to fix up some of the mechanical infidelities.

If the A/D runs at 100kHz but you only need 10ks/s output and your A/D is half decent, there will be no noise: the LSB will not flip unless you're close to the quantization boundary. 30mV FS is plenty of signal to work with -- at 4.5kHz bandwidth and 350 Ohm source resistance you should see stable LSB in a properly designed system.

This can save some headache. First of all you don't need to stock/order all the different sensitivities of load cells. Say, for some use a full scale signal equivalent to 4000 counts is enough. That means you can use a load cell that's 16x less sensitive than your load range. It's also a lot less likely to get damaged due to rough handling. It will also have 4x higher natural frequency, and will be a whole lot less likely to fracture.
 
With EtherCat, you can sample things synchronously with jitter on the order of 10ns. That's either hard to do or impossible when you mix-and-match systems.
I agree. With multiple data systems, it is hard to insure the time-lines agree, especially after many minutes of recording. One might see a false time shift between events, due simply to a slightly different clock rate in each. The normal fix is that all data systems record a common reference channel, like a square wave or an IRIG signal.

As for shunts: Cue in ratiometric measurements. The A/D output value then expresses a fraction of the excitation voltage by design.
Ratiometric is common in purpose-built instruments. However, our data channels must be easily reconfigurable. Sometimes they measure strain bridges and other times a mV (thermocouple) or V signal. Most data systems are designed for +/-10V at the A/D @ gain = 1, with a standard A/D reference voltage.

The drawback of calibrating with shunt resistors is it a round-about way to infer Vex, with many possible errors. Often, the shunt resistor used in the field is different than the one used in the cal lab. Ideally, the resistor would follow the xducer as a transfer standard, which is why some manufacturers build them into the transducer. Even then, when you apply the shunt, it is thru external wiring and contacts that add resistance. A bigger problem is that the signal you get with the shunt is usually temperature dependent. The resistors in the bridge vary with temperature, and the shunt's temp coeff is usually different and/or it is at a different temperature (if external). This is extremely true with new pressure transducers that use semi-conductor bridges.

If you have extra multiplexor channels, it is easy to switch to read Vex before a test, or periodically as Beckhoff's strain modules do. I wonder why Beckhoff didn't use ratiometric since their modules are purpose-built to read strain bridges, though I like being able to read Vex explicitly since that catches problems like broken wires (did so many times in a strain module at a prior company).

... A/D chip ... should run at the maximum sampling rate, with appropriate fixed-frequency analog antialiasing filter preceding it.

I also never appreciated the emphasis on analog filtering before the A/D. That adds much complexity and expense. In some cases, the User must physically install different filter packs. Some PC filter boards cost much more than the A/D boards.

I agree it is better to run the A/D at the max sampling rate and digitally average down to the desired data rate. That is flexible and keeps the hardware fixed. You do need an "anti-aliasing" filter before the A/D, but that can be fixed, and is effectively built-in if a sigma-delta A/D. One approach is to save data at the full rate and average down post-test, either all in RAM or via a file.

However, with a processor such as TwinCAT, averaging can be done in real-time. 15 years ago, I designed a data system using an Innovative Integration A/D board that had an on-board DSP. I ran the A/D at its max 100 kSps and the DSP code averaged it down to the desired output sample rate. I recall the noise was ~0.3 bits. Some may wonder how it is possible to realize less than 1 bit resolution. Look up "dithering", used in image processing. They purposely add random noise to give multiple readings about the mean, to better determine where the mean lies. In my case, there was enough background noise that I didn't need to add dithering. We also see <1 bit noise in a current procedure where we post-test average samples in a data file.

... use a load cell that's 16x less sensitive than your load range. It's also a lot less likely to get damaged due to rough handling. It will also have 4x higher natural frequency, and will be a whole lot less likely to fracture.

A former data analyst said to always over-size load cells 10x, for more stiffness to decrease low-frequency thrust stand oscillations. Also, a failed load cell would be very bad in a propulsion test. Since the data system usually has much lower uncertainty than the load cell, one generally can do so without compromising accuracy.
 
Update - Beckhoff slips again

As expected, Beckhoff slipped the EL3104 again, to 1st qtr 2011. A good guess is that come Mar 30 it slips another quarter (pattern since 2005). This looks true of all 16-bit analog in modules with >2 channels, other than thermocouple ones. I suspect they are dealing with design issues like packaging, noise, or heat. I wonder if many of the EtherCAT modules that are shipping are the original FPGA "prototype design" (more heat and cost).

On the worse side, I read it is getting hard to get delivery of the CX processors, which do exist (we have several). That problem seems due to growing popularity of EtherCAT.
 

Don't get me started. I have a feeling they were absolutely not ready to the current spike of business activity and are woefully short of the manufacturing capacity...
 

Similar Topics

At my current job we have a relatively new system that has an Allen Bradley PLC as the main controller with some local I/O, but a lot of remote...
Replies
12
Views
2,636
Hello, I have a Beckhoff TwinCAT system with local I/O and a remote EtherCat Box I/O. The Beckhoff TwinCAT has failed and needs replacement. Is...
Replies
3
Views
1,703
Hello, I have several VFD's that communicate Ethernet/IP, and need to integrate these drives to an existing Beckhoff EtherCAT network so that...
Replies
11
Views
3,410
I am tying to connect a PILZ pnoz m1p plc with a Beckhoff CX9020 plc true Ethercat. I have connected a PNOZ mc2.1p ethercat module to the PILZ...
Replies
1
Views
2,391
Hi guys anyone had this before? Latest AX5103-xxxx-0011 xml files from Beckhoff's site added in the device repository using ABB's Automation...
Replies
3
Views
3,121
Back
Top Bottom