Can you post the unaltered gcode? I'll run it through the debugger and will be able to tell what is going on.
the one with AS_ is the generated one... this generated file has always the same size, no matter the resolution used, maybe I am doing something wrong, sorry if that is the case
funny piece, is that I dont see any g2 g3 gcodes on the generated file... definitely I am doing something wrong then...
BTW the antistutter check box is enables on the plugin settings. It takes 6 seconds to process this 6.4 mb file, isn´t it too fast?
6 seconds sounds about right. The processing is fast because it's written in C++.
I ran your code through my instance, and it resulted in a 3.8mb file. Hmm... Something is going on. Can you take a snapshot of the anti-stutter settings?
I may have a localization bug. Try changing 0,5 to 0.5 and see if it works.
same thing with 0.5 instead of 0,5..it produces the same results, gcode on the file has not g2 or g3 instrucions on it... 
What OS are you running it on? Also, do you have G90/G91 influences extruder correctly configured (I can't see your setting because you have 'Use Octoprint Printer Profile Settings' selected)?
Edit: You may want to try disabling other plugins to make sure there is not some kind of interference. I've not heard of this yet, but there is a first time for everything 
windows 10, tried on three different machines... the plugin stuff will need to wait will current print ends... but sounds weird that I am the only one with this problem... is it normal that there were not G2 G3 commands? My understanding is that lots of G1 should be converted into arc gcodes... am I right?
Thanks man!
Yes it is odd. Except for people who were trying to convert vase mode prints, this is the first I've heard of this issue. There have only been a dozen or so ppl using it, so it's definitely possible there is an undiscovered issue.
Regarding the OS, I don't mean the browser, I mean what is running OctoPrint (raspberry pi maybe? OctoPi?).
raspberry pi 3b with octopi, yes. three more hours till the current print ends, will try the plugin deactivcation then.. by the way, I have checked the g0/g1 influence on the setup and currently running marlin 2.0.2 on the firmware.. not sure if there is anything else about that that needs to be taken into account. To be honest not sure on how the relative/abosolute piece will influence the gcode generation, but seems that something is broken before reaching that point, as aboslutely no G2/g3 codes are being generated...
For marlin 2 set G90/G91 influences extruder to true. However, I tried both settings when testing your code and they both worked because the gcode is unambiguous (sends G90 AND M82). Absolute extrusion shouldn't cause a problem with arc conversion, but may with extrusion amounts. I've been doing a lot of testing on absolute extrusion, and I'm getting good results, but still need to do more tests.
It's more likely that there is some issue sending the settings value to the actual conversion routine, which is written in C++. Are you running Python 3 by chance? I developed the plugin using python 3, and have tested it on an RPi running Python 2, so there shouldn't be a problem (but you never can tell).
How about we continue this via PM to keep the thread length down. Once we figure out the issue I will post the cause here. Sound good?
Sounds perfect!
Could the problem MIMUPREFERIDA is experiencing be due to the system settings is set to something other than English? I'm thinking it's probably set to a European country because the use of comma instead of full stop for a decimal place. In another software I was beta testing, this turned out to be a problem. Maybe if MIMUPREFERIDA could change the system setting to English and try again?
Just a thought...
Is that something to be done on Octoprint, or in the Raspberrry OS?
Registered here to try this. Don't know that I can send DMs. Can you send instructions?
Also, I've been using KISSlicer recently and getting good results. Any additional info on if there is arc support there?
And also how can I tell if my arc support is enabled? I'm running Marlin 2.0.5.3 on a Geeetech A20M
Arc support is most likely enabled. If you read the thread starting from the top, there is some gcode submitted by @OutsourcedGuru that you can use to test from the terminal. I will DM you with a zip file soon.
I don't know, I am by no means an expert in this... I just throw it out there for FormerLurker to consider and for you to test. How this can be done, i don't know.
If it sounds stupid then you can just ignore this.
I'm adding extensive logging to the c++ routine to help with @MMUPREFERIDA's issue. It's difficult since the logging has to occur via python's logger, but what needs to be logged is in c++. I've got it working, actually, just need to add settings to control it all now.
Fyi, I have implemented python logger capability within the C++ python wrapper. Console logging is available (including stderr output for exceptions) within the core library, which is overloaded in the python wrapper. Console logging is used when running from the comsole app, of course. The best part is there is minimal (nearly unmeasurable) performance loss when not logging, which is obviously very important.
It does require a special python logger at the moment, which isn't 100% compatible with the octoprint logging plugin. For that reason the logging settings can be found within the anti-stutter settings page, along with some other conveniences: log to console, download log, clear current log, and clear all logs. With some slight modifications to the logging module, they could be made to play nicely together.
For now the settings in the logging plugin don't affect anti-stutter, but the log files appear there for download. Im sure that will confuse people, but hopefully logging wont be necessary very often. All exceptions and critical errors are logged automatically to handle unexpected issues.
The log is MASSIVE when using the DEBUG level, but it should provide enough info to at least narrow any problems down to a few functions.
As usual I had trouble getting things to compile right on the pi. Eventually I got it all figured out. Hopefully this will help to figure out why @MIMUPREFERIDA is having trouble.
Are you still looking for testers?