"Firmware Unresponsive" AGAIN!

Controllers Smoothie
1

Hello
I had this problem a couple of months ago, then it went away for little while, but it decided to come back yesterday when I upgraded my simplify3d to 3.0
I’m getting tired and very frustrated with this BS!
I never had this kind of problems with Ramps, so i’m thinking to go back to the “old” arduino firmware, only that maybe this time I’ll get a Rambo board.
This one is giving me headaches and I think for what I read in the forum, a lot of people find a lot of issues with this board too.

Imported from wikidot

2

Hello.

I’m actually surprised that you didn’t get this problem in the meantime. There is a long-running interaction bug between Simplify3D and Smoothie.

We have contacted the Simplify3D guys, and they are completely un-cooperative, they deny the bug exists ( even though there are plenty of posts about it, and many users have contacted them ) because they have not seen it occur themselves, and they will not help us fix it.

We have worked quite hard at figuring this problem out, but without S3D’s cooperation it’s proven extremely difficult to pinpoint. I am afraid this problem will stand until S3D changes their attitude, or we get lucky trying to debug it.

Please don’t be upset at Smoothie, we want this issue resolved very much, but we don’t get the cooperation we should.

You can use Cura or Slic3r instead of Simiplify3D, they are free, and work just fine.

3

i’ll back what was just said.
their is defiantly some odd interactions going on with simlify3d creator which i have observed while printing.

btw they released 3.01 to fix stability issues.

i’ve not had the problem using ponterface with smoothie so far…

That being said, this is how i use simplify3d creator. slice my model, then upload it to the sd card though usb. then i unplug the usb.
to start prints i use the GLCD… i suppose i could also use the web interface as well for upload and for starting the print…

all things i would monitor or change via simplifiy3d during a print i can do on the GLCD directly on the machine.

4

First of all, love the smoothie project and I’m looking forward to it’s continued development! I’ve been using smoothie for a few months now and S3D for even longer, so I thought I’d add some details to this thread that might help others.

I’ve talked with the S3D team extensively about the “firmware unresponsive” message that is sometimes displayed when sending gcode files. This message is only displayed when the software sends a command, but the firmware doesn’t respond to it. Because our 3D printing firmwares typically use some type of back-and-forth (ping-pong) communication, it’s important that the firmware acknowledges each command so that the software knows when to send the next command. So that should at least explain why you are seeing this message.

Now from my investigation, there’s several things that can cause it. First, and the easiest to explain, is if the firmware receives a command and truly never responds to it. For example, I remember on a really old build of the Sprinter firmware that I used, whenever I would send a specific style of preheat command, the firmware would just stop responding. It never sent back anything, almost as if the board had reset or something. If this is what’s happening, it’s really easy to confirm in S3D because the Communication tab in the machine control panel records every command that is sent and received (just make sure you have the verbose checkbox enabled). So if you look at the communication traffic and you see something like this:

SENT: G1 X50 F3000
RECEIVED: ok
SENT G1 Y100 F3000
Warning: firmware unresponsive

it means that the software sent the “G1 Y100 F3000” command, but never received a response back. As I’ve seen in some other threads on here, you can actually adjust how long the software will wait for a response by going to Tools -> Firmware Configuration, clicking on the Communication tab, and adjusting the “communication timeout” value at the bottom. So if the smoothie needs more time to respond, you could increase that value. Personally, I’ve had it at 30 seconds and I’ve never seen these unresponsive messages from my smoothieboard, even with some long 10+ hour prints. So if yours is something shorter, maybe try increasing it. But if the software doesn’t get a response in that period of time, it’s going to display a warning saying the firmware is unresponsive.

So next time someone sees that warning in the S3D communication log, check to see if there was a command SENT but nothing RECEIVED. And if that’s the case, maybe we can start investigating that specific command that was sent right before it stopped responding to see if there’s any reason why the smoothie firmware didn’t send back a response.

Just a few ideas to hopefully help get to the bottom of this :slight_smile:

PS - I remember emailing with the S3D team many months ago about smoothie support and they mentioned that they had actually already purchased a few smoothieboards on their own to make sure that the software was compatible with the smoothie firmware. I had quite a few conversations with them about it, and it was pretty clear that they had already spent a lot of effort testing it with the software. I think one of their developers even found a bug that got reported to the smoothie repo and is now fixed. So I think they’ve definitely spent some time helping with the project and trying to make it compatible!

5

Yeah, having a timeout on how long the firmware has to answer, is a very bad idea ( unless it’s an extremely large value ).

This is not how the firmware works, so it’s not how the host should talk to it.

Smoothie can take a long time to answer to commands, under completely normal circumstances.

Smoothie receives commands, fills it’s queue with the movements, then starts executing the movements, and only answers “OK” when there is room enough in the queue for additional movements.

This is standard, sane, and S3D should change their code to take it into account.

6

S3D already works that way. It supports command buffering which is what you’re describing. It’s the same thing that Marlin, Sprinter, Repetier, and many other firmwares use. They support all of those other firmwares too, so I think they have the buffering part figured out :wink:

The timeout warning is also present in other software packages like Repetier. I would argue it’s a really good thing to have, because as most everyone knows, USB communication is not reliable. So if you need to send 10000000 commands over a USB cable and you have a 0.001% error rate, you’re bound to lose a few due to corrupt communication. As this happens, the software might not know that it’s supposed to send another command, for example, if the “ok” got corrupted on the way back. It’s smart to inform the user about this if it becomes and issue, because otherwise it would cause prints to stop after a few dropped commands. But of course, it is an option in the software. So if it’s not your cup of tea, you can just disable it. The default value for mine was 30 seconds which is plenty of time for any movement on my printer.

So to help anyone else out there who encounters this, you should go to tools -> firmware configuration, click on the communication tab, and make sure that the “communication timeout” value is some large number like 30-60 seconds. If you want, you could even disable the option entirely if you don’t want to see these warnings.

7

It seems like the folks at Simplify3D are not willing to fix this problem that seems to be a S3D software problem.
After I posted a reply to a thread on the S3D web forum the forum moderators deleted it. I was simply pointing out my problems with S3D running on Smoothie. They apparently didn’t like what I had to say and took it down. I basically stated they need to fix the problem and the post was yanked!

8

Yes, S3D moderates all their forum posts a-priori, and censor what they don’t like.

This is -not- a community-friendly company, as they have demonstrated time and time again.

Because so many people still use their software, we’ll work on making Smoothie compatible, but without S3D’s cooperation it’s a very hard task.

9

what cooperation you still need from them? I have talked to others who send you gcode files that do not run on latest smoothie firmware. They stop at the exact same place every time when using from SD card. Very repeatable.

I have tested one of these files myself. Here are results

sprinter firmware - file ran successfully from SD, no issues
marlin firmware - file ran successfully from SD, no issues
repetier firmware - file ran successfully from SD, no issues
smoothieware - file stops at the exact same place each time, causes weird motion and print stops

I think this makes it easy to solve. Very repeatable and same file works with every other firmware I know. So I would think you have everything you need to investigate and find issue in smoothie

10

what cooperation you still need from them?

Any would be good. Actually, not being hostile and condescending would be a good start before that.

After contacting S3D, they have started by denying the problem exists ( even though many users have reported it to them ), have refused to give us a license ( even though it doesn’t cost them anything ) arguing they have a Smoothieboard and will find the bug if it exists, and have censored users reporting this problem on their forum. And have generally been hostile and not really community-friendly.

I know many people like S3D. It’s probably a great piece of software. But the people behind it have been incredibly far from what we’d expect from people developing software that has to interface with reprap firmwares ( I’m trying not to say anything to mean here, hard to resist ).

I have talked to others who send you gcode files that do not run on latest smoothie firmware.

I have only very recently gotten everything I need for debugging, and have not had time to get to it yet ( I’m moving ). Before that there was always something missing.

smoothieware - file stops at the exact same place each time, causes weird motion and print stops

Yes, and Smoothie works fine with Slic3r, Cura etc.

The current best guess on this problem, is that S3D doesn’t clean up it’s G-code, and leaves insanely small “residual” moves for high-detail prints ( this is not the first time we see them doing something dumb, but previous bugs have been fixed by them ). The more mature slicers don’t do this because it’s just begging for trouble ( S3D is relatively new ).
This doesn’t cause problems with 8-bit firmwares because they are not fast enough to chocke on this.

And BTW : this is trivial to fix on S3D’s side, and much harder to fix on our side. We are working hard on figuring this, they are not.

I think this makes it easy to solve.

It absolutely doesn’t. This is most likely going to be a lot of work.

11

Hello.

A small update of the S3D issue :

  • Simplify3D finally acknowledged the issue, and claims to have fixed it in their latest release ( https://www.simplify3d.com/software/release-notes/ )
  • The latest major update to the Smoothie firmware ( http://smoothieware.org/blog:14 ), which is a complete rewrite of step generation, is expected to make Smoothie resistant, if you are using an older version of S3D, or some other new slicing program which would make the same mistake.

We’d really appreciate it if users of S3D and Smoothie would test the latest versions of both together.
And if you run into any problem, report it to both.

Cheers.

12

I had a print yesterday that failed with “firmware unresponsive” message. When this happens, it is repeatable, i.e: if I run the same print job it fails again in the exact same spot. I updated smoothie to the version mentioned by arthurwolf, ran the same print, and succeeded.

Simplify3D version is 3.1.0. It was strange to find this issue, it was a long time ago since the last time it happened to me, but let’s hope that it is finally fixed because it is really annoying.

By the way, I can also confirm much smoother motion, especially on moves that already had a high acceleration like retractions, it’s nice to see that my extruder will get a break from jerky movements.

Thanks for the work!

Cheers