maartenw

Thanks, I wrapped a little aluminum foil (household quality) arount the bottom axis of the Z crew, and yes now the axis doesn't have excess room no more. Unfortunately, the axis still wiggles (a bit less), and when the plateau is at the bottom, the wiggle really is too much. Improvement? Yes, a bit. Problem solved? Not yet, I'm afraid.

@Nicolinux, @gr5: thanks a lot for your comments, links and suggestions. This week I didn't have time for 3D actions, today I did some investigation. I took out the Z screw - keeping the rest in place. The Z screw is perfectly straight. -> OK In the plateau, I could manually move the Z nut in foreward and sideward direction. -> OK The aluminum connector which connects the Z motor and the Z screw shows no 'flexibility' on the motor-side, but it has on the Z screw side. This causes the screw to be slightly excentric when tightened by the little screws, and can cause the wiggle I see on the top of the screw. -> NOT OK Unfortunately the small tightening screw are not symmetrically placed, so I have to think about something to have the Z screw centered in this connector. No idea yet... Any suggestions?

@illuminarti: it is an Ultimaker 1 @Dim3nsioneer: I have the same idea. The pitch of the Z-'screw' is 3 mm also. When moving in the z-direction, commanded from the Ultimaker controller, a regular movement is seen and felt. The regular bands or ridges start to irritate me, as the surface should be smooth. It happens with all objects. There seems to be an overextrusion every 3 mm, or the plateau doesn't move regularly.

For all items printed, I find regular irregularities. For a cone and two vertical cylinders, ridges are seen at regular 3 mm interval. These object should have a smooth surface. I made 2 pictures from 3 object, one with light from above http://umforum.ultimaker.com/index.php?/gallery/image/4275-light6088/ the other with low light. http://umforum.ultimaker.com/index.php?/gallery/image/4276-dark6089/ I started printing last october with Cura 13.10, now I am using 14.01 / 14.03. Ridges are present for all prints, and circular. A ridge is wider over the full circle. Any idea how I can prevent these ridges from occuring?

Former 'pling' results for 14.02 were from a 'real' machine. Installed 14.03 on a fresh VM with XPSP3, same 'pling' result. Here, OpenGL 1.1.0 was found. Installed 14.03 on a fresh VM with W7, and layer view was OK. Here, OpenGL 2.1 was found. The stl object was put 'swinging' to the platform, The layer view was 'building' up from the top, and I could watch the layers at all heights. So is the problem caused by different OpenGL or by Windows version?

I see that 14.03 is released on 17 march. So it is not a RC anymore. It was not clear whether for XP a separate version was available, and the 14.03 version and the 14.03-for-XP had the same size. Anyway, the version indicated as 'for XP' was downloaded and installed. Still the layer view sounds 'pling' and the program does not respond anymore. No message is shown, so this is all I can report.

Even geklikt op het Faceboek linkje. Er wordt gevraagd in te loggen. En ja, dan wordt het voor een bewust niet-faceboek-lid lastig om mee te doen! Andere opties?

Daid, First priority at this moment is to get the new release working - in English. I do agree with Tomasz that not all people are able for whatever reason to use the English language. So when Cura would allow translation and volunteers can do translation, much more people could use and experiment with 3D printers. Changing texts from version-to-version can be seen as a handicap for translation, but (the) volunteers could fast enough create new translation files. And before this is done, the English text could be used. So I would be enthousiast for a setup where translation would be possible! The fact that many people want to use their (nearby) native language is supported in this forum, where a French, German, Italian and 'all other languages' forum exists. Anyway, keep up the good work you're doing for Cura :-P !

It is for the Ultimaker original. After installing RC1..7 I only changed the setting for Support Type to Touching buildplate. No other setting was changed for these tests. Also for Support Type = None the result is the same...

Daid, I do appreciate your effort! But unfortunately in this RC7 still the result is the same. I did some more tests: 1. Loading the Ultimaker robot (loaded at first startup: layer view -> pling. Output.txt empty, not responding. 2. Loading the Panton Chair egg holder: - Loading OK - Transparant OK - X-Ray OK - Layer view: pling, not responding, Output.txt contains part of gcode. 3. Loading the egg chair, save gcode: the code for RC7 is bigger (23.764 compared to earlier RC's 16.450) 4. Using 14.01 I loaded gcodes from 14.01, RC's 6 and 7: all shown. 5. Using RC7 loaded gcode from 14.01: pling, output.txt empty, not responding. 6. Using RC7 loaded gcode from RC7: pling, output.txt empty, not responding. After pling, all times the processor was used by python for 99% for about 1`minute. During and after this time Cura was not responding. (pling is the translation of the short sound being heard). Good luck in finding the program bug!

Was it on monday half o'clock (included in RC6), or on monday 24.30 (to be released in RC7)? Anyway, I also tried on a fresh VM-XP machine. At first start, the Ultimaker robot was seen almost transparant, and layer view was shown, starting from the top (!). All further tries were unsuccessfull: the object (robot or egg chair) shown (normal view) correctly, at layer view 'pling', and nothing else than a processor being busy for about 60 sec, but program not responding. Also after uninstall and install again, no success. Even 14.01 showed the layer view error after this (before it was ok). Just to inform you and maybe given a clue... (time is something one cannot have in hands, so it slips all the time :-P ).

I tested with - firewall interactive: same behaviour, no interactions from firewall - firewall allow all: same behaviour - all protection off: same behaviour. Sad, but no correct guess. What other cause (change) could prevent the program from further responding? Btw: the newest RC is named 14.03 RC-6! Slip of the keyboard :wink: ?

I have AVG running as firewall/virusscanner. Versions 13.06, 13.10, 13.11.2 and 14.01 did not have this problem, so I do not expect this to be the cause / problem.

Daid, complements for your great effort! Unfortunately, the result is the same as for posts #60 and #113. The gcode-files show lots of changes in (F-)X-Y-E-line for the last digits for E. The output.txt file shows lots of information, mostly parts of gcode. But, layer-view is still a problem!

I did not have the time to test RC4, but now I uninstalled RC3 and installed RC5. Unfortunately when asking for layer view I get the same result as in post #60. The file output.txt is completely empty now. The resulting gcode shows the 3 added empty lines from the start code, and an extra line indicating the extruder starts at Z0.30.The other lines are the same. Diad, good luck in finding the cause for this bug!

Uninstalled RC2, downloaded and installed RC3. After 1st start it forced me a bit more to make contact to the printer, but this was not my goal in testing, so I escaped that action. Then loading one of the models tested before in RC2 (and printed in 14.01). Loading was OK. Then clicking on Layer view... 'pling' sound, RC3 not responding, CPU 80% down to 60% use for 1 minute, then down to 0%. python reported (after this minute) 0 % CPU, memory almost stable. No layer formation visible, now I could move another window over the view plane, which was not blanked out, but remained as it was after loading the model. So forced the application to stop (Taak beeindigen). Restart RC3 with the same result. Output.txt shows: Listening for engine communications on 49674 Closing down Listening for engine communications on 49674 Closing down Conclusion: something has changed, but still a bug. Daid, I still appreciate your work! Good luck! Edit: WinMerge shows the .gcode for RC2 and RC3 is identical (except for Sliced at time).

I give the text as displayed in the error window (2 different cases: 1. (Most times) An error has occurred during the 3D view drawing. WindowsError: 'exception: access violation reading 0x00000000' @ wrapper.py:wrapperCall:763 @ latebind.py:__call__:45 @ openglHelpers.py:render:181 @ engineResultView.py:OnDraw:142 @ sceneView.py:OnPaint:1034 @ openglGui.py:_OnGuiPaint:227 2. (Just one model tested, this model was rotated 180 degrees for correct print position.) An error has occurred during the 3D view drawing. NullFunctionError: 'Attempt to call an undefined function glBindBuffer, check for bool(glBindBuffer) before calling' @ baseplatform.py:__call__:340 @ openglHelpers.py:render:193 @ engineResultView.py:OnDraw:142 @ sceneView.py:OnPaint:1034 @ openglGui.py:_OnGuiPaint:227 (OpenSCAD reports I have OpenGL v 1.4.0 - build 4.14.10.4693) When opening a gcode file, the second message pops up, but with 128 on the engineResultView line.

The crash happens with all models I tried. It never happened in 14.01 OS: XP-SP3

Being a requestor for the 'angle' for support, I was enthousiatic to test. The slightly reduced print time and material needed show an indication that the support was made under an angle. But when a layer view was selected, a windowsError was given, and the view window (with the plate and printobject) did not refresh anymore. (Now I would like to give some screenprints showing this problem, but apparently I can only include URL's...) I appreciate the work being done on improving CURA! One other thing surprised me: when opening a 3D model file, it is now possible to open an image (.bmp, .jpeg, etc\). So now it is possible to print something like 3d photo's? Great to experiment with!

Maybe you are interested in: Bezier surfaces: http://williamaadams.wordpress.com/2011/05/26/linear-extrusion-of-bezier-surfaces/ Rounded surfaces: http://williamaadams.wordpress.com/2011/07/01/revolutionary-surfaces-with-openscad/

Thanks for the quick answer. OK, at the end of the file, but in the default code, the partial info is in the start code, and gives eg #P_TIME#, which is something I cannot translate to time ... You mention to import the values, but howto?

in Cura (14.01) the default start.gcode is: ;Sliced at: {day} {date} {time} ;Basic settings: Layer height: {layer_height} Walls: {wall_thickness} Fill: {fill_density} ;Print time: {print_time} ;Filament used: {filament_amount}m {filament_weight}g ;Filament cost: {filament_cost} This results in a start of the generated gcode: ;Generated with Cura_SteamEngine 13.12 M109 T0 S220.000000 T0 ;Sliced at: Mon 10-02-2014 00:50:32 ;Basic settings: Layer height: 0.1 Walls: 0.8 Fill: 30 ;Print time: #P_TIME# ;Filament used: #F_AMNT#m #F_WGHT#g ;Filament cost: #F_COST# Would it be possible to get the correct figures for {print_time}, {filament_amount} and many other settings - also those not shown in the default start.gcode? I would like to include the Basic, Advanced and Expert settings in the gcode file.

Great tool, Tony! It would be nice to have this incorporated into Cura! Just one remark: would it be not too complicated to have the line numbers count from 1..N in stead of 0..N-1? The first layer is layer 1, and the user would not make mistakes. Just a remark... Great compliments in creating this tweak.