lars86
-
Posts
351 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Events
3D Prints
Posts posted by lars86
-
-
Sounds about right, but I use Twisterblocks by chopmeister https://www.youmagine.com/designs/twisterblocks
Mine are superior.
-
About how much did the frame components cost you?
Post up some pictures!
-
I bought a couple rolls of Polymaker PolyMax PLA from Printed Solid, and like it so far. One of the selling points is higher impact toughness than PLA (by a lot) and even ABS.
It definitely has a softer, more ductile feel than normal PLA. It prints very nicely. the surface finish of the filament is very smooth, and it seems dimensionally consistent.
-
1
-
-
Just wondering, does Ultimaker have plans to rebase their firmware on top of the upcoming Marlin 1.1 for the UMO+? The code of the upstream seems to be much more clean and has some interesting new features.
I am hoping so! It looks like the devs have improved it a lot with the upcoming release.
-
This is a long thread and I haven't managed to read all of it. If you are looking to replace the controller with a BeagleBone, probably the easiest way is to use a Replicape:
http://www.thing-printer.com/product/replicape/
The big advantages of the BeagleBone over the Raspberry Pi are the integrated fast microcontrollers that can have a shared memory interface to the ARM for sending the stepper motor pulses really fast and reliably. There's also more PWMs (good for heating elements, fan controls, etc.) and ADCs (good for thermistors, etc.).
For firmware, Elias has rewritten Marlin as Redeem http://reprap.org/wiki/Redeem. If you you are more of an expert and want more flexible machine control, there is Machinekit http://beagleboard.org/project/MachineKit/.
It looks like this is is not of the new Rev B, but I'm not sure how much has changed. A very thorough review, and it all sounds awesome... until you get to the software side:
-
1
-
-
It looks interesting, but a more modest upgrade.
It seems like if you are going to the trouble of sorting out different power requirements, etc, that you might as well jump to something even faster, and with more features, like integrated networking.
-
That looks like a really cool controller! I have been eyeing a replacement for the Arduino.
-
I'm with gr5. There is a lot of value in the official bed kit.
I found room to further improve stiffness of it, but I don't regret buying it for a second. Should have sooner.
https://ultimaker.com/en/community/view/15881-official-heated-bed-upgrade-kit-ultimaker-original
-
It does take a bit longer to set large values with these new settings (ie setting temp from 0 to 220).
It would be super cool to add in a velocity dependence to the pulses per step. If you track the clicks per second over the last X number of clicks, then use that calculated knob velocity to increase the pulses per step, it would let you have your cake and eat it too!
Whatcha think @amedee?
-
Unfortunately:
configuration.h
#define LCD_FEEDBACK_FREQUENCY_HZ 400#define LCD_FEEDBACK_FREQUENCY_DURATION_MS 20
seems to have no effect at all.
-
I can confirm that:
configuration.h
#define ENCODER_PULSES_PER_STEP 4 #define ENCODER_STEPS_PER_MENU_ITEM 1
ultralcd.cpp:
#define ENCODER_FEEDRATE_DEADZONE 1
Work very well.
-
The only other references to those variables I could find are these. It looks like if not otherwise defined pulses / step is 1 and steps / item 5.
People seem to be having good luck with pulses/step @ 2 and steps/item @ 4.
I'm guessing that these need to be integers. Kind of tough in that case to get exactly what you are after. Seems like you can end up with say every 4th knob click not causing a menu change.
ultralcd.cpp:
#if !defined(LCD_I2C_VIKI) #ifndef ENCODER_STEPS_PER_MENU_ITEM #define ENCODER_STEPS_PER_MENU_ITEM 5 #endif #ifndef ENCODER_PULSES_PER_STEP #define ENCODER_PULSES_PER_STEP 1 #endif#else #ifndef ENCODER_STEPS_PER_MENU_ITEM #define ENCODER_STEPS_PER_MENU_ITEM 2 // VIKI LCD rotary encoder uses a different number of steps per rotation #endif #ifndef ENCODER_PULSES_PER_STEP #define ENCODER_PULSES_PER_STEP 1 #endif#endif
Also found this guy. I had wondered why I had to turn the knob so far (even with the UC) before getting a feedrate override:
ultralcd.cpp:
#define ENCODER_FEEDRATE_DEADZONE 10
-
@amedee, would you mind pointing me to the section of code in your firmware branch to get the robot logo? Maybe the new forum took it out from post #5.
What about browsing the commit log?
I like the mapping of one knob click, per menu item, but the value changing isn't so great. Is there a section of the firmware that governs the steps / unit?
ENCODER_PULSES_PER_STEP in the config file. By default one encoder pulse generates one unit step in the values.
Difficult to find a good compromise there, if you increase it, you will have to turn a lot to make big changes...
Also, ENCODER_STEPS_PER_MENU_ITEM relies on that one, so if you change the first, it will affect the menu browsing as well, so you need to tune both.
Personally I wouldn't go there...
Ah yes, that makes perfect sense now! I'm a github noob.
Both those lines are commented out in my config. It seems simple enough on the surface: tune pulses / step to give the behavior desired on value setting, then use steps / item to to get menus working again. I'm guessing the reality isn't that simple. Are these variables hardcoded elsewhere when not defined here?
Does anyone know how many knob encoder pulses are generated per detent position? Maybe it even varies depending on controller mfg.
-
The other thing I noticed is that while most menus are very responsive, the SD card menu is quite laggy. Does anyone else have that issue?
-
Sweet, up and running!
@amedee, would you mind pointing me to the section of code in your firmware branch to get the robot logo? Maybe the new forum took it out from post #5.
I like the mapping of one knob click, per menu item, but the value changing isn't so great. Is there a section of the firmware that governs the steps / unit?
Thanks!
-
Does anyone have / know of a list of the customizations which differentiate the Ultimaker (original) branches from the vanilla Marlin master?
I'm interested in testing out their new RC build, but the structure has changed enough to make comparing files tricky. I could compare (file by file) the master Marlin release to one of the UM branches, but it would take a while. I'm hoping somebody has catalogued the changes.
Thanks!
-
You need to implement draw_line() in dogm_lcd_implementation.h.
Call was defined by the Ultimaker folks and that's why it is not in the dogm_lcd from Marlin.
(You can check my firmware branch for more details)
Thanks Amadee! I downloaded your branch and compared the dogm_lcd_implementation.h files to find the needed code.
-
Hi guys, trying to install my full graphic controller.
I'm using the UMO official HBK marlin build, with a few tweaks. I already recommented the Ulticontroller definition and uncommented the one for full graphic controller.
I have installed this into the Arduino libraries: https://bintray.com/olikraus/u8glib/Arduino/1.18.1/view
I also installed the Arduino Liquid Crystal library.
When I try to compile, I get this error. Any ideas?
ultralcd.cpp: In function 'void lcd_control_version_menu()':ultralcd.cpp:961: error: 'lcd_implementation_draw_line' was not declared in this scope lcd_implementation_draw_line(0, PSTR(MSG_VERSION)); ^'lcd_implementation_draw_line' was not declared in this scope
-
Thanks gr5, good to know!
I am not 100% on the error message, because it was very hard to read. The LCD was doing it's best impression of melting down. Not sure why that happens.
-
There is definitely some development going on in the main Marlin branch on Github.I think they are getting close to a release, though I'm not sure how extensive the port to UM specific firmware is.
Their response to this issue was that they have rewritten much of the code that governs this, so it would need to be tested to see if it was fixed.
-
No problemo, I am not sure what the formula was exactly either I can take a peek in the firmware.
The basic Idea that I got from the formula was that there is a imaginary table (represented by the formula and rules)
and it creates an imaginary line graph with watts on one side and temperature on the other
and if for some reason that the watts input did not create the (degrees) that it "should" produce within 3deg (i think it was 3) then it will kick out one of the heater block or heater errors.
Could I get a few more details from you?
Picture of the heater block (to satisfy curiousity)
exact type and stats of your heating elements and thermistors
changes you made to the firmware (general)
the suggestion about using the other on board connections for the secondary heating setup is more pointed towards having better control, and so you can keep things (firmware) as "stock" as possible.
Interesting, I'll have to dig around in there!
I've taken a little break from this project as I've been busy with other stuff. I actually had another issue, where molten filament started to leak out from a press fit between the thermal brake and heater block! I did not expect that one.
-
Using both heater1 and heater2 on the ultiboard is a firmware nightmare - you would have to rewrite the PID code. I don't recommend that. Hopefully the single MOSFET can handle 7.7 ohm (50W) load.
Your calculations were fine.
Did you measure the resistance of the heaters? I would check them. They were supposed to be around 14.4 ohms but it sounds like they sent you the wrong heaters.
How much heavier is your aluminum block than the default one? Even if twice as heavy it shouldn't be more than twice as hard to heat, right? Also what is the surface area of your block versus the original?
You know, I should have done that right away! hahaha
I checked the heaters and they measured 8.2 ohms in parallel. After switching back to the stock heater, everything seemed fine. But a few days ago, I got another heating failed error. I went underneath and reseated the heater wires in the terminal block. Since then, I have run a couple 7 hour prints without issue. I'm wondering if that error was just coincidence.
The physical size / mass of the heater block isn't as important as the steady state characteristic of the whole thermal system. Basically, looking at all the heat flows (at the desired temp): into the filament, up into the heat sink, and radiative/convective loss. All that combined equals the steady state power consumption. Things like surface area can definitely have a big impact here. But mass / volume would just slightly slow the initial heating.
-
1
-
-
also I wouldnt stick the aluminum foil in the heaterblock... if the foil fits you are doing something wrong prbly
If you want a good fit find some thermal compound made for a temperature that you are trying to achieve... on second thought... You could probably use some ceramic compound for that.
I have yet to see a compound that is rated for sustained temperatures like a hot end produces. If you have a suggestion, I'm all ears!
Using aluminum like that is pretty common. We are not talking much, just a couple layers. Many people suggest that even if the heater is a slip fit to the block, that it expands enough during heating to form solid contact. Adding aluminum foil helps to fill any airspace voids which would not conduct heat well.
-
Here's the long difficult solution to the heater block error
If you have solidworks premium with simulation this is a lot easier.
*************DISCLAIMER********************
-This sciency part is probably wrong
- This worked for me
- This MAY not work for you
- I am still working on my coffee
- This is a lot easier with solidworks simulation
- you literally have to add material types hot spots and get temp @ thermistor point
Find the thermal conductivity of the material used buy UM for their hot ends. (watts per meter kelvin (W/(m·K)
-Yellow brass I believe(
Then Find the thermal conductivity of the material you are using
(I suggest just using their material)
If you know it then compare the distance and dissipation of your heater bock
IE if you are using 306 stainless steel 26(tc) then you will have to place your
heater 2.5 times closer than the yellow bras with a (tc) of 67.
67/26
It should get you close enough to beat the "heater block" error 90% of the time
My heater block and the Ultimaker block are made from aluminum, so no substantial difference in thermal conductivity. UM makes their nozzles from brass, but that won't affect heater / thermocouple placement.
I have done extensive thermal simulation on this hot end configuration.
-
1
-
MXL vs. GT2 - print results
in Third party products & modifications
Posted
@mariuszem, I find that hard to believe. What do you mean you "hear scratching". That is not how you would determine a failure to clamp the belt. If you want to check belt holding, grab the belt near the block in one have, grab the block in your other and give a tug. You should see no movement between the two.
Are you running GT2 belts?