The decay fix is a fix for an electronics problem. The electrical motor drivers that we are using can be put into different modes of operation. The intention was to have it in a certain mode, which was done by putting a certain pin at 0V. However, this was done with a pull-down which is not strong enough. It causes an inaccuracy every 16 steps.
This can be fixed with a simple solder bridge over this resistor.
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.
I did some testing today and found that grounding ROSC actually made things a bit worse. Possibly the back EMF is too strong in this mode, causing other issues...
But... in my opinion, there's actually no need to change anything. The UM3 has virtually no Z banding compared to the UM2. I'm guessing this is because the Z axis now has 1/16 microstepping enabled, making the missed steps less troublesome? I wonder if the stepper was also changed to a 400 step version...
I'm very impressed by the quality I'm seeing out of this machine. Z banding and the ubiquitous "stair stepping" ripple on circular objects is virtually gone. dare I say it's finally surpassed the Zortrax in this regard 
The decay fix is a fix for an electronics problem. The electrical motor drivers that we are using can be put into different modes of operation. The intention was to have it in a certain mode, which was done by putting a certain pin at 0V. However, this was done with a pull-down which is not strong enough. It causes an inaccuracy every 16 steps.
This can be fixed with a simple solder bridge over this resistor.
Daid, I think those unpopulated resistors were tied to VCC, not GND, which puts it into an "automatic" mode.
Very interesting!
Small note: The diagrams appear to be cropped?
Also you forgot a word or two at the end of the following sentence:
But, for a most stable and fast network connection, I recommend cable. This is directly provided by the .
The decay fix is a fix for an electronics problem. The electrical motor drivers that we are using can be put into different modes of operation. The intention was to have it in a certain mode, which was done by putting a certain pin at 0V. However, this was done with a pull-down which is not strong enough. It causes an inaccuracy every 16 steps.
This can be fixed with a simple solder bridge over this resistor.
Interesting! I am "misusing" the UM2+ as a laser exposure device for PCBs, by mounting a laser on top (now instead) of the 3D print head and by modifying the firmware slightly to give sync pulses on certain movements (adding a parameter to the G-Code that causes the pulling of the fan output high once that path starts) so that the laser control producing 500-1000dpi pixels can by synced with the movements.
And I discovered an irregularity pattern in the resulting lines that I assumed to be exactly this, but I thought I had to live with it.
Attached a photo of a etched PCB that shows thicker and thinner lines (horizontal lines) and oscillating thickness (vertical lines). That's exactly this thing I suppose.
The print head was going horizontally with constant speed in that case, stepping vertically.
I think the tracks are in the 5mil range, don't remember exactly.
So if the resolution of the printer is 1016 dpi (not perfectly sure), 1 step being one dot, then 5mils are 5 steps. Each track + distance 10 steps.
As it happens ca. every 3 tracks that would be some 30 steps (likely 32 if it's connected to the steps).
Does that reflect the issue?
1
I noticed that it looks like the USB connection is removed from the back panel. Does the UM Board still run Ulti-Marlin? Does the A20 process some of the GCode and send the command over via a standard serial connection?
It could be. You would expect the head to move a smaller distance every 8 or 16 steps and so the laser would rest longer on that spot.
It's easy to ground this pin but also easy to destroy your stepper driver. Only do this if you or a friend are experienced with working with and soldering SMT. Someone on the forums destroyed their stepper driver already when they attempted this change.
Cohen at Ultimaker who chose to set these boards this way felt that the potential error was smaller in importance to the additional torque you get but I know he wanted to do experiments and measure the change in torque at each of the 16 microsteps in both modes of the stepper driver. Not necessarily a simple experiment.
1
I noticed that it looks like the USB connection is removed from the back panel. Does the UM Board still run Ulti-Marlin? Does the A20 process some of the GCode and send the command over via a standard serial connection?
The A20 connects to the ultimarlin board through (I believe) that very same USB interface (I could be wrong). Now if you want to send just a single gcode without sending an entire gcode file you have to use the REST interfact I think.
Anyway you are definitely correct that the USB is gone. Now if you want to print something just send it to the printer over the network. If you want to update firmware the printer can update itself.
A20 has a serial port that the griffin firmware uses to talk with the motion controller (thr old white board). I think it should be possible to write a script to override the griffin and be able to send gcodes (afaik that's what the griffin python does at some level). Ofc now the white board works in griffin just like a mere driver of a printer.
Ahh that's a little disappointing. I am looking for a printer to use in some software development revolving around a custom CAD/Slicer suite that would explicitly require that usb connection. Don't want to rip apart a 3.5k machine to do so though. The UM2+ looks like it should satisfy that requirement though, am I wrong? I understand it isn't officially supported but nonetheless possible by setting the flavor on the machine to reprap?
Exactly @jdkuki um2+ can be fully gcode controlled. Also is a pretty good machine. Since I got my hands on um3 I wanted the same, a gcode console to be able to test experiments and mods.
I suppose is just a matter of time that they add some Cura plugging or interface to be able to connect directly without having to go through Griffin. But ofc atm like @daid explained on other post, there's no 'home g28' gcode, so it might not be doable atm.
It's easy to ground this pin but also easy to destroy your stepper driver. Only do this if you or a friend are experienced with working with and soldering SMT. Someone on the forums destroyed their stepper driver already when they attempted this change.
I have experience soldering.
Is there any instructions on the web on this, where to fix the PCB? Researched for a few minutes (web+forum) and could not find any?
That's the culprit, R84? (see attached image). That needs to be shortened to ground?
The datasheet of the A4988 mentions a problem with skipped steps (page 7/8 ).
Exactly @jdkuki um2+ can be fully gcode controlled. Also is a pretty good machine. Since I got my hands on um3 I wanted the same, a gcode console to be able to test experiments and mods.
I suppose is just a matter of time that they add some Cura plugging or interface to be able to connect directly without having to go through Griffin. But ofc atm like @daid explained on other post, there's no 'home g28' gcode, so it might not be doable atm.
I guess another workaround could be using ser2net on the A20 since it looks like they give a shell with hopefully root acess as outlined in the developer mode post. Hopefully there will be some way to accommodate the new homing in the UM3
I did some testing today and found that grounding ROSC actually made things a bit worse. Possibly the back EMF is too strong in this mode, causing other issues...
You were testing with UM2? What does worse mean, what happened?
Couldn't help but double check what resolution I was running when I discovered the irregularities.
Here's an image where I exposed with 1016dpi and the "gap" happens every 8 lines.
That would mean the native resolution of 1 step of the UM2 is 2032dpi or 80 steps per mm.
And yes, that's what I find in the Marlin firmware:
#define DEFAULT_AXIS_STEPS_PER_UNIT {80.0,80.0,200,282} // default steps per unit for ultimaker2
So... yes, it's every 16 steps, it is that problem.
I did some testing today and found that grounding ROSC actually made things a bit worse. Possibly the back EMF is too strong in this mode, causing other issues...
You were testing with UM2? What does worse mean, what happened?
I tested on my UM3. Grounding all the ROSC pins made some wavy lines appear when printing a circular ring. On the other hand, when I did this hack on my UM2 last year, it really improved Z-banding.
1
I noticed that it looks like the USB connection is removed from the back panel. Does the UM Board still run Ulti-Marlin? Does the A20 process some of the GCode and send the command over via a standard serial connection?
The A20 connects to the ultimarlin board through (I believe) that very same USB interface (I could be wrong). Now if you want to send just a single gcode without sending an entire gcode file you have to use the REST interfact I think.
Anyway you are definitely correct that the USB is gone. Now if you want to print something just send it to the printer over the network. If you want to update firmware the printer can update itself.
Indeed, the USB is gone (good riddance IMHO). The A20 is connected trough a direct serial interface to the "main" board, (UART1 instead of UART0 on the AVR), this means it gets rid of USB latencies.
Only a small amount of commands is still handled by Marlin. For example M109 (heatup and wait) is handled by python code. So the "Brains" of the system know that this is happening. Marlin is only a dumb slave. So directly looking into it might not be the best idea.
This solves the "who is in control" problem, which is quite an issue once you start using the USB on the UM2, as you override the display control.
If you want to a hackable motion platform, I would recommend the UMO or UM2+. They are much more suitable for that. And there is no plan to end-of-life those.
1
I did some testing today and found that grounding ROSC actually made things a bit worse. Possibly the back EMF is too strong in this mode, causing other issues...
You were testing with UM2? What does worse mean, what happened?
I tested on my UM3. Grounding all the ROSC pins made some wavy lines appear when printing a circular ring. On the other hand, when I did this hack on my UM2 last year, it really improved Z-banding.
That's helpful, thanks. Will try this hack/fix! :-)
So there are no sensors to check filament flow right?
I was hoping it could measure that it ran out of filament or even that isn't not going in as fast as it should.
(I understand that with the NFC reader/writer you could potentially store the amount of filament that's left on each filament roll)
You've explained where the ambient temperature sensor is added, but not why this sensor was added, I', assuming there are plans?
Nope, no sensor to check the material movement. It is one of the features that didn't make it. (it's "feature X") We had prototypes, you can encounter remains of it in the code. But we had reliability issues with the design. And we did not want to release something that wasn't reliable.
The sensor was added because it is almost free. And in the future we can use it for better temperature control as well as potential warnings when you want to print with PVA and your room temperature is too hot.
Nope, no sensor to check the material movement. It is one of the features that didn't make it. (it's "feature X") We had prototypes, you can encounter remains of it in the code. But we had reliability issues with the design. And we did not want to release something that wasn't reliable.
The sensor was added because it is almost free. And in the future we can use it for better temperature control as well as potential warnings when you want to print with PVA and your room temperature is too hot.
Is it possible to release the work that was done so that the community may pick it up?
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
Recommended Posts
Top Posters In This Topic
14
8
4
4
Popular Days
Oct 27
14
Oct 25
12
Oct 28
9
Oct 24
7
Top Posters In This Topic
Daid 14 posts
conny_g 8 posts
ultiarjan 4 posts
rimb05 4 posts
Popular Days
Oct 27 2016
14 posts
Oct 25 2016
12 posts
Oct 28 2016
9 posts
Oct 24 2016
7 posts
Popular Posts
Daid
This is day 4 of "Inside the Ultimaker 3", Electronics. - Other days: Day 1 - GCode Day 2 - Remote access part 1 Day 3 - Remote access part 2 - Another week day, another "Insi
Posted Images
conny_g 251
What exactly is the decay fix? Is that in the Marlin firmware?
Link to post
Share on other sites