Can you send pictures of how you’ve wired your EBB to Octopus?
How long is the wiring? How have you connected power to the EBB (and what gauge wiring have you used)?
I can describe it 
So RJ11 with the Cable and used the 2 middle wires for high and low. (0.2 Cables)
AWG 20 from PSU directly to the Board
So i think i will order IGUS Can Bus Cables (Twisted and 0.5 Diameter) and try that again
That should probably be fine. I use:
and clip off the connector at one end along with 18 AWG stranded. The distance from the opened end of the cable to the Molex connector is 20mm. I did a back of the envelope calculation and came up with a characteristic impedance of 112 Ohms which is pretty good.
I guess you’re looking at:
https://www.igus.com/product/1109?artNr=CFBUS-PVC-021
They claim 120 Ohm characteristic impedance (at least I think that’s what they call “Wave impedance”) so you’re getting a bit of an improvement with this but not enough that would significantly change things.
Personally, I suspect your wiring and that you may have an internal break in one of the two CAN bus conductors that opens periodically. The 20 gauge wiring is a bit smaller than optimum for the nozzle heater current, but you should be okay.
Before you invest in the Igus, could I suggest that you make up another cable (say with all 18 or 20 gauge stranded wiring for all four conductors)? Don’t worry about twisting pairs and don’t put it in your drag chains (if you’re using them) and see if you get any change in operation. It will at least give you another data point. Chances are you won’t have any signal integrity issues (I presume you’re like me and your cables are around 1.2 metres long which shouldn’t be a problem for the Octopus CAN bus drivers to overcome).
Good luck!
1 Like
Hi,
so i did nothing you advised me but:
I have installed a CanHat to the Pi, reflashed my Boards (EBB using CAN, Octopus using USB) and guess what ? It works !
So there must be somethign faulty either with my Board or the Software.
Now i am Happy and it only cost me 13 Bucks more
2 Likes
I don’t know how it applies to others in this thread, but I believe it tracked my issue down to a failing 5v regulator on my toolboard causing the MCU to mess up can signalling if too many fans are turned on. I’m waiting for 24v fans to come in to test it. I’ll report back if it solves my problem.
EDIT: I got the 24v fans in, the printer is now working as expected, no more timeouts. Just errors caused by faulty components.
Can you provide an update on this? I am experiencing the same issue with bytes_retransmit being at 0 all the time, then climbing to 500 and erroring out hours into a print in a matter of seconds. I have a single 5V fan 30x10 20mA to cool the Mellow FLY SB2040-V2 and I doubt that it messes with the 5V regulator too much. Maybe the LEDs do aswell?
No more issues for you still?
klippy (3).log (408.0 KB)
Hello @VoltexRB !
You noticed that all these informations are over a year old?
New versions of Klipper have been out since then.
I recommend to open a new thread on your issue.
Hello, I put a heat-sink on the mcu of the EBB 42. Make a special cable that have separated shield from VCC. It has no problem now. I think it just bad design
hardware. I don’t know how the Klipper handle real time control to synchronize on separated mcus. That could be a problem too if you are getting to high speed printing. And Oh if you try this with extremely high speed printing, you will like to be over load the can bus again. My setting is only 128000 for speed and 128 for buffer.
I was hoping to see a more in dept information, but I guest not.
What is your current setting for the TMC2209 on the EBB42?
If you are passing too much current through it and you have it attached to the back of a NEMA 17 stepper, you will find that the MCU overheats.
Questions back:
- Do you monitor the temperature of the EBB42’s MCU (STM32G0B1)? If not, you should add something like:
[temperature_sensor toolhead_temp]
sensor_type: temperature_mcu
sensor_mcu: toolhead
- What is you current setting for the EBB42’s TMC2209? I run mine at 0.4 to 0.6A
As Myke mentioned, you should heatsink the mcu AND the stepper driver if possible. Mine can get up to 50-60c WITH a heatsink on both.
Cooling the steppers is very much recommended.
I have it set to 550mA.
I have the Can Bus stable at low speed printing. under 100mm/sec. Cpu =35C
any thing related to realtime data transfer like speed, pressure advance, retraction make EBB Mcu to choke. I don’t know why the error message always tell me that this is the host problem. My Pi4 barely @ 10% load even with live camera. Typical error msg misdirection.
Also Cooling steeper is difficult for my use case. I have encloser with air temperature @35C. But that just for PLA. Some matterial Iprint will have air @ 80C. which is even with cooling water pump I can only put it down to 50C.
Normally, cooling shouldn’t be required for a toolhead controller unless you are pumping a lot of current into the stepper that’s wired to it. In this case, the heat dissipated by the TMC2209 as well as what is conducted through the screws attaching the toolhead controller will heat the MCU to the point where it stops working.
Having a chamber heated to 35C should not be an issue. However, having it at 80C will be a problem for the toolhead controller and I’d think that you would have to forego it in this case: I was going to put in some homespun knowledge but realized that I just happened to have the STM32G0B1 datasheet and the EBB42 schematic up on my computer.
If you look at the datasheet (https://www.st.com/resource/en/datasheet/stm32g0b1ce.pdf - “Selecting the Product Temperature Range” - Page 154) you’ll see that it goes through a calculation to find the chip’s junction temperature in a 50C ambient environment:
With the temperature ranges (defined by the last digit of the MCU’s part number) being:
Looking at the EBB42 schematic, they use the STM32G0B1CBT6 - note the “6” as the last digit which means that it’s only been tested up to 105C.
Even if you had a higher temperature rated part, running it in an 80C ambient environment is going to be problematic.
You’ve tacked your question on the end of somebody else’s thread - could you start a new one? I’d be interested in understanding what is your system (you say rPi 4) but you haven’t said what your main controller is, whether or not you’re using CAN built into the main controller or using a U2C board and you haven’t shared your klippy.log. I’m sure we can help you with your issues regarding speed, pressure advance, retraction (none of which shoudl be an issue) but we need to have more information and starting a new thread would be the right thing to do.
I do have a heat sync mention in previous message. Now I have a question for the creator of the klipper: What does it means: “Timing too close”? He put this message out base on a condition or more. What are those?
I guess you are talking about “Timer too close”
There is a search function here (top right)
If you have a lot of time, you might read all the hits you get.
My mistake, I use the STM32F407 as Can Bus controller. EBB is the tool head. The mainboard for the 3d printer is the BTT GTR
As first I focus in making really high quality Can cable( twisted pair, shielded). As I start the print, they often working but after some time a timer too close error start to appear. By experience, this often link to temperature problem. So a cooling heatsink is needed. I was able to get to the end of print by printing slowly(under 100mm/sec). after many trial I think any thing over can bus relate to realtime control is a problem. So if I use a stepper control from a Extension board M5 for the BTT GTR to control the eXtruder stepper I get no problem with the EBB CAN NOW ONLY USE TO CONTROL HEAT AND FAN ect… This lead me to try flashing the can bus and ebbcan to a lower speed at 128k and this should be enough for the EBBcan to handle. I think Can bus by design is very reliable but that will not in the case if the mcu and clocks slippping over tempreaturre. I will try to do a case study on how the mcu load and the clocks related to the can bus over load. I was alos hopping to see a detail document of all the error code from klipper ( this is a standard practice for any software developer?) . But I guest, i only found vague discuss about what “Timer too close” mean. Any way, I’ll be visit later, I must figure out how to do a data load test on EBBcan. Thanks for answer my question.
On a different note, 80C is a low requirement for application as 3d printer if you are consider it as toy. A normal functional chip would be in the range of 200C for industry commercial application. a space application would require more. But we’re talking China isn’t it?
Just out of curiosity, can you give an example of a “non-toy” silicon chip that can work at 200C?
The temperature silicon chips work at have nothing to do with where they are made, it has everything to do with physics.
1 Like
Ok . that really not need to be specific. but here is the standard you can find every where.
Related topic here.Making an STM32 last at 150°C? - STMicroelectronics Community
And I happen to be able to solved the problem that supposedly related to timer.
This is from the mcu.py.
TRSYNC_TIMEOUT = 0.025 # for 500kbs change to 0.05
TRSYNC_SINGLE_MCU_TIMEOUT = 0.025# for 500kbs change to 0.05
I have to change my can bus rate to 1000000Mb/s as the minimum for this to work.
You’re confusing ambient temperature and junction temperature. From the file in the link you gave.
Ambient temp can be pretty high for robustly built devices. Silicon devices have an intrinsic junction temperature limit though which is what Myke was alluding to.
From Analog Devices (link above) who have been making semi conductors for nearly 60 years:
All semiconductors have some specified safe upper limit
for junction temperature (TJ), usually on the order of 150°C (sometimes 175°C). Like maximum power supply voltages, maximum junction temperature is a worst case limitation which must not be exceeded. In conservative designs, it won’t be approached by less than an ample safety margin. Note that this is critical, since semiconductor lifetime is inversely related to operating junction temperature.
In other words, don’t get anywhere near 150c if you value the life of your semi-conductor device. Most devices are rated at a TJmax (Thermal junction) of ~100c for a safety margin.
Also, Fun fact about plastic encapsulated devices (which nearly all are):
The maximum safe junction temperature for plastic encapsulated device is
determined by the glass transition temperature of the plastic, approximately +150°C
1 Like
You are absolutely right. I am concern about ambient temperature. Junction temp is normally a lot higher than the sensor can shows. How ever, good heat-sink and thermal management can help reduce the risk of junction temperature reaching critical threshold. So my complain here is the board design does not have a good surface contact point to get more heat out of the board. People simply think as long as one can stick a heat sink on to the chip that was enough. The thermal design of the pcb, the arrangement of components ect… need to take into account. this board simply needs to have heatsink on both sides which is make it impossible to have a better thermal management. Most chip all has made the same way but they all have different temperature quality. I am talking about quality. Chip are tested with high quality can category as ClassA will have higher temperature. These chip simply better by the evaluation. chips are lower quality will have class B, C. So yes. it is possible to get the chip working properly at higher temperature. But as a cost of reduce the life time of the chip (See doc). Chip are made with higher quality naturally has longer life time. If you have a CPU/GPU you should know how hot it can be. But as long as the thermal management is good it can be used in industry environment. The short sight here is one you make the EBB mountable on the print head, you must known that it is exposed to vibration, heat and all sort of thing. That why the EBB should be in the category of higher quality by design. It should not be the same class as other devices which far away from those condition. I hope this make sense.