@jebba : The fix rCT182c043e604d and rCT1e83b65d02f6 was done in CuraLE only, so the bug is still present in Marlin therefore other than CuraLE programs, such as Octoprint would have the same problem.
Wed, May 22
@alexei Why not close this ticket though? The problem in this T5686 ticket is that Marlin restarts when taking too long in Quiver, but that is no longer an issue, it correctly says "probing failed". If we want to track whatever is going on in upstream Marlin's #11715, isn't that a separate issue?
Sounds good. Per Alexei we will leave it open until it's resolved upstream
@DaniAO Works on .116 as well, but I don't have permissionsauce to mark this Resolved.
@youngmrcarlson will you update your firmware to .116 and try it. If there are no issues please close the ticket.
Just tested it with 184.108.40.206 and it shows the "Probing failed" message as expected.
I just tried to multiply an object in 3.6.8 and cura crashed on me.
That is a different issue being reported here: https://code.alephobjects.com/T5010
Please post there that you were able to recreate that, and do your best to include the same information others have, if you have it.
We have had a a few firmware updates since the last few comments- are we still seeing this as a problem? Or can we close this ticket?
Well I may sit corrected. I just re-opened cure and tried it again with no problems. It may be a different bug or just coincidence it happened.
We have had several revs of firmware and Cura with no update reports. Going to close this one down and it can always be reopened if needed.
@DaniAO I just tried to multiply an object in 3.6.8 and cura crashed on me.
@MikeR not sure what version of Cura you were using here- but any more reports? Think we can close this one down?
Mon, May 20
Thu, May 16
This is actually a tricky thing to fix. The UI does not allow for different increments for unrelated items which share the same screen. I'll have to split up Linear Advance and Runout into individual screens, but then there is the problem of cramming an additional button into the Advanced Settings menu.
Wed, May 15
Wed, May 8
This is "intentional" in the sense that if there was a reprapdiscount display connected, it would have asked you to press the button again to resume printing. But the way this is done in Marlin, it isn't quite compatible with our new color display. I thought I had found a work around, but apparently I did not.
Mon, Apr 29
After using the jigs provided by @west, the wipe and rewipe is much closer. Now hitting the right edge of the pad, still off to the right 2-3mm of effective wiping.
@west sounds good. Now I just need to know how to use them and what to reference them against to adjust the bed...
@adam if your printer is wiping too far to the right (on the bed) then you need to use the jigs (orange) I gave you two weeks ago to re position your bed to the correct location
Fri, Apr 26
@adam: I do not see this on the Redgum in R&D, but I do not know whether that one is up to date. I did notice that the printer can loose steps if it hits an endstop when moving towards the wipe location. This is a problem that has haunted us in many different occasions. Listen for a click to see whether this is happening. If it is 20 mm to the right, it may mean the Y axis is hitting the endstop while the head is still travelling to the left. This would cause the move to be aborted and the machine's coordinate system would shift.
@marcio the base behavior is correct, but for some reason the redgum I'm testing on is 20mm off to the right. Whatever the distance is that bump stop is setting is wrong, is my guess.
The change did update to move the tool head to the center and then wipe on the left as is correct, the location is just off.
Thu, Apr 25
@karrad: I pushed .112 with this change. Go ahead and give it a test and close this ticket if you are satisfied.
This should have been implemented in Marlin .111
@adam: I pushed .112. It should solve the homing Z issue. If so, go ahead and close this ticket.
Well, fudge. The hint was right in the console:
@adam: The home Z at startup doesn't seem to be working on the 8-bit boards. I can hear a small *thunk* at startup, but the axis doesn't quite move. Maybe the steppers take a while longer to initialize.
Request: when re-wiping it may be best to have the head in the center of the X axis travel before leveling X axis. This would help provide a better level, and avoid superfluous movements.
When re-wiping, the printer will move the head to the lower right corner, and then move left to wipe.
I think everything but the home Z has been taken care of or determined as "Won't fix" so as soon as we get the home z we can close this and just open separate tickets for new issues.
This is 220.127.116.11 FW
This must be old FW. The second wiper pad is only defined in the code for TAZ Pro.
@adam I will defer to you on that one, I reported here as it was originally said to be fixed here. If you want to close this out and split them up, please add me to the new ticket.
@karrad do we want to continue to collate marlin feedback on this ticket and move it to the beta column in redgum or close and open a new one?
@marcio Testing 18.104.22.168 for redgum hardened steel, we are missing the home Z axis when first powering on.
Apr 16 2019
PR created in upstream Marlin and merged. Will be in .111.
PR created in upstream Marlin. Awaiting merge.
This has been corrected in .110
Apr 11 2019
@marcio x max = 295 y = 308
@marcio the nozzle is centered over the front left washer x=2
The x min position is -32, for dual compatibility we need to change it to -51 for dual v3 compatibility
Also the z doesnt home when powered on in .109
Apr 10 2019
Double checking machine definitions, set to 286 in Z in order to allow a max Z of 285. Closing out.
Apr 8 2019
Apr 5 2019
@karrad: It will be .109
@karrad: I already made the change, take a look and if you don't like it's easy to unhide it. I'll push it to buildbot.
@karrad: But hiding it is more fun!
@marcio Ahh, reprap only. Yeah lets go with About Printer. I don't think we will need to hide it though, if we get complaints/issues from schools or other organizations we can remove it.
@karrad: The little games only show up on the RepRapDiscount display, so Quiver will not have them. So Interface Settings is not an option.
@marcio About seems it should be printer statistics and firmware. Thoughts on interface settings, perhaps a second button next to customize sounds?
@karrad: How about the "About Printer" submenu for the games? Seems a little more logical than "Advanced Settings"?
@marcio Checking with .108 redgum we are not homing when Z when first turning on the printer.
Apr 4 2019
Apr 2 2019
@matth ok thanks! Please reopen if you run into it again.
This hasn't been an issue for a while, whether it's printing from cura or usb stick. Can close for now.
@marcio can you please confirm if this is still an issue or if a fix was already implemented?
Apr 1 2019
Mar 29 2019
When updating Z offset via GLCD, it does not save once clicking in the button as before. Please update to automatically save settings onces this is updated.
Front right probe point does not hit flat of washer, but on the "conical" shape of the nozzle making contact with the edge of the washer. a 2mm adjustment should give plenty of room for variance.
We go from 0-100 slow, 100-200 medium, and 200-300 goes very fast. Can we reverse this order?
Mar 27 2019
It looks like this problem is known on 32-bit boards. At the moment there is a possible workaround, but not a fix.
Mar 21 2019
Mar 20 2019
Sorry for the delay. Confirmed it is fixed.
Mar 12 2019
@marcio Looks & works great! Thank you!
Mar 11 2019
@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.
Mar 8 2019
@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?
Mar 7 2019
@marcio , Merged your workaround to CuraLE master.
Mar 6 2019
Mar 4 2019
@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?
Mar 1 2019
I can confirm that problem does not occur on other versions of the firmware. 22.214.171.124, 126.96.36.199, and 188.8.131.52 do not experience this bug. All instances of 184.108.40.206 in the cabinet have been downgraded to 220.127.116.11 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.