Maybe use { Auto-report temperatures with M155 S<seconds> }
in marlin configuration_adv.h -> #define AUTO_REPORT_TEMPERATURES
instead of constantly sending M105.
my 10 cents on optimizing usb communication.
All slicers do that... really. This is because a an STL files have no information's about arcs, circles, lines etc. STL files are just a bunch of triangles.pixelpop wrote: ↑Sun Jan 06, 2019 2:48 am I've always wondered why S3D never uses any of the Marlin gcodes for geometric moves like arcs, circles and lines. Instead, S3D produces a gazillion discrete point-to-point gcode lines. If S3D would use the available geometric commands, it would greatly reduce the size of the gcode and thus probably eliminate pausing issues when printing via USB.
no. still in 4.1.2Conundrum68 wrote: ↑Tue Dec 04, 2018 10:24 am I'm pretty sure this problem was attributed to an erroneously-generated zero-speed move and was fixed in V4.1.0.
Paul, would you care to expound on your workaround?Paul wrote: ↑Sat Sep 07, 2019 6:09 pm UPDATE:
After 40+ hours the problem has been solved with a work around.
I am surprised that no one has run into this, or they are just not expressing this problem.
It is duplicatable and a very specific event.
This should have been fixed a long time ago, and it will continue until it is addressed.
Good luck out there.
Paul wrote: ↑Mon Sep 09, 2019 12:47 pm We originally thought the issue had something to do with the infill overlap but my tech said it wasn’t in that module.
We tested over 100 different combinations of settings pertaining to all things ooze control and retraction.
We ruled out the machines, the model itself and the program that created the .stl.
We zeroed out all ooze control settings and unchecked all boxes under advanced.
Nothing changed as far as the blobs, and we had some minor stringing from crossing open spaces, which wasn’t the cause.
As the picture shows the uncorrected model has a thick seam that we programmed in to control where the seam would be least noticeable.
None of this has anything to do with temp or ooze control.
73E8EC91-F50A-44A5-B022-56F76C0EEB65.jpeg
So maybe negotiate a free license and inform S3D of the fix? You have an opportunity to help a lot of people out and maybe get something in return.Paul wrote: ↑Mon Sep 09, 2019 5:08 pm 5E655D49-0AE2-4CFC-9A2D-6812AEEEC115.jpeg
Another 2 hours and the deed is done. Meets production standards.
As far as the fix?
That is the $980. Loss in our production costs question, now isn’t it?
It’s definitely a problem S3D should have fixed a loooong time ago. I’m sure we aren’t the only company with this issue who is using S3D in manufacturing critical dimension parts.
Good luck, and choose wisely!
I'm guessing you're from Europe.Paul wrote: ↑Mon Sep 09, 2019 5:08 pm 5E655D49-0AE2-4CFC-9A2D-6812AEEEC115.jpeg
Another 2 hours and the deed is done. Meets production standards.
As far as the fix?
That is the $980. Loss in our production costs question, now isn’t it?
It’s definitely a problem S3D should have fixed a loooong time ago. I’m sure we aren’t the only company with this issue who is using S3D in manufacturing critical dimension parts.
Good luck, and choose wisely!