Morning everyone! I have a Wanhao Duplicator 4s running Sailfish v7.7 with S3D. If I don't keep S3D open and active on the PC then the prints will just hang up then resume, hang up and resume like a buffering issue. I have it connected via USB.
Thoughts?
Re: OS X El Capitan and Duplicator 4S Buffering
There's all kinds of power saving stuff on El Capitan, so you have to be careful to not let the computer go to sleep since that can cause the prints to stop.
I just run this little app called Caffeine that keeps it awake for specified periods of time like 2 hours or something like that. It's easier than constantly changing my sleep settings and helps make sure the computer stays awake.
I just run this little app called Caffeine that keeps it awake for specified periods of time like 2 hours or something like that. It's easier than constantly changing my sleep settings and helps make sure the computer stays awake.
Re: OS X El Capitan and Duplicator 4S Buffering
Well I don't think this is the case here because I'll have the MAC on and trying to use Safari or working with Adobe and it buffers and stops and buffers. Only keeps going if S3D is in the front.
Re: OS X El Capitan and Duplicator 4S Buffering
I'm having the exact same issue, on a Macbook Pro 13" Retina, with a Wanhao 4S. As long as at least some part of any Simplify3D window is showing, the print continues as it should. If I have Simplify3D in the background, even if I'm not actively using the Macbook, the printer will stall for a few seconds then make one or two small movements, then stall again. If I CMD-Tab to Simplify3D, the print resumes instantly, as if nothing had happened. Prints where I keep Simplify3D in the foreground for the whole duration go through as they should. There is definitely no sleeping of display or Macbook involved in my case, I've disabled all of that stuff.
Re: OS X El Capitan and Duplicator 4S Buffering
Again, this is likely due to OS X power saving stuff. It throttles the available CPU and memory for background apps. So if you put it in the background and start doing other stuff, it may start throttling the resources available to the app, eventually causing it to stall.
I'm not sure if there is a way to fully disable this in the latest El Capitan, so your best bet is probably to use the SD card or try to leave the software in the foreground when printing.
I'm not sure if there is a way to fully disable this in the latest El Capitan, so your best bet is probably to use the SD card or try to leave the software in the foreground when printing.
Re: OS X El Capitan and Duplicator 4S Buffering
Well this is a very big pain and needs to be addressed.
Re: OS X El Capitan and Duplicator 4S Buffering
As I said, no power saving involved in my case. Besides, limiting memory for background apps? I think you are confusing OS X with iOS (which does things like that since swapping is a no-no on mobile devices). The kernel does move inactive background applications to swap after a while, but that depends on the application's activity, not the fact that it's running in the background. It also doesn't happen if you still have unused physical memory, which I have, in my case (you could generate such a scenario by producing so much memory pressure, i.e. run so many active applications that you have to overcommit your memory to satisfy all demands, and then stuff grinds down to a halt, but that doesn't happen easily). Simplify3D is by no means inactive (or should be), so I doubt this is the explanation for this bug.
The CPU limiter is only active if you're running off the battery, or once the CPU hits a certain temperature threshold (and you have to push the machine hard for quite a while to hit that). Darwin does have an unfair scheduler, but its behavior does not include resource-starving applications which have no foreground GUI elements. That would cripple any browser, for instance. At any rate, Simplify3D's memory usage stays mostly constant, as well as its CPU usage, regardless of whether the window is visible or not, on my machine. Stalling still happens. When I pull it back into the foreground, the UI is instantly fully responsive, also an uncommon thing for applications that have been moved to swap or whatever.
One more thing I noticed, I don't even have to keep it in the foreground; I just have to move my windows in such a way that a part of the background window is showing. It's only when all of the UI is covered that this bug appears.
Besides, Simplify3D is the only application showing such behavior. If your theory was true, you couldn't run anything that as a daemon in the background, or just in detached mode, or whatever, and that manifestly works extremely well, otherwise a huge lot of software would simply stop working (like Makerware, which uses a background daemon to communicate with the printer, and the software I develop for a living does that too.)
And lastly, such trivial things (that none of the free competition suffers from) shouldn't be an issue in a commercial application at this price point. I hope something can be done about this issue. If it makes everything more complicated and error-prone, I can't really justify the purchase.
The CPU limiter is only active if you're running off the battery, or once the CPU hits a certain temperature threshold (and you have to push the machine hard for quite a while to hit that). Darwin does have an unfair scheduler, but its behavior does not include resource-starving applications which have no foreground GUI elements. That would cripple any browser, for instance. At any rate, Simplify3D's memory usage stays mostly constant, as well as its CPU usage, regardless of whether the window is visible or not, on my machine. Stalling still happens. When I pull it back into the foreground, the UI is instantly fully responsive, also an uncommon thing for applications that have been moved to swap or whatever.
One more thing I noticed, I don't even have to keep it in the foreground; I just have to move my windows in such a way that a part of the background window is showing. It's only when all of the UI is covered that this bug appears.
Besides, Simplify3D is the only application showing such behavior. If your theory was true, you couldn't run anything that as a daemon in the background, or just in detached mode, or whatever, and that manifestly works extremely well, otherwise a huge lot of software would simply stop working (like Makerware, which uses a background daemon to communicate with the printer, and the software I develop for a living does that too.)
And lastly, such trivial things (that none of the free competition suffers from) shouldn't be an issue in a commercial application at this price point. I hope something can be done about this issue. If it makes everything more complicated and error-prone, I can't really justify the purchase.
Re: OS X El Capitan and Duplicator 4S Buffering
I'm not confusing the two. There's plenty of OS X stuff that goes on behind the scenes that affects app function and USB interfaces. As proof that this is an OS X issue, try running the software in prior OS X versions. I never had these problems in earlier 10.8, 10.9, etc until they introduced all their new power saving stuff in El Capitan. As I mentioned, unfortunately, I don't know any way to turn it off, so you might be stuck with the options I mentioned above.
I'm just trying to help, so if you don't agree and you want to troubleshoot some other way, I wish you luck. But there's no way the S3D team is doing anything different with their software whether it's in the foreground or the background. The application wouldn't even know that information, so in my opinion, this is definitely an OS X related issue.
I'm just trying to help, so if you don't agree and you want to troubleshoot some other way, I wish you luck. But there's no way the S3D team is doing anything different with their software whether it's in the foreground or the background. The application wouldn't even know that information, so in my opinion, this is definitely an OS X related issue.
Re: OS X El Capitan and Duplicator 4S Buffering
Thanks bud! Its just annoying lol! I'll poke around some more and even ask Apple for some support.andrewk72 wrote:I'm not confusing the two. There's plenty of OS X stuff that goes on behind the scenes that affects app function and USB interfaces. As proof that this is an OS X issue, try running the software in prior OS X versions. I never had these problems in earlier 10.8, 10.9, etc until they introduced all their new power saving stuff in El Capitan. As I mentioned, unfortunately, I don't know any way to turn it off, so you might be stuck with the options I mentioned above.
I'm just trying to help, so if you don't agree and you want to troubleshoot some other way, I wish you luck. But there's no way the S3D team is doing anything different with their software whether it's in the foreground or the background. The application wouldn't even know that information, so in my opinion, this is definitely an OS X related issue.
Thanks I'll reply if I find a solution.
Re: OS X El Capitan and Duplicator 4S Buffering
I think found the culprit, it's App Nap. That sorry excuse for a power saving feature has been around since Maverick, so I didn't check this until now, based on observations that this happens only under El Capitan (perhaps App Nap behavior changed subtly? I don't know of major changes but who knows).
You can easily try this yourself using Activity Monitor:
Apple calls that a "standby" mechanism (which is horrible naming because this is at least standby mechanism #2 in OS X). Anything more complex than a word processor and this feature starts to break things, unless precautions are taken. Since it's not exactly new, most affected applications take care of this one way or another. It's also a really cheap way to make stuff appear snappier ... until you CMD-Tab to a "App Nap"ping window that suddenly needs to catch up with a lot of things. Someone at Apple also seems to have forgotten to add kernel logging for that as well ... that kernel logs next to absolutely any inane thing, but then completely freezes an app and no word reaches /var/log (or I've missed it completely).
At any rate, it's super easy to turn off, you don't even have to touch the command line (unless you want to disable it system-wide, which even I wouldn't recommend, despite all the flaming...)
How to fix this:
Go to /Applications, locate your Simplify3D app file (the one with the funky symbol, probably in a subdirectory), select it, CMD+I, tick the "Disable App Nap" checkbox. This setting needs a restart of Simplify3D to become effective. That's it, no more App Nap for Simplify3D.
I hope this works for others having the same issue too, I'm an hour into a longish print and with S3D hidden from view behind this browser window, without as much as a tiny hiccup, so I guess this did it for me. Good luck, everyone!
You can easily try this yourself using Activity Monitor:
- Launch Simplify3D, start a print. Wait till your printer starts printing.
- In the Activity Monitor, within the CPU tab, right click on the column names, select App Nap. Drag it to the left so you see both Name and App Nap column.
- Cover your S3D window completely, e.g. with a browser window or maximize the Activity Monitor or whatever. There must not be any part of S3D's UI in view, not even the title bar, nothing.
- Wait. Your printer will stall after a minute or so. Once that happens, within a second or so, the App Nap column suddenly says App Nap is active. CMD-Tab to S3D, boom, printer resumes, App Nap says disabled. Repeat until you're satisfied.
Apple calls that a "standby" mechanism (which is horrible naming because this is at least standby mechanism #2 in OS X). Anything more complex than a word processor and this feature starts to break things, unless precautions are taken. Since it's not exactly new, most affected applications take care of this one way or another. It's also a really cheap way to make stuff appear snappier ... until you CMD-Tab to a "App Nap"ping window that suddenly needs to catch up with a lot of things. Someone at Apple also seems to have forgotten to add kernel logging for that as well ... that kernel logs next to absolutely any inane thing, but then completely freezes an app and no word reaches /var/log (or I've missed it completely).
At any rate, it's super easy to turn off, you don't even have to touch the command line (unless you want to disable it system-wide, which even I wouldn't recommend, despite all the flaming...)
How to fix this:
Go to /Applications, locate your Simplify3D app file (the one with the funky symbol, probably in a subdirectory), select it, CMD+I, tick the "Disable App Nap" checkbox. This setting needs a restart of Simplify3D to become effective. That's it, no more App Nap for Simplify3D.
I hope this works for others having the same issue too, I'm an hour into a longish print and with S3D hidden from view behind this browser window, without as much as a tiny hiccup, so I guess this did it for me. Good luck, everyone!
