Sorry for the delay. Confirmed it is fixed.
Wed, Mar 20
Tue, Mar 12
@marcio Looks & works great! Thank you!
Mon, Mar 11
@karrad I dont think fw needs to be updated. Cura controls the print volume
@mbloom Yup, it should get them fixed up in the same matter.
Fri, Mar 8
@logan: Implemented in .99, please test and close this ticket.
We are also having the same issues with the TAZ's running Flexy filament. Would including the M420 lines fix those files, or would they need something extra because they are Flexy?
@youngmrcarlson: This should be fixed in FW .92 and beyond. Can you confirm and close this ticket if it is resolved?
Thu, Mar 7
@marcio , Merged your workaround to CuraLE master.
Wed, Mar 6
Mon, Mar 4
@EricNugent With each update to marlin, there will be specific changes to start gcode required. For example in the 1.1.7 FW we needed to change the way we homed in order to take account for fringe cases of euphorbia builds for Mini 1.
@karrad that .gcode is the the start/end for the 236's. Do we have an updated start/end .gcode that we know will work across all firmware versions?
Fri, Mar 1
I can confirm that problem does not occur on other versions of the firmware. 184.108.40.206, 220.127.116.11, and 18.104.22.168 do not experience this bug. All instances of 22.214.171.124 in the cabinet have been downgraded to 126.96.36.199 until we can get new slices made.
@EricNugent This is old gcode it looks, and the issue you are describing sounds a lot like the Bed Calibration stack up we ran into when first going to 1.1.9 firmware.
Feb 20 2019
Okay, that makes one complaint in the forum. With everything in development right now, going to mark this as wish list.
Feb 19 2019
I have not once gotten a complaint about the TAZ 5 fan
@karrad: So this was on a TAZ 5? If so, it explains it. Our current code for all printers is based on TAZ 6 FW. If someone implemented this feature for TAZ 5, did not push it upstream, and also forgot to add it to the TAZ 6 FW, then the feature would have been lost.
@TyTh Are you getting a lot of complaints on how quickly the TAZ 5 electronics fan is running? We haven't produced these in a bit, and want to get an estimate on how pressing of an issue this is.
I have not been able to determine under what circumstances Marlin crashes, but it seems like the root cause of this may have been that Cura was not waiting long enough for G29 to complete before deciding Marlin was unresponsive and attempting to revive it. However, this was happening multiple times in the row and it was filling the serial output buffer, eventually causing Cura's serial code to block. It's unclear why this ultimately leads Marlin to crash, but I have pushed a patch that will keep Cura from initiating this process due to failed probes.
So this actually happened today. After quite a bit of pulling I was able to remove all but a small little piece that is too small to grasp. See the attached picture.
Feb 18 2019
If serial data can cause Marlin to crash, this may actually explain T4900, T4916 which Dani recently closed. It's possible we just haven't run into serial errors because the Archim board is more reliable after the fixes Mark implemented in hardware, but I suspect that the serial error recovery is what is causing the Archim to crash. It's good that we found a good test case to reproduce the problem.
I was able to reproduce that error outside of Cura by using a script I have that prints from the command line using "MarlinSerialProtocol.py". So now I can test this outside of Cura, which will be a big help in tracking it down efficiently. There are actually two problems rolled up into one here. For one, Marlin should not crash, no matter what gets sent to it from the serial port. Second, from my initial testing it is clear that the MarlinSerialProtocol is not behaving how it should with regards to timeouts on Quiver. This is a separate issue that will need to be addressed.
@marcio Nice! I changed that value to 1000 and it now displays the error as expected.
Cura is expecting certain commands to complete in under 100 seconds. This is certainly no longer the case for G29, which on Quiver, as the worst case scenario, is several minutes. I suspect that when Cura tries to "wake-up" Marlin, it is causing the crash. One very useful test to run would be to increase the following value to 1000 in MarlinSerialProtocol.py and see if the problem goes away:
So what is interesting is that if I connect to the printer via a serial console, and type "G29", the probe repeats the correct number of times and shows an error. So it seems like Cura is doing something that is causing the printer to reboot.
It looks like the machine crashes during a move towards the middle of the bed right after wiping after the second probe fail. Is this what you are seeing?
Not sure, I think we used to scale the fan speed dependent upon what drivers were being used, and what load.
Not sure, I think we used to scale the fan speed dependent upon what drivers were being used, and what load.
Maybe set it to 130?
188.8.131.52 set up:
Probably Configuration.h or Configuration_adv.h
@karrad That's what I started testing right after my last comment :)
Probe fail message displays as expected when printing from USB drive - only affects tethered printing over USB
@marcio Looks like we didn't save config files for the 184.108.40.206 branch, any idea what tab of marlin.ino that would be located on?
@youngmrcarlson Ahh thank you. One last thing to check, can you force a fail while printing via USB stick? Will help determine if FW or Cura issue, or communication between the two
@karrad The issue with the probing hot end being retracted seems to be resolved, and it's just that the printer restarts instead of displaying an error if it fails probing twice. Updated task to reflect.
Tested using Cura 3.6.5 and .88 FW. Reproduced just by disconnecting zero sense from one hot end (to fake a probe fail) and starting a print.
@eBeardslee What version of the firmware are you using?
@marcio Gracias! Will do.
Please test this under 2.0.x. I believe such issues were fixed in this release.
@karrad: Should not have, but 220.127.116.11 is before my time, so it's possible it got lost in the translation.
@marcio I will try to grab old config files to find the difference in speeds. Do you know if we increased the fan speed to max on this for a reason?
@youngmrcarlson Can you reflash to .88 and re-test? Be sure to restore factory defaults after updating firmware
Feb 13 2019
@matth: The fix is baked in to .87
Feb 12 2019
I tested it three times, and that seems to fix the issue.
Oh good. I was waiting for my current print to finish before using that command. I've tested it with several difference gcodes and got similar bad results. I first noticed it after printing:
Nevermind. I am able to reproduce it.
Can you send me the GCODE from a print that is exhibiting the problem?
@matth: I suspect it's the bed leveling that remains enabled after a print. Can you run "M420 S0" from the console after the first print and see if it restores your ability to calibrate? If it does, it would be an easy fix for me to do that prior to the auto-calibration.
Feb 6 2019
Confirmed this is now working as expected.
Feb 4 2019
Feb 1 2019
Versions up to .80 had a workaround for a Marlin bug. In .81 this workaround was removed as it seems like the underlying issue was solved by the MINIMUM_STEPPER_PULSE
Jan 31 2019
I checked a few of the Taz 6's over here and a couple of them seem to be a bit off. We've got one that says it's been used for 20 hours, which seems a bit low for our printers over here, and then another one that says around 2 days of print time on it, which also seems a bit low. We have another one that shows 13 days of usage, which seems a bit more in range.
Jan 29 2019
Testing on SL 18.104.22.168 i am unable to set the fan below 0% are roll it over above 100%
Seems fine to me. I powered off, moved the toolhead to different positions, then powered on. Each time the toolhead just moved up to the top most position.
LCD calibration is working fine with USB flash drive plugged in from the start and halfway through calibration.
@karrad: I would never trust an odometer, on a printer or on a car. Supposedly on newer cars it is extremely easy to hack using an inexpensive tool from eBay...
Plugging in USB drive while in calibration screen also did not kick back to main menu. I was able to complete calibration as expected
@bigmansas Before sending out the info, please check a few of your printers around TSR to see if any others have become corrupt. Marlin doesn't document that command to try to keep sellers of used printers honest: http://marlinfw.org/docs/gcode/M078.html
however, now there appears to be a bug where when at 0 the user is able to decrease speeds past 0 and loops back to 100. It appears to only be the lower limit.
The counter probably got corrupt. The only fix is to have the user run "M78 S78" which resets all the statistics to zero (essentially rolls back the odometer!)
Testing on SL 22.214.171.124 with USB plugged in I am able to calibrate.
@tutley: This would be tricky to do, plus homing at startup helps level the X-axis, so there is a reason to do it.
@jebba: If you are satisfied with the behavior in .78 or .79, please close this ticket.
@youngmrcarlson: This has been addressed in .78. Please confirm.
This will be addressed in .79
Jan 28 2019
@bigmansas Hmm, I would suspect that total print time is off....
Jan 26 2019
Jan 25 2019
@oliver: I see. What happens is that if the USB thumb-drive is plugged in, it jumps to the main screen to show that the drive was inserted, this will typically happen before the calibration screen has completed.
@tutley Could be, this is something we can do a final confirmation on beta units than.
@oliver i also have the USB plugged in and i am not seeing this. however my unit has all the upgrades for EMI/ESD. Maybe this is why i am not seeing this
I can confirm that I am still seeing this issue on my printer running FW .78 when the usb is plugged into the printer
i am not having any issues with calibration on .78
I can also confirm that this is the case with mine as well. Currently running FW 126.96.36.199.
@oliver Thanks for mentioning that! I discovered that the issue exists when the USB flash drive is plugged in. If I unplug it, I'm able to calibrate.
Jan 24 2019
@oliver: That makes sense. If the board is not present, it will try to show an error message and this would cause it to jump to the status screen, even if the calibration screen was up.
@marcio The USB board
@oliver: You mean with the USB board not plugged in, correct? Or with a USB flash drive not plugged in?
@marcio After creating the fixture to test the touch screens I did notice that without the usb plugged in, when trying to calibrate the screen it will go grey for a second and quickly snap right to the main screen. My guess is it could be the marlin interrupting the screen calibration to display some error message.
@youngmrcarlson: I am unable to reproduce this. The calibration screen will only show up if the touch screen is detecting a touch at startup. It looks like your touch screen may be registering invalid touches -- possibly something is causing those false touches?
Jan 23 2019
I have confirmed this on my printer as well.
Nevermind, can recreate this on Q11. That text is a good distance away from the button being triggered.
@youngmrcarlson I'm currently unable to calibrate the LCD. The calibration screen shows for a quick second, but exits to the main menu before I have a chance to tap dots.
Did you try re-calibrating the touch screen?
That is done by powering off and holding a finger on the screen while powering on, this will trigger the calibration sequence prompting you to touch several points. You may try using a dull stylus of sorts to increase accuracy.