robinmdh
-
Posts
326 -
Joined
-
Last visited
-
Days Won
11
Content Type
Forums
Events
3D Prints
Posts posted by robinmdh
-
-
@ftoons and @kc-li
There is the option to turn off the prime blob in the new Cura maybe that can serve as a quick fix?
if you go to preferences->settings then under build plate adhesion you can enable the visibility of the "enable prime blob" option so you can then disable the prime blob in your print setup.
There has been some discussion here at Ultimaker about prime strategy and I had a similar problem with the UM2's prime in the air, the blob seemed to be the simplest fix and he best of both worlds in that it sticks to the bed and there can be some variation in amount of material used during priming.
The best would probably be if we could prime next to the buildplate but that's not an option on the UM2 or 3.
We've had a low priority issue for most of a year to change it to something else since the blob is the exact right size to fit under the Z end switch. But as people seem afraid to change this it is taking a while...
Ideas are always welcome!
Should we go back to priming in the air or print a more complex prime structure?
Disable the whole thing and prime in the brim/skirt etc?
Adding hardware like that is not likely to happen though, we've discussed making cleaning flap out of silicon etc but it's not something that is being worked on.
P.S: Since the prime blob is completely my idea and implementation I do apologize for any problems
-
1
-
-
It's bundled with Cura.
um, NO, Bad Jaime, for the UM2 that is true, for the UM3 it is downloaded from the internet!
Settings -> Maintanance -> Firmware update will download a new firmware version from the internet.
P.S: If you have no direct internet connection you can also use images on a usb drive you'll have to download them separately but they'd be visible in that menu as well so in that case only no download happens.
-
Good stuff! I'd love to see more "developer mode" tricks added to David B's already useful postings that he made right when the UM3 came out.
right, well, not sure if we had the property system implemented by then, but we do now
so with list you can see a bunch of values you can change with the set command for instance you could manually change the GUID of the currently selecte material as if you've clicked select material in the material menu
set material_guid
you can even execute code as the running code:
exec self.startProcedure("PRINT", {"url": "file:///tmp/UM3_someFile.gcode.gz"})
which ties to print a file on your remote machine (you'll have to upload a file first though)
you can even authenticate yourself remotely using this method :Pbut that might be too much power, no?
-
or if you are in the console you can select the hotends and set the "pre_tune_target_temperature"
the console also has code completion in a lot of places, so you can type select and hit tab and get a list
su ultimaker(Cmd) select beep led printer printer printer/head/0/slot/0 camera material printer printer/bed printer printer/head/0/slot/1 interface.http interface/http/auth nfc printer printer/head/0 system (Cmd) select printer printer/head/0/slot/0(Cmd) listangle = 70current_temperature = 27.7filament_size = 2.85flat_size = 0.3hardware_revision = 0hot_zone_size = 21.0hotend_cartridge_id = AA 0.4insert_type = tefloninteraction_required = 0is_enabled = 0is_present = 1is_primed = 1last_material_guid = 506c9f0d-e3aa-4bd4-b2d2-23e2425b1aa9manufacturer_id = Ultimakermaterial_extruded = 41175material_guid = 506c9f0d-e3aa-4bd4-b2d2-23e2425b1aa9material_guid_source = USERmax_exp_temperature = 361max_power = 75max_target_temperature = 350.0maximum_temperature = 350nominal_resistance = 23.0nozzle_size = 0.4pid_Kd = 40.0pid_Ke = 0.0pid_Kff = 0.57pid_Ki = 0.2pid_Ki_max = 100pid_Kp = 9.0pid_Kpcf = 0.06pid_functional_range = 25.0pre_tune_target_temperature = 0.0programming_state = serial_number = 14db96100000target_temperature = 0.0time_spend_hot = 85756tune_offset_temperature = 0.0voltage = 24.0x_offset = 0y_offset = 0z_height = 3.7404787726917803(Cmd) set pre_tune_target_temperature 20 (Cmd) Jun 29 15:43:20 ultimakersystem-ccbdd300003f python3.4[15964]: 2017-06-29 15:43:20,352 INFO heatableHotend Going to enable hotend 0 to 20CJun 29 15:43:20 ultimakersystem-ccbdd300003f python3.4[15964]: 2017-06-29 15:43:20,471 INFO heatableHotend Going to enable hotend 0 to 20Cset pre_tune_target_temperature 30(Cmd) sendgcode M105ok N56 P15 T0:27.7/30.0@0p1e1f0/0 T1:27.7/0.0@0p1e0f0/0 B22.9/0.0@0(Cmd)
(I have journalctl running spitting out those log lines in the background in case you were wondering where those extra lines came from)
-
2
-
-
FYI Cura pushes it's materials to the printer and could in a past version of the firmware overwrite existing material definitions, this can always be solved with a factory reset (or indeed a firmware update).
-
@neotko Maybe we could do that but we've recently created an internal version that is only available here... So I would expect the testing version to become a bit more stable in the future.
As currently we pushed a release to testing when it needed to be installed on multiple machines in the office
-
1
-
-
that might help a little bit.
the hot zone with molten material is somewhere between 21mm and 10mm I think (in an UM3)
so you need to extrude about 10-21 mm in the time it takes to degrade at the working temperature or in mm^3
((1 / 4) * pi * ((3 mm)^2)) * (21 mm) = 148.440253 mm^3
I have no idea how long it takes for PVA to be degraded, but it'd make sense to do this every layer, right?
maybe print minimally and then dump the excess material (if there is any) inside the now hollow prime and wipe tower
-
TL; DR: Yes but it is a bit more complicated.
@ahoeben Yes you can! But remember the PVA material needs to be extruded a certain amount otherwise it degrades and plugs your printcore, causing your print to fail (more often anyway).
Since this is what we started with and moved away from for a reason it's worth noting.
As some portion of the PVA is hot if that volume of PVA stays hot too long the material becomes black and hard it starts becoming yellowish/brown first and then adhesion and extrusion are already worse.
This is why we cool down the unused core while the other core is printing but the current method of generating support does also grantee enough is extruded.
The ideal solution would be to know the "hot" volume of plastic in the printhead and then make sure to extrude that inside some material specific time.
Determined by the time the material is above a certain temperature for that volume of plastic.
-
For whoever else has the same problem...
This error can have 3 causes:
- Broken usb stick. this happens, try printing via network?
- You did not eject the USB drive properly after copying files to it?
- There is a communication error in the serial connection inside the printer and the motion controller(marlin) receives the gcode garbled.
The last one is only really visible since a testing version 3.6.90 but has been possible for ever (never saw it before that version though, mind you I've seen point 1 and 2 happen occasionally before then).
If you have ruled out the top 2 possibilities and you are using 3.6.90 installed please downgrade to a stable release.
-
1
- Broken usb stick. this happens, try printing via network?
-
We have some partial hacked compatibility with microsofts wsprint api for 3d printers, maybe that is being detected.
This is active IN developer mode only!!! this is not meant to be used by anyone but developers at this point and it's only included because we experimented with it.
The upshot is that if you have windows 10 you could discover and use the printer with native (included in windows) tools.
These tools are however way more limited then just using Cura.
I'm thinking of this since it uses a bunch of outdated terminology (imho) and at some point indeed comes across as a plain old 2d printer.
maybe it could work as long as the postscript you send is then actually gcode, I have no clue...
we have certainly not tested this!!!!
-
1
-
-
In your case the printer accelerates instantly* from 0mm/s to the maximum of 11.2 mm/s or decelerates instantly* to 0.
However remember that marlins jerk implementation is not exactly correct and is only applied to/from standstill, if I remember correctly.
Given that cura's time prediction was based on A version of marlin things might have changed on your machine so that might explain it...
Have a look here and compare that to your marlins plan_buffer_line function (in planner.cpp) if you really want to know.
And as I said there are bugs in marlin, both the main marlin and the ultimaker marlin...
*: instantly reach a speed is obviously mechanically and physically impossible but to the software it pretty much is what happens.
-
Clicking are from Z axis.
It is about active leveling ?
It is trying to compensate ?
difficult to tell, I often get a very soft click click click when it is compensating this sounds different. you can put a bit of tape on the axis at the bottom, so you can see it turning(let the tape stick out in one direction and don't put it too high or it will get crushed by the bed coming down)
also note: compensation happens up to 2cm high in your print, not beyond it.
-
ask on a fusion 360 support forum, maybe?
-
No, since acceleration is taken into account and jerk as well actually (part of marlins motion planning is just ran on all the movements to calculate all that so I'd be surprised if jerk was removed from that checked with Tim(bagelorb)), the time estimates are within about 1~5% of error margin (for typical prints) except when heating up or cooling down printcores, as far as we've seen with the UM3.
The thing that's not taken into account is the weird little rounding errors and things that are actually bugs in marlin.
If you use a non marlin printer time estimates might be off more.
Does this information make you happy?
-
all non Ultimaker printers are added by others, if you make a printer definition then you can create a pull request for it and it will be included in Cura in the future if this is all magic to you, have a look on github, here's an example https://github.com/Ultimaker/Cura/pull/1761.
-
hi frejete,
All the read information requests should not be locked down or require authentication.
So a pure information page can be done easily.
Changing things about the printer will require authentication though.
We'll want something like this for ourselves as well but then having some login would still be required, we don't want to make an inherently unsecure machine, like some internet of things machines are these days.
Besides that you can even use the username password prompt you get right now with proper authentication data if you want to... (requires some Linux knowledge or python scripting).
your browser can save it for you even if it is some unreadable string...
-
Thanks for the reply neotko.
It is the Printer, UM3 saying "print finished" when it not even started.
Could I have your log files? you can use the dump logs to USB function(from system->maintenance->diagnostics->dump logs to USB) to get the logs.
I can also be a mistake in the header of the gcode files, in which case the S3D profile messed up as stated by others.
Not having S3D I've never seen it work on the printer and I can only hope they don't just slam a default header on there... (little things like when printing with one extruder, you want to leave out all mention of the other extruder.... )
-
if I change this file, will it be overwritten with a firmware update?
also, if i wanted to reverse the feeder, is that possible?
- Yes it will be overwritten.
- we will probably have a way to override these files that is not overwritten when you update your machine in the future but be patient for that
- you can't reverse the direction from that file AFAIK (maybe we should add that... but for now that is still compiled into marlin)
-
1
-
Hey guys! So just to make sure I understood correctly. To change/turn off the LEDs I add the M142 RxxxGxxxBxxxTx code after the header (not in it).
doesn't matter where you put it, but put it after the header anyway.
M142 is for the case leds. (has no T parameter) and has rgbw parameters (note: lowercase!)
M143 is for the head leds.
There is an API for the case leds that will work in future firmware version 3.5.x
-
We did test with the decay fix
Do you mean the extra EMI generated is picked up by the capacitive sensor, or something else? Mixed decay on the UM2 made such an improvement for Z banding, it would be great to be able to apply the hack on the UM3 as well.
Mostly the movement has changed a bit and the active leveling is very sensitive to that.
but this should be addressed in the future, for sure.
-
due to noise from the XY steppers active leveling also fails when you put the printer on it side >:-) we completely cut power to the XY motors, this introduces a tiny bit of uncertainty in the position when the power is turned back on, this is fixed by homing the head(obviously)
-
Other big changes missed by Daid is maybe the RGBW case LEDs
he did explain how the API to set them isn't working yet :)in one of the previous threads...
We did test with the decay fix, It seems like a straight forward fix but it does impact everything, things like the active leveling for instance.
EDIT: I've been using an ultimaker original since the first one came out and had the luck to be looking for a job at the right time to join in with UM3 development. First post on the new forum btw... (I'm not much of a forum hanger out anyway but I now understand the dislike I heard about)
-
1
-
Is anyone else having issues with the initial knead of material being pulled into the print
in UltiMaker 3D printers
Posted
on the bed flatness, yes talk to your reseller
I think there was a test firmware made to measure buildplate flatness, not sure if that is necessary though.
We have come up with a fix for buildplate flatness in software, but it completely changes the active leveling feature so it'll take a (long) while to prove it is working OK, and get it approved by marketing, check the UX designs, etc.