johnse

Most of the flexible filaments are not very grippy. They will compress and bend, but the surface is fairly low friction. Flexion XC-60 (Shore 60A) is more like rubber in that respect. You need a really good direct extruder with a completely constrained filament path. Flexion claims their extruder is the only one that can print it. I modified a Monoprice Ultimate (Wanhau D6) to use their extruder. Unfortunately, their partner in making the filament changed hands and is no longer making it. Flexion is working to line up another source. I luckily found a spool from a store in Canada.

I had a similar issue with MatterHackers PLA. The spool is a little to thick to place in the spool holder/guide for material 1 (the one furthest from the printer body. As such I couldn’t use the guide. It seemed to be feeding OK but during the print, the MH filament slipped over the rim and was being pulled between the coils of the breakaway support material in the inner (#2) position. This caused it to bind in the counter-rotating spool of material 2. I have found that when printing without support, I can use the wide spool in position 2 just fine. I have successfully printed with support material in position 1 using the holder/guide.

Three possibilities to try: Try adjusting either the thickness of the wall to be an exact multiple of the line width, plus a very small amount. Example of a 0.4 line width, make it 1.21mm or 1.61mm (3 or 4 width). Adjust the line width slightly smaller so that a 3x or 4x the width is 1.49 mm. search the forum for @burtoogle custom build of Cura that has a different fill method for thin walls BTW, I don’t think the infill settings (you mention 30%) come into play during wall fill. One other possibility that may or may not work for you. I was printing an open container with walls exactly 1.6 mm (4x line size) that were almost vertical (slight outward draft angle) also modeled in Fusion 360. It would print 4 wall lines but then on certain layers, and only in certain spots, it would do as you describe. I followed advice from someone here (I don’t remember exactly whom) and exported it as a solid model. I then set infill to zero, zero top layers, and 4 walls. This made cura print it as 1 skin wall plus 3 interior walls. The zero infill made it hollow, and the zero top layers made it open on top.

You could print a layer or two of PVA (water soluble) or Breakaway between the pieces. They're not "non-stick" but breakaway has lower layer adhesion and PVA will dissolve.

I am right there with you...

Hey, @burtoogle. I know you have stopped being able to make Mac builds because of your lack of a modern Mac... A possible route for you would be to use Azure DevOps to build it. (Disclaimer, I work for Microsoft and have used DevOps—formerly Visual Studio Team Services—quite a bit in my work, but do not work in that part of the company.) The free tier of service includes up to 1800 minutes per month of build services in their CI/CD pipeline and they have cloud-hosted OSX machines to build Mac stuff. And you can point the build systems at your GitHub repo. It can be set to auto-build triggered on a commit to one or more branches, or you can just kick off a build at your convenience. if you want any more info, feel free to ask.

I used Google Translator to read the above-linked thread. It appears you can use the start/end gcode provided in the initial reply by @Guillaume777

You could make a similar argument that since Cura can slice the model, there’s no reason the printer could not do so. Some printer controllers such as octoprint can so this. Cura does not get the density from the printer. It gets that from its own list of materials—to which you can add. It communicates with the printer using GCode, which does not have a way of communicating density. Cura could add a comment that could communicate this, but as was mentioned above, that would require a firmware change, and it would only work for things sliced in Cura.

If I am not mistaken, the printer has no need to know the density of filament. It can easily show the length by finding the last extruder move command in the gcode. To display weight, it would need to know the weight per meter. You could calculate this factor for each of your materials, then simply multiply the stated length by that factor when starting a print.

Are you putting the spools on one at a time? I.e. do these steps: tell um3 load material 2 put PVA on holder, press confirm that spool has been placed wait for detect. finish load process for material 2 tell um3 to load material 1 put PLA on holder, press confirm that spool has been placed wait for detect. finish load process. at both steps 3 and 7 the display should initially say “no material detected” and then a few seconds later will identify the new spool.

I loaded this in Cura and it is huge. Then I loaded it in Fusion 360 and it seems like it is about 37 meters from top-to-top, and about 8 meters across each of the narrow sections. The slide pieces are about 21 mm thick. To shrink 37 meters to a 200mm wide build plate, that is 1/185th scale. That is also going to scale the thickness of the sheets making them about 0.12 mm thick. This is too thin to print. I would suggest pre-scaling it in whatever modelling tool you are using, so that it will fit in the build volume. Then adjust the thicknesses so that they are at least 1mm at that overall smaller scale (and that's assuming you've got a 0.4mm nozzle.

Can you post the project file that did this strange printing? And can you post the Fusion 360 design? In Fusion, did you have 3 bodies in a single component (or the root component, or three separate components? If the latter, did you make sure the origins were aligned?

From some quick Googling, it appears that Linux uses Mesa. It appears Mesa will use hardware rendering where it can, but also falls back to software rendering for things not supported by hardware. So no troubleshooting to do here. The Linux OpenGL 4.1 support on HD 4000 is not an existence proof of 4.1 features on this GPU.

I ran into this tonight. Cura shows the icon briefly, and is running in the background, but the loading window never opens, and there is no log file (there was a large log file from many prior runs, but nothing from this run attempt. I renamed that logfile and tried again. No new logfile. I am running on a Surface Book v2. This has a detachable screen. When connected to the keyboard, it uses the Nvidia GTX 1060 housed in the keyboard. When detached, it uses the GPU integrated in the Core i7. The detachable mechanism is great, but sometimes it seems to lose connection to the Nvidia GPU. I looked in device manager and indeed the Nvidia was not shown. I detached and reattached the screen, confirmed both GPUs were shown, and launched Cura as normal.

Was this labeled correctly? The one on the left looks a lot better than the one on the right. (Just realized this was a necro'd thread... sorry to add to it).

As an explanation, if you are using 0.1 as a layer height, there are only 10 layers different from one side to the other. Thus, you will have 10 “stairs” along that distance. going down to 0.06 layer height would make about 16 steps.

As a developer with almost 40 years experience, I’m not a fan of “web tech” for applications. (Nor am I a fan of Python...) JavaScript is a language that throws away several decades of industry learning about how to build robust software. Typescript fixes that to a small degree, but you still often have to break type safety to achieve your goals. If one were going to rewrite, it would be better done using something like Xamarin...C# is an excellent, performative language with a lot of community support. It has Microsoft behind it who is doing a ton of cross platform and open source work these days. (Disclaimer, I work at Microsoft but not on these systems—my words are mine and I do not speak for the company.) and Xamarin appears to have support for Metal.

I don’t recall which version of Cura it was, or if it still happens (my main machine is a UM3 now) but it seemed like my Monoprice Ultimate was doing nothing at the start. But it was heating the bed...but wasn’t displaying the changing temperature. I don’t know if the printer wasn’t reporting the temp changes, or Cura wasn’t displaying it. check to see if your bed is heating...

The software is not backward, it is that it does not match your expectations. As I understand it, the purpose of combing is to avoid using retractions when moving within a part by making sure any plastic extruded will fall on sections of that layer that have not yet been printed. It does that by staying within bounds of the part and not crossing anything that has been printed on that layer. Reducing retraction is important because too many retractions in a short time will tend to grind down the filament. What @burtoogle pointed out is that if you don’t want those extra thin lines to show on the finished surface you can set it to not comb on the skin (top/bottom) layers where it will be visible on the finished part.

The point I was attempting to make is that the flow rate (volume of material per distance travelled) is independent of nozzle shape. Circle, square, ant convex polygon. The key to accurate computation of the volume extruded is to accurately model the shape of the sausage, I used ideal shapes above for the thought experiment. Furthermore a square would be a poor choice for a nozzle because the minimum line width would be different depending on the motion vector. As for the area of the nozzles being different, that only affects the velocity of the plastic going through the nozzle. Imagine a 0.1 nozzle with the same external geometry (flat nozzle surface 1mm wide). If you extrude the same volume of plastic through it as the 0.4 nozzle, it will produce the same line width. But for the same head speed, the velocity of the plastic through the nozzle would be 16x faster. The extruded sausage would be the same shape because the formation it is dependent upon the shape of the bed (or prior layers), the bottom of the nozzle, and the surface tension of the plastic that constrains the sides.

@MDA The UM3 moves print core 2 up and down by a certain amount...up to get it out of the way when #1 is printing, down to get it an equal distance below #1 so #1 is out of the way when #2 is printing. Therefore, the nozzle of PC #1 needs to be roughly in the center of that travel range of PC #2. As I understand it, the 3D Solex cores have replaceable nozzles. I've not taken apart any print cores, but in some other hot ends, the tube entering the top of the heater block and the nozzle share the same threaded hole and, when tightened, but up against each other. It is possible that the top tube is threaded in either too much or too little, causing the nozzle to be at the wrong distance from the heater block. That would put the nozzle outside of that center range the UM3 is looking for. Tagging @gr5 here as he may be able to help you more since he sells the 3D Solex cores here in the US.

I think @yellowshark is confusing the plastic delivery system (the nozzle opening) to the plastic forming system. This is what @geert_2 was trying to get at with his drawing. Nozzles are not all shaped the same, but most 0.4 mm nozzles have a flat surface that is 2-3x the diameter of the hole. For the sake of this conversation, let's call it a 1 mm diameter surface with the 0.4 mm hole in the middle. Let's also assume a 0.1 mm layer height. Assume for a moment that the head is not moving, and that we can exactly push specific amounts out the nozzle (The 3D printing equivalent of the physicist's, "assume a spherical cow"). The extruder pushes exactly 0.1 mm of plastic from the nozzle. You now have a cylinder of plastic, 0.1 mm tall x 0.4 mm diameter, or .0126 mm³. This geometry is completely defined by the nozzle shape. Also assume a square nozzle doing the same thing: you have a square 0.4mm on a side--again defined by the nozzle shape. Still without moving the head, push more plastic out the nozzle. The plastic will expand within the space defined between the print bed and the bottom of the nozzle. By the time the circular nozzle has filled the 0.1 x 1 mm disc under the nozzle, you will have pushed out 0.0785 mm³ of plastic and it will still be a circular shape. Is this because of the circular nozzle? Let's see. With the square-holed nozzle, as you continue pushing plastic out, there are no straight vertical sides to constrain the shape. As the edges are pushed out, the pressure will be higher on the middles of the walls than on the corners. Thus you will see the sides start to curve and trend toward a cylinder. Therefore the shape of the extruded splotch of plastic is not going to stay the shape of the nozzle. The circular patch is a special case where it does. Now repeat the thought experiment with the head in motion. Once the initial 0.1 x 0.4 mm cylinder has been extruded, the head starts moving at some speed v, for some time t. We don't want to expand the width of the already-deposited filament, so the moves look like this: The amount of material needed to fill the new space is exactly 0.1 x 0.4 x vt (assuming vertical sides of the printed area). It does not matter whether the nozzle opening is a circle or a square. The nozzle shape only determines whether the end of the line is rounded or squared. The area of the openings is different, so the speed of material flowing through the nozzle is slightly different, but the amount of plastic is the same.

My experience is the same as with @Smithy, but it probably depends on what material is selected for printing the brim or skirt.

Also, make sure you don’t have any post-processing gcode scripts running, like are used for temperature towers. These hang around in Cura until cleared.

From my experience, that section of support in the V is caused by horizontal expansion of the support on the outsides. As I understand it, the expansion is useful to prevent the interface (top) layers, or more importantly the bottom layers being supported, from falling off the edge. It seems that this expansion is not aware of being completely separated from the rest of the support when there is a feature needing support on one side of a wall and nothing on the other side. It seems CuraEngine expands the footprint and never looks back. It might be possible to mark expanded support as tentative until it connects with something actually providing support. Probably would need a second pass after all layers have been sliced.