CarloK
-
Posts
558 -
Joined
-
Last visited
-
Days Won
22
Content Type
Forums
Events
3D Prints
Posts posted by CarloK
-
-
Changing the steps / mm can be done without firmware modifications, but then you have to correct it with every print job.
You can do this in the start code section in your Cura's printer definition:
G92 E<steps/mm>
Disadvantage is that this gcode now only works on your modified printer.
The UM2+ / UM3 feeder wheels do wear down. When tested with composite material, just printing 1 roll of filament was enough to cause extensive wear on the feeder wheel. That's why the abrasive resistant CC-printcore is not supported on the UM3. The S5 feeder wheel was hardened extra.
Perhaps you can get a replacement feeder wheel?
-
A printer rebooting during the build plate heating up is almost certain a power supply problem. During the first phase of heating up, till about 50C, the power supply is stretched to its limits.
Since everything was working smoothly before and now not anymore, what did you change with respect to the power supply block?
Did you perhaps switch the power supply block with that from another printer?
Did the ambient temperature in the room change?
Perhaps the power supply block gets warm because it is now in the sun or next to an active heater?
When nothing was changed and none of the above questions applies, then perhaps you have a power supply block that's at the lower end of the specifications. Contact your reseller if warranty applies.
There is also a software workaround when you are brave enough to change a configuration file on the printer...
- Enable developer mode from the menu
- Open an SSH connection to the printer
- log in as root / ultimaker
- type: vi /usr/share/griffin/griffin/machines/um3.json
- Scroll down to line 102
- Change the maximum power supply wattage from 221 to 200 (first press the 'insert' key to be able to insert new text).
- exit the editor by typing after each other the 4 keys: 'ESC : w q'
- exit the SSH connection by typing: exit
- reboot the printer
-
1
-
-
I have an idea about where the problem comes from. Do you people have set the Active Leveling frequency to 'never'?
Setting it to 'never' means that firmware 5.x will use the manual leveling settings. But when you insert an unknown print core I noticed some people use the Active Leveling to measure this print core.
My hunch is that there is a problem in this combination of Active Leveling and Manual Leveling where both methods use slightly different data.
Until we fix this the workaround would be to either:
- re-level with Manual Leveling
or
- Always use Active Leveling (don't set the frequency to 'never').
-
No, there is no release date planned yet. The camera API problem is fixed but not considered large enough to validate a new release.
The workaround is to use the hard coded camera paths like:
http://x.x.x.x:8080/?action=stream
and for a picture
http://x.x.x.x:8080/?action=snapshot
If you ever add more camera's to the the printer, then the second camera will be at port 8081, the 3rd at port 8082, etc.
There are no plans to change these paths, so hard coding them in your application shouldn't be a reason to wait for a new firmware release.
-
@David Stewart Thanks for the feedback and I'm glad to have been able to help someone.
-
@Bob38, the WiFi module is not reporting in. When broken, in about 50% of the cases, it then reports with a specific warning in the dmesg.log file. That message is missing here but te WiFi module isn't reported on USB so I suspect the module is broken.
I suggest to contact your reseller / distributor. Even when warranty is out, they might come with a good proposal.
Otherwise, a replacement WiFi module is sold by Ultimaker for $100 and can be exchanged relatively easily.
In my opinion $100 for the \WiFi is way too much, but it is an older model that is no longer for sale.
Alternative suppliers can be found when you search the internet for 'WUBA-171GN', I found it for $42 in the US and €38 in the UK.
Another option is to connect a wireless router to the LAN connection, or try using a power-line modem on the LAN connection.
-
2
-
-
Let's keep this thread related to 1 topic: Active bed leveling on the UM3. Wifi related problems should go in another thread.
@Patronus reported a bed leveling problem where the procedure seems to run fine, but then when printing both nozzles are pressed too hard into the build plate. I'm looking into this using the provided log files.
@erind and @David Stewart, you both are reporting a problem where the bed leveling procedure fails with an error message. The print cores are pushed into the bed during active leveling. This shouldn't happen, the print cores should be just touching the build plate. For printers where this happens, first perform the following checks:
1) The screws for manual leveling the build plate should have some moving distance. When tightened all the way, the bed leveling will fail. Some procedures describe a bed height of 14mm but as a guide line the aluminum build plate should be level with the aluminum front plate (not sure how to describe this better).
2) If bed leveling still fails after correcting step 1), then run the 'bed level sensor test' that was added to the diagnostic menu.
-
The file sorting wasn't implemented because of the limited RAM size that Tinkergnome refers to. Now with hindsight there is a trick we can apply to re-use some memory space that's not used at the time of file selection, or at least have the most recent file appear on top as in the UM3.
But ... development of the UM2 software by Ultimaker has stopped, perhaps a bug fix release will follow but no new features.
Since a week I have my private UM2. With the UM2 software being open source I'll have a look into this some time later.
-
1
-
-
Are you printing from USB?
The line nr. errors often are caused by a usb stick with memory errors.
-
I'm now waiting almost a month for the requested log files.... 😪
Without the log files I can't convince our management to put the probem high on the actions list.
Please people. help me helping you!
This works two ways. You correctly complain about problems, but when I want to help you, you should give me some pointers.
Please mail me the log files using the message function of this forum (hover over my name next to this post and from the menu that pops up select the 'message' option).
Create the log files by performing an Active Leveling function and then from the Maintenance menu choose the option 'Dump logs to USB'. Ensure to include all generated files, including the probe report files.
-
2
-
-
@Patronus I'm sorry to hear about your problems. Similar problems have been reported by a few people but we need more info to investigate this. A month ago I asked two people to email me the log files from an Active Leveling procedure but I'm still waiting their reply.
Could you please perform an Active Leveling procedure and mail me the log files?
You can create the log files by performing an Active Leveling procedure and then use the maintenance menu option for 'Dump log files to USB'.
Send these files to me using the mailing function of this forum (hover over my name next to this post and in the pop-up is a 'message' symbol). Please include all dumped files, that's including the probe reports.
Without the log files I can't convince our management to put the probem high on the actions list.
-
Sorry to hear the modification didn't work.
Instead of posting another change that might not work either, you'll have to wait for me to return home later this week. Perhaps I can figure out another change but want to test it out on my machine first.
-
I moved this question to the firmware section as it is not specific to Cura or plugins.
Your problem sounds a bit like a firmware bug we had over a year ago which resulted in the last 250 bytes of a print being ignored. I don't remember exactly, but this was about Cura version 3.2 in combination with firmware from that revision or older.
Cura 3.3? or newer are shipped with a firmware that fixes this problem.
What version of Cura are you using?
Which firmware version are you using?
Have you tried updating the firmware?
-
The Ultimaker employees are not actively monitoring this forum so your feature request might get lost here.
Best is to report feature requests at : https://github.com/Ultimaker/Cura/issues
-
My guess is that at your first change to the um3.json file you made a typing error. This file is not intended for modifications by users and therefor lacks any error checks. Any small error in the json file will create big problems. Hence the advice to always first make a copy of the file before you modify it.
Without a backup copy of the json file the only way to fix this is by updating the firmware, either through the network or from USB.
Glad to hear you were able to fix it yourself.
-
It is a safety feature to prevent starting a print when possibly an object is still present on the build plate, this would cause mayhem.
For the above reason we never created a way to overrule this feature but more requests are coming in, so perhaps in a future firmware update...
How daring are you to make changes on the printer itself? Since you mention SSH I assume you have some Linux knowledge?
On the printer is a configuration file where you can make low level changes, but there is no official support for this modification.
In the file /usr/share/griffin/griffin/machines/um3.json there is at line 149:
"PRINT": ["print.printProcedure.PrintProcedure"],
Change this to
"PRINT": ["print.printProcedure.PrintProcedure", "cleanup_step": "false"],
THIS IS NOT AN OFFICIAL SUPPORTED CHANGE!
In fact, I don't have a printer here and didn't test it working.
-
1
-
-
Which instructions did you follow for the upgrade? Can you post a link to these instructions, or post a list of the modifications you made?
I don't understand your problem description. You describe two situations where the error happens in one situation but not in the other. What is the difference between these two scenario's?
Did you perhaps replace the Z-motor?
-
Short answer: this printer has an electronics hardware problem.
What the problem is can be difficult to discover...
I never heard of a printer with similar problems, but then again, I'm a software engineer and our distributors do see a lot more of the field problems than I do.
The communication error to the printhead would be my first suspect. The early UM3 printers had a cable connection in the print head that was a bit too loose. Over time this stressed the connecter in the print head and creates communication problems. In the later models this was solved by a printhead cover that was slightly more tight fitting. Try pushing down the cable into the connector.
Reseating the printhead cable video
If this doean't work, contact your reseller or the distributor in your country for a solution. Sometimes a printer does break down and parts have to be replaced.
-
Nice board. Just verify that it can drive the front LCD and SD card reader if you want to keep this original.
For the LCD you need an I2C connection and for the SD card an SPI connection available. From the comparison chart with v1.1 it looks like those two interfaces are not present on the v1.3 board.
-
@stephenbo Just wondering, what kind of 32-bit are you planning to use for the UM2? Most likely the connectors used in the UM2 won't fit. Are you then going to change the connectors?
-
One of the assumptions for Cura Connect is that it is running on a printer. CC will try to connect to this printer and keeps restarting when this fails.
Alternative approach (without any garuantees):
Get yourself an identical Linux board as used in the UM3 / S5: A20-OLinuXIno-LIME2-n8G for €48
Install the firmware using the procedures described on this forum for a bricked printer (insert an SD card with recovery image).
The printer-part of the firmware will fail to start, but there is a good chance CC will start.
-
@bsaygan I haven't received a log file yet so couldn't look into this problem. Could you email me the log files for the failure situation?
Since I'm on vacation I will be slow in responding.
-
On 8/14/2019 at 10:52 AM, zaaf77 said:
What are the possibilities we can do with the 3D printer software without breaking/bricking it? How far we can go? what would be the safe passage? These questions and many more related/similar you already being asked?
The Web API is the only official supported remote interface. On the printer's own web page you can find this documentation.
Note that we recently introduced a 'cloud connection' in Cura and Cura Connect. This makes it possible to start print jobs and monitor your printers from all over the world. Perhaps this already covers most of what you want to do?
-
Hi @Bob38, see your PM.
UM3 y axis calibration / the printer is almost printing outside the bed
in UltiMaker 3D printers
Posted
I just found your other thread where you report print core problems.
My conclusion is that there is a problem in reading the configuration data from your AA 0.4 print core.
You can re-program your print core by:
- Disable Active Leveling (not required, but saves 5 minutes).
- place the core to be programmed in the slot on the left.
- print one of the files below.
- Remove the print core. When you insert it again the new configuration will be read.
Note that on this forum there are alternative methods for programming the print cores, but these have the following problems:
- Only the print core names are changed. Other parameters that should be there are ignored which create problems in XY calibration like you posted above.
- The checksums are not updated. When a new firmware will check this for errors, then the printcores will be rejected.
- bb04_program.gcodeaa04_program.gcode
aa025_program.gcode