ArcWelderPlugin
ArcWelderPlugin copied to clipboard
FormerLurker
AW Somehow hoses first layer speed on huge conversions.
@KenLucke, can you create a separate issue for this and include the terminal output for the first layer? I'm looking at the file right now in simplify 3d, and the first layer looks like it should be printing at between 300 and 1170mm/min:
It could be that some overrun happened since G2/G3 can be longer commands than G0/G1 (I have seen this before, but thought it was solved), and the max gcode length in your firmware may have kicked in.
Originally posted by @FormerLurker in https://github.com/FormerLurker/ArcWelderPlugin/issues/134#issuecomment-770434420
It will be a while before I can free the printer to be able to include the terminal output for the first layer, as requested.
This one is important to me, as I do a LOT of huge files, and AW not only helps the stuttering, it reduces filesize so that OctoPrint's gcode tab can display them (this one won't display as it's 266.3 Mb, whereas the AW conversion is only 107.8 Mb and WILL display)
Ok. After you capture the terminal output, try switching the maximum radius to 1000mm, re-weld, and try the first layer again. If that fixes it, I may need to rethink my defaults.
So, My guess as to what the issue is still stands: The gcode is overflowing the buffer. This MIGHT be happening on G2/G3 that have all of the possible parameters (X, Y, Z, E and F), and are of a very large radius. For example, here's a monster command I found in your gcode:
G3 X140.190 Y240.566 I-0.092 J-12990.988 E1154.47377 F1500
I could be jumping the gun a bit, since I'm not sure what's going on yet. This might be solvable with some changes to the firmware defines, but the default settings should work for most ppl, so I'll adjust that too if my suggestion helps.
Will do, as I said, it will be a while. I want to use the same file, so I need to use the same printer, the other one(s) are set up with different sized nozzles, retracts, etc., so I want apples to apples, not apples to rusty shelf brackets.
Let me pull up the firmware build files and see if I can find the maximum gcode length. Any idea what it's called (I suspect something such as MAX_GCODE_LENGTH or something similar)?
OK, mine's set at the default of 96, and that command you quoted was only 58, so that's apparently not it.
// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
#define BUFSIZE 8 //NOTE: was 4
// Transmission to Host Buffer Size
// To save 386 bytes of PROGMEM (and TX_BUFFER_SIZE+3 bytes of RAM) set to 0.
// To buffer a simple "ok" you need 4 bytes.
// For ADVANCED_OK (M105) you need 32 bytes.
// For debug-echo: 128 bytes for the optimal speed.
// Other output doesn't need to be that speedy.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256]
#define TX_BUFFER_SIZE 0
// Host Receive Buffer Size
// Without XON/XOFF flow control (see SERIAL_XON_XOFF below) 32 bytes should be enough.
// To use flow control, set this buffer size to at least 1024 bytes.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048]
//#define RX_BUFFER_SIZE 1024
#if RX_BUFFER_SIZE >= 1024
// Enable to have the controller send XON/XOFF control characters to
// the host to signal the RX buffer is becoming full.
//#define SERIAL_XON_XOFF
#endif
// Add M575 G-code to change the baud rate
//#define BAUD_RATE_GCODE
#if ENABLED(SDSUPPORT)
// Enable this option to collect and display the maximum
// RX queue usage after transferring a file to SD.
//#define SERIAL_STATS_MAX_RX_QUEUED
// Enable this option to collect and display the number
// of dropped bytes after a file transfer to SD.
//#define SERIAL_STATS_DROPPED_RX
#endif
on my CR10 my first layer speed is insane on my CR10s its okay somethings is definately off with the CR10
I kept trying to slow it down in the Settings for the first layer and it won't stop going superfast on the SKIRTS
on my CR10 my first layer speed is insane on my CR10s its okay somethings is definately off with the CR10
I'm not using the default firmware, are you? If different firmwares are still doing it, then it's probably not the printer.
on my CR10 my first layer speed is insane on my CR10s its okay somethings is definately off with the CR10
I'm not using the default firmware, are you? If different firmwares are still doing it, then it's probably not the printer.
on my CR10S I'm using the same firmware its updated I added a EZABL just like the CR10 but the older 10 is acting strange
Hmm. Maybe try resetting eeprom?
I'll give that a shot and report back
@djlightflighter, can you post the gcode that you are talking about (preferably the original and welded file)? I still haven't found a gcode error for the original issue, and if I could it would be extremely helpful. If the gcode is correct, but the printer doesn't respond to them as expected, this would appear to be a downstream problem. If the gcode is incorrect, at least I can fix it myself.
Thanks!
Latest version (from the version you put out in that other thread [#138]) prints this same file fine. Strange, did you tweak anything else?
@KenLucke, actually yes. There was an issue with gcode files that had blank lines inside of segments that would later be turned into arcs. I received an issue from another user that clearly had problems, and after some research figured out what the issue was. There were actually 2 problems. There was a bug in my circular buffer code that was delivering the wrong element in some cases, and I needed to skip any blank lines that appeared within an arc command. Solving both issues fixed that issue, so perhaps that fixed yours as well.
It's very strange that I couldn't see any problems with the gcode you posted here (and I dug in deep). I suspect two commands must have gotten swapped, and the change was hard to see. That also points to problems with simplify's speed visualization.
Anyway, I'm going to try to push another RC for both repos (command line/lib + plugin) today if possible. I really need to get this out, lol!
Also, THANK YOU for your support @KenLucke! I did a little dance when I got an email from you :)