nallath

As far as I can see from your logs, Cura attempted to send the materials to the printer. It also didn't seem to have received them, which usually happens because the printer refused them. The main situation when this happens is when you duplicate a material and then forget to unlink the material. At that point it has the same GUID, which makes the printer think that it already has that material. Anyhow, someone from the FW team will need to have a look at this, since this is as far as my knowhow on how the printer handles it goes. You could have a look at http://{PRINTER_IP}/api/v1/system/log right after you start up cura and have a look what pops up there.

You actually found the reason why the settings that produce more accurate prints are not the same as the visual ones. The engineering profiles have a very, very high jerk setting. This means that they are forced through the corner as fast as possible (instead of slowing down for the corner). This means that it doesn't pause as much in the corner, which means you have less of a blob in the corner. The downside of this is that you get these wobble vibrations. They do cause a slight inaccuracy, but that is way less than the blob you would normally get. Unfortunately, these wobbles are really easily noticeable to the human eye (which is why we can't enable this setting by default, since the "visual crowd" would get pretty upset...)

The engineering profile mostly improves the accuracy in the XY direction. For the next sprint, we're going to be working on material shrinkage compensation, so I expect that to be in the 4.8 release.

That is because the flow on the screen of your printer is based on a change on what is in the g-code. It will always show 100%, regardless of what you change in Cura.

It's just that most discussion about things like this happens on the github issue tracker (since that is where most developers / contributors of Cura are active)

Lots of reasons, really. One of them being is that not everyone is printing parts that need to fit well. Some settings have a positive influence on accuracy, but a very negative influence on how the part looks (which is a big thing for a lot of visual prototyping / architectural business). So as with all things, it's a balancing act. This balancing act is also the main reason that we added the "intent" profiles; those make it easier to select settings for what you want to achieve. The experimental settings are primarily because they are simply not quite as stable as the rest of the features. So we basicly have two choices to make here; Don't release those features at all, or provide them with a bit of a warning that it might not quite work as it should. We chose for the second option, since we believe that it's better to at least provide the tools. In that sense, it's also nice that people need / use them, since it indicates that we need to put more effort into improving them so that they can move out of experimental.

Yep! Download the 4.7.0 beta. This is one of the issues that has been significantly improved! It's not entirely incorrect. Some people use this to overfill areas. Going over a 100 is a bit of weird thing to do, hence it turning orange. Also a known issue. I expect us to work on that for the 4.8 release.

Upon connection (so basicly; if you reboot cura, the sync has happend). You don't need cloud connection to sync materials. Anyhow, please provide the full logs from Cura. The entries that you singled out are not the ones that are causing the problem. Furthermore, you can check what materials are installed by checking http://{YOUR PRINTER IP}/api/v1/materials in the browser.

Are the cards locked? Most SD cards have this lock clip to prevent writing.

Yeah, that's about right. The monitor view for USB only has the control panel on the right.

Yeah, mods like that would need to happen in Griffin itself. There is obviously a limit to what you can make modifiable. I think that the automatic leveling can be bypassed by changing some settings in a json file though. As for the MS deprime, if I remember correctly, it is one of the things that is being worked on to change that.

It goes a bit beyond that; You could even add services to the printer that run in their own environment. They can use the internal API's to talk to the rest of the FW. So that should make it a lot more stable, since you won't have to modify anything (you're just adding extra services, so it's a bit more alike a micro service setup). Since you're not modifying any source code, you also don't have to worry about any copyright issues. The only downside to this is that when you update your firmware, these extra services will be removed (so you would need to re-install them again). It's not really difficult to create a script that does this automatically. As I (briefly) mentioned before, there have been people that added a cloud client to ultimakers in this way (so basicly; a small program that pretty much does the same as the cloud client that we provide, but it uses a different format and a different end-point).

I assume you're not using an Ultimaker. The materials on the marketplace are only designed to work with that.

Neotko is just a guy with an axe to grind. I don't know why he's so mad, but he's flat out wrong. He also has little to no experience with software design (or common practices), so I hink his observations should be taken with a large grain of salt. There is a fairly easy way to change the firmware. It's not as easy as making a complete new build, but that is it. There is an easy way to force certain g-code and the heating sequence can be changed, since the internals use D-bus, which you can expose to be accessible over the network. The source code is available, because it's python. It's on every machine we ship.

Open can mean a lot of things. Same as closed. It's a scale really. But why the complains about some things not being as open as they could possibly be? You can change the software that's running on the machine. Hell, there are even other parties that allow you to install different SW on the printer to connect to their cloud service. Just because it's open, doesn't mean that we have to provide you with a consultant that holds your hand while doing it. We could do it, but it would mean that the product becomes even more expensive, since someone will have to pay for that. But all engineering is about making choices. It has jack shit to do with "taking away 'muh freedoms". But if you want something to be more open (and that it works), it means that you have to spend a lot of time on it. So, ask yourself, what do you think is more important? So we chose the middle ground here; Whenever it doesn't take an insane amount of work, we keep things open or we put them behind a bit of a config, so it's possible, but not every single user will change them (since more changes == more support requests that are harder to debug). There is indeed a certificate on the build. It's there because of common and sensible security measures. It's not there to prevent anyone that has physical access to the machine from changing anything.

I think it's the other way around; I've been spending quite a bit of time to speed Cura up (it's even to the point that I'm getting a bit of a reputation in the team for finding bottlenecks) The bed deforms a bit once it's hot. Since it doesn't deform exactly the same every time, the bed leveling needs to be done every time. It has little to do with trust. The UM3 doesn't have that problem, since the bed is a lot smaller. Could that problem have been fixed in another way? Yeah, probably. Almost every problem can be fixed in multiple ways, but not all of them are economical / feasible.

It's a feature that was sent to the shadow realm. The implementation wasn't all that good (so it was costing us quite a bit of effort to keep it up to date). We only got a few remarks about it actually being used, so it was disabled a few releases ago. You're the first to actually say anything about it.

Without log files, I can't say what could be causing this.

During the loading plugins phase of cura, it's loading the plugins as if they are python modules. It could theoretically be possible to find a way to re-load such a module based on changes, but that would complicate the flow (since we can now make the assumption that plugin loading only happens during a single moment of the program). What you can do is use the livescripting plugin. That plugin provides a way to execute python code inside the python instance used by Cura. You can find it here: https://github.com/Ultimaker/CuraLiveScriptingPlugin/

What visibility preset do you have active?

You could increase the number of walls or go for the more labour intensive option of using modifier meshes.

The slicing is never done on the GPU. Parts of the rendering are done in the GPU, but certain things (such as sending the right information to the GPU) must be handled by the CPU.

It's merged to master, so it's in the 4.8 release.

Just because it's built in doesn't mean that it has an actual quality profile. There are mutliple "levels" of profiles. A number of machines have quality profiles per material. So if you select "normal" quality for PLA you get a different quality than with normal ABS. If it doesn't have those profiles, it only has the basic material settings. The profile you created yourself probably has the type PLA, so it's using the PLA qualities.

It's because Cura doesn't have a quality profile for PLA+. The warning that you get is that it's not using material specific quality settings (as it normally does), but using defaults (which may or may not what you expect). If the material is a lot like PLA, you could change the material type to be PLA (instead of PLA+). It will use the quality settings of PLA instead (and stop showing the orange warning)