Claghorn

Here's what I've started doing when I want to make a new profile: 1. Go into Configure>Profiles and copy an existing one 2. Go back to "prepare" screen, select that profile, and scroll through it changing things. 3. Now go back to the Configure>Profiles screen and select this profile 4. That gives me a dialog which has a button I can click to save all my changes. This works, but it seems like there ought to be a single place I can both edit and save a profile. Is there? Or is my technique the best I can do?

I've read all the objections in github report 2779, and I have a new proposal that should solve every objection: The rotation dialog box could have a single field for specifying an angle and a pull down for specifying X, Y, or Z (probably should default to Z since I suspect that's most common). Now you can type in an angle and it is absolutely unambiguous what order to apply the rotations since you have to rotate a single axis at a time.

DOH! That was it. I never noticed that button, but apparently got a different default in the two different versions. If I turn it on, the image shows up in the solidoodle connection now. Thanks. The discovery versus manual thing was quite puzzling. I think it did discovery the first time I installed the plugin, but then when I started cura again later, the connection was gone and discovery wouldn't find anything on a refresh, so I manually connected and that has been working ever since.

After looking at the haproxy.cfg file on the pi, I discovered that this url does allow a browser on the remote system to see the webcam on the pi: http://solidoodle.my.lan/webcam/?action=stream Where solidoodle.my.lan is the address of the pi on my local lan.

After some experimentation, I'm pretty sure the pi is setup by default so mjpg-streamer is only talking to localhost, so a remote cura can't get the stream, but I'm attaching the cura.log file here in case it is useful. cura.log

Just curiosity here. I have one instance of octoprint running on a raspberry pi, and when I use cura (4.12.1 appimage) connect to it, the pi camera image doesn't show up in the cura monitor tab. I have another octoprint instance running on an ubuntu 20.4 x86_64 system with a USB webcam, and the same version of cura shows the camera in the monitor tab. The octoprint web interface shows the camera image just fine for both. Just curious if there is some magic I need to do on the raspberry pi to make the camera image show in cura? (not that it is really important since I can use the web interface if I really want to watch the print in progress).

Yep, that works perfectly. Thanks.

I have an x86_64 system where I have installed octoprint. A printer with a smoothieboard is on a USB connection at /dev/ttyACM0. Octoprint works perfectly by itself. I have also downloaded the cura appimage (1.12.1) and with octoprint stopped and octoprint plugin removed, it also works perfectly by itself. If I install the octoprint plugin in cura, I can connect to octoprint, but apparently cura and octoprint are still fighting over control of /dev/ttyACM0. I can try to move the print head via manual control and nothing will happen for several seconds, then it (sometimes) suddenly moves. Octoprint gives errors about communication problems with the usb device. Is there some hidden setting I can use in cura to make it never try to talk to /dev/ttyACM0? It shouldn't need to if it is talking to octoprint.

Maybe I should make this a feature request then. I know cura knows how tall the model is, so if it had a separate setting for "park position" where I could set X,Y, and Z locations I want it to move to at the end of the print, then it would be possible to put something like this in my end code: G0 Z{max_of_model_height_and_Z_park} I want this to move the bed to a convenient position for removing the flexible build plate after the print is done.

I'd like to move the Z level at the end of a print to something like 50mm, but if I just printed something higher than that, I don't want a "G0 Z50" in the end script to jam the tall print back into the extruder :-). Is there any kind of cura magic like S{max_model_height_or_z_park} or gcode magic in marlin to achieve this?

OK, I have no idea what changed, but after fooling with this a lot, my prints are coming out perfect now. Maybe it was just bed level as my big problem.

I'm trying to get cura dialed in on my old (but newly upgraded) solidoodle. If I print this single wall one bottom layer test cube I use a lot, in RepetierHost with slicr3 it comes out just about perfect. Copying lots of settings from slicr3 to cura, the same print in cura comes out perfect everywhere except one corner (where the bottom layer lines are really short). In that same corner the brim (which works fine in all the other corners) looks like the lines pushed up from the bed. Anyone have any idea what settings could be related to this? The compare.jpg has the slicr3 version on the left and the cura version on the right. The corner.jpg shows the bottom corner where things pushed up. In case it matters, that corner is the corner where it initially started printing the bottom layer (it was front right on the build plate), the Z seam was the back right corner.

Maybe the pull down was to tiny for me to hit the right spot :-). Nope. I see what it is - if I'm looking in "select settings" after selecting an stl in the preview it isn't there. Up in global print settings it is there (which makes sense now I think about it, you probably wouldn't want a separate skirt on each part).

Lots of (old) documentation for cura tells me the "skirt" setting is found under bed adhesion, yet when I make every possible setting visible, there is no skirt there in 4.10. Has it been removed since you can now turn the brim into a skirt by adding an offset?

My ancient and much modified solidoodle 2 homes X and Y to X max and Y max, not 0,0. X max also puts the print nozzle 8mm off the right side of the print bed. I was interested in giving cura a try, but how the devil do I communicate this bed geometry to cura in a custom printer definition? My poor brain can't see any way to tell it something like this. Update: Maybe my brain is better now. In RepetierHost, the manual controls try to inform me where the tip of the nozzle is at all times, so it needs to know the same things Marlin knows to be able to tell me. I think I finally understand that cura makes no attempt to do that, so as long as Marlin moves where cura tells it to go, all is well. I guess only Marlin needs to know where home leaves the nozzle.