mutley3d
-
Posts
24 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by mutley3d
-
-
8 hours ago, jaysenodell said:
That is an interesting animal. I have all sorts of quesitons. Where should I ask them?
If it is Ultimaker related, and no one objects I could create a new post/thread about it on this forum.
Note that I am aware to some sensitivies and the potential accusation of "spamvertising", since expressing or detailing features and the reasons for them may well sound "salesy" but then it is a product development that interests people, since it meets and solves particular challenges and functionality and does so quite well. So for those that may feel that way, it might be best to look away 🙂 (joke of course).
If not Ultimaker related, but for another OS machine, feel free to email or send contact through the website and I will be sure to reply. there is also a Discord server. -
Referencing the fitment of the Flex3Drive Ultimaker version to the UM2GO. I have downloaded and looked at the TinkerGnome code and its pretty much the same as for any UM2 machine in terms of just swapping the pin numbers between the Z and E0 axis to take advantage of the x8 microstepping on the Z axis (through setting of J5 jumper).
Code changes for this are very straight forward and simple/minimal to swap axis pins in pins.h, but having not looked at TinkerGnome before (although it was on the list a while back) I can see there are #ifdef's for UM2GO for setting bed size and bowden tube lengths, which hints to me compile will be as simple as selecting the UM2GO #define however, I cannot find this "#define" so it suggests to me (being completely new to TinkerGnome) there is a compiler switch or setting outside of the code base itself that determines compile option for UM2GO. Is this correct?
I will look at the instructions for compiling as my initial compile attempt with Arduino IDE threw an operator error, as well still being in the dark about setting for UM2GO option. What is the best or easiest way to compile TinkerGnome? My initial skim over the instructions suggests a different compiler is required, but a skim on the forum also indicated Arduino IDE will do it too. Or alternatively could anyone compile it for us given the simplicity of the changes in pins.h if they can compile it easily?TIA for any tips suggestions on this as I would like to set TinkerGnome on my own machines too.
(BTW cheeky note 🙂 Ive just launched a new 4into1 multi filament solution compatible with almost any OS 3d prnter - see website flex3drive.com) - it could potentially fit a UM2 machine aswell with some modification and addition of 2 extra driver boards.
-
1 hour ago, halfie said:
Tried flicking my 2100's over to spreadcycle on the weekend, and I think I burned out one of the chips trying to bridge that tiny tiny little gap. No matter, the A4988 Black Edition I got are fantastic, and I have just thrown it into a back room to avoid the noise.
I also noticed that 90% of the noise is from the extruder motor, so I'm going to chuck the astrosyn on just that, and take them off the x and y axis, I think.
Ouchies. I dont use the solder pads, my eyes cant cope with that small. I put a bridging wire across pins config1 and gnd, and i'm assuming from the results i see that i am getting spreadcycle mode. Certainly feels like more torque
-
@halfie Spreadcycle...for now.
-
1
-
-
2 hours ago, halfie said:
This sounds dumb but could there be slop introduced into the driver over time with heat generation or something?
Ive hacked about with these machines quite a bit over time. They both run Flex3Drives with a suitably modified firmware but none of the changes caused the issue. I may have had an accident at some point tinkering where the board switched off but then reset, so I don't know if maybe there was a damaged component on the board, or partial failure of a driver. Having said that I have reverted to "from scratch" firmware to make sure no old late night forgotten changes playing tricks, mapped to the spare driver chip, and plenty other tests and checks, and replacement of donor parts to no avail. Going to off board driver was instant fix for me so maybe board component, but i cant recall ever getting such print quality out of the machine. Defo the best I have had, and i'm very satisfied with this level of output now.
-
A quick before and after photo. I think something might have been seriously wrong with the drivers on board, or maybe i'm just used to the finer prints from my other machines, but I swear my UM2's used to print better than the result on the left side. But I have same issue on both the machines. Piece on the right is after TMC mod.
I think the stepper carrier approach is a right royal PITA, it took a while to get the second TMCdriven axis to work, testing different remapped pins. However I think the result is pretty conclusive, at least in my case. This machine is now back to producing production parts once boxed back up. When the 2.1.5 board arrives I will fit this to the other machine, if all goes smoothly, I will order another for this machine to keep things as tidy as possible and recover the carrier boards back into my spares bin.
For reference the printed item is just a thin walled hollow item similar to the cylinder, but with some straight edges, rounded and sharp corners. Printed in black (ABS) so as to highlight surface striations, 0.8mm wall thickness, 0.2mm layer height. I think that is a wrap !
-
Well i'm almost there. Got each axis running when mapped and connected individually one each to on-board, and off-board driver. When I map both axis to off board drivers, i get odd behaviour from one axis. Calling it a night for now, as one of the off board driver carriers blew the voltage regulator, through plugging in an old blown driver (4988), it happens when tired. The odd axis behaviour might be down to how I was grounding both carrier boards (as per manuf' instruction), and sods law just when I'm about to eliminate that concern with separate ground wires, the magic smoke escapes.
It didn't help that I had a whole pack of faulty 8825 drivers throwing me off track, maybe the plane from China took a lightning hit
The intention is for a relatively straight forward documented method of circumventing the 4988 related print quality issues once and for all, whilst retaining the original board. From where this "idea" was a few days ago, it has come along pretty far. Of course the other option is that 2.1.5 board fitted out with TMC drivers. I have one on order. Certainly the off board driver carrier approach is being a lot more hassle but once finalized, some documentation will make it pretty straight forward. at least thats the plan.
-
1 hour ago, tinkergnome said:
This should be already done at startup (if the correct pin numbers are defined):
https://github.com/Ultimaker/Ultimaker2Marlin/blob/master/Marlin/stepper.cpp#L698
pin numbers in your case should be 54 to 56 for x-axis and 59 to 61 for y-axis, right?
...but there are perhaps some more things to consider:
Hi tinkergnome and good shout on inverting the enable and step signals. I am (perhaps dangerously) assuming that because the drivers i'm using are "usually" drop in replacements for 4988's, that I shouldn't have to make changes to those. But I will certainly keep this in mind now that you mention them.
Using the analogue pins seems to be working, although I am having a bit of trouble. In diagnosing, if I fit just one external driver, and set the pins accordingly, I have both X and Y running (one from the offboard driver, one from the original onboard 4988). But if I wire in both off-board drivers and set pins accordingly, I get one axis running.works. Just working my way through a few tests. Do you think the inverting Enable and/or Step is going to be necessary? I wouldn't have thought so given the "drop-in" replacement nature of these.
I am so close to my goal.
-
OK so I think I have worked out what to do with those analog pins to define them as digital pins. Its so easy.
I now have motion on one axis testing with some spare 8825 drivers (instead of blowing tmc2100's). I have to recheck the other axis closely as it is lifeless, might be wiring, might be a dud carrier board.
@neotko yea but does it have the bed levelling routine? @halfie seems to be having probs with it. Ill check it out once I have these drivers sorted, but taking one step at a time, too many changes in one go is dangerous. For now just using the Ultimaker/Marlin from their github repo
-
Some sort of progress. I have remapped pins in pins.h, and now have 2 external driver sockets wired in. I am using 6 pins from connector J25 (ADC0 ADC1 ADC2 for X axis) along with (ADC5 ADC6 ADC7 for Y axis) for STEP DIR and ENABLE signals respectively. Firmware has been flashed and I have managed to not let any magic smoke out, but i'm not quite there yet.
The Y axis motor seems to get enabled, but wont move, the X axis has no response. The 2560 data sheet appears to indicate these pins can be analog input, or signal output. I am not sure if or how I set these pins to become signal outputs. Anyone shed any light on these? I envisage/hope this will be an excellent and easy upgrade once it is resolved, transforming the level of print quality achieved.
Thinking aloud, I may remap one axis back to the onboard 4988 and the other to 3 known digital pins in the area of these headers to verify all circuitry and the off board drivers.
@halfie yea that's the problem with using the general Marlin release, its updated but may miss some of the UM functionality. I have one of those board in my alexpress cart, just waiting on the seller to get back to me about supplying with TMC drivers.
-
5 hours ago, halfie said:
I'm using the aliexpress 2.1.5 board at the moment, and it's working just fine.
What I did was change the MS1, MS2 and MS3 microswitches to OFF/OFF/OFF, to make the board full step, and then inserted the 2100 drivers. No modifications to drivers, like resistors or whatnot, just plug and play. The printer was completely silent. I got some TMC2100's sent along with the board, but I couldn't get them to satisfactorily print, it was constantly skipping steps. Could be voltage, or could be something else to do with the switch positioning? I don't know.
Also, the UM2 LCD isn't supported in the latest 1.1.8 release of Marlin, so I had to jump on the bugfix version, which made the screen work, but I could never get good, sharp corners. Just a ton of bleed (Linear advance on or off). There were a host of other issues too, like I couldn't figure out how to get auto bed levelling working with my piezo, which drove me nuts since it seems like such a cool thing.
Wish I had more time to experiment, maybe I could have fixed the issues, but eventually i just switched back to A4988 drivers at 1/16 stepping on tinkergnome and the 8 diode smoothers. I'm sad.I am looking into that board and have contacted the seller to request TMC drivers with it, along with some spares.
I suspect you may well have had the voltages set incorrectly on the drivers, and cooling them helps as they can get hot. Also if you had them in stealthchop (silent) mode, you get less torque, so possibly cumulative unfavourables working against you. Putting them into spreadcycle mode with a bridging wire increases available torque, but also noise, although my experience tells me you can get them pretty quiet with some tuning of the vref, especially when compared to original 4988 drivers. I will also be sticking with the original UM2 firmware, but might explore tinker fw aswell.
So Neotko's post threw my train of thought toward remapping pins with off-board drivers that I have laying about, and drop the TMC drivers onto those.
Now my stumbling block at this moment is some uncertainty on remapping pins for the X and Y motors. Can someone possibly advise if the pins on J25 (ADC1) and/or J24 (ADC2) can be remapped and used as STEP/DIR/ENABLE pins. I read that they are analog port pins but can also be used as digital I/O pins. If not, which pins can I use? I need six of them. If not, I notice a combination of 2 available pins on J23 + 3 available pins on J24 + 1 available pin on J26, if J24/J25 wont work.
-
1
-
-
1 hour ago, neotko said:
There’s an user called 3Dper on twitter that a few months ago did send me this picture (no manual or how-to) but basically what he did was rewire the board and connect tcm drivers outside cooling them with a waterbased something. He did pm this picture
I don’t have more info, but... is doable
If I would be on your situation I would try the so called 2.1.5 um2 board on aliexpress that some guys sell that has the stepper chips removable and I don’t remember who but someone already told me it works (can’t find the twitter where they did)
IMO duet3d wifi, send stuff remotely and better PID tunning is just awesome. But all depends on how much work you want to put on soft or hardware.
OK so I wont be doing that
however I think you just altered my train of thought and pulled me out of a rabbit hole.
I will update more shortly but I think I have a solution. Thank you for your response.
-
1
-
-
Maybe this should be a new thread, but posting here as it is directly relevant to this thread.
I am Suffering the same issues on my 2 x UM2 machines. Want to finally do something about it. Done all the tweaks and mods, shorting ROSC pins, diode smoothers etc, none really "FIX" the issue. I have Duet boards available to upgrade like Neotko above, but kinda thinking I would like to retain as close to original as possible ie keep existing LCD. I also have a couple spare Arduino/RAMPs boards to hand.
So my thinking is use a RAMPS board with TMC2100. I have these drivers on my UMO and it prints wonderful. I have other RAMPS based machines with TMC2100 and they too print same great level of quality. I have a E3D thermistor cartridge, to replace the hotend thermistor, and will also replace the bed thermocouple with a thermistor and run new wires along the loom. This should take care of the main sensor differences. But has anyone fitted a RAMPs board and retained the UltraLCD? or to put the question another way, Has anyone compiled the UM2 firmware to work for a RAMPs board using the UM2 LCD?
Ive tried compiling the UM2 Marlin, with the board #define set to RAMPs EFB but as was expected, compile errors occur, for motor current variables, which of course are set via LCD, but not available on a RAMPs board.
If someone could help me around the compile errors, or point me in the direction where something like this with TMC drivers might have been done before (I'd be surprised if it hasn't), or suggest another approach in case im looking at this from the wrong perspective, I would be eternally grateful. Thanks in advance.
-
I go away for five minutes and look what happens.
This is very nice. How can I not do this to one of my machines? baahaawaaa
-
Guys,
Real intereting stuff in this thread. Im around but just incredibly snowed under so trying to clear backlog. Sorr i havent added much here...yet!
@Macua85 can probably work something out
Ive got a couple interesting titbits on the way too
will update as son as i can -
Just seen this thread for first time - foehnsturm thanks for bringing it to my notice.
Let me digest and consider the options. 30x30 easy - possibly a bit smaller depending on how its attached.
Macua85 - dont be shy
plus, all the parts in the Flex3Drive will be interchangeable into anything developed here.Have also been looking at nema8 solutions - got a couple on order from a couple weeks back, waiting on delivery.
Ill be monitoring here closely from now on.
-
I also found turning up material flow to around 120% made a lot of difference with some filaments.
Ill soon write a new post dedicated to Flex3Drive as I dont want to steer this topic, off topic
-
Retraction is in the region of 1.5mm +- 0.5 depending on material, temps, travel speeds etc. Retract speed can be as low as 10mms upto around 30mms, again dependant on material type and temps. Too fast and you can find some odd artifacts possibly due to air being sucked in or excessive back pressure in the melt zone.
A safe setting for majority of materials would be 1.5mm at 15mms.
Note: using a 1.8 degree stepper on E axis!
-
OK so these have been my efforts at this extrusion test. These have been done with a Flex3Drive equipped UM2. Black and White ABS and PLA. All the settings on the machine are the default aside from the changes necessary for the Flex3Drive (ie e steps and motor direction). I have not done the E motor current mod (set to 1300ma)
The middle narrower cylinder is a 20mm/3 speed test - Black ABS
- Im not sure if it did run to its maximum speed near the end on this cylinder (i think there was a limiting factor in one of the machine settings like max feed rate or similar) i think it toppped out at 17mm3 for the last three speed segments i will be investigating and retesting this one.The PLA was done at 225c the ABS at 250c. These were all UM filaments.
The blue cyclinder on the right is the standard issue UM PLA that comes with the machine, the changes in appearance (translucency towards the top) was me turning up the temp mid print.
Then i did some retract torture tests. These have had NO post processing and are exactly as they came of the machine (not sure if i should post these elsewhere? i couldnt find a "retraction test" thread)
And you can see a time lapse here (sorry i couldnt help myself
) -
OK i meant with a standard factory spec with 0.4mm nozzle :cool:
I see Cor3ys hitting the mark. Who else?
-
Has anyone achieved 15mm/3 sec?
-
I think there is some website work being done, this may be affecting things.
-
Is this a dual Bowden? Any news on its progress?
however I think you just altered my train of thought and pulled me out of a rabbit hole.
)
The Mighty UM2go
in UltiMaker 3D printers
Posted · Edited by mutley3d
Thanks gr5 that makes complete sense about the build script. I will get to a more detailed read of things and download the required elements of the build environment. I did see some say they built it with Arduino IDE with no issues but think there might be different cases where it does and does not build that way, or something else going on. If you could contact on my behalf that would be most appreciated, or I could even join the slack if its not a private channel, or do a compile with basic changes provided.