Long distance issue

[FelipeDelgadoR]

Hello, First of all, I'd like to explain that I was just making some tests with Teacup, my first option was Marlin, and actually the issue I'm about to say it doesn't happen in Marlin...

I'm working in a big project (around 2x2m working area) and I was using Teacup, but we had the problem when moving the machine more than ~1700mm The behavior was:

• trying to move at correct speed the first 5 cms
• suddenly break
• keep moving REALLY (really) slowly... We never tried to get to the end, because it can be several minutes of waiting, so that's all that we gather, hope you can take a look to something like this...

Best of luck!

[Traumflug]

I'd guess you run into integer overflows. Teacup stores distances in micrometers and 2^31÷1000000 = 2,147. And there's some margin needed for calculations.

Workaround could be to multiply everything distance related by 10. Configuring ten times more steps/mm and for compensation, dividing speeds and commanded distances by 10. One might still run into overflows if more than 4 billion steps are needed for a movement.

[Wurstnase]

Here are the lines depending for the ~1700mm.

https://github.com/Traumflug/Teacup_Firmware/blob/9b934c364e52c976adaa08fabdffd1f99d6af3eb/dda.c#L328-L330

[ahmetonat]

I have the same problem but with -apparently- much smaller values. I am trying to retrofit an old UpMini! printer with an Arduino Nano. It has 1/128 microstepping, 1.5mm pich belt 1.8 deg/step and 20 tooth pulley. These numbers prodce 853333 steps/m

When I select acceleration as RepRap or Ramping, the movement starts fast, but then drops to extremely slow just as FelipeDelgadoR mentions.

EDIT: At these extreme low speeds, the positions seem to be correct and repeatable.

If I set 499999 steps/min, for example, speed is good, but of course positioning is wrong.

There is another problem: When I set the movement to 700000steps/m for example, and select 10mm of movement from Repetier Host, the first 10mm is smooth, but all subsequent movements are slow as described above.

Any ideas?

• I did not understand Traumflug or Wurstnase's comments as it seems they would change dimensions of the print.

[Wurstnase]

I would reduce the microstep size to 1/16 and check again. I suspect some overflows. The Teacup firmware does not have many regression tests for such values. At such high values there could be overflows that would cause such an observation.

[ahmetonat]

Thanks for the reply!

Yes, most probably there is overflow. If I reduce the steps/m setting to 500,000 (arbitrarily) the problem goes away. This is the same thing as changing the microstep size to a coarser value than 1/128 as you say.

However, if I do that, the size of the printed object would be wrong.

Probably the actual solution is to increase the type of the overflowing variables to int_64t or something.

However, which ones?!! Do you have any suggestions?

Is it possible to use the simulator to check if some variables are overflowing?

[Wurstnase]

I would reduce the microstep size to something smaller. E.g. 16. In that case you can reduce your steps/m by a factor of 8.

[ahmetonat]

Yes, that wolud have been my first choice, but on this printer (Up! Mini) the motor driver chips are soldered directly on the PCB, have heat sinks glued on them, and their part numbers have been scraped off. I could not find any reference to the board design on the Internet either.

Even halving the microstep setting to 64 would have saved the day for me.

So unfortunately essentially I am stuck with the microstep setting. Will still check to see if I can do it.

[ahmetonat]

Progress on UP Mini

I am happy to report progress on the Up Mini Teacup firmware conversion! After a long hybernation due to work pressure, I was able to get back to the Up Mini Teacup conversion. The problem was that had I used an AVR328 (Arduino Pro-mini) to run the firmware and the Up Mini had stepper motor drivers pre-configured for 128 microstepping. This caused the math calculations to overflow and it just did not work. There was no way to change the microstepping in the hardware. Even the stepper motor drivers were unidentified.

After looking at the stepper motor driver chips I found that they were an oddball 30 pin SSOP package. When I checked stepper motor driver chips with 30 pins, THB6128 came up. Surely, comparing the datasheet and board connections, the signals matched and indeed the drivers had been wired for 128 microstepping.

It is confirmed now that Up Mini uses THB6128 as stepper motor drivers.

The next problem is how to change the hardwired 128 microstepping to a more reasonable 32 or so. The datasheet says 3 pins control the microstepping rate: Pins 26,27 & 28, which were all wired to logic high. Pin 27 must be logic low for 32 microsteps. I managed to desolder, lift up and airwire Pin 27 to GND on all 4 motor drivers as desired (under a makeshift microscope).

After doing the firmware setup, motor positioning is running as desired now. I still need to adjust the extruder and bed temperature control parameters, but that is a known path and should be manageable.

Some photos show what was done inside the machine.

Best,

Ahmet