Actually from hibiscus 9:
Sorry I didn't look at the last one before I posted it, so you can ignore the last post.
From Hibiscus 9:
From hibiscus 7:
@marcio this is from hibiscus 19.
added M75 and M77 to hibiscus start and end gcode here: d99b49f74292
Tue, Apr 24
So far we have had production set aside about 8 printers that were having uneven skirt measurements. This seems to be our main issue currently with calibration.
Doing some digging here, going to drop what I find for you @marcio Not sure if it is helpful or not, but recent marlin g29 issues posts.
Does the auto-leveling utilize different step values when applying the bed leveling matrix vs those used in other print/travel moves?
Initial tests with m126.96.36.199 and c3.2.19 (with start gcode modifications) successful. Print timer starts at first print, and stops once bed moves forward. it never clears.
@marcio Good call, announcement went out today! Mini 2 FW offset, closing out!
@karrad suggested I rack the axis to accentuate movements of the Z-Motors during first layer. While they ARE moving, they are NOT moving enough. Not close, really.
Watching the motors during the first layer, to me it looks like the same amount of motion you'd see if that motor was attached to drive rods (which it shouldn't be) very slight movements. Does the auto-leveling utilize different step values when applying the bed leveling matrix vs those used in other print/travel moves?
Something is causing the auto-leveling process to not function as it should, just trying to narrow it down.
@karrad: It looks like I didn't really disable the autostart in .33, but it is disabled in .34.
@logan: Sorry, when I said .33, I meant .34.
@karrad: In .34, the default Z-offset for Hibiscus (can we call it Mini 2 yet?) is -1.1
@marcio Just to verify, the M75 should go before anything else in start gcode, and the M77 should be at the end of the gcode after bed moving forward?
@marcio Sorry I think we were both typing replies at the same time, that first question can be ignored. I will wait for the fix and see if it has any affect on my issues, only thing I really can do. At this point I have eliminated hardware/mechanics as the root of the issue. The auto bed leveling should be able to compensate, but it simply isn't.
@marcio Could this cause the first layer issues I was seeing? If the machine isn't getting a bed leveling matrix, (only guessing because it wont report one) it would just run the first layer flat? or how does Marlin handle a situation where bed leveling is turned on but it has no bed matrix data?
@logan: The reason you were not getting bed probe data (and why your printer was crashing with G29 V4) was actually a serious bug that I wouldn't have caught otherwise. So thank you for reporting this. Thinkyhead (lead Marlin devel) had informed me of a possibility of arguments to G29 causing problems with my new rewipe code, but the fix that he had suggested itself had an issue. I will fix this in .33 as well as push a fix upstream.
@tutley Correction; when not homed first, G29 automatically levels, wipes, and then probes. If already homed it will go straight to probing
@tutley Ok. I tried with 188.8.131.52 also, same result. G29 V4 and G29 perform the same moves. Only difference is that G29 doesn't reboot the machine when it finishes, neither report the bed leveling matrix.
@logan im putting 184.108.40.206 on my machine now and going to try a g29 v4
@tutley Wanna come watch? Its definitely not treating it like a probe fail
@logan the G29 V4 should not enter the leveling and wipe sequence. That means the printer thinks it had a probe fail and is trying to relevel, rewipe, and reprobe.
Mon, Apr 23
It's current, newest firmware in our public version of Cura 2 is 220.127.116.11 (I think I and the forum user left off the 1).
To me it seems like the best solution, but that is only from my perspective. It would seem easier to me to instruct those who may run into that issue to update to the latest Cura.
@logan: Yes. I suppose this would be less hacky. This would mean that the timer would not start if the newer FW was used on older versions of Cura. If we are okay with that, then yes, it may be the best solution.
I am willing to test any of the gcode changes before implementing into Cura, but we will need to change each machine. @marcio Can you post the Hibiscus start/end as an example?
or would that need applied to all machine's start/end gcode in order for the timer to function properly?
@marcio From above:
It looks like the threshold between what Marlin considers to be low vs high temp is EXTRUDE_MINTEMP/2. Since we set EXTRUDE_MINTEMP to 120, this means that we could lower to nozzle temp to 65 in the end gcode without interruption of the timer. We could then wait for the part to cool, and at the very end set the hot end to 0. This would stop the timer.
@marcio No changes to end gcode have been made, what is your suggestion?
@karrad: Were the end GCODEs for Cura modified as I suggested? I guess what I am saying is that this is not a Marlin issue.
@marcio I have no hibiscus at the moment to test this. After a print is complete, does the timer on the LCD reset once bed is moved forward?
@karrad: Can this ticket be closed?
@bigmansas: I put in a correction in Marlin 18.104.22.168, could you give that version a try and see if it resolves the issue?
It's hard to say. That's ridiculously old FW. I would recommend upgrading to the version of FW in Cura 2.
Fri, Apr 20
@logan Yeah that is a good idea. The good thing is that we have instructions to note down the offset here: https://www.lulzbot.com/learn/tutorials/firmware-flashing-through-cura for the Taz, we would just want to update the steps to match the Mini LCD menu.
The default will almost never be correct, I'd rather have them adjust until it sticks than damage the bed first try.
For documentation sake, have the user record the offset prior to flashing = no issue setting offset after flash
This had been requested on production runs in the past but, I recommend that we set the default above the average to prevent users from crashing into the bed first attempt. So if average comes up -1.00, we should be setting -0.9