Printing freezes on round corners and cylinders about jz-ts24-2

[miblooming]

what is the gcode command cache count of marlin? Is it 4?

…

---Original--- From: "EtherToroid"<[email protected]&gt; Date: 2020/1/22 21:25:04 To: "miblooming/JZ-TS24-2"<[email protected]&gt;; Cc: "Subscribed"<[email protected]&gt;; Subject: [miblooming/JZ-TS24-2] Printing freezes on round corners and cylinders (#30) Greetings. I've run into a problem using my flyingbear TS40 display. I'm running version 3.8.0 of the display firmware and marlin 2.0.1 on skr 1.3. The problem is that the printing process completely freezes at certain points throughout the model with heaters on. These points are usually round objects and round corners. The issue initially occured at rounded corners of some models, so I've tested printing 10 mm cylinder to induce the bug. When the printing freezes, skr 1.3 no longer follows any commands from the display (display telling "Busy!..."), but keeps posting temperature data to the serial port (later tested with octoprint terminal) and can be controlled with octoprint. The only thing that can reset the situation except power cycling is the "Offline" button in the "Tools" tab of the display, which succesfully resets serial connection. Nothing of the described above happens, when printing with Octoprint. Increasing the Maximum deviation in Cura to reduce number of linear moves also doesn't help. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[mziai]

I am not sure. How can I check that?

[miblooming]

Configuration_adv.h
"#define BUFSIZE"

JZ-TS send 4 gcode command to marlin before receive feedback of “ok".
If the cache for marlin is too small, there will be a mistake.
The default cache count is 4 of marlin 1.x

[mziai]

I have 32 for this setting:
#define MAX_CMD_SIZE 96
#define BUFSIZE 32

[miblooming]

The "Busy" notice come up, when JZ-TS sending more than 4 command whitout receiving feedback of "ok".
So may be the commands are lost on transmission by some reason.
1> Try change the baudrate to 115200, to slow down the speed of transmission.
2> Try rewire the wire to avoid the electronic interference.

[Sharkys80]

Its normal for a skr 1.3 board with the orginal TFT you have the same problem, the board it self have a problem. With the Gound shielding. You can try a ferrite Cores for USB cabel and miblooming Tips

[mziai]

I will try the 115200 baud rate option now. Also, what is the recommended option for
#define NO_TIMEOUTS 1000 and
#define ADVANCED_OK
Should they be enabled/disabled to work better? As far as I know they impact the format of the "ok" messages.

[mziai]

Changing baud rate to 115200 seemed to solve the problem. I've managed to print 2 tall cylinders with no glitches at all. Thanks for helping!

[mziai]

Unfortunately, the problem appeared once more, ruining my 12 hour print ;( The cable to display is properly shielded and separated from motors/heaters cables. After the print froze (this time at layer change) I tried "Pause", and then, after touching "Resume" button, the display becomes unresponsive at all.

[Sharkys80]

You use a 2 Screen or LCD at the same time ?
TRY (Configuration.h) #define SERIAL_PORT_2 to enable , you have a 32 bit board it can handel a scond serialport.And use a other pin for TX&RX for the Display as normal (pins.h) sometimes it helps

[mziai]

I am currently using 1 display (TS40) and tmc2209 uart and have both serial ports enabled. Gonna try turning ADVANCED_OK feature off and check again. Intuition tells me, that it is easier to transmit simple "ok"s than "ok"s with extra telemetry.

[Sharkys80]

can you upload youre logfiles from Octoprint?

[mziai]

I do not have any issued using it, and it is physically disconnected from the printer when the freeze problem is observed.

[Sharkys80]

Ok sry i misunderstood.

[mziai]

So, turning off Advanced_Ok feature doesn't help either. Printer keeps getting permanently stuck at small round objects. The Octoprint terminal shows a clean communication, where every line is followed by "ok".

[TAOGde]

Is linear advance on? mit freundlichem Gruß Torsten Goltz

…

Am 24.01.2020 um 08:36 schrieb EtherToroid ***@***.***>:  So, turning off Advanced_Ok feature doesn't help either. Printer keeps getting permanently stuck at small round objects. The Octoprint terminal shows a clean communication, where every line is followed by "ok". — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[mziai]

Yes

[TAOGde]

Try off. With my Printer i got some error messages mit freundlichem Gruß Torsten Goltz

…

Am 24.01.2020 um 09:01 schrieb EtherToroid ***@***.***>:  Yes — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[mziai]

Ok I'll try then. But it is not a solution, because turning off LA decreases corner quality..

[TAOGde]

I know but we clear the problems mit freundlichem Gruß Torsten Goltz

…

Am 24.01.2020 um 12:12 schrieb EtherToroid ***@***.***>:  Ok I'll try then. But it is not a solution, because turning off LA decreases corner quality.. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[mziai]

Due to my lastest tests this issue is not appearing, when the linear advance is turned off (not defined in config_adv). Also, it is somehow connected with retraction and coasting, but I haven't found the exact formula. Most of the cases the print freezes the moment before a retract should happen.

[Sharkys80]

Best is test first without the TFT only with Octo
You ask youre self why : And again the SKR Board is not the best many Problem with GND(electrical isolation you can only see it with a oscilloscope = you have Problem with Serial and UART communication),when you have luck they fix the problem on youre board and the TS40 is the real problem

[mziai]

I've tested the serial and 24v lines on the display with an oscilloscope and they are pretty clean. No distorsion or noise seem to be present. Also, freezes are connected strongly with the linear advance setting, which supposes the software bug.

[Sharkys80]

Ok youre test youre Board in headless Mode with Octoprint without errors??

[mziai]

What's the headless mode? As I said before, printing with OctoPrint goes with no issues.

[Sharkys80]

headless mode = without TS40
I test only the 2.8 with other Problems and my Result :
We use a new Master/Slave ( Board/Display)
the Display ignored many Commands & Setups from Marlin @ printtime. And use his own presetup for a simple 3dprinter.Switch to a FSMC or DWIN or Nextion Display when you want the real free setting & options like a RepRapDiscount Smart Controller an more check MarlinKimba

[mziai]

I have increased MINIMUM_STEPPER_PULSE to 2 from 1 and I've successfully printed a model that has always been failing. (LA is on).

[mziai]

But the problem isn't gone completely. The main fact though, that it never appears with the LA disabled.

[Sharkys80]

my LA work fine but for good working you must setup
#define HYBRID_THRESHOLD

[mziai]

My extruder is running spreadsycle.

[Sharkys80]

Spreadsycle and HYBRID_THRESHOLD various Stuff

[mziai]

Ok guys. I've also decreased extruder steps from 128 to 16 and the prints stopped freezing. It's time for some long-term stability test.

[miblooming]

Oh maybe the reason is that the calculated amount is too large for the chip of motherborad.
The speed of sending gcode command of JZ-TS is faster than octoprint.
JZ-TS send 4 command before receiving the feedback of "ok" to fill in the cache of marlin.

[mziai]

Seems fair. Don't think I am losing the quality by decreasing microstepping. Interpolation should do the trick. Anyway, thanks for assistance.