#linuxcnc-devel Logs

Oct 25 2017

09:54 AM Roguish: pcw_home: Peter, good morning. kinda quick electronics question, please?
09:56 AM pcw_home: Morning Roguish
09:56 AM Roguish: I am concerned about encoder signal integrity. and am thinking about going from TTL at the encoder to 422 differential.
09:56 AM Roguish: do the mesa boards take 422 differential directly? or do I need to go back to TTL then into the board (5i24)
09:57 AM Roguish: probable using something like MC3486 and MC3487
09:57 AM pcw_home: Differential is much more noise resistant, though digital filtering can go a long way also
09:58 AM pcw_home: The FPGA cards are TTL, so the daughtercard needs a RS-422 receiver
09:58 AM Roguish: ok, so I do need to go back to TTL. right?
09:59 AM pcw_home: (the receiver also provides protection for up to +-25V inputs)
10:00 AM jepler: pcw_home: like 7i33 for instance?
10:00 AM pcw_home: Yes, or newer boards
10:01 AM pcw_home: Newer boards use the same RS-422 receiver for both TTL and differential inputs
10:02 AM pcw_home: (in the TTL input case, one of the differential inputs is tied to 1.65V and the other used as the TTL input))
10:05 AM pcw_home: We typically use ISL32273s (CMOS) for non muxed encoder inputs and 26LS32s (BIPOLAR) for muxed encoder inputs
10:10 AM Roguish: OK, so for my simple LM18200 drives that take a PWM directly, I need to have my own TTL-422-TTL circuitry. For my Yaskawa drive system that uses the 7I33, it's already 422 compatible.
10:12 AM pcw_home: If you have differential encoders you could also mount and external RS-422 --> TTL converter close to the FPGA card
10:13 AM pcw_home: Digikey has some cable blobs that do this and we have some tiny PCBs that do the same thing
10:13 AM Roguish: that's the idea. a simple TTL-422 converter at the enconder, and a 422-TTL converter at the FPGA end.
10:15 AM Roguish: is teh 422ENC bidirectional?
10:16 AM jepler: no
10:16 AM jepler: at least not the ISL32273 that pcw mentioned, I'm looking at its datasheet
10:17 AM jepler: the to-422 part is ISL32x72
10:18 AM Roguish: jepler: i appreciate the interest. i'm not an EE.
10:18 AM jepler: I'm a proud high school graduate
10:19 AM pcw_home: Do you have a noticeable issue with noise?
10:21 AM Roguish: not sure. just don't even like the thought of it.
10:21 AM pcw_home: sometimes you can fix this by tweaking the input filtering (via the encoder filter bit and encoder sample frequency pins/parms)
10:23 AM pcw_home: This works because most noise is induced into the encoder wires via inductive or capacitive coupling
10:23 AM pcw_home: and this tends to generate short noise pulses that can be filtered out easily
10:24 AM pcw_home: also a way to check if you have a noise issue is to enable encoder error checking (which checks for illegal state transitions)
10:26 AM pcw_home: ( external noise tends to affect both A and B at once which causes an illegal quadrature state transition )
10:27 AM Roguish: where is the encoder error checking. i don't see it in the encoder hal comp.
10:28 AM skunkworks: I have had good luck with TTL encoders using shielded network cable up to about 10 ft.
10:29 AM jepler: In master branch, there's a pin called hm2_xxx.encoder.##.quad-error-enable
10:29 AM jepler: it appears to be undocumented
10:29 AM skunkworks: above that the start losing it. I the K&T we use the ttl/diff converter (cable blobs from digikey) at the encoder end.
10:29 AM Roguish: oh. in hm2.....
10:29 AM pcw_home: the error checking is in the hm2-hardware (it certainly could be added to the software encoder though)
10:30 AM jepler: if the pin is TRUE, then it checks whether the FPGA has recorded an invalid quadrature state transition
10:30 AM jepler: .. this would appear in the normal place that messages from realtime components go, such as dmesg for rtai based systems and terminal/stderr for preempt-rt based systems
10:30 AM jepler: HM2_ERR("Encoder %d: quadrature count error", i);
10:33 AM Roguish: is that pin exposed? and setable?
10:33 AM pcw_home: I think its disabled by default since startup transients could trigger an error
10:34 AM pcw_home: hm2_7i96.0.encoder.00.quad-error-enable
10:34 AM pcw_home: for example
10:34 AM jepler: also it looks like there's a programming error in linuxcnc that will be seen if you don't set all the quad-error-enable pins to the same value (either all FALSE or all TRUE)
10:35 AM Roguish: ooops.
10:37 AM jepler: https://github.com/LinuxCNC/linuxcnc/issues/343
10:37 AM jepler: afk
10:38 AM pcw_home: Thats possible sine normally you would set them all true
10:38 AM pcw_home: since
10:46 AM Roguish: pcw_home: as usual, a wonderful lesson. thank you. someday I'll get by to see your new shop.
10:56 AM pcw_home: welcome, and thanks jepler for spotting that bug
01:24 PM pcw_mesa: One of our customers got Rob E. to extend circular arc blending to rotary axis
01:24 PM pcw_mesa: They would like it merged into master, what would be the best way for this to proceed?
01:50 PM jepler: pcw_home: by creating a high quality pull request on github
01:58 PM pcw_mesa: Probably something for Rob to do
02:12 PM skunkworks: oh - wow.
02:12 PM skunkworks: that is awesome
02:15 PM hazzy: It sure is!
10:12 PM linuxcnc-build: build #3308 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/3308 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
10:43 PM -!- #linuxcnc-devel mode set to +v by ChanServ
10:47 PM linuxcnc-build: build #5168 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5168 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>