Loss of accuracy and position.

Loss of accuracy and position.
Jun 17, 2020, 06:12 am
I hope this is the correct forum for my problem. Please point me in the right direction if not. :smiley-confuse:

Hello AnyCubic RAMPS/TMC 2208 users,

I'm running my original RAMPS board (Motherboard 33) in my AnyCubic Delta Plus using TMC2208s in Standalone mode @1.2V on the Vref pins. Anything lower and the motors lose steps and go out of calibration. Their temperatures are only 42 deg. C with good fan blast to keep them happy.
I just don't understand how this seemingly-random loss of steps can develop out of the blue.

The upload seems to be okay and the printer works reasonably well when making relatively small calibration blocks, 40 x 40 mm or so and is consistent at this size. Trying to print towards the edge of the 240mm dia glass plate brings on these problems. The item I'm trying to print is only about 160L x 100W x 40H so it should be okay.

Has anyone had similar problems?

I might try to replace the 2208s with the original DRV 8825s but this would defeat the purpose of the upgrade.
The 2208s are really quiet and run the steppers very smoothly when they work at all.

I have looked in various forum pages but so far there's nothing relevant to my problem.
All suggestions will be very welcome.

Thanks,

Scintilla.

Update:
I have just swapped the TMC2208 with DRV8825s for the X, Y and Z axes. Exactly the same problem.
Because I have had this problem using RUMBA boards as well, I'm wondering if it could be some sort of glitch between the PC and the USB input of the PCB.
I will dig up a longer USB cable and try to improve the connection. Watch this space...

It is not a problem of USB cable. If you would have problems with USB cable then the print would completely fail or pause until an USB packet could be successfully sent again. It would not have impact on precision.

Possible reasons:

1) Low current. You can try to increase Vref or decrease maximum acceleration. The reason why low current can cause missed steps at the edges and not at the centre is that to keep constant acceleration of the hotend the carriage accelerations must be higher near the heat bed edges. You can check whether this is the reason by lowering maximum acceleration to lets say about 1/3 of the value you use now and check whether the problem was mitigated.

2) Low voltage. For the same hot end speed, the carriage speeds must be higher at the heat bed edges. That means higher stepper RPM. Higher stepper RPM needs higher voltage. You may to switch to 24V power source to fix this. Some electronics may not be able to handle more than 12V. So increasing voltage may not be possible. You can always decrease the maximum speed.

3) Low stepper driver cooling for the current used. The driver will shut down for a while when overheated. The steps are lost during the thermal shutdown and printer will lose calibration. Decrease Vref or improve cooling.

Missed step due to low current will be associated with sharp loud and very short "PUK" sound (or a series of them if more steps are lost). Missed steps because of temporary thermal shutdown will be much less audible.

Edited 1 time(s). Last edit at 06/18/2020 06:18AM by hercek.

Are you able to command the print head to move (with Pronterface, LCD or something) around the bed without any problems? I'd start with the Z at like 0.2 and slowly move it around.

Hello Hercek and Thehankinator,
Thanks for your kind responses to my questions. Much appreciated and lots of food for thought.

The changes I made regarding the drivers have made no difference whatever. changing the drive current makes no difference either.
The problem only manifests itself when I run an .stl file using Repetier as I have been doing for a couple of years now.

When I connect via Pronterface all is sweetness and light.
The print head moves exactly as it should. It moves very smoothly and very precisely over the +/-50mm range
and the Z increments are good to the 0.1mm. So X, Y and Z are all excellent in Pronterface and rubbish with Repetier.

After running the motors for some time in an attempt to print a test piece at some height above the heat bed (to reduce crashing!) the driver heat sinks
are cool at 38 deg. C. They can easily handle this temperature and they live in a good blast of air over their heatsinks.

I found a USB cable which is of higher quality than the one I've been using all these months and years but, as you anticipated, it has made no difference.

I thought of reducing the Baud rate from 250000 to 115200 might be something relevant but, again, no improvement in the printing movement process. The movements are very 'jittery'
and rough, even after reducing the acceleration settings throughout.

I'm starting to think I may have some flaky code in the Arduino version I'm using so maybe it's time to revert to an earlier iteration, maybe with different parameters
in the files, which may be the cause. After all, it's fine until I try to run Arduino for my Delta printer. In short... I have no ideas left

I wonder if there is a well tried version for AnyCubic Delta somewhere in cyberspace. I guess the next step is for me to dredge through the history to see if I can find a working variant.

Again thanks for your generous time and suggestions,

Scintilla.

Are you able to share your firmware config?

Movements can be jittery because of line buffer underflow. Check your delta segments per second. If it is more than 80 then set it to 80 or maybe even 60 if you run your printer slowly (no more than about 50 mm/s).

Anyway a jittery movement is not connected to printer losing precision. A well calibrated printer can lose precision only when some steps are missed (or when the firmware is outright buggy - very unlikely). A missed step can be heard quite well if it is not caused by a thermal shutdown of drivers (which is not your case based on the temperature reading of only 38°C at a driver heatsink).

Hello again, Hercek and Thehankinator,

I think Hercek's comment on the Delta Segments Per Second have been really helpful. I'm not knowledgeable enough to understand the exact significance of this parameter but I guess it has something to do with the rate of transfer of co-ordinates within the data stream.
My setting was waaaay too high at 100 so I reduced it to 60 and there has been a significant improvement in the smoothness of operation. Thanks so much for this real improvement!

As The Hankinator has suggested, I have attached the Config_h and Config_adv_h as well as the .ino file so that you can see my settings. I don't recall making any alterations from the basic files I received with the printer but my memory is failing with my advancing years so anything is possible.

At the risk of being a further pain, I would welcome any comments you may make about refining the settings along best practice lines. The original Arduino configurations underwent a few changes along the way, as various new experts engaged in refining this type of printer, so I'm sure to be in the dark about many factors.

As I write, I am watching the printer run through a practice print and I notice that sometimes the print effector moves fairly slowly and smoothly and at other times it is quite abrupt and apparently non-linear in long print moves. It still prints reasonably well now so I'll try to do a full test print and see how it turns out...

Thanks again for your help,

Scintilla.

Just as I thought I was making progress...

I tried to upload a sketch as usual and all I see in the Pronterface window is hash and symbols and I now have 'An error occurred while loading sketch' in Arduino.
I have checked Ports, renewed drivers and checked the connections, to no avail. It's a good thing that I'm the most patient person I know. ( after my wife, that is... )

I know this is something I need to work out for myself but I can't help wondering if the recent changes in the printer's formerly-good performance has any connection with this
latest development.

Thanks again,
Scintilla.

Quote
Scintilla
As I write, I am watching the printer run through a practice print and I notice that sometimes the print effector moves fairly slowly and smoothly and at other times it is quite abrupt and apparently non-linear in long print moves. It still prints reasonably well now so I'll try to do a full test print and see how it turns out...

This is a feature of Marlin based delta firmwares. They print more slowly near bed edges since the firmware tries to keep constant carriage speed instead of constant hot end speed. You would need to switch to some other firmware, e.g. Repetier based or RepRap firmware.

Quote
Scintilla
I tried to upload a sketch as usual and all I see in the Pronterface window is hash and symbols and I now have 'An error occurred while loading sketch' in Arduino.

Just try to upload firmware again. Make sure you have selected the right board in arduino ide. Maybe try disconnect a reconnect usb cable. If that does not help then maybe your hardware is faulty.

Thanks, Hercek. I will try to download an earlier version because I have read elsewhere in the Forum that there were many bugs in various iterations.
It appears that Marlin versions have been, in the words of Richard III, ...'sent into the world scarce half made up' and the result is mayhem on some occasions.
Apparently it depends sometimes on just how the program is opened! Go figure!

Thanks for all the helpful comments. I will post any useful results after further experiments. I told you I'm patient

Scintilla.

What is the temperature of the motors themselves? If they overheat, you can also get missed steps.

When printing at the outside edge of the bed, one or two steppers will be doing a *lot* of movement for very little movement of the effector, so will tend to heat up more.

Thanks Frankvdh,
Yes, the motors can overheat if driven too heavily and suffer accordingly. The X, Y and Z motors and the Extruder motor are all cool to the touch, barely above room temperature in wintery Australia.
The Driver heatsinks have never gone above 38 deg. C.
There was a big improvement when I reduced the Delta Segments pr Second to 50 (from 100) but the movements were still less-than-perfect. On one of the Examples files I read the value was set at 200! Go figure...

There now appears to be some kind of problem with my PC running any iteration of Arduino/Marlin. Previously I could upload the sketch in the usual way and all would be well. Now, whichever version of Marlin I try to run
I get an error message saying something like 'An error occurred when transferring the file' or some such non-specific, singularly unhelpful complaint. I have absolutely no idea what has changed on my PC but,
perhaps not co-incidentally, my other PC has crapped out of its printer function after the kind attention of Microsoft's 'Take it or else!' update.
I've just spent a day with a helpful elf from Microsoft helping me to regain some sanity in this bewildering space.

It's possible that my PC has also ingested an Update bug of some kind but, as you can probably guess, I'm clutching at straws.

Now that I can'r run anything I have nothing to lose by stripping out all the crusty old Arduino files I've accumulated over the years and start again, from scratch.
I'm wondering if there's an Arduino Purge program that will uninstall every file and chunk thereof. Maybe there should be!

Any further ideas would be even more welcome than ever!

Hello again,
Here's a quick update.

I searched the forums and found instructions (mainly from 'pert' ) on how to excise Arduino from my PC. Pretty simple process as it happens.
I sought and removed everything I could find, with some fragments lurking in unexpected places, but eventually all seemed to be removed.
When this was completed I downloaded Arduino from the windows store, rather than from the Arduino site. I'm not sure of the difference but the Arduino IDE
loaded without drama and I could then run Marlin as required for my AnyCubic Delta Plus. Who would have thought that something free from Microsoft would be worth having?

It now seems that I am back where I started all those years ago and, after parameter setting with Pronterface, I have loaded a couple of calibration objects into Repetier.

There still seems to be some weird behaviour going on so I will have to backtrack on the Config_h and Config_adv_h settings to see if there are any likely glitches or gotchas.

I will post any results in the next day or three...

Scintilla.

Hello again,
Well that didn't take long

I just ran two prints of a calibration square and both times the print abruptly stopped. No noises, no error signals. Nothing!

The search for peaceful printing continues...

Following on from the last post, I exchanged the DRVs to TMC2208s with approriate firmware settings, e.g. reversing the DIRs, and started to do another trial print.

All goes well for about five minutes then we have an abrupt halt. The Verbose script says 'Error min temp' but since this happened once I tried it again while watching the temperature readouts in Repetier.
I have them set to 200 for the Hotend and 60 for the Ultrabase. Both seem to track well but the Hotend does dip to around 198 before the PID pushes it back up to 200-201.

In desperation I reset the Extruder Temp Hysteresis from 3 to 5 degrees and this seems to have done the trick.

I will now try to print the fairly large item I originally started do do many days ago and I'll let you know if it has finally all come together.

Cheers

Scintilla.