search

prusa3d / MM-control-2.0

Multi Material 2.0 PCB board
Other
36 stars 18 forks source link

C60 can cause timing issues #12

Open NielschB opened 4 years ago

NielschB commented 4 years ago

I have experienced some issues with my MMU2 board, where all LEDs started flashing and could not get the motors working anymore. All pinned down to capacitor C60 which is connected to the latch input of the shift registers. This caused a slow ramp of the latch signal which resulted in timing issues on the shiftregister side. After reviewing the schematics I wonder why C60 is there in the first place. If its function is to implement a low-pass filter, then a series resistor should be added, now its determined by the Atmega output drive strength. All together this is not a nice way to do this since a slow signal ramp is applied to a digital input (cross currents etc.) Another thing is that continuously charging and discharging this cap by the MCU is a waste of current.

chriswal commented 3 years ago

and you resolved this issue by removing C60?

NielschB commented 3 years ago

Yes, just remove it

NielschB commented 3 years ago

This C60 might just be there to give non-prusa sellers a hard time ;) I have the feeling that the original Prusa boards might not have this cap assembled.

chriswal commented 3 years ago

You are right , there should be a resistor in series. but i dont see where there is a timining issue. the enable signals are always on, only the dir signals can change because of the direction the motor is moving. the leds are working also without a problem. so what is the timing issue you are refering about?

NielschB commented 3 years ago

Most boards don't show the issue, I have had 2 boards that did have this timing issue. Most probably its related to the output drive strength of the MCU where the cap is connect to, which determines the slope of the latch signal. It might vary over batches. Again, in the end a design should never have an analog LPF on a digital input like this.

When the MCU is shifting out data to the shift registers, the latch signal should toggle at a certain moment in time to load the data in the registers. When the latch signal is being delayed (By the cap and finite drive strength of MCU) the latch signal is crossing the shift register's threshold when next data is already shifted in! which causes corruption of the data in the shift registers.

chriswal commented 3 years ago

So you had flickering leds and loud motor noises on this boards? because there is a known issue that you need buffer capacitors for the shift register. if you dont have them the registers output random noise to the pins while switching the latch.

NielschB commented 3 years ago

Flickering leds yes, motors would just not turn in my case, but I expect anything can hapen. May I ask why you are interested? Are you experiencing the same issues?

chriswal commented 3 years ago

i edited the message before. yes i had this issue and solved it a different way.

chriswal commented 3 years ago

if the motor doesnt turn then this could be some different problem than mine

NielschB commented 3 years ago

I did try the buffer capacitors, did not help for me. Then I traced it down to this issue which was confirmed with scope measurements. I am wondering if the people who fix their issue with adding decoupling caps to the shift registers are actually suffering this C60 issue and the error is masked with adding buffer caps. Charging / discharging C60 takes quite some current which could explain why adding buffer caps could help.

Shift registers producing random data due to lack of decoupling caps would mean that the supply drops significantly, which I personally have not observed. (I did measure it actually)

chriswal commented 3 years ago

but that is a small capacitor and it is charged from the mcu... so for the layout that is further away from the register. i think to measure this you have to have a very fast scope. is it possible that on these board you had wrong capacitors assembled? i caan repoduce it on my board if i remove the buffer capacitors.. i also made a workaround in the firmware where you dont change leds while moving the motor .. i can try to remove the capacitor..i think they added it because they had problems before with erratic output

NielschB commented 3 years ago

Well, 100nF cap on digital output is not small to me! Assuming a drive capability of 50mA with 100nF load results in a time constant in millisecond range, this is significant. The MCU output pin should not require a cap to make the communication stable, this is just wrong. Nothing fancy on the shiftregister communication protocol, just some plain shifting and latching of which timing can be adjusted in the MCU firmware if required.

There seem to be a lot of people making a lot of assumptions and not just actually do proper analysis (measurments) of the issue and fix it. "Don't change leds while moving the motors" ? How can you expect to build a stable system when you are implementing these kind of workarounds? I would suggest to buy a simple USB scope and do some measurements on your board to see what is going on.

chriswal commented 3 years ago

i didnt build this system ..i had this board ..and some of the people are not able to solder.. so i made this workaround .. i can solder so i can fix something..i have a 100mhz scope but not around at the moment. and this was not an assumption
grafik grafik from the datashhet

chriswal commented 3 years ago

but there can be multiple problems leading to the same outcome. thats why i am interested to find the real problem. there is also a problem with the design of the 5v power on this board.

NielschB commented 3 years ago

Sure, there should normally be a decoupling capacitor, as 99% of the datasheets will advice, no question about that. If you want to find the real problem on your board, just do the measurements, otherwise just solder the C60 off the board and see if it fixes your issue. If not, put it back on.