I totally agree with you and this is what mainly drew my attention to the plugin initially. The reduction of file size means a reduction in the number of commands that have to be sent and therefore should reduce the load on the processor. In theory, this could mean that we could speed up the process. However, this many not happen depending on the physical requirements of the material being used.
Re: ArcWelder, I thought I read that Marlin converts arc commands back to a series of G0/G1 commands. Is that correct? I’ve been running ArcWelder for several months now on one printer and haven’t noticed a significant difference in quality using my delta printer. I do like the file size reduction and can see how it would be useful with 8-bit boards.
You can run current marlin on any 8 bit board. It all comes down to disable features to gain enough flash size for the stuff you need. If you e.g. deactivate SD card support you can enable more or less all other features. It usually ends to be a little of try and error until it compiles, but when it does it will work.
It is not. This probably would cause troubles as those 8 bit CPUs are slow like hell and you would need some math to fix that.
Your printer just has ARC enabled. Without these commands are just ignored. There is no fallback, which makes sense.
Sorry @Geit, what I meant is that I’m surprised that you can trim Marlin 2 to fit and still have a really useable version. For example, for me, not having SD support would be a deal breaker. I realize you can disable other stuff, but really, I would rather spend a little money on a new board rather than waste hours trying to make Marlin 2 fit an 8 bit board.
Yeah, but that would be wasting even more time getting the new board to work and the connectors to fit.
However, Marlin runs fine even with SD card support enabled. I enabled additional homing menus and xyze-Step menus plus other stuff on my 8 bit printers without any problems. I also added the PID menus.
In my case I just disabled SD card printing, as I never ever used it. Not even once and the menu items to init, update and select a print from SD card was annoying like hell, as usually the menu items I wanted where behind those.
I wonder if this explains why I was having such a problem a few months ago trying to initiate the M600 filament change command. I could never get it to compile. I can’t remember what the error message was but it is back in the archives of this forum.
For some reason beyond my limited knowledge I can insert a change filament instruction in Cura but not in Prusa which I greatly prefer. Why would this be?
Can I insert a script into Prusa that would accomplish this?
Could be. You need to enable at least the pause command as well for that, which requires a lot of space on its own. And filament change is a lot of menus and text, too.
This is mostly an issue because Marlin does not have proper designated display functions, but repeating code everywhere, which eats space. So just to have a “press a button to continue!” screen and check for a button press, you need tons of code.
I agree with @Geit; the space issue is, in large part, due to programming inefficiencies.
I believe this happens because open source projects are, to a large extent by necessity, agglomerations of many disparate pieces of code. Many of those bits of code end up duplicating code in other bits, and there is often no central authority that can mandate streamlining of the code.
For example, take 1 programmer working on a feature they want to see in Marlin. They start coding it, but they need to use menues to see if it works & test it. So, they program the menues in. Unfortunately, there can be a number of programmers working on their own pet feature(s) that are also adding in their menues. So, you wind up with menu code sprinkled throughout the program.
Look, it’s 1 of the costs of the open source model. That said, these issues can often be overcome by throwing better hardware at the problem; the perfect example being the advantage of using 32-bit control boards over 8-bit boards to make space for larger versions of Marlin.
The alternative is closed source programs, otherwise known as proprietary programs. The code is often quite a bit more efficient, there is a DFD (Data Flow Diagram) that all programmers working on the project must adhere to (i.e. no rogues allowed; no going off on your own), there are frequent meetings where managers & programmers hash out issues (like removing redundant code), and so on. However, proprietary programs are not free, and some of them are pretty dang expensive. The slicer programmer, Simplify3D, costs $149 USD. Rhino slicer costs $995 USD! Many people balk at paying such prices. Many more simply can’t afford them.
Installed the plugin in Octoprint and used it to print the bracket for the Ezabl. I noticed it didn’t look right so I canceled it and just printed it normal.
The mayor problem is that there is no visual feedback in Cura.
Unless it got fixed, you also need to open “arcwelder_settings.def.json” with an editor like notepad++. You need the section “arcwelder_resolution” and there the “maximum_value”, which is “0.075” by default. Change this to 0.75 or so. This allows to specify a bigger range in settings.
Now back to the general use:
Some “serial” delivery tools like Repetier-Server for some reason have trouble sending the G3/G4 commands, so this could also be a problem with OctoPrint.
What value did you use as ArcWelder resolution? Too big values will cause exactly stuff like this.
I also imagine you may did that, as your result looks like ArcWelder values where set to high and it optimized several straight lines by just one and in the next step did a course correction.
So use far less values in OctoPrint is my solution for a fix. A Resolution should be around 0.75mm or smaller.
But as I said. This should be an option in printer settings, where you can enable Arc-Support right beside “has a heated bed”. Cura knows where an Arc should be and where a line. The shell tool just turns multiple small lines into an Arc, which, depending on the model, may not be what you want and result in shapes like your fail.
The setting I used in Octoprint were there defaults which I had used before but not on something as circular. In reading your reply something can to mind. The other times I used it I was using Smith3dfirmware, the print below was done with stock Ender 3 v2 firmware.
Seems like a very interesting topic for a DrVAX video. I understand other creators have already covered this but I think different “creators” use different approaches that different people with different learning styles will find more understandable. I will be sure to give a shout-out to this forum.
In terms of finding a g-code viewer. Version 2.3 of Prusa has a g-code viewer for files produced in any slicer built-in. Just go to Files / g-code preview and it will open a window where you can select a file. Unlike the viewer that was highlighted in this forum, it does not show you the g-code and the graphical representation side-by-side, but it does render any g-code.
You can load gcode files into Cura, too. The display switches into preview mode, while the main object mode just shows nothing and an uncalculatable print time.
The main problem is that the slicers viewer have no implementation of the G2/G3 commands required for the arc motion. They don´t create them, so there is usually no need visualize these specific gcode commands.
I can only speak for Cura and those files containing Arc-Commands are shown wrong and so others probably fail, too.
Every Marlin version since 2.0.0 AFAIR has arc support implemented. You should probably go for the most recent version as there were probably a lot of fixes implemented and the entire operation probably got optimized. In 2.0.6 it got a mayor overhaul, so you should not use anything older than this point.
You can simply use a terminal and send an “G2” or “G3” command. If the result is “unknown command” it is not implemented. If you get an error or the terminal gets closed due to an bad argument error, it is implemented.
Starting with 2.0.6 you can use the “firmware info”-command M115 to see if arcs are implemented. Beside other useful information on the printers configuration is should return a line “Recv: Cap:ARCS:1”, where the 1 indicates the feature is turned on.
It should be enabled by default, when the official default branch of the marlin source was used, but it is possible that it may got disabled by the manufacturer.
Yes, that’s why I asked about the (Ender 3) v2 firmware.
I tested a truncated version of Maker Mashup’s test part using the default Cura profile (for PLA on the delta) and the AW plugin for Octoprint. At 60 mm/s print speed, file size was reduced from 3.1 Mb to 468 kb and print time from 90 mins to 50 mins. There was no noticeable difference in print quality. Oddly, at 120 mm/s, the print took slightly longer than the time for the default 120 mm/s setting.
