nowbotmis

• Freeze And Never Run Issue 2435 Docker/for-mac Github Free
• Freeze And Never Run Issue 2435 Docker/for-mac Github.com
• Freeze And Never Run Issue 2435 Docker/for-mac Github Download

. I sliced a model, put the gcode on the external micro SD card (Viki2), and started the print. Homes and preheats like normal. Bot starts the print, gets most of the way through the first skirt loop. STOPS DEAD, making a constant tone noise that I have to assume is the Viki2 buzzer. (I've never heard the buzzer before now, ever.) Steppers on, heaters working normally. LCD is responsive.

I try the E-stop button. Steppers disable, no other effect.

Bug Report or Feature Request (mark with an x) - [ x ] bug report -> please search issues before submitting - [ ] feature request All creatures CreateObject messages currently include their burden.

Heaters stay on, maintaining target temp. No apparent change in print file play status. I try to abort the print via the LCD screen. Power cycle, retry the print multiple times. Exact same effect every time. Re-copy the same gcode file to the micro SD card, retry the print, NO ISSUES. Yeah, the cable length is marginal, but this is the only time I've had issues with it.

There are no stepper or heater wires parallel to the LCD cable bundle. And the print stopped at the EXACT SAME gcode line six or seven times in a row. There's only one gcode command in the print file that would show that specific XYZ coordinate on the LCD at that point in the print, and it stopped there like clockwork every time. I'd be incredibly surprised if electrical noise could do that.

It's also never happened to any other print before, and hasn't happened again on a few different prints since. So I'm a bit skeptical of that explanation. I could buy some kind of SD read bug, not so much noise.

100 segments per second is really not high enough for high-speed motion (eg 400mm/s). It's also not high enough to do long fast travel moves without scraping the crap out of the infill when running without Z-hop. For example, I'd really like to slice with 'only retract when crossing open spaces' selected in S3D because Smoothie has no pressure advance function, but S3D only does Z-lift when retracting, and with 200mm/s travel moves it was crashing the nozzle into the print with alarming regularity.

After several failed prints due to nozzle crashes on travel moves, I tried higher segment rates and that helped. 300 is probably still overkill though.

Ryan Carlyle 26/4/2015, 11:12 น. I downloaded the most recent edge build binary from, err, maybe Triffid's site linked from the main Smoothie website. The LCD splash screen says March 26th. I can try whatever build you recommend, as long as it's recent enough to have the newish Delta tower offset code.

I'll order some more micro SD cards to try to rule that out. If I remember correctly, one came with the Smoothieboard from Uberclock and one came from a reputable brand via Amazon. (I'm not home and can't immediately check.) The printer is only connected to 120VAC while printing.

My office/workshop layout isn't great for leaving USB connected while printing, but I can try Pronterface streaming later in the week. Wolfmanjm 28/4/2015, 17:42 น. I'll do some more testing on printing the same file from each SD card and USB to see whether it crashes in the same place. This bot was working great (or at least not freezing every print) until I rebuilt the effector and updated firmware.

I don't think there's any way switching from PLA to PC effector parts would mess up the board, so the only thing that 'changed' as far as I can tell is the firmware build. So after I try all the various comms troubleshooting options, next step is going to be a firmware rev change. If that still doesn't work, I'll swap in a spare Smoothieboard. Leon Grossman 29/4/2015, 14:34 น. Ryan, I was running some like (12 hour or so) prints over the weekend (all weekend) on the March 1st firmware without issue. I'm using Slic3r 1.2.7 experimental though, you might want to try slicing your model with that and see if it makes a difference.

I've been looking at S3D but I keep seeing posts from people having issues with some of the G-Code it produces. If Slic3r works at least we would know its something in the S3D G-Code and not necessarily teh firmware. On Tuesday, May 5, 2015 at 9:52:47 AM UTC-4, Ryan Carlyle wrote: Yes, S3D. Ryan Carlyle 5/5/2015, 8:32 น. I just had this happen with the 3/1/2105 edge firmware. I had combined three Kossel upper vertices on a build plate and it died at the same point on the 5.8mm layer.

It did this both when Octoprint was serving the data through the USB and from the SD card. I'm going to retry tonight with the newer edge posted to github to see if that also exhibits the same problem. The model was sliced with Slic3r 1.2.6 experimental and with one vertex on the plate scaled to 102% it worked, this was three combined at 102% scaling.

I'll try and see if I can isolate the 5.8mm layer from Slic3r to see if there is something odd in there. On Saturday, April 25, 2015 at 8:53:25 PM UTC-4, Ryan Carlyle wrote. I sliced a model, put the gcode on the external micro SD card (Viki2), and started the print. Homes and preheats like normal. Bot starts the print, gets most of the way through the first skirt loop. STOPS DEAD, making a constant tone noise that I have to assume is the Viki2 buzzer. (I've never heard the buzzer before now, ever.) Steppers on, heaters working normally.

LCD is responsive. I try the E-stop button. Steppers disable, no other effect. Heaters stay on, maintaining target temp. No apparent change in print file play status. I try to abort the print via the LCD screen. Power cycle, retry the print multiple times.

Exact same effect every time. Re-copy the same gcode file to the micro SD card, retry the print, NO ISSUES. Turns out mine was a chair to keyboard interface issue.

Somehow my G-Code file was incomplete and smoothie was doing exactly what it was told. File was about 1/4 the size it should have been, DOH! On Wednesday, May 13, 2015 at 8:37:40 PM UTC-4, Ryan Carlyle wrote: Ok, that's a different crash issue then. I've seen at least three or four different types of crash since I started using Smoothie a few months ago. (It is not particularly stable.) The type of crash I've been posting about is simply the only one that's repeatable enough for troubleshooting to be possible.

Wolfmanjm 14/5/2015, 0:07 น. Actually Smoothie is very stable and has been for quite some time, only very few people seem to have issues, unfortunately you seem to be one of them. Karma sucks;) On Wednesday, May 13, 2015 at 5:37:40 PM UTC-7, Ryan Carlyle wrote: Ok, that's a different crash issue then. I've seen at least three or four different types of crash since I started using Smoothie a few months ago.

(It is not particularly stable.) The type of crash I've been posting about is simply the only one that's repeatable enough for troubleshooting to be possible. WZ9V 14/5/2015, 8:45 น. I sliced a model, put the gcode on the external micro SD card (Viki2), and started the print. Homes and preheats like normal. Bot starts the print, gets most of the way through the first skirt loop. STOPS DEAD, making a constant tone noise that I have to assume is the Viki2 buzzer. (I've never heard the buzzer before now, ever.) Steppers on, heaters working normally.

LCD is responsive. I try the E-stop button.

Steppers disable, no other effect. Heaters stay on, maintaining target temp. No apparent change in print file play status. I try to abort the print via the LCD screen. Power cycle, retry the print multiple times. Exact same effect every time. Re-copy the same gcode file to the micro SD card, retry the print, NO ISSUES.

I may have missed this Ryan, but have you stepped back to an earlier version of the firmware to determine if the hang still occurs? I should also mention that I have just completed another printer using the latest version of smoothie bin and I have been getting hangs.

Several things are different with this build and I am still eliminating possible wiring or interference issues, but I can't totally dismiss that this is the first one with the latest firmware. Reverting to an earlier version of the firmware will be the easiest thing to try so I'll do that first. In any case I'll keep working on it over the weekend. Steve Graber Ryan Carlyle 15/5/2015, 20:03 น. I sliced a model, put the gcode on the external micro SD card (Viki2), and started the print. Homes and preheats like normal. Bot starts the print, gets most of the way through the first skirt loop.

STOPS DEAD, making a constant tone noise that I have to assume is the Viki2 buzzer. (I've never heard the buzzer before now, ever.) Steppers on, heaters working normally. LCD is responsive.

I try the E-stop button. Steppers disable, no other effect. Heaters stay on, maintaining target temp. No apparent change in print file play status. I try to abort the print via the LCD screen. Power cycle, retry the print multiple times.

Exact same effect every time. Re-copy the same gcode file to the micro SD card, retry the print, NO ISSUES. Problem narrowed down to LCD/SD card issue. I've been fighting some unusual hanging/disconnect/reboot/LCD/SD Card issues too. I am using a Viki2/X5-mini V1.1 combo with stock length cabling provided by Panucatt. I tried stepping back through several earlier versions of firmware all the way into mid-2014 and my test file (Exported from S3D surprise surprise) continued to hang up this printer. Well hung printing from internal SD, external SD and over USB host on all firmware versions.

I'm going to say it's definitely NOT firmware version related. This file has printed successfully on many a previous Smoothie printer but on this one it's giving me nothing but grief.

I disabled all of the LCD panel code from the config and pulled the Viki2 off the printer, re-upped to the latest firmware version and the printer is now running on it's 3rd hour with no issues, no hiccups, just plain, super quiet, uneventful printing at 90mm/s with 300mm/s travels and accelerations set to 4,000. Using.9 degree steppers, 16th microstepping, 24v motor and hotend, with 110v heated bed and 110v heated chamber using Fostek 40A SSRs. My intuition tells me that it's all about the LCD/ext SD (maybe just cabling noise) at this point. The big difference on this printer is that I've located the X5-mini control board BELOW the 400mm round 115v AC heated bed. On all previous printers the control board was located in the TOP of the printer about 1m away from the heated bed coil.

Assuming we are seeing RF or other inductance interacting with the Viki2 wiring harness, do you think that looping the Viki harness through a ferrite bead setup might help? My current takeaway? - For the time being I won't use an LCD panel with SD card. Leon Grossman 16/5/2015, 14:00 น. I sliced a model, put the gcode on the external micro SD card (Viki2), and started the print. Homes and preheats like normal.

Bot starts the print, gets most of the way through the first skirt loop. STOPS DEAD, making a constant tone noise that I have to assume is the Viki2 buzzer. (I've never heard the buzzer before now, ever.) Steppers on, heaters working normally. LCD is responsive. I try the E-stop button.

Steppers disable, no other effect. Heaters stay on, maintaining target temp. No apparent change in print file play status.

I try to abort the print via the LCD screen. Power cycle, retry the print multiple times.

Exact same effect every time. Re-copy the same gcode file to the micro SD card, retry the print, NO ISSUES. I do appreciate the work and effort you put into Smoothie, I really do. You made a number of good suggestions in this thread for troubleshooting steps.

But honestly, if you don't feel a sense of ownership for the code, then you shouldn't be doing so much work on it. People like Jetguy and I are of the opinion that if you don't take some level of ownership of the code's performance and quality, you shouldn't be a significant contributor. That sort of 'I'll add to it but I'm not responsible for it' attitude leads to bloated, buggy code that eventually dies under its own weight.

(This is a big reason why people are gradually abandoning Marlin.) If no one working on the project feels responsible for its overall direction and performance, it's effectively abandonware. It's zombie code that just hasn't had enough time to decay much yet. As far as I can tell, the Smoothieware project has no devs.

It just has some people who add features they want, and some people who noodle around with improvements every once in a while. Whether that's true or not, that's how it looks. Y'all (Jim, Arthur, etc) are welcome to maintain or not maintain and support the code as much as you want, and that's fine, it's your project / your contribution to the project. But it surprises and disappoints people when they realize that Smoothieware is just a shared sandbox somebody built at the playground, and not a product that someone feels a sense of obligation to support. Wolfmanjm 16/5/2015, 19:10 น. WRT this specific bug I have expressed my opinions on what the problem may be. I cannot fix it as I cannot duplicate it.

I have expressed my opinion that is is unlikely to be a regression introduced since march 1, that is my opinion. I have spent much time looking at what has been committed since then and see nothing that would cause this issue. Coupled with the fact that a significant number of people are using the current code with no problems I think it is reasonable to suggest it is something odd with your system.

Jim, thanks for taking the time to respond in a reasonable manner, I appreciate that. People can get very heated when it comes to differences in how projects should be run (or not run). There are multiple flavors of open source.

People like Jetguy and I are used to the kind of project where someone dedicated to the platform 'owns' the code base, acts as gatekeeper to changes, keeps a system-level view to maintain stability and performance, and does thorough pre-release testing. (Repetier, Sailfish, others.) That's one type of open source project. Smoothie isn't that type of project. And that's fine for Smoothie.

The problem here seems to be that people think Smoothie IS that type of project. That's where you get the incorrect expectations and apparent sense of entitlement. People think Smoothie is the kind of open source project that has active devs with a sense of responsibility for the code. Why do people think that?

It's an honest question - what makes many competent and reasonable people believe Smoothie is supported by a core team or run as a cohesive project? Whatever is creating that expectation is the root issue here. Ed Boston 16/5/2015, 20:56 น. As a new user of Smoothie, maybe I can help with understanding why people think they way they do. Personally, I was under the impression there was a core group behind Smoothie.

One reason for that is the existence of. For such a website to exist, it is reasonable to believe there is a group behind it to maintain it. I know this is just a page hosted on, but someone must 'own' it and maintain it. Another thing is how Smoothie was started, as a Kickstart project. I think it is reasonable to assume the people behind the kickstarter project would still be involved in it and controlling it to a point. When someone purchases a smoothie board, it is flashed with the firmware already.

Who decides which version is sent? What is on the SD card? I understand what you are saying about the type of open source code this is. But when someone buys a complete solution, like a smoothieboard which has both hardware and software, I think it is understandable that people would think there is someone behind it, directing it. When those people are not around and active, others that are passionate about the project step up, like wolfmanjm, and to the new people become the driving force behind the project. Wolfmanjm even indicated in his reply there are gatekeepers (Arthur can replace me.).

So if Smoothieware is not run like other open source projects, I can see where people can get confused. That does not justify personal attacks.

This is just my personal view of what has happened in this thread. I'll keep lurking in the background learning what I can in the mean time.

I'm hoping when I get some of my other projects finished, I will be able to help contribute to the code some. Chris Cecil 16/5/2015, 21:41 น. The other day after he had 3 reports of the issue he asked me to update my FW and check to see if I have the same thing. I printed over 30hrs without an issue. I am not using the external SD or S3D.so I have to assume.like wolfmanjm did.that it is something in one of those 2. To assume nothing is being done and your complaints are ignored is probably a bad idea in most cases.there are times where it is being tested by multiple people at once and they are unable to replicate your specific issue. I appreciate everything wolfmanjm does for the project and I see very few others with the same type of dedication to code and helping the end user.don't mistake a coarse answer as not helping.

Freeze And Never Run Issue 2435 Docker/for-mac Github Free

Wolfmanjm has as much responsibility to support 'every owner of the board' as much as he is responsible to support the breadboarded smooothies that were done years ago.NONE.he makes nothing off board sales. Wolfmanjm 16/5/2015, 22:16 น. Say you have a RAMPS board, running Marlin, and you run into the sort of trouble this thread discusses. If you contact your board seller, you'll most likely get no answer, and if you do they'll just tell you firmware isn't their responsibility. If you want to try contacting the Marlin community, no meaningful IRC or mailing lists there really, you'll just have to open an issue on Github ( it's become such a mess that they aren't even currently available ) and pray somebody takes interest in your problem ( pretty unlikely ) or somebody who knows how to code runs into the same problem, and fixes it him/her-self. Another option is to contact the reprap community, but that won't really give you any meaningful help if you have trouble with an actual bug, it'll only help you if you are running into a common-place user error of some sort. So yeah, lots of the time, you are fucked, and things only get fixed due to the sheer amount of users Marlin has.

You can also contact me directly, my email is all over the wiki. Now when you contact me, I'll do my best to help you with your problem. Not because I sell Smoothieboards, I've been doing the helping since before I made a single buck.

Just because that's my way of contributing to the Open Source Smoothie project. I spend about 50% of my active/work time doing this, answering emails, helping people on the various community mediums etc. Most of the time, it's people not having taken the time to read the documentation ( which I also spend a lot of time on ).

Sometimes it's a problem with the user's setup, very rarely it's a problem with the board ( in which case I become RobotSeed's Arthur again and work on getting them a replacement ). Now say you want a board that's exactly like the Smoothieboard, but in addition to the board, you want some sort of guarantee that any bug you run into -will- be investigated and fixed in say a week.

That means I have to hire somebody. That means I bump the board's price 50%.

That means nobody buys it ( because nobody cares about week-fast bug fixing ), people will just buy the board that's exactly the same but doesn't cost 50% more. Then I go out of business, I have to take a job, and I don't even have time to do what I do now for the project. Everybody looses.

Smoothie:. Is way more structured than any other firmware I've seen around ( at the cost of performance even. It was one of the initial design decisions ),.

Has very strict standards for contributions ( which has gotten more than one person upset ),. Has the best documentation there is all around ( I get quasi-daily emails of people saying how impressed they are with it ). Is extremely focused on building a community ( find another firmware with a 100-strong IRC channel, that's 1/5 #reprap.

Also have very active mailing lists, forum, and social media presence, all of which are not common in other firmwares ). I have to answer this: Ryan Carlyle I do appreciate the work and effort you put into Smoothie, I really do.

You made a number of good suggestions in this thread for troubleshooting steps. But honestly, if you don't feel a sense of ownership for the code, then you shouldn't be doing so much work on it. People like Jetguy and I are of the opinion that if you don't take some level of ownership of the code's performance and quality, you shouldn't be a significant contributor. That sort of 'I'll add to it but I'm not responsible for it' attitude leads to bloated, buggy code that eventually dies under its own weight. (This is a big reason why people are gradually abandoning Marlin.) If no one working on the project feels responsible for its overall direction and performance, it's effectively abandonware. It's zombie code that just hasn't had enough time to decay much yet. To me, where the confusion comes in is the difference on how the RAMPS board and Smoothie board are sold.

In the case of the RAMPS, it is just a shield to an Arduino Mega board and comes with no firmware (not sure if boards like Rambo that has the processor built in has the firmware preinstalled). Whereas a Smoothie board, when purchased, does comes with firmware already installed, and a firmware with a name so similar to the board, it is hard not to think they are one and the same. On Saturday, May 16, 2015 at 10:16:04 PM UTC-7, wolfmanjm wrote.

Well this topic took a hard right turn! My.0003c opinion is firmly agreeing with Jim foremost echoing the sentiment of Arthur. My opinion is that if you don't like the free cookies, don't eat the damn cookies! The hardware is very inexpensive for the performance and the firmware is FREE!!! Damn it all, I dig smoothie.

Freeze And Never Run Issue 2435 Docker/for-mac Github.com

It runs my deltabots so fine. Nothing in the Arduino camp can touch it not only in performance but also for ease of configuration and customization. So Jim, please don't quit! I do want to get back to the original issue, coming from my current experience which is eerily similar to Ryans. So if Ya'll don't mind? Take it outside (to another thread maybe?) or drop it like gentlemen.

Having been experiencing some unusual hangs and resets on my latest build I did remove the LCD and ext SD from the machine. Jim you did indeed tell me some time ago that there were some issues with timing regarding the length of the cable. In any case I removed it all to see if it was causing the hangup.

The first print after removing the LCD panel lasted for 5 out of 7 hours and then it reset. I decided rather than attempt a complete rewiring of the printer back to an earlier spec that has proven very reliable that first I would just swap in another x5-mini control board. Post swap - Lo and behold the 7 hour print completed and I am now in the middle of a 12 hour print job.

I might even consider adding the LCD back on and continuing the testing. Ryan, have you swapped control board for a fresh one? Leon Grossman 17/5/2015, 17:55 น. Steve, I haven't tried another board.

Having the issue be persistent and repeatable with one firmware build, but nonexistent with another firmware build, suggested to me that a hardware swap would be unproductive. I COULD swap in a spare Smoothieboard, which I have on hand already, but to be honest, I've reached the limit to the level of effort I'm willing to put into the platform. A few dozen troubleshooting hours is enough to give up and move on. Smoothieware is not sufficiently mature or stable or actively-supported to meet my needs. I'm on to the next ARM-based platform in the list. Arthur, it seems pretty obvious that you're not familiar with Sailfish.

It's open-source and has a much larger installed userbase than Marlin. Plus better support, better code, better performance, and better stability. That's the bar you ought to compare Smoothie to, not the bloated and unfocused Marlin code. Wolfmanjm 2/6/2015, 21:47 น. On Tuesday, June 2, 2015 at 7:42:41 PM UTC-7, Ryan Carlyle wrote: Steve, I haven't tried another board. Having the issue be persistent and repeatable with one firmware build, but nonexistent with another firmware build, suggested to me that a hardware swap would be unproductive.

I COULD swap in a spare Smoothieboard, which I have on hand already, but to be honest, I've reached the limit to the level of effort I'm willing to put into the platform. A few dozen troubleshooting hours is enough to give up and move on. Smoothieware is not sufficiently mature or stable or actively-supported to meet my needs.

I'm on to the next ARM-based platform in the list. Arthur, it seems pretty obvious that you're not familiar with Sailfish. It's open-source and has a much larger installed userbase than Marlin. Plus better support, better code, better performance, and better stability. That's the bar you ought to compare Smoothie to, not the bloated and unfocused Marlin code.

Triffid Hunter 2/6/2015, 21:50 น. On Wed, Jun 3, 2015 at 4:42 AM, Ryan Carlyle wrote: Steve, I haven't tried another board. Having the issue be persistent and repeatable with one firmware build, but nonexistent with another firmware build, suggested to me that a hardware swap would be unproductive. I COULD swap in a spare Smoothieboard, which I have on hand already, but to be honest, I've reached the limit to the level of effort I'm willing to put into the platform.

A few dozen troubleshooting hours is enough to give up and move on. Smoothieware is not sufficiently mature or stable or actively-supported to meet my needs.

I'm on to the next ARM-based platform in the list. Sailfish is open source. The main fork IS community-driven. Some pieces came from early open-source Makerbot Cupcake/ToM code, but Makerbot wrote fairly little of what's currently in there - they actually ended up forking Sailfish to run their own product because it performed significantly better than Marlin or their own original firmware in benchmark testing. The community of early Makerbot users developed it, tested it, and continues to support it. It has about as many active users as Marlin (hundreds of thousands).

Dozens of companies and untold numbers of hobbyists build machines around the open-source Mightyboard/Sailfish platform. I am honestly baffled that you're so dismissive and ignorant about it.

Dan Newman, one of the two primary authors of Sailfish, is so generous with his time answering all kinds of questions and responding to bug reports that my jaw literally fell open when I saw this. He's one of the most active contributors on over a dozen google groups, including the specific group for Sailfish support where you can go ask questions about that code. He's been supporting Sailfish on a daily basis for years without ever earning a dime on it.

Freeze And Never Run Issue 2435 Docker/for-mac Github Download

He doesn't promote it, doesn't sell products based on it, doesn't Kickstarter it. He just supports a large fraction of all global consumer/hobbyist 3D printers because he wants to. And his helpfulness and responsiveness to bug reports is legendary. For one minor example: whenever he finds a bug in Sailfish that originated from GRBL, he reports it over to Marlin and Repetier devs because they share a lot of the same underlying algorithms by way of Sprinter.

Again, I am baffled by how you could get the support situation so wrong. Sailfish is one of the best examples for how an open-source project should support end-users. The bits of code that Makerbot originally wrote when they were open-source are not terribly impressive. No disagreement there. But the core Sailfish functionality - the motion planner - is so insanely hyper-optimized that it's actually used as an example of platform-specific code optimization in some university courses. (Usually in contrast to Marlin, which is kind of the opposite.) This means much of the code is ugly and hard to work on, because that's what was required to get superior performance out of an 8bit processor. OO programming was never an option - that was tried by others and it failed miserably.

So no, I'm not surprised you're not impressed by the code, that's fine, just different philosophies there. For example, nobody would re-write Sailfish on an ARM, because the entire point of Sailfish was doing everything possible to make the 8bit processor perform at its limit. It's not intended to be ported or platform-independent. (Very different from Repetier in that regard, which is interesting, because otherwise they have a lot of similarities.).

There are a few reasons why it isn't visibly developed or forked more actively than it is. (And I should add, it IS forked actively in the commercial consumer bot space, but that's not on Github.) One reason is that most major machine configurations are covered by existing firmware builds and text config files, like Smoothie uses (but a little less user-friendly). Another is that Dan often works with people in private and either fulfills feature requests himself or adds their code directly to the main repo without public pull requests. But the main reason is probably because Sailfish is terminally mature - the Atmega1280's code space is filled within a few bytes by every build, so new features will only go to the minority of users who have Atmega 2560s.

The execution speed is already optimized to the bleeding edge of what an AVR can do, it has all the features that are practical for an 8bit processor, it's reliable, configuration via EEPROM for different printer hardware is fairly easy, and the final print quality is still in this day of ARMs considered by many to be superior to all the other open-source alternatives. It simply doesn't need 2,000 forks to meet people's needs. Some pieces came from early open-source Makerbot Cupcake/ToM code, but Makerbot wrote fairly little of what's currently in there - they actually ended up forking Sailfish to run their own product because it performed significantly better than Marlin or their own original firmware in benchmark testing.

The community of early Makerbot users developed it, tested it, and continues to support it. It has about as many active users as Marlin (hundreds of thousands). Dozens of companies and untold numbers of hobbyists build machines around the open-source Mightyboard/Sailfish platform. I am honestly baffled that you're so dismissive and ignorant about it.

Dan Newman, one of the two primary authors of Sailfish, is so generous with his time answering all kinds of questions and responding to bug reports that my jaw literally fell open when I saw this. He's one of the most active contributors on over a dozen google groups, including the specific group for Sailfish support where you can go ask questions about that code. He's been supporting Sailfish on a daily basis for years without ever earning a dime on it. He doesn't promote it, doesn't sell products based on it, doesn't Kickstarter it. He just supports a large fraction of all global consumer/hobbyist 3D printers because he wants to. And his helpfulness and responsiveness to bug reports is legendary. For one minor example: whenever he finds a bug in Sailfish that originated from GRBL, he reports it over to Marlin and Repetier devs because they share a lot of the same underlying algorithms by way of Sprinter. Again, I am baffled by how you could get the support situation so wrong.

Sailfish is one of the best examples for how an open-source project should support end-users. The bits of code that Makerbot originally wrote when they were open-source are not terribly impressive. No disagreement there.

But the core Sailfish functionality - the motion planner - is so insanely hyper-optimized that it's actually used as an example of platform-specific code optimization in some university courses. (Usually in contrast to Marlin, which is kind of the opposite.) This means much of the code is ugly and hard to work on, because that's what was required to get superior performance out of an 8bit processor. OO programming was never an option - that was tried by others and it failed miserably. So no, I'm not surprised you're not impressed by the code, that's fine, just different philosophies there. For example, nobody would re-write Sailfish on an ARM, because the entire point of Sailfish was doing everything possible to make the 8bit processor perform at its limit. It's not intended to be ported or platform-independent. (Very different from Repetier in that regard, which is interesting, because otherwise they have a lot of similarities.).

There are a few reasons why it isn't visibly developed or forked more actively than it is. (And I should add, it IS forked actively in the commercial consumer bot space, but that's not on Github.) One reason is that most major machine configurations are covered by existing firmware builds and text config files, like Smoothie uses (but a little less user-friendly).

Another is that Dan often works with people in private and either fulfills feature requests himself or adds their code directly to the main repo without public pull requests. But the main reason is probably because Sailfish is terminally mature - the Atmega1280's code space is filled within a few bytes by every build, so new features will only go to the minority of users who have Atmega 2560s. The execution speed is already optimized to the bleeding edge of what an AVR can do, it has all the features that are practical for an 8bit processor, it's reliable, configuration via EEPROM for different printer hardware is fairly easy, and the final print quality is still in this day of ARMs considered by many to be superior to all the other open-source alternatives. It simply doesn't need 2,000 forks to meet people's needs. Well to EVERY other smoothie owner and I'm one of them, this is literally what you are up against owning that board. Jim, might be some hero to many of you, but his response to bug reports, his lack of responsibility is just beyond belief. The attitude of 'I gave the code freely- accept it and don't complain' is just the jerk that he is.

Some of you might be running MORE than a printer from smoothie. You might run a CNC mill or laser cutter. Given the response from a main firmware contributor, your eyes should be wide open.

I'm not making this up, Ryan's not making this up, you heard it directly from Jim. Safety is not his problem. He doesn't care, and expect you to kiss his @$$ for anything he does. Again, you own a board (and so do I) that only runs one firmware branch. You have no alternative. Other boards, you can run many different firmware from alternate sources.

If you get one bad apple contributing to a firmware and he want's to be an complete prick, fine, use something else. Smoothie owners are stuck with Jim. Jim said in public he doesn't care. Make your own choice but again, this is bigger than one single error. This is bigger than just me or Ryan or anyone complaining.

Arthur Wolf 12/6/2015, 2:05 น. Well to EVERY other smoothie owner and I'm one of them, this is literally what you are up against owning that board. Jim, might be some hero to many of you, but his response to bug reports, his lack of responsibility is just beyond belief. The attitude of 'I gave the code freely- accept it and don't complain' is just the jerk that he is. Some of you might be running MORE than a printer from smoothie. You might run a CNC mill or laser cutter. Given the response from a main firmware contributor, your eyes should be wide open.

I'm not making this up, Ryan's not making this up, you heard it directly from Jim. Safety is not his problem. He doesn't care, and expect you to kiss his @$$ for anything he does. Again, you own a board (and so do I) that only runs one firmware branch. You have no alternative. Other boards, you can run many different firmware from alternate sources. If you get one bad apple contributing to a firmware and he want's to be an complete prick, fine, use something else.

Smoothie owners are stuck with Jim. Jim said in public he doesn't care. Make your own choice but again, this is bigger than one single error.

This is bigger than just me or Ryan or anyone complaining. I sliced a model, put the gcode on the external micro SD card (Viki2), and started the print.

Homes and preheats like normal. Bot starts the print, gets most of the way through the first skirt loop. STOPS DEAD, making a constant tone noise that I have to assume is the Viki2 buzzer.

(I've never heard the buzzer before now, ever.) Steppers on, heaters working normally. LCD is responsive. I try the E-stop button. Steppers disable, no other effect. Heaters stay on, maintaining target temp. No apparent change in print file play status.

I try to abort the print via the LCD screen. Power cycle, retry the print multiple times. Exact same effect every time. Re-copy the same gcode file to the micro SD card, retry the print, NO ISSUES.