LS7366R encoder counter issues

T ChapT Chap Posts: 4,000
edited 2019-05-04 - 13:56:02 in General Discussion
I have been incorporating this device LS7366R into my designs for a few months to count an encoder external of the Prop so that that counter can stay alive for several days on a battery if the power is lost. This avoids rehoming systems on power outages. There is a 12 battery that goes to the LS 7366R board. The board has a 2amp 5v switching reg. The regulator is a solid design I’ve used forever. The Prop drives a BLDC motor driver and reads the counter via SPI to know where the motor is. The part is in use in a lot of designs and is sold by many large automation companies including USDigital which is where i get the encoder. The counter connects via i shielded Cat5 10’ to the encoder located right off the motor shaft.


I have mysteriously had about 4-5 die over the part months on my bench. I attributed one to hot swapping the SPI connection to the Prop. If there were a serious spike I’d think the Prop would die too.

Yesterday I had someone out at site updating software for the Prop and accidentally left some test code in from my bench mock-up. This allow the motor to overshoot and hit s hard stop and stalled out the system with errors. After the error we corrected the code and ran the motor. The counter then had a cumulative error per cycle. There is no possibility of mechanical slip. The encoder is shaft mounted. In testing we spun the motor 4 revs positive and got 7200 approx. Then reverse to the starting point and end up at 70! Repeat the cycle and get 140. 210. 280 etc. accumulating 70 per 4 revs forward and backwards. Needless to say the system will crash after one cycle.

The counter and encoder is only powered from the lithium motorcycle battery(with its smart charger) via 5v SW reg. So any damage would have had to have been EMI or noise from overloading the motor at the initial crash.

I had dismissed the 4-5 dead units as bench oversights but now am having to consider that this device is very delicate. Any thoughts on how this could accumulate an error? The error seems to accumulate only running ++ as the plus value was higher each time than the negative direction.

Photos show the Click counter module with 7366. The black box is the Prop main board and motor driver. Photos are my bench test rig. Not the system that died yesterday.
«13

Comments

  • The socket outline at the rounded end of the Counter-Click is intended to supply the encoder with 5 volts. I note that is not what you've done. Presumption at this stage is a ground loop of some sort.

    To make recommendations will need schematics for that and all the the cat5 signals and also motor/encoder and the motor adaptor board, along with details of where all related power supplies connect in.
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • I hesitate to mention this because it's kinda rare, in this day and age for the encoder to sustain damage due to the shock of the axis hitting a dead stop...but back in the 80's.....

    FWIW, I have been a dual-loop-proponent for the past 25 years. One encoder on the motor for loop stability and another on the load for actual position feedback. Both feedback devices are compared during each servo loop update and must be within a window of tolerance or the system will immediately shut down.
    Where I don't have the option of dual-loop, I at least capture the index and check that the encoder count is a multiple of encoder resolution/rev.

    7366, never had a failure so I also suspect some electrical mischief.
    Again, FWIW, I only use encoders with complementary signals and interface to the 7366 via a 3486 line receiver.
    I had a similar issue crop up when on-site in Italy... I remembered that our member ManAtWork offered a converter board for a 3-wire encoder to differential. Nicolas (Bene) overnighted the board to me and the problem was solved. :cool:
    Failure is not an option...it's bundled with the software.
  • The rounded end and the SIP 5V are the same. The output of the regulator ends up at the SIP 5v and routes on the board to the rounded end connection VCC.
  • I have used a thousand of these US digital E series and they never die unless plugging in power backwards. I don’t see how a hard stop can affect it. It’s not that fast of a spin to force the encoder disk to spin free from the set screws.
  • T ChapT Chap Posts: 4,000
    edited 2019-05-04 - 16:33:35
    Here is the Counter board with 5V regulator. The board gets 12V from a battery. The board connects GRN via 2 of the 8 pin molex KK to the Prop main board. The same exact regulator/Circuit powers the Prop board.

    Included is the Breakout board at the motor. It takes the CAT5 and breaks it out to the Molex 4 pin KK to the encoder 5V/G/B/A. There are 3904 transistors in series with all the connections to prevent damage to the encoder and hall sensors in the event of plugging in the CAT5 to the wrong powers.
    835 x 701 - 284K
    1403 x 801 - 158K
    461 x 813 - 195K
    1371 x 813 - 154K
  • At the risk of offending one who is clearly knowledgeable and experienced; Are you running those encoder wires (I remember, long-distance) with the PWM-ed motor power and did you stick a scope on the encoder signals? I had one case of 50+v induced on the encoder lines.
    Failure is not an option...it's bundled with the software.
  • T ChapT Chap Posts: 4,000
    edited 2019-05-04 - 17:02:01
    10’ single ended. I haven’t recently looked at the lines but it’s easy to do. I did notice they wire tied the 3con 18 three phase Brushless motor wires together with the cat5 hall/encoder lines. I had them separate the wires after the damage. Motor driver is PWM from Prop and PEAm off the brushless driver/mosfets 24vdc. Keep in mind this is stuff I have some done tons of in terms of the same encoder and cat 5 to the Prop inputs. Only difference is adding the LS7366r in series with the encoder lines.

    Power supply from prop is shown with blue xformer. GND is all tied together in the chassis star to each board of the power PCB. GND is only tied to the Counter board via molex con on two wires. Battery has no other connection to the system. I don’t see an option for ground loop. Noise from motor lines seem like the only culprit. But I have never experienced noise affecting other parts.
  • The Click module has pull-ups but maybe you need to load them up a bit more? BUT destroying devices... I'd wager that you have some serious noise issue.
    Failure is not an option...it's bundled with the software.
  • Fresh board replacement.
  • Yeah I use the same product, never an issue.
    This alternative is interesting for me because it incorporates the line-receiver.

    Gonna grab one at some point.
    Failure is not an option...it's bundled with the software.
  • T ChapT Chap Posts: 4,000
    edited 2019-05-04 - 18:45:41
    Since I never had an issue with the prop reading encoders in the same exact configuration I am thinking of how to communicate from the main prop to the counter prop. Already assigned CS Clk Sdo Ssi 4 pins available. Good thing about using a prop is many inputs. I have seriously overstressed motors and had the same proximity of lines and never blow up props
  • Dunno... personally, I don't take comfort in a problem-masking solution.
    Failure is not an option...it's bundled with the software.
  • jmgjmg Posts: 13,923
    edited 2019-05-04 - 20:24:53
    T Chap wrote: »
    Here is the Counter board with 5V regulator. ...
    No poured copper ? (not showing on PCB CAD board, but later pictures suggest a pour)
    That seems to have very fine GND traces, and worse, the fat V+ decoupling cap has a very snake-like thin trace, that includes the LS 7366R board gnd pin.
    High energy/high current paths should be kept well clear of small signal stuff, especially for fault condition situations.
    It also looks like LS 7366R is 5V operated, but talking to a 3.3V Prop ?
  • T ChapT Chap Posts: 4,000
    edited 2019-05-04 - 20:22:44
    Yes There is a pour I just didn’t run ratsnest to show it. Eagle does not show the pour until you click ratsnest.
  • jmgjmg Posts: 13,923
    Mickster wrote: »
    The Click module has pull-ups but maybe you need to load them up a bit more? BUT destroying devices... I'd wager that you have some serious noise issue.

    Yes, killing or damaging parts is more serious energy pathways.
    T Chap wrote: »
    Fresh board replacement.
    You could check the damaged board on your bench ? How exactly did the other units fail ?

    Simple series resistors can limit energy, and I see the LS7366 board has none on the Encoder connection wires, or on the SPI wires ?
  • T ChapT Chap Posts: 4,000
    edited 2019-05-04 - 21:01:22
    The 4 units that went dead just simply stopped reading data. The one in the field is accumulating values when counting ++. I bought some chips so I just swap them out on the Click and it starts working. The same encoder signals are routed to the main board and connect to a MAX7311 IO expander. So any spike is going to those devices as well. Never damaged. 7311 is there to allow to diagnose if the encoder is putting out data to test if the encoder is alive. The encoder is also Connected to the main board and at that point I put termination 100ohm>.1uf>VSS on a and b.
  • jmgjmg Posts: 13,923
    T Chap wrote: »
    The 4 units that went dead just simply stopped reading data. The one in the field is accumulating values when counting ++. I bought some chips so I just swap them out on the Click and it starts working. ...

    Do you still have the removed parts ? Could be worth comparing current drain, pin leakages etc for signs of difference ?

  • Just a thought, but you mentioned this behavior began (for certain?) after performing a software update. What is the system behavior if you completely revert to the state of the software prior to the update when this issue was noted?
    Ordnung ist das halbe Leben
    I gave up on that half long ago.........
  • I cant find the dead ones, likely gone. I'll keep the future dead ones.

    The software update caused the motor to hit an obstruction. Going back to previous versions didn't help, I tried that just be sure. The updated software just causes the motor to crash, no other changes.

    There are times that I test the motor running and I kill the battery to simulate a failure and the Prop must catch the failure(the missing 5V input from the Counter PCB) and the Prop shuts everything down. On the failure, the Prop does the following:
        IF ina[20] == 0    ' If NO 5V you **MUST** KILL these pins or counter can still be read
            ' even though the encoder has no power.  
            Dira[9..11]~~    ' SSN1 10 , SSN2 9, CLK
            Dira[15..16]~~   'MISO MOSO  set low to kill power to device to allow full reset
            outa[9..11]~    ' kill pins to allow SPI Counter to reset
            outa[15..16]~   
    

    The reason you must set everything to zero is that even with 5V missing to the Counter it can still be read with just the voltage present from the Prop pins! So the registers are still reading and but the count is just no updating. This code forces all voltages from the Prop to zero and then on the next read the device has truly had it's registers reset to zero so that the Prop knows the device is reporting a failure and can shut down.

    In some cases if there is no battery present, the Prop may try to read the registers at least once meaning some voltage interaction is going on while the device has no 5V. Likewise it may be possible for the device to regain it's 5V after a Battery kill test, and the Counter may be outputting a voltage while the Prop is setting all pins LOW! I haven't verified this can happen yet its just a thought but if the Counter is trying to send data and the Prop is holding the SDO in LOW maybe there is some damage possible?



  • jmgjmg Posts: 13,923
    T Chap wrote: »
    In some cases if there is no battery present, the Prop may try to read the registers at least once meaning some voltage interaction is going on while the device has no 5V. Likewise it may be possible for the device to regain it's 5V after a Battery kill test, and the Counter may be outputting a voltage while the Prop is setting all pins LOW! I haven't verified this can happen yet its just a thought but if the Counter is trying to send data and the Prop is holding the SDO in LOW maybe there is some damage possible?
    All these combinations are where simple series resistors 220~4k7 can assist, and they also limit any spike energy too.
    CLK out / Data out would be maybe 220R region, and Data into prop can be 4k7 if close to Prop pin.
    A direct connect of 5V.SDO to a prop pin, will try to pull up the prop Vcc.

  • T ChapT Chap Posts: 4,000
    edited 2019-05-04 - 22:29:49
    I can modify the cable to include the series resistors for now. Then next rev add board resistors. Likewise the encoder connects via a molex 2 con KK and I can add series R there too. I'm seeing 4V on MISO.

    Also making to Prop not be able to force the MISO pin LOW.
  • Good call on the MISO SDO line needing series R. I added all the series as mentioned to the wiring harness, 1k from the encoder A/B to the input to the Counter. Everything if buffered now.
  • T ChapT Chap Posts: 4,000
    edited 2019-05-05 - 12:48:15
    I have been thinking about the earlier ground loop concern and didn’t see any real loop. This morning I realized there is a potential loop.

    In the screenshots of the Counter PCB the encoder and Counter board both have two direct short paths to the Main Prop PCB about 1’ away.

    One is 2 wires of a 12” 8 wire Molex KK plug.
    One is a 12” CAT5 that goes to the Main board RJ45 input.

    Both of these hit the ground plane immediately at the Main Prop board. The Main board then has 5v/G wires back to the power supply about 12” away. The power supply has VSS tied to the ground wire on the AC120 cable. The chassis is tied to ground/earth as well. All PCBs are not connected to the chassis. Star only.


    However I metered the 12v battery “-“ and it is connected to AC120V Neutral via the charger. The charger is 2 prong plug that is polarized so I don’t think it can be plugged in reverse. This means a path a 100’ back to the main AC box, and there it also connects to the ground wires that are routed back to the Main board VSS.

    Battery - ends up tied to VSS at the Counter PCB and the Main board. At the main AC box neutral is tied to GND. So how can there be a loop if both ends connect to GND.

    Is this a potential 200’ loop?


  • Only the 7366 and encoder is supplied by the 12v DC supply and the -ve is tied to the AC neutral?
    Failure is not an option...it's bundled with the software.
  • T ChapT Chap Posts: 4,000
    edited 2019-05-05 - 14:53:07
    Here is an overview. I left out hall sensors and other stuff that is not relevant. The basic connections for ground are as shown.

    The battery "-" is just a couple ohms metered to Neutral on the power strip. Main box, battery charger, etc are all on one strip.

    The only thing powered by the battery 12V is the Switching regulator, Counter Click(LS7266R), and encoder/Hall sensor at the motor. Total is 35mA off the battery.

    I looked at all the signals yesterday on the scope and all the signals are clean under normal conditions. If there were a loop/spike that sporadically popped up I would have no way to capture such noise.
  • And prior to the 7366 addition, there was no battery backup, right?
    Failure is not an option...it's bundled with the software.
  • T ChapT Chap Posts: 4,000
    edited 2019-05-05 - 15:26:38
    Correct. Prior to the 7366 counter, the encoders were direct connect to Prop inputs. Never a failure under very stressed conditions on the motor. 1000+ encoders in use direct to Prop. Adding the LS7366 was to maintain position under power outage so systems don't have to be rehomed and the battery can keep positions for 4 days. If the battery finally dies, the system gets errors because the LS7366 Power Loss Flag has been reset to default and the Prop gives errors required a real rehome.

    Now, the encoder A/B are no longer connected direct to the Prop but to a MAX7311 IO expander chip. The expander has not died when the LS7366has died.

    As I mentioned before there was code that did allow a slight potential for the Prop to force to ground the MISO pins from the LS7366. But my assumption is that shouldn't matter since you can connect two LS7366 on the same SPI pins and chip select which to read. I am running dual Counters on my bench 24/7 for months toggling CS. FWIW the system in the field that died Friday was a single encoder/counter version.

  • Might be a good idea to drop the whole 12v thing for awhile to see what happens(?)
    Failure is not an option...it's bundled with the software.
  • T ChapT Chap Posts: 4,000
    edited 2019-05-05 - 15:43:46
    I'm flying out to install 4 systems tomorrow with the counters :smile:

    So testing with or without 12V is not an option at this point.

    I have added 240R series resistors to the SPI signals IN and 4.7K to the SDO. Also added 1k from the encoder A/B to the LS7366 inputs.


    EDIT: I have seen the LS7366 die the other day without a battery. I substituted in a 12V wall adapter for the 12V. Which would be similar in terms of the output "-" being to Netral.
  • Just been perusing random PSU design references and haven't found any with the DC -ve connected to AC neutral.

    Also came across this
    Failure is not an option...it's bundled with the software.
Sign In or Register to comment.