Jump to content

jflund

Dormant
  • Posts

    7
  • Joined

  • Last visited

Personal Information

  • Country
    US
  • Industry
    Medicine
    Engineering

jflund's Achievements

0

Reputation

  1. I keep anticipating each new version of Cura hoping that the navigation issues will be resolved (panning, rotating, zooming). Perhaps the problems only occur on the Mac, maybe just on Retina Macs, I don't know, otherwise I don't know why more people don't complain about it. They do only occur when "Zoom toward mouse direction" is checked. I have a MacBook Pro 15" with Retina display. The latest version (4.x and beyond) have made things worse by adding a new bug (#1 below). Here are the problems I see (again, they only occur when "Zoom toward mouse direction" is checked): 1) Zooming doesn't zoom toward mouse direction!!! This seems to be a new bug introduced in one of the latest versions of Cura. It appears to zoom toward a position EXACTLY TWICE the coordinates of the mouse. I have to place the cursor in the left lower corner of the screen to get it to zoom toward the center of the screen. This is a new problem as of Version 4.x, This has to be a bug. Could it have something to do with a Mac's Retina screen where coordinates are halved compared to actual pixels? It seems to zoom to a point exactly 2x the current mouse position. 2) With "Zoom toward mouse direction" checked, orbiting (rotating) occurs about a point a fixed distance from the viewport (camera position). This is wrong! This has the effect of making orbiting useless when the camera is at any position other than one of the default positions. Doing so INSTANTLY ROTATES EVERYTHING OFFSCREEN. The further away from the default positions the worse the effect is. This is wrong, it is not a design or personal preference. If you feel it is, you aren't understanding the problem. This cannot be the intended effect (I can not see how this could possible be a feature and not a bug). I have written may 3D user interfaces, the key is that orbiting should occur about the point the person is looking at! The mouse cursor should be used to determine where that is. This is how every 3D modeling app works. If the cursor is pointing at a part of the model, orbiting should occur about the point on the model where the mouse is. If not pointing at the model, orbiting should occur about a point halfway between the closest and farthest area of interest (in Cura's case, halfway between the front and back of the build plate (as being seen by, or from the perspective of, the user's current viewport) at the y location of the mouse. If the camera is over the build plate, orbiting should occur halfway between the camera position and the back of the build plate. A fudge factor can be ue d to prevent orbiting too close to the camera or behind the camera. This provides for a very intuitive user experience. But what exists currently is completely useless when using Zoom toward mouse direction is checked and the camera is not in the default position. I hope someone from Ultimaker will finally listen to this frustration instead of brushing it off as a design preference. It makes it impossible to examine in detail and assess the effects different parameters have on slicing.This is a very important aspect of a slicer, and is handled much better by other slicers. Cura is too good otherwise to switch to one of the other slicers that allow better inspection of the sliced models. So please fix this so I don't have to use those slicers. Sincerely, John F. Lund
  2. Unfortunately there is no Compatibility Mode (that I am aware of) on the Mac. But I uninstalled and reinstalled it and it hasn't happened again since .Here's hoping it never will..
  3. I'm having a similar problem on a Mac ever since installing Cura 4.0. Cura 3.6 crashes before the user interface shows onscreen, and Cura 4.0 simply won't print. It states that the model I am printing exceeds the print volume even thought it slices fine and clearly fits within all build volume constraints. In addition, Cura 4 will not locate my Ultimaker 3 on the network. Cura 3.6 found it just fine, but Cura 4 can't. I can add it manually (by entering the IP address of the printer, it isn't located automatically.I don't know this is why I get the build volume error above. I've had nothing but trouble since installing Cura 4. I have uninstalled and reinstalled it and still it's no better. It really seems Cura 4 was not adequately tested before it was released, very uncharacteristic of Ultimaker...
  4. I've found a much bigger problem with the Settings pane. On a Mac, I tried to move the bottom edge of the pane downward, and it jumped to the top. Now, when I try to drag it down, it goes up. And when I try to scroll it up, it goes down. And the largest I can expand it is so such that it shows about 2 settings! It is now impossible to use! The attached ZIP file has a video that shows the behavior. Cura 4 Bug.zip
  5. I use SketchUp for modeling most of the objects I print, but on annoying "feature" with SketchUp is that it moves, merges, and even throws out vertices, edges, and faces that are extremely small or close together. The generally accepted workaround to this is to design objects at a scale 10, 100, or even 1000 times larger than needed and then scale back down in order to export the STL file for printing. However, this is a real pain. If you forget to scale the model down, Cura scales it down to fit the build plate, but you may not notice that is what happened if your model nearly fills the build plate. And even when you do remember, its annoying to have to keep scaling up and down. Even worse is to model objects at their actual size because then you often end up with problems that can take hours to repair. I would suggest a cleaner workaround. Could Cura be modified to allow a scale factor to be specified when an object is extremely large? That way, if I usually model at 100x, I could specify a scale factor of 0.01 for extremely large objects and Cura would do the scaling-down automatically for me when I load the model. The current functionality of scaling to fit the build plate could continue to be used if the model is still too large after applying the specified scale factor. This way, only the second scaling operation (i.e. the "scale-to-fit" operation) would need to generate a warning, and the first scale would seamlessly connect SketchUp with Cura, no warning necessary. So in summary: Can a new preference be added to the General section and the existing scaling preference be changed as follows: [x] Initially scale extremely large objects by ___0.01___ to attempt to make them fit the build plate [x] Scale models that are still too large so that they fit the build plate where the "0.01" value can be modified by the user (and saved as a preference)? Just a thought, but why not make life simpler whenever possible?
  6. I upgraded my printer with the 2+ upgrade from Ultimaker and updated the firmware as recommended. However, I can now no longer save modifications to materials. When I change the printhead temperatures and save the material as a custom material, the new material doesn't exist. When I save the Materials to a text file, modify the text file, and load the new file back into the Ultimaker, the changes I made in the file are not loaded. I have done this many times in the past, so I doubt I'm creating an error in the file or anything. Even just changing the name and loading the file doesn't work. I'd appreciate anyone's help with this.
  7. I just got my Ultimaker 2 and it initially worked great. I printed 5 or 6 item without problems. I then upgraded the printer firmware and since the retraction seems to be working incorrectly. When I print something with several different high areas separated by low areas (the latest is printing the ribs on a T-Rex skeleton with the ribs pointing up. I get massive stringing between the ribs, so much that they are essentially one solid part. I have determined that the problem seems to be that when one rib is printed and the head is ready to move to the adjacent rib, the Ultimaker 2 pauses the print head, performs the retraction, but then advances the filament forward BEFORE moving to the next rib. Because of this, it essentially prints the space between parts. It seems this has to be a bug. Is there utility in retracting AND advancing before a move? I have tried with combing enabled and disabled and the same think happens. Even stranger, it appears that when the print gets to the top-most layers where each layer is small, the extruder retracts and advances the filament repeatedly while it waits for the minLayerTime to expire. This has flattened the filament several times causing failure to extrude (just before the print finishes of course). I have tried using the default combing/retraction settings, and I have lengthened "Minimum travel" and "Minimal extrusion before retracting", and both enabling and disabling "Combing", but none of those settings seem to have any effect. Any ideas how I can stop this behavior of both retraction AND advancing BEFORE moves?
×
×
  • Create New...