- User Since
- Nov 28 2017, 1:11 PM (98 w, 5 d)
Nov 12 2018
@karrad -- Thank you!
Nov 2 2018
@karrad - Excellent -- thanks -- I'll stay tuned. Hopefully Cura can tolerate it, because it is a huge benefit for Octoprint users! :-)
Oct 31 2018
Feb 21 2018
Comment: As I recall, the concept of this task was to determine shrinkage for each material type, then use that with Cura's Horizontal Expansion feature -- as opposed to the old 100.5 steps that roughly approximated 0.5% shrinkage. The problem is that Cura's Horizontal Expansion feature uses an absolute mm offset, not a percentage. So for this concept to work, there needs to be a prerequisite task for CuraEngine to accept a percentage expansion parameter as opposed to (or in addition to) an absolute mm offset.
Feb 13 2018
Feb 9 2018
Ran several more prints with 22.214.171.124, have had no occurrences of G29 exiting like it did under 1.1.5. Closing this as resolved by 126.96.36.199; if it does pop up again I will reopen.
Feb 6 2018
@marcio - I have run (19) prints with a 188.8.131.52 build. No problems to report (with G29 or anything else). Will keep watching for a while, since the G29 issue was so intermittent, but it looks good so far.
Feb 5 2018
Could you see whether you can reproduce this with 184.108.40.206?
Feb 2 2018
Feb 1 2018
Ok, G29 exited without action again, and this time I had DEBUG_LEVELING enabled. I am attaching two debug output files: G29Success_Debug.txt, which captures a successful G29 sequence; and G29Skipped_Debug.txt, which captures a sequence where G29 just bails out early. (These are two prints of the same Gcode file, spooled via Octoprint.)
Jan 31 2018
Jan 2 2018
For what it is worth, I actually find that 45-115 looks more centered to me, at least on the printer I am doing my testing.
I've pushed start gcode changes. Made the adjustments you suggested.
•After a G29 (leveling active), repeated back-to-back G28's report Z=159.
•Following that with "G0 X150" and "M114" still reports Z=159.
•But after "G28 X" (to home only X), Z=158.55.
Sure seems like something odd is happening with G28 XY, like it bypassing the leveling matrix
and effectively changing Z when homing only X or Y (depending on bed level, and > where the nozzle was when the G28 was called).
@marcio - Regarding your question about wiper location... This is just aesthetic, since it is still on the pad. Not sure how many users would even notice. On the other hand, it's a pretty simple change to make it "centered" again. So very minor issue with minor effort to fix.... I would vote to fix it, but I wouldn't cry if it wasn't fixed. :-)
I have confirmed a collision is possible with current start Gcode.
One other quick observation.
Before trying the "no quickhome" firmware, I wanted to make sure I could replicate the problem with the existing firmware. With .68 firmware, I tried both the combined moves (stock cura 2.6.65 gcode) and the discrete moves I implemented. I saw no difference in skirt thickness produced -- meaning I cannot replicate the problem that caused me to open this task. I will investigate further as I don't know what else changed that would explain it. But for now, I would say not to waste any more time on this issue until/unless I can find a way to reliably reproduce it again.
My first suspicion with this problem was the initial move away from endstops -- the one after the "G28 all". At that point, all endstops are triggered -- and a combination move in XYZ is made. Of course that is before G29, which should reset any problem. But that suspicion, along with XY position problems you saw when homing XY together during G29, led me to convert all the G28's (before and after G29) and "moves away from endstops" into individual moves. The leveling problem disappeared, but I can't be sure precisely which change(s) were responsible.
Dec 30 2017
As I understand it, this plugin was temporarily disabled (removed) from the .63 build for public release. But it still appears disabled in the .64 and .65 builds (at very least, __init__.py is missing from those builds). Can it be added back into Dev builds now so further testing can be done?
Dec 29 2017
Dec 28 2017
@marcio - I pulled down your build of .68 and tested.
I will grab .68 and run some tests. THANKS!
I wondered about new beds, but assumed as long as the same thickness washer is used and is on top of the surface -- then offset should be the same.
@marcio - I tested the new macro you posted for .68 on both stock Foxglove (Y_Min at 0) and Foxglove modified with Gladiola rear Y-rod mount (Y_Min at -6). I triggered rewipes at all 4 washers, and rewipe XY positions were correct for all.
@marcio - I concur, was just about to post that I tried .67 with "do_blocking_move_to_xy(X_MIN_POS+0.1,Y_MAX_POS-0.1);" and it solved the problem for me (with no violation of endstops before the move). But that simple fix wouldn't solve the problem if endstops had actually been overshot -- because the +0.1 wouldn't be enough, for example, if coordinates were offset by 5 due to an overshoot. Hopefully your more comprehensive fix will handle both situations.
I understand the argument regarding endstops and print area. If it only impacted maximum size print models, it wouldn't be such a big deal -- but it is also affecting other areas, requiring a bunch of workarounds in gcode and firmware. Still -- I understand your reasons for not attempting to incorporate the old patch.
@karrad - This octoprint instance is based on octopi, which fixed the pyserial 250k problem about 2 years ago. That comm error has happened once (I ran several more hours and did not see it again), so may be some other anomaly. If I see any additional comm errors, I will open a separate ticket on that.
Dec 27 2017
I merged your changes and did a build of .67. I am seeing some odd behavior with "rewipe".
I was afraid that might be the case (no single set of points that work for all). Your solution is cool though! Sort of like using the problem against itself. :-)
Dec 26 2017
Using the drawings, and measuring from insert holes to the edge of the y-rod mounts: The Gladiola mount is 5.65mm shorter (i.e., 5.65mm more Y bed travel towards rear) compared to Foxglove.
Hmmm.... Yes, I think so.
@marcio -- Yep, sometimes the simple solution for today becomes the complex problem of tomorrow. :-)
Dec 23 2017
Addendum -- The above test was done with 2.6.64.
Dec 22 2017
If you take this discussion internal, I ask that you please consider the following as customer input in that discussion:
Dec 21 2017
This looks good -- however, looking at the commits, it appears it was only done for Mini with "SingleExtruder".
@marcio -- Wait, if it was a physical printer difference that needed a larger Z_max, then why did it work with older firmware? He apparently didn't have the problem with old firmware, and it has the same Z_Max.
Also noticed in customer's responses, a large negative value for Y axis position. That may be relevant. His M119 response shows Y_min is NOT triggered, but M114 shows Y=-30. That isn't happening with the stock startup gcode on my Foxglove, and would seem to indicate a previous command that attempted to go way beyond Y endstop.
I don't think this is fully resolved.
Dec 20 2017
Dec 19 2017
I think the range needs to be -1.00 to -1.48 (please see my earlier message again). A minimum of -1.30 would not be small enough for the Mini.
Currently Z-Offset is implemented only for USBPrinterDevice, get/set ZOffset functions are not simply there yet.
Another issue... Log is being filled with errors when using network printer device (i.e., Octoprint). This is partly due to the plugin trying to refresh M851 multiple times per second (mentioned as #1 above, also makes console unusable) and partly due to inability of plugin to directly communicate with the network device.
One more observation / question:
I tested this and observed the following:
Dec 18 2017
This problem is exhibited on the existing Mini as well.
My experience so far.... I eliminated the lulzbot_debug file a couple days ago, and have not experienced any problems. As Victor indicated, it actually cleans up the interface a lot -- because sub-options are collapsed when parent option isn't selected (i.e., selecting/de-selecting "Support" automatically hides/shows all the support parameters below it).
Dec 17 2017
@bigmansas - Same issue/solution described above and in T1466. The customer needs the new start gcode which follows G28 with an immediate move away from endstops in order to work properly with new firmware. Customer is using 2.6.52 which has the old start gcode.
Dec 15 2017
I was aware of the lulzbot_debug definition, but not it's history - thanks for the explanation.
Dec 14 2017
@ScottWell1: I agree that if X_MAX is triggered during G29, you may end up with a slightly negative value on
the X_MIN endstop. However, aside from shifting the print >by a bit on the build plate, it should not affect print
quality since you should go nowhere near the X_MIN once the print has started.
@marcio - Also want to mention, if G29 RIGHT exceeding X_Max endstop is a problem, then G29 LEFT may also be a problem. The LEFT probe point for G29 is X=0, which will trigger the X_Min endstop and possibly set a slightly negative X value.
marcio added a comment.Thu, Dec 14, 11:51 AM
@ScottWell1: Absolutely. I suspect that it is a manifestation of the same problem and your explanation may be spot on. One thing I don't understand is why
your printer is unable to reach X=164. I feel like perhaps Foxglove printers have less travel distance than the Gladiolas. Folks have assured me that is not the case,
but I am starting to have doubts.
If the travel distance is different, then the start GCODE would need to compensate for that somehow or there would need to be a
separate Foxglove FW with the probe points further to the left.
For the customer who sees this with 2.6.52, but doesn't see it immediately after flashing (report from @bigmansas): That sounds like T1466. Re-flashing would fix it for 1 print, just as power off/on fixes it for 1 print, because both reboot the firmware (which tosses leveling matrix). @marcio has addressed that problem with changes to start gcode, but the user with 2.6.52 would not have that fix yet.
My input -- This is not a case of a "broken" setting, but rather a setting only applicable to one printer (UM3 with Griffin firmware). It is directly tied to a Gcode feature only implemented in that firmware. It is not applicable to any Lulzbot printers -- unless/until the feature is added to RepRap (unlikely), or a manual coding approach is taken to implement it within Cura2.
Dec 12 2017
Having browsed through the CuraEngine code, I am of the opinion that "Enable Prime Blob" simply isn't working at all for Lulzbot printers. There may at times, coincidentally, be some filament spurting out when the start gcode returns 30mm of filament into the hotend, but that isn't coming from the "Enable Prime Blob" function in Cura2.
I should also mention -- I can see a blob in the "visualization" on Cura's build plate image. It appears / disappears when enabling/disabling the Blob in settings, and changes position appropriately with changes to the "Extruder Prime X Position" and "Extruder Prime Y Position". The visualization is not affected by whether Brim, Skirt, Raft, or None is selected.
Hmmmm.... I initially had this problem with 2.6.54, and still have it with 2.6.60. Both on Windows10 with Mini.
I don't see any gcode for a blob in that file, either. Start gcode returns to E0 (to compensate for E-30 retract after soften), then print starts without any Blob being created.
Still not working for me, with or without skirt/brim.
Dec 11 2017
I pulled down 2.6.60 to test this. Works great! I foresee some people questioning the "multiplier" effect -- i.e., if "Flow" is 95% and I specify "First layer flow" at 110%, I actually get something like 105% of Esteps for first layer (i.e., 110% of 95% of Esteps value). But in practice, I agree with how Victor implemented it -- because having layer 0 flow be "relative" to the standard flow, as done with M221, is the best way to do this.
Dec 8 2017
I bow to your superior diagnostic work. :-)
Just some background, since the description mentions the "tweak at z" plugin for this functionality....
That sounds great, particularly T1484. Thank you!
Dec 7 2017
As mentioned in T1466....
I tested adding "G29 J" in the Mini startup script, immediately before G28. That simulates the "old" behavior (clear matrix at G28), and allows running successive prints on 1.1.5 without issue. So that is certainly one possible approach.
I agree what happened with T1258 is the cause of what I'm seeing here. If I'm following that... You changed G28 to keep compensation matrix because you had previously added G28 to the "Pause" code, and tossing the matrix during "Pause" caused problems.
Just thinking out loud here, which may or may not be helpful....
With .57, "Create" now works -- and I can edit the "Created" material after exiting/restarting. This is good!
Dec 6 2017
I just want to mention again -- that the Material files contain other invalid temperatures -- including print temperatures that are completely unprintable (for example, 200C for ABS, Cheetah, HIPS, and NGen). This apparently happened because most the Material files were copied from a PLA file, and the print temperatures were never updated.
Dec 5 2017
The inability to edit a "created" or "duplicated" material after restarting Cura is 100% repeatable on Windows platform (I haven't tested other platforms).
@marcio: Excellent -- THANKS!
I agree that M851 Z-offset is "a characteristic of a particular printer". In theory, it should be set for a given printer and not changed unless the printer geometry changes. That is precisely the reason the additive software Z-offset in Legacy Cura was valuable, and why users are disappointed it doesn't exist in Cura2.
@marcio: I browsed the 1.6 code, and no fix there.
Dec 3 2017
@marcio - This may be helpful.
Dec 2 2017
Dec 1 2017
@marcio: Some additional testing -- I tried enabling software endstops. No luck. After power on (and after new flash, M502, M500) -- endstops don't work unless I explicitly enable them with M120.
I think this is related, so I'm adding it here instead of a new task - may need to be moved.
Yes, I will want to take a look at 3.1, at least when you get to a beta point with it.
Ahhhh..... Ok then.
Is there a way to solicit wider discussion within AO on this? Do you have some kind of internal review board or process that looks at pros/cons of feature changes to decide on direction? Any of the options have costs (except perhaps just waiting for upstream to add a feature), and will be very visible to users. It would be good to have multiple experienced folks weigh in on the design decision before choosing one.
The code you just posted is the same as before - "M109 R" before G28. ? What I propose is:
@DaniAO: Is there a reason for having "M109 R" before G28 (rather than after)?
FYI - My testing above (posted by @karrad) was on Windows platform... Might make a difference due to permissions or folder structures (or might not). :-)
Nov 30 2017
The customer request is a way to "slightly alter" Z offset of model in a given slice operation.
Also... Is your printer still using XY step of 100.5, or have you moved to 100?
It is a 1.03 Foxglove I think, s/n KT-PR0035NA-4042. No changes to X-axis of any kind, it is "stock". I have replaced the rear Y-rod holder with the Gladiola design, which lets the Bed travel back a few more millimeters, but no changes to X.
@karrad - I suspect testing has actually been with the "overridden" temperatures placed in the QUALITY profiles, not the temperatures from the MATERIAL profiles (at least for Print temp, maybe not for others). The temperatures in the MATERIAL profiles (at least in some cases) are so far off as to be unprintable, and the soften temps are way too high (causes oozing before wipe). Referring to the examples in this task -- HIPS, Cheetah, TGlase -- all have 175C as the Soften temp, and 200C as the Print temp! Better bump up the driver current if these are going to extrude at 200C. :-)
Expanding to think about all models... That 159 is obviously only for the Mini <=1.04, and with Xsteps 100.5. It could probably be pushed to 160 if Xsteps are changed to 100, as is being considered (implemented?) for Mini2.