Welcome to the SeeMeCNC Community

Qdeathstar wrote:The main problem was bad design .... i2c was a bad bad bad choice. But, looks like the ferrites solved the issue. I have some laying around so I might give this a go, although I was happy with my calibration on the first go but I havnt printed out to all the edges yet...

Can you explain that in more detail? Is it I2C vs an endstop? What is it about I2C that is bad? I've read that i2c causes issues and haven't seen an actual description of why.

miaviator wrote:Begginer level video instructions: https://www.youtube.com/watch?v=DxGT18rDKUM

Thanks for the instructional video, I'm going to pick some beads up this morning....

miaviator wrote:

Qdeathstar wrote:The main problem was bad design .... i2c was a bad bad bad choice. But, looks like the ferrites solved the issue. I have some laying around so I might give this a go, although I was happy with my calibration on the first go but I havnt printed out to all the edges yet...

Can you explain that in more detail? Is it I2C vs an endstop? What is it about I2C that is bad? I've read that i2c causes issues and haven't seen an actual description of why.

I2c, or inter-integrated circuit, is a short distance communication method, that really shouldn't be extended beyond a connected daughterboard. It's designed to connect IC's on the same PCB or within a very short distance, and is susceptible to EM interference. It's also a lot higher speed than is really needed for this, and has more of a protocol overhead than is strictly needed, although it is built into the Arduino mega the RAMBO is built off of, and a number of other sensor chips. A number of different protocols, such as a smart probe that imitated an endstop, or RS-485 would have been far better as they reject noise better. For that matter, a shielded 2 conductor cable for the I2C connection would likely have helped a great deal, although it would have needed to be tied to ground somewhere to be useful, and thus needed yet another connection (Also, crimping/soldering to shields properly is hard).

Thank you for the explanations and the video- all very much appreciated. Hopefully a resolution is going to be found soon. In the mean time I found some ferrite cores in my shop I am going to try and for anyone looking for some here is a link- 3 for a dollar.

http://www.goldmine-elec-products.com/p ... ber=G18707

I installed ferrite cores I removed from a USB printer cable however I did notice that the cable was also shielded. The first go around I only ran the 2-wires, black and red, straight through the core, verses wrapping them around the core, and the results of printing the calibration ring was immediate failure after running the calibration G-code form Octoprint several times as suggested. So I took the wiring apart and for posterity sake I looped it around the core on each end. Second go around with the wires looped around the cores and results were the same - still not printing properly, between the X/Z towers the print is non existent it is so close to the glass. So my tests failed, if anyone has other suggestions, I tried to eliminate any interference however in the top of my machine even with all the cable management I did there are a lot of wires that could cause a problem.

What can I enter at the terminal window that will display the probing results? I watch it in the terminal window while it is probing but I am not sure I am seeing a result. I just know when I print the test ring or a 220mm triangle I made the printing issue persists.

Hey y'all. I haven't been on this forum since the MAx V1! It's nice to see familiar voices still solving problems.
I was impressed by the probe and I needed to dedicate a machine to a 3-4 month project so I picked up the V3 because meet the project demands. My bed leveling issue are exactly the same as you guys have described - low between the x-Z towers. I'm going to try the ferrite bead fix and I'll report back. Thanks for making this easy!


GUY

Since the ferrite cores did not resolve the first layer issue caused by poor leveling, for me, I will try a twisted pair and if that does not work I will install a shielded cable for the two I2C communication wires. I may connect the o-scope to look at the signals at both ends of the wires during probing however I am concerned about further degradation of the signals.

If someone can let me know what to look at from a terminal window to know the probing results worked I would be apreciative.

Tim

Stopped by my local RadioShack and found that they sell three sizes of Ferrite Beads. I bought all three sizes, each size has two per pack. When I got home I used the Small 3.5mm ID for the Rambo Board. The largest which has 3/8 ID was used at the Hot End. So far things are looking better at the edges. Still more test to do. If things change I'll let you fine people know!!

Well, this is not going to be good news...

I did a series of tests to validate if the beads were the silver bullet, they are not. This one was an easy test. Basically, I did 3 calibration runs with the beads on, three with no bead at the effector and three with no beads at all. If interference was leading to bogus data - hypothetically on the Z and/or Y tower offsets, one would expect the tower offset data, at a minimum, to be different between these sets of runs. But that's not the case:
As you can see, the offsets, Z Max and calculated delta radius are extremely consistent. This conclusively rules out interference as the contributor to this problem.

I should note, these were all done stone cold, even the fan in the power supply was off. I ran them back to back and observed and listened carefully. The "no hiccups" comment means that all runs went very smoothly.

Next I need to print with this latest calibration to verify it is still laying down a good first layer.

cloneit3d wrote:Since the ferrite cores did not resolve the first layer issue caused by poor leveling, for me, I will try a twisted pair and if that does not work I will install a shielded cable for the two I2C communication wires. I may connect the o-scope to look at the signals at both ends of the wires during probing however I am concerned about further degradation of the signals.

If someone can let me know what to look at from a terminal window to know the probing results worked I would be apreciative.

Tim

Support just got back to me and they shipped in a machine with the issue some of us are seeing and they expect to have a solution in place by the end of this week. I am suspending further testing to see what the solution is. They said they will report the solution to the forum. Can't wait to have my printer up and running.

mhackney wrote:Well, this is not going to be good news...

I did a series of tests to validate if the beads were the silver bullet, they are not. This one was an easy test. Basically, I did 3 calibration runs with the beads on, three with no bead at the effector and three with no beads at all. If interference was leading to bogus data - hypothetically on the Z and/or Y tower offsets, one would expect the tower offset data, at a minimum, to be different between these sets of runs. But that's not the case:

Screen Shot 2016-11-08 at 9.23.10 AM.png

As you can see, the offsets, Z Max and calculated delta radius are extremely consistent. This conclusively rules out interference as the contributor to this problem.

I should note, these were all done stone cold, even the fan in the power supply was off. I ran them back to back and observed and listened carefully. The "no hiccups" comment means that all runs went very smoothly.

Next I need to print with this latest calibration to verify it is still laying down a good first layer.

That's not bad news. That's not even "not good news." It's just more observational results. More data is always good.

I do wonder though, can I ship you a set of ferrite beads and have you reproduce the same settings used on our machine and the other machine both of which did show improvements? This would just mean wrapping the two I2C wires around the ferrite bead at both ends, cutting the wires flat at the HE280 plug and running the probing routine 2X.

Bones056 wrote:Stopped by my local RadioShack and found that they sell three sizes of Ferrite Beads. I bought all three sizes, each size has two per pack. When I got home I used the Small 3.5mm ID for the Rambo Board. The largest which has 3/8 ID was used at the Hot End. So far things are looking better at the edges. Still more test to do. If things change I'll let you fine people know!!

Have you also created a support ticket? Once an "official" solution is found all of these ferrite beads should really be replaced with whatever the proper fix is

cloneit3d wrote: Support just got back to me and they shipped in a machine with the issue some of us are seeing and they expect to have a solution in place by the end of this week. I am suspending further testing to see what the solution is. They said they will report the solution to the forum. Can't wait to have my printer up and running.

Can you get some pictures of your ferrite bead installation and of the top wiring on the machine?

I will also be adding their solution to the OP here once it's released. Our hope in sharing the solution was that it could get more machines printing until an official solution could be found.

gsnover wrote:Hey y'all. I haven't been on this forum since the MAx V1! It's nice to see familiar voices still solving problems.
I was impressed by the probe and I needed to dedicate a machine to a 3-4 month project so I picked up the V3 because meet the project demands. My bed leveling issue are exactly the same as you guys have described - low between the x-Z towers. I'm going to try the ferrite bead fix and I'll report back. Thanks for making this easy!


GUY

Be sure to also open a support ticket so you are notified once an "official" fix comes out.

miaviator, I''m happy to test. PM or email me and I'll forward my address.

Testing the efficacy of this is dead easy. If the collected probe data is the same with or without, there is no benefit. That's what my results show with my beads. I'm happy to try yours to eliminate a variable.

miaviator wrote:

cloneit3d wrote: Support just got back to me and they shipped in a machine with the issue some of us are seeing and they expect to have a solution in place by the end of this week. I am suspending further testing to see what the solution is. They said they will report the solution to the forum. Can't wait to have my printer up and running.

Can you get some pictures of your ferrite bead installation and of the top wiring on the machine?

I will also be adding their solution to the OP here once it's released. Our hope in sharing the solution was that it could get more machines printing until an official solution could be found.

Here are the requested pictures- please note I tried running the wires straight through first and then the loop around, both with no improvement of the first layer of the test circle.

Again, it is VERY easy to check if this works. Simply record the Max Z, delta radius and X/Y/Z tower offset values from EEPROM before and after making the change. The Max Z and X/Y/Z offset are what the probe measures. If interference is causing a measuring issue it will show up there. The delta radius is calculated from 2 measurements that are not stored but you can see on the console. No need though since the X/Y/Z offsets tell the story. If these are reproducible from run to run like mine above, there is no interference issue.

Hi all,

+1 to the same problem.

If accelerometer uses I2C digital interface and there is no signs of lost communication between controller and accelerometer, how ferrite beads can help? Consistency in experiment with and without beads (or just consistency) points on something software related. I guess the accelerometer is a mechanical sensor not very sensitive to electrical noise, but can create some latency in data transfer. It just my thoughts.
I can be wrong.
I would like to perform the same experiment as mhackney did, only without beads and compare my offset numbers against posted.
Please direct me how can I read offset numbers after calibration?

The idea was not that communication was lost but that noise was introduced and interpreted as data.

My data includes results without the beads - its the last 3 rows. You simply need to look at your eeprom values. Matter Control, Repetier host and a plugin installed in OctoPrint all let you do that.

Your offset numbers are not going to be consistent with mine or anyone else. They are a result of the total distance from bed to triggered home switch. You can (and should) adjust these as I describe in my build thread to be less than 4 steps each.

mhackney wrote:The idea was not that communication was lost but that noise was introduced and interpreted as data.

My data includes results without the beads - its the last 3 rows. You simply need to look at your eeprom values. Matter Control, Repetier host and a plugin installed in OctoPrint all let you do that.

Your offset numbers are not going to be consistent with mine or anyone else. They are a result of the total distance from bed to triggered home switch. You can (and should) adjust these as I describe in my build thread to be less than 4 steps each.

I don't believe that inside the chip tiny electro-mechanical sensor can pick-up any electrical noise.
It is a resistive element inside silicon.

Significant noise in I2C interface will cause likely communication problem not wrong data.

On the other hand accelerometer cannot send data faster than every 1 - 2 ms. With 100mm/sec probing, error in Z position can be 0.1 - 0.2mm
(can be more with controller latency).

One more question:
What does it mean "X Offset = 0" always and Y and Z offsets are not 0.
Will I see X offset = 0 in my case?

Sorry for silly questions. This is my first experience with 3D printers.

Here is a large print to test if things are any better. I still have the problem at the x tower being a tad thin. Based on Cloneit3d, looks like things are moving at the company level. Will not do any more testing as it sounds like there may be a fix close at hand...

Not an electronics guy, but, I was wondering if anyone had tried just twisting the wires like a pair of wires in an ethernet cable. I was told they were twisted to block interference and it would be cheap insurance to add

cloneit3d wrote: Here are the requested pictures- please note I tried running the wires straight through first and then the loop around, both with no improvement of the first layer of the test circle.

There is a significant difference in your wiring and my/testA wiring. The plastic cap is off your HE280 and there is a lot more slack and touching between the wires and hot end. At the top of the printer your accelerometer wires route towards and around other wires and the board itself vs moving immediately away from the board.

Check my mechanical notes on the v3 build. This can also be the cause of many first layer leveling issues:
http://forum.seemecnc.com/viewtopic.php?f=112&t=11104


Let me first say you guys are great! We are and have been actively investigating this mhackney and miaviator! We want everything to work perfect! We've had very in-depth discussions all day and we have a few things to check in the firmware. Look for a ***possible*** firmware update by the end of the week. We will know tomorrow, which after thorough discussion, Oly will dig into it on the firmware side, we can not say there is a minor problem yet. This took hours of several of us testing and 'breaking' things on purpose (firmware, eeprom, and mechanical). So give us a moment.

I also want to apologize ahead of time if I missed something in your post. I'll be honest - I scanned quickly through this posting and just want to add some comments.

Keep in mind that an average human hair is roughly 0.003inch (.076mm) diameter. Let's keep in mind this relative size information when considering the accuracy you're trying to achieve. In injection molding, under high tonnage and pressures, you can't get thermoplastic to flow into 0.001" thick cavities or cracks. So at low pressures, like our printers, don't expect a 0.002" (0.05mm) layer to turn out very good in FFF printing. A fine layer is 0.1mm. There's tolerance in everything from the machined parts to the type of plastic to the PTFE tubing, etc. You have to account for those tolerances and design them into your finished product or 3D print. Not to get side tracked on a whole separate discussion, just a quick reminder that there's a bunch of variables in 3D printing that can make it tricky.

Here at the shop, not one of us have put ferrite on our machines. I agree that ferrite can't hurt. If miaviator was in house at SeeMeCNC, my team would say whoa, you changed too many things at once to make certain ferrite is absolutely necessary. We would try for the problem machine and change that one thing after observing the error to see the result. It's sometime painstaking to troubleshoot, but necessary. And it's very important to have good connections in the wiring of course. We've built a lot of machines and don't see a noise issue. So a wiring noise issue is likely corrected by the ferrite. It really can't hurt anything, but we're not convinced it's necessary.

Modifications are part of what this is all about too. I'm interested in some test results you guys post with and without the ferrite. Where are signal wires related to stepper motor wires? In the RMAX v1, running end stop wires up the tower with the extruder stepper wires guaranteed shifting layers. The current in the stepper wires induced a false signal in the end stop circuit. So keep your stepper and signal wires separated. This is why you do not probe with hot end on. Are you probing with bed and hot end on? Then you're probably not running current firmware or your firmware is not configured properly .

I2C bad. No way. Nearly every Eris and RMAX v3 machine built at the shop prints great with a very good first layer after firmware upload and auto probing. The repeatability has even surprised me. Some of this error may be caused by the mechanical build. See my link above for mechanical build notes that can improve your results.

Look for a *possible* firmware update at the end of this week

Steve, I trust that JJ has shared with you the emails I've sent him over the last 3 weeks describing the testing I've done in detail, methodically, changing one thing at a time and testing. My point has always been, whatever is leading to this "issue" - for all 18 of the users that I have personally verified have the same symptom of thinness ONLY near the X tower base and thickness opposite it between the Y and Z towers - is that it is absolutely reproducible and amazingly consistent. I have rotated the effector 120°, moved carriages from one tower to another, swapped the X & Z steppers (and end stops), scrutinized the bed and its mounting, checked plumb and tilt and all other mechanical attributes I can, introduced mechanical errors to see if I could inject a similar problem or increase the magnitude of this one. The fact that I can make all these changes and afterwards a series of test probes give almost identical values for Z max, delta radius and X/Y/Z tower offsets (within +/-2 steps) really tells me 1) there is no appreciable backlash or other mechanical slop in endstops, carriages, etc and 2) there is no communication issue with the accelerometer to RAMBo interface with the hotend and bed off. I've performed many hours of methodical observation and testing and I'm completely stumped.

At this point, I understand and have profiled the offending bed tilt to the point where I can run the calibration and simply edit the tower offsets to compensate for the "tilt" and I get a perfect .2mm thick first layer on the ENTIRE print bed. And, the number of steps I need to adjust the offsets is also consistent from run to run. The V3 is absolutely capable of a high level of performance but something is leading to a consistent bed tilt error after calibration. The only thing I have not really investigated is the firmware calibration code.