ScottW, thanks for such detailed feedback. Additionally those are really nice comparison videos between the two FWs. Have you added a heatsink onto your extruder motor? Were you experiencing a problem that adding a heatsink solved?
Concerning #1 did you wait for it to reach the target temperature? When marlin is instructed to do a ‘heat and wait’ command (M109 or M190) it will not accept external commands until the target temperature has been reached. It will explicitly give out temperature statuses during this time without being prompted.
I downloaded the files from: devel/lulzbot/mini/Gladiola/software/firmware/Marlin_Gladiola_v1.1.0.5_f5e8154. I launched Marlin.ino from the Marlin directory. It fails with:
endstops.cpp:29:22: fatal error: endstops.h: No such file or directory
#include "endstops.h"
^
compilation terminated.
Error compiling.
And that is because the file isn’t in the directory.
I had the same problem. Endstops.h is missing, so the #include in Endstops.cpp causes the compile to fail. Apparently Endstops.cpp isn’t needed (i.e., no external references to it), because I deleted it and the compile succeeded.
Yes, I have. No mechanical problems, but the extruder motor was getting so hot it was painful to touch even briefly. There was room and it was easy to add, so I figured it couldn’t hurt and cooler operation might extend component life.
The firmware hung DURING the initial preheat, i.e., prior to the filament retraction that occurs before starting the wipe sequence. During that time, it stopped sending the temperature reports. I waited several minutes, no further reports from the firmware and no filament retraction. I then went to the console; no activity there and no response to commands.
I had the same problem. Endstops.h is missing, so the #include in Endstops.cpp causes the compile to fail. Apparently Endstops.cpp isn’t needed (i.e., no external references to it), because I deleted it and the compile succeeded.
Thanks. I deleted endstops.cpp and now it compiles fine.
Sorry, i wasn’t following the discussion up to this point, so i may have missed something. But an extruder motor should NOT get that hot from normal use. And while i am far from an expert, my understanding is that if a stepper motor is getting super hot to the touch (as opposed to warm) that there is a problem somewhere. Possible problems could include: 1.A firmware mistake where the stepper motors are not getting the correct amount of current. 2.the wrong size stepper motor being used. or 3. a undersized and/or failing stepper driver chip.
I have only experienced number 2 myself as i was using a half-sized stepper motor on a homemade extruder. I found out later that the half-sized stepper motors are only for the TAZ machines for dual-extrusion mode and have the current turned down in the firmware to prevent an overheating motor and loss of steps.
Negative on all three: (1) Stock firmware values. (2) Original, stock full-size stepper motor. (3) Original, stock mini-rambo board, with heat-sinks on all stepper chips, and no missed E-steps.
I was seeing ~70C surface temp when doing long prints on hot days or in an enclosure. It is not abnormal or unusual (and probably not dangerous) for these steppers to approach 80C (a quick Google search will prove that).
So the heatsink probably wasn’t necessary as I never saw 80C. But there is ample reason to believe cooler is better for longevity, it certainly won’t hurt anything, and I already had the heatsink. If there was room, I’d put one on the X and Y motors as well.
I did have a problem with missed steps on the Z axis about 3mo after purchase. I investigated and found that the heatsink that Lulzbot installed on the mini-rambo’s Z stepper driver chip had fallen off. I cleaned it and put it back using Arctic Alumina thermal epoxy – no more problems. Of course while I was there, I added heatsinks to all the driver chips.
Sorry for going off-topic here. We should probably take discussion of heatsinks and steppers to another thread if more discussion is desired, so that this thread can stay focused on the new CURA and Marlin.
I have tested the firmware and cura V20 and they function fine on my mini.
I like the % complete listed in cura now. And the pause works as expected (I was previously using cura V17).
I have also noticed the increased cabinet fan noise though. not a big deal for me since the printer is in the garage, but could be a problem for others.
On the new firmware has anyone else experienced loss of the jog controls capability from the control window? I’ve started to experience inconsistent jog ability after a print completes. For example, once the bed cools and the print is presented my tool head moves along the X axis. Once complete I can only use the controls to move the tool head farther to the right and back to where it was when the pint was presented, but not farther back to the left. The only way to resolve is to click the X-Home button to get it back to the left side. Same type of behavior with the Y axis. I have not tested the Z axis.
Interesting you should mention this. I think i experienced something similar yesterday, but not with the controls within cura but the manual controls with octoprint. I hadn’t thought it might be a problem with the new firmware i had just assumed perhaps it was a problem with octoprint as i had recently updated it. They then released another update and it seemed like it fixed the issue, but i will continue to monitor it to see if i notice that behavior again.
But yes, the arrows that move the z-axis seemed to not be responsive, but doing a home was responsive.
Anyone testing the new firmware and using octoprint experiencing an unusual high number of strange communication errors mid print leaving several unfinished prints because octoprint disconnected from the printer? I’ve had several within the last few days. The new firmware is highest on my suspect list, but there are other potential causes (ie. electrical). But i don’t think i encountered this problem before. I mention it consider the other weird issues reported 3 comments ago.
I think the latest cura still has the recommendation to use PVA glue sticks for nylon based filaments. Since the PVA gluesticks are now a new formula and Lulzbot now recommends cheap washable gluesticks instead it probably should be changed within cura as well.
The issue for me seems seems to be Cura specific (inc the new version). I seem to be able to jog control from within Simplify3D, but in Cura the jog is not reliable.
The unresponsive issue seemed partially intermittent at the time, but i was not even using cura as i was using Octoprint. But since using the latest HEX file for the beta firmware the issue seems to have gone away completely. Not sure if that means they fixed a bug or what. But so far so good. Best case scenario is that everything will work perfectly now. Worst case scenario is that i just havn’t tested it enough to notice those problems again yet. http://devel.lulzbot.com/mini/Gladiola/software/firmware/Marlin_Gladiola_v1.1.0.8_5cb655e.hex
Hmmm, OK, I’ll try again with your link to the latest firmware. Something definitely seems off with my Mini. I was trying to calibrate my E-steps last night and could only submit one G1 E100 F40 command without having to restart the control window (and remember to set it to extrude temp). If I try to do it multiple times (after each one finishes) to average out the feed rate, it moves a fraction then nothing. Restart the Control window and all is well again, once.
I noticed this as well as my bed leveling washers has been at the edge since day one. With the new firmware i noticed that the rear ones had been greatly improved to be near the center, But i found it unlikely that the front ones would not have been accounted for, so i had a look at the latest y-axis rod mount for the back. And sure enough it has changed slightly to be a few mm shorter. This is enough to change the home position and thus change the bed leveling washer locations for the remaining two washers. So in this case a firmware upgrade AND a hardware upgrade are needed together.
I’m not sure if this is the issue, but make sure that you’re resetting the extruder position back to 0 (M92 E0) between sending G1 extrude commands. By default the printer is in absolute coordinate mode meaning that it’ll try to move to the position you send with a G1. If it’s already at 100mm because you just extruded that much, it won’t move when given another G1 E100 unless you manually set the extruder position back to 0. Alternately you can just put the printer into relative coordinate mode with G91 for the extrusion test and it will move 100mm every time you send a G1 E100. You can set it back to absolute coordinates with G90.
Thanks bam, that is exactly the issue! I thought the “E100” parameter meant “Extrude 100mm of filament”. I see it does just that, but, my thinking was that it was a reference to an amount, not a coordinate. Thus I figured I could just send the same command each time to extrude 100mm. None of the eSteps calibration instructions that I’ve seen reference the “M92 E0” to reset it. Makes sense and I just added that to my notes! I’m new to 3D printing but I learn more every day. I’m annoyed with myself that I didn’t get into this technology sooner!
BTW, something I just thought of…if I send a “G1 E100 F50” command and it goes to that extruder coordinate, if I send the command again shouldn’t it do nothing? I’m going to try it again tonight. I recall it moved a mm or so then stopped (meaning it should know it was already at coordinate 100 and the E shouldn’t move at all.) Maybe it is just the nature of the electronics… (shrug). Anyways, thanks again!
Sorry about that, the endstops.cpp file should have been removed during an earlier revert. Arduino was trying to include it in the build process even though it wasn’t needed. You should be good to build with the latest version of the Arduino IDE.
Just an FYI there is a makefile in the /Marlin/ directory which you can use to build without needing Arduino, simply run make .
.