LS7366R encoder counter issues
T Chap
Posts: 4,223
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.
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.
1124 x 1500 - 360K
1124 x 1500 - 430K
1124 x 1500 - 465K
Comments
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.
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:
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.
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.
This alternative is interesting for me because it incorporates the line-receiver.
Gonna grab one at some point.
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 ?
Yes, killing or damaging parts is more serious energy pathways.
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 ?
Do you still have the removed parts ? Could be worth comparing current drain, pin leakages etc for signs of difference ?
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?
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.
Also making to Prop not be able to force the MISO pin LOW.
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?
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.
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.
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.
Also came across this