Jump to content
Ultimaker Community of 3D Printing Experts

FormerLurker

Member
  • Content Count

    20
  • Joined

  • Last visited

  • Days Won

    2

FormerLurker last won the day on February 9

FormerLurker had the most liked content!

Community Reputation

24 Excellent

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 8 bit is fine. However, I have quite a bit of experience dealing with that fork. Most of this issue was spent figuring that out. At that point, it turned out arcs were disabled in the firmware. In this issue on the firmware repo a few settings problems were identified and fixed in this commit. However, I do not know if the arc fixes from Marlin 2.0.6+ have worked their way into that fork. You may want to post on knutwurst's repo and ask about this.
  2. I understand things can be frustrating, and appreciate your being reflective. It is very important that you make sure Arcs are enabled on your printer, though. I have seen this issue 100s of times, and it's usually Creality printers or custom built firmware. Also, to be clear, I am NOT putting down your printer, any creality printer, or any other printer at all, just pointing out that this is relatively common. In fact, I bought my folks an Ender3, and am happy with it. Disabling arc support is usually done to save memory so that other features can be added. If memory is not
  3. @brunoosti, Those settings look fine, but the slowdowns are concerning. What version of marlin are you running? At least 2.0.6 is recommended, else you may have slowdowns depending on your other settings. There have also been fixes since 2.0.6, but I hear there may be some issues in the latest bugfix branch if you are running OctoPrint, so stick with the stable release for now.
  4. That means they are enabled, so you should be good to go! If you are using OctoPrint, that will disconnect your printer, but that's expected, and causes no harm. Just reconnect and know that empty G2/G3 commands will NOT be generated by ArcWelder (unless there is a bug, lol). Just open the file and search for G2/G3 commands and see if there are any. If you are using OctoPrint, you might want to try out the beta version of the Arc Welder OctoPrint plugin (you can disable it later when you are comfortable). It has a firmware checker, will give you a ton of useful statistics yo
  5. This software is free, was made by people working in their free time, and the source code is open and available to anyone who wants to take a look and help improve it, so please keep that in mind. Second, your problem is almost certainly due to arcs being disabled in your firmware. I'm guessing you upgraded your printer with a bed leveler, and flashed new firmware for that. I see lots of these firmware forks, and most of them have arcs disabled for creality printers due to limited program space. It's very easy to check to see if arcs are enabled within your printer's firmware by sendin
  6. @fieldOfView, I noticed that the default options have both 'Min Arc Segments' and 'MM per Arc Segment' filled in. That will kick in firmware compensation. Not sure if that's a good thing or a bad thing. Anyone using Marlin 1.0 (or a fork) will have fewer issues with small arcs, but other users will have less compression around tight curves. I'm wondering if an 'Enable Firmware Compensation' box should be added that shows these two controls when checked? If it is disabled, both options can be set to 0, which will disable firmware compensation. Not sure if it should be enabled by default
  7. @brunoosti, Sorry if you already mentioned this (I scanned, but could not find this), but what version of Marlin are you running? I know some changes have been made to JD recently, and am curious in case I run across an issue that is related.
  8. @fieldOfView, I got a few issues about UltiGcode, and went ahead and added support in the latest master. Working on a release right now, so no need to deal with this in the plugin.
  9. It is 100% a visualization problem. If you have OctoPrint installed anywhere, I highly recommend using 'PrettyGcodeViewer' to look at these files. It uses a port of Marlin 2.0's arc interpolation algorithm, so you can be sure what you are see is what you will get. Barring that, Simplify 3d is the 2nd best viewer, though it also renders arcs with a relatively low resolution (think scad's facet setting if it is low). It is still very good. NCViewer.com is SO SO close to being great, but it does need a few tweaks, like ignoring some gcodes (it treats progress gcodes like arcs for some reason
  10. Also, @fieldOfView, I want to personally thank you again for fielding all these questions. I really appreciate all of the great work you do. I understand the sheer effort it takes, so I'm doubly thankful!
  11. @snarg, I ran your welded gcode through simplify to see what I could find, and it doesn't appear as though the speeds are unreasonable. However, I've gotten a couple reports about your exact printer and firmware doing exactly the same thing. See this issue in my GitHub repo.
  12. @ahoeben, regarding the Ultimaker, should I be considering adding this capability to the ArcWelder console app? If so, can you point me to some reference for how this works, and samples of the gcode header in question? I'm just totally ignorant about ultimakers. If I had one, I would have probably know this, and accounted for it.
  13. > Let's see if pinging @FormerLurker works. It always does 🙂 > The ArcWelder command returning an exit status of -11 means it encountered a "Segmentation vault" I've actually never received a segfault report for ArcWelder before. However, I see in the log this is being generated from OSX, and I've never run on that OS before (I don't have access to it at all). However, perhaps it could be executed from the command line with the following parameter: --log-level=DEBUG That should give me an idea where it is crashing at least. The console output
  14. Fyi @ahoeben, some issues with the binaries you are using have been discovered: 1. In some cases depending on the gcode precision, both I and J can be rounded to 0, which will cause a 'bad parameters' reply from the printer. If running from Octoprint, this will disconnect the user unfortunately 😞 In these cases the radius is so small that simply skipping the command would be fine. In every case I've seen the distance traveled was right around 0.001mm, but due to the disconnect this needed immediate correction. 2. This should not really affect the cura plugin, but in some cases the 'dy
  15. Updating this to note that the issues pointed out by @cuq have been resolved. I moved some code around to support counting of arcs aborted due to the firmware compensation, but missed a step. In my haste I just replaced the 1.0.0 release (though in the future I will update the version number appropriately, but have been putting out forest fires recently and breaking my own rules). The new artifacts are available in the 1.0.0 release. There still could be some small glitches with the firmware compensation. Testing that more completely now. @cuq has suggested that a default of 14 for min
×
×
  • Create New...