-
Posts
195 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by Marco_TvM
-
-
43 minutes ago, kmanstudios said:
I still want the dilithium crystal matrix for off grid power operations
With an integrated Scotty AI?
-
Thanks a lot for the logs @Polarice ... I've seen something strange happening in your case that warrants further investigation!
For those who want to see for themselves (and maybe have similar messages): see boot-5.log...
Edited:
Can you do the following:
1. Reboot the printer
2. Then upgrade the firmware?
It looks like your /tmp (tmpfs) is full which causes problems. Rebooting the printer clears it completely.
-
Thanks a lot for the logs @Polarice ... I've seen something strange happening in your case that warrants further investigation!
For those who want to see for themselves (and maybe have similar messages): see boot-5.log...
-
Hello Kees (sounds Dutch?),
The problem here I think is that when you keep only doing the step one as you describe (rotating the wheel) to move the bed and then loosening up the screws all the time, you will end up with all screws indeed being unscrewed. Or at least, that might happen.
May I suggest the following.
- Only do manual leveling when it's really necessary. Try to rely on the automatic procedure after doing it (maybe once a month or so).
- Before doing the manual leveling... tighten the screws completely so the springs are really compressed. This goes for all 3 of them (2 front left and right and the one in the middle at the back)
- Then loosen up all screws like a complete 1/2 or 1 full rotation
- Perform the normal manual leveling as described in https://ultimaker.com/en/resources/23127-build-plate-leveling
Hope this helps you with doing the manual leveling.
-
The material profiles are not stored on the eeprom of the Print Core.
The new profiles come from Cura, the default ones are stored on the printer.
@gr5 also made some script to create profiles for print cores, see
A Print Core is being identified by a number of fields stored within it's eeprom for the type, manufacturer, nozzle size and a few more.
The format of this has not been specified, as far as I'm aware of, but maybe @SandervG can shed some more light on this?
You can also look at
where @gr5 seems to be 'hacking' a bit to program cores. This might help you with your own third party print cores, but use it at your own responsibility.
For the time being, I think it's the responsibility of the third party print core builder to have the eeprom programmed correctly.
-
I think you need to contact the third party supplier. The Print Cores have to be programmed with a nozzle size, in your case 0.4.
If they are Print Cores without an EEPROM, they can not be identified by the printer.
For now, there are no plans to make this something configurable on the printer, as in selecting a custom printcore with settings.
I'm not sure, but I think Cura would allow to override this?
-
The printer cannot distinguish between Generic and color generic... because the menu structure to make that would be quite cumbersome to work with...
Hence PC (Generic) and only NFC detected PC (White/other_colors).
Because that doesn't match with Cura's selected profiles for slicing, you have to agree to override.
I think this is a question for Cura and not the firmware section.
So maybe @Msuurmond is able to answer this.
- 1
-
Maybe I'm missing something, but these do not seem like the normal log files to me.
How did you make/get them?
-
On 2/3/2018 at 11:36 PM, Indy31 said:
The bug for the printer restarting the last print job was just fixed this week and will be in the next firmware release (can take a few months).
This may be there in the next testing release, with luck, at the end of the week.
- 1
-
Thanks, checking ...
- 1
-
25 minutes ago, Bossler said:
Which would not help during a print already running, right?
No it would not. I do see your point, but fixing this is not yet on our board of things to do soon(tm).
-
Ok, some more info.
Not entirely by design, but because of Marlin...
Marlin only supports one speed for flow speed for all possible extruders. There is an issue on the backlog to fix this, but it's not a priority right now.
-
This is by design, so not a bug.
I think @Daid might shed some light as to why.
If you want to use different speeds tho, you can use the settings in Cura to make it so.
-
What happens when you try to download the new stable firmware?
It would be good to see the messages on the screen and preferably have the log.
Even after it seems to be stuck, using the System -> Maintenance -> Diagnostics -> Dump logs to USB might give some insights in what might be going wrong.
-
20 hours ago, macio said:
The printer is currently in use. Maybe I can download the logs tomorrow.
That is fine, no rush.
-
@cjs : I think @Indy31 summed it up quite nicely.
Custom materials should stay on the printer after a firmware update. However, a factory reset will remove them.
As for the latter, about submitting material profiles to be shipped with the firmware, the firmware only uses the fdm_materials repo. Cura is more in control because they use the profile to create better gcode.
Hence, I'll put this request forward to the Cura PO.
-
Check the connection with System -> Network -> Connection status.
This will provide the information to check whether or not the printer has gotten a valid IP address, how it's connected and it's associated MAC address.
-
1 hour ago, macio said:
Hi,
just found another bug that I would like to share with you.
Reproduction steps with Ultimaker 3 Extended connected via WIFI):
- Start print via Cura over Network
- While printing, pause print via Cura
- Abort print via Cura
- Clear build plate and select "NO" retry on printer panel
- Start another print via Cura over Network
Problem:
The printer makes a way too big prime blob that will cover the hole nozzle in filmament (about 4 times the size of a normal prime blob).
The extruder will mill into the filmament.Would be great to get a fast fix for this issue. This is the 8th bug that we have seen on our Ultimaker 3 Extended within 3 month in occasionally usage.
It would help to get the logs when this happens, using System -> Maintenance -> Diagnostics -> Dump logs to USB and send them either by using something like WeTransfer or attach them.
That way we can see which firmware is being used (missing in the report) and the state of the printer logic being used.
-
Check out the WEB API to add materials: http://<printer-ip>/docs/api/#/Materials
This will allow you to add material profiles (files) you have created, outside of Cura.
- 1
-
23 hours ago, orkulkarni said:
I hope it provides better print quality and reliability
If you can explain what kinds of problems you're having, there are a lot of people here that might help you with your issues.
- 1
-
10 hours ago, cjs said:
Alexa support for Ultimakers ?
1Food for thought...
But I doubt we'd have the processing power to implement voice recognition.
-
On 1/19/2018 at 2:03 PM, kmanstudios said:
It is a bit of, 'ya gotta look at more than one thing' to know what is going on. Otherwise, put on a text read out and voice synthesizer, with the voice of "Hal9000" just to goose the nerves a bit.
Taking out the core, "I'm sorry Dave, I cannot let you do that...."
1I'm so tempted to make this work...
- 1
-
18 hours ago, cjs said:
May I do a feature request regarding the color of the print cores?
Have been thinking about it for a while and I think it would be awesome to use the led's to make it easier to spot whats going on. Maybe as option to enable.
My idea would look like this:
<snip>
What I don't know is how good the colors can be differentiated.
I will take the idea up with the PO (product owner).
- 1
-
3 minutes ago, cjs said:
I understand that things do take time to be done right. As Ultimaker has had already over a year I just would have hoped that you were further in discussion regarding this topic.
When I know more etc. I will keep things posted here.
- 1
Print artifacts due to controller not keeping up:
in Firmware
Posted
As @WesleyE mentioned, there is a chance of buffer underruns happening when lots of small gcode is being generated.
If this happens, it would be interesting to see the numbers.
For this, you can use the URL HTTP://<printer_ip>/api/v1/debug/marlin/errors which shows you a number of statistics of the serial protocol used by Marlin.
If the planner_buffer_empty increases dramatically, this indeed means a buffer underrun.