EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: rockbassist90 on June 22, 2016, 09:20:41 pm
-
Hello I'm currently working on a carrier PCB for a board mount style servo drive. The quadrature encoder in use is a Pittman E30D with 500CPR or 55kHz max operating frequency.
I'm looking for some direction on the best filtering method with use of a long cable line (twisted pair ~8ft, low capacitance cable).
The servo manufacturer recommends a 121ohm resistor to terminate between the complementary encoder lines (i.e. A/A-, B/B-,X/X-)...but I'm worried that I will see significant noise due to the long cable line....
Perhaps a low pass RC filter would work best here (without overloading the input line). How should I select my RC components? Operating freq. @ 55kHz, let's say we want to eliminate up to the 9th harmonic...so ~<500kHz would be our cutoff freq....now after this I need a bit of guidance if possible :).
-
If you do have the optional differential output then 8 ft. should not be a factor. More important probably is that your receiving input device also takes advantage of differential lines and you utilize shielded cabling.
-
If you do have the optional differential output then 8 ft. should not be a factor. More important probably is that your receiving input device also takes advantage of differential lines and you utilize shielded cabling.
Thanks for your input!
You mean that with the differential, I shouldn't worry too much since any accumulated noise would cancel out? I am using shielding and only grounding on the quiet end o the controller chassis. Hmm, I guess I won't know until testing is done, but I thought SOME filtering would be a better approach. Just my opinion.
Sent from my iPhone using Tapatalk
-
As long as you have a proper differential receiver at the drive end you should be fine and at 8ft it'll likely work perfectly fine even without termination.
You can terminate the lines with 120ohm directly or do an "AC-termination" where you put a 120ohm (or rather a resistor equal to the characteristic impedance of the cable you're using) in series with a small cap across the differential line.
-
I'm looking for some direction on the best filtering method with use of a long cable line (twisted pair ~8ft, low capacitance cable).
8ft isn't "long".
I can't imagine you'll have any problems.
-
...
You mean that with the differential, I shouldn't worry too much since any accumulated noise would cancel out? I am using shielding and only grounding on the quiet end o the controller chassis. Hmm, I guess I won't know until testing is done, but I thought SOME filtering would be a better approach. Just my opinion.
Actually, this is a case where "some" filtering - especially in the form of an RC network on each line - would be worse. Differential signalling relies on the fact that external sources of noise tend to affect each wire in an unshielded cable the same - ie, the noise is common mode. In a perfect world with ideal and precise components you could put an RC network on each line with no consequence (but, with no benefit either), but the R and C values - especially the C - are all but guaranteed to be different and so will end affecting the noise levels on each line differently - that's exactly what you don't want, because now the differential receiver will respond to the noise, rather than cancelling it out through subtraction!
Thus the only type of "filtering" that should be used on differential pairs is transient protection (preferably low capacitance TVS diodes).
-
Have you practiced proper wiring for the encoder signals? Proper shielding and routing of the encoder wires coupled with proper routing and beading of the motor wires works wonders.
In one project working with a robot with a pair of 48V stepper motors I was able to mitigate 5V noise spikes in the electronics just by re-routing the wires and installing some ferrite beads. Performance of the system was night and day.
If you're really concerned with the encoder pulses you could always consider level shifting it during the run but 8 feet shouldn't require this.
Are you able to redesign the system at all? You could move the circuitry you're using to monitor the encoders adjacent to the motors and then relay the resulting information over CAN or 485 to your main computational engine.
-
Are you able to redesign the system at all? You could move the circuitry you're using to monitor the encoders adjacent to the motors and then relay the resulting information over CAN or 485 to your main computational engine.
RS485 is pretty much exactly the same as the differential encoder is already outputting. CAN, although it can techniacally be run "on top of" some other physical bus it's usually exactly the same, ie. a differential line. So if noise is a concern in the first place then that same noise would be present on the RS485 or CAN bus realying the information to the "master" - so, except for possibly some error correction built into the CAN protocol (RS485 isn't a protocol) I don't see any benefits at all.
No, as have been said, if you have 8ft of cable with a proper differential driver/receiver at either end and you're having problems you must be doing something horribly wrong. (Like using US Digital encoders *).
* If you want to know the background of that statement feel free to read about my knee mill CNC conversion, specifically this page (http://henriksplace.se/cnc/abene_4_4.html)
-
It's not just the physical signaling method, but what you're sending down and how fast you're doing it. With a high CPR (especially with high gear ratios) it's a constant stream of bits with an incredibly fast baud rate. However, if the primary computational engine only needs updates every 100ms, then a local MCU can monitor the encoders locally and then send off a packet with proper checksumming and error correction codes and at a much slower baud. It's more reliable. Plus you can NAK when a malformed packet comes in and re-transmit the same data.
If you don't parse it locally then noise in the transmission line will cause positioning errors due to lost counts. This wouldn't happen if you use the scheme I described.
I mentioned CAN because I could have sworn I remember seeing some CAN transceivers from Microchip that have baked-in hardware error correction schemes which would even further improve reliability.
-
There are encoders using SSI, basically a 12/24v SPI shift register you can read.
-
It's not just the physical signaling method, but what you're sending down and how fast you're doing it. With a high CPR (especially with high gear ratios) it's a constant stream of bits with an incredibly fast baud rate. However, if the primary computational engine only needs updates every 100ms, then a local MCU can monitor the encoders locally and then send off a packet with proper checksumming and error correction codes and at a much slower baud. It's more reliable. Plus you can NAK when a malformed packet comes in and re-transmit the same data.
Yep. If noise is a problem (which I doubt) then mini Arduinos are $2 each. Read the encoder with that so you never miss a pulse and transmit the data using some reliable protocol. It won't matter if 9 out of 10 of the packets are corrupted, the next packet will have the correct position of the encoder.
-
The best solution: replace the encoder in/on the motor with one that has "line driver" outputs (ie - differential). Most encoder manufacturers offer a choice, btw, so this shouldn't be too hard. You will need to use an appropriate receiver IC to convert the differential pair to standard logic (3.3v or 5v), of course.
2nd best solution: convert the single-ended pulses from the encoder to differential using, e.g., a 75ALS191.
Using an Arduino or other MCU at the encoder to lower the data rate and/or implement error correction doesn't solve a noise problem, it masks it. Perhaps it will do a "good enough" job, but it is a kludgy and inelegant solution.
As for the encoder cable, you can use commonly available Cat-5 (etc.) UTP cable, just make sure to assign power to its own pair, A/!A to its own pair, etc. I hate to point out the obvious here, but I do so because I've seen this get screwed up before.