Posts made by tommyb

Config file with M906 to and M913

M913 Output

Could it be that there is any reason to believe that the M913 output is incorrect? My x& y motors are running pretty cool even though the output shows 100%.

@Notepad Any luck in understanding this issue any better?
I basically gave up printing over this , and not just bulging corners but start/end of layer issues. And without specific notes to confirm....prior to 3.x I have beautiful prints on the same printer!
One repeated theme throughout this thread is 0.6mm nozzle with Volcano (and Hemera). This too is my setup (well was since I gave up).

It also seems PA is missing a fundamental understanding considering Vol is a ^3 function and PA has been reported as a linear response function....but since the formulas have not been posted I could be wrong here.

Jerk will always compete with PA for material flow since Jerk reduces residence time but not flow at intersecting travel events, while PA having no knowledge of reduced time intersections event, compensates for excess flow at longer residence (during decel) times and increased flow and shorter residence (during accel) times. It would be really nice if the math were shared and some sort of temporal plot created whereby using the math alone, the zones of goodness could be determined vs wasting so much plastic to try and test this. It sure seems like a mm3/mm travel could be the output and the goal is to show where variation is minimized for various combinations. Every printer is different, but the math is the math and a perfect model should be the starting point. Fudge factors such as bowden tubes stiffness factors deviates from the perfect model, whereas a direct drive might be closest to the perfect model (choose your perfect model).

I finally closed up shop when I had holes, blobs and or bulging corners but never acceptable at all three locations that I could fix. In short I wasted too much time and plastic and finally gave up and stop by here occasionally to see if there has been any new insight.

There has to be a smarter way!

@phaedrux You are brilliant. This indeed was the issue.
Thank you!

No luck finding the Solved button - please tag this as so.

Also not sure if anybody noticed, "upload" without a file name deletes files...could be noted as a bug.

@siam try 20% slower out wall, then try outer before inner. Sometimes infill does funny things when % fill artifacts show up, try no infill.
Which slicer?

@mikeabuilder Quickly check with great hope that there is a Start.g file ...and no such luck, no start file.
I have homed by ALL, by axis and by individual G28 and G30 verification...all perform normally. Z=0 in all case both actual and display.
I suppose I could try a different Z starting point prior to each of these executions...I'll report back. But as I mentioned, I removed all slicer based start codes (blank field) and even tried a lone G90 Absolute Coord in the Slicer start code. This should have forced the axis to use the previously verified Axis conditions. What happens is the DWC reports first layer height @ Z=0.3 from the existing Z height. It appears that a G92 is getting inserted before the print starts.

Is there a debug mode to see all streaming executions? That would be the most helpful right now.

@owend
Issue occurs on all print files. Here is more of the same gcode from above. I just noticed I did not include the first layer (duh).
FLAVOR:RepRap
;TIME:2401
;Filament used: 3.806m
;Layer height: 0.45
;MINX:126.636
;MINY:144.069
;MINZ:0.3
;MAXX:183.364
;MAXY:165.931
;MAXZ:58.8
;Generated with Cura_SteamEngine 4.8.0
T0
M140 S65
M104 S245
M109 S245
M82 ;absolute extrusion mode
G28 ; home

M83 ;relative extrusion mode
G1 F2100 E-0.85
;LAYER_COUNT:131
;LAYER:0
M107
G1 F1800 Z0.6
G0 F4800 X128.489 Y145.729 Z0.6
;TYPE:SKIRT
G1 F1800 Z0.3
G1 F2100 E0.89064
G1 F1800 X129.014 Y145.295 E0.05604
G1 X129.587 Y144.925 E0.05611
G1 X130.199 Y144.625 E0.05607
G1 X130.674 Y144.449 E0.04167
G1 X130.992 Y144.347 E0.02747
G1 X131.652 Y144.177 E0.05607
G1 X132.328 Y144.086 E0.05611
......finish layer 1
;MESH:NONMESH
G0 F1800 X174.765 Y152.667 Z0.75

@mikeabuilder
Thanks for the comments.
Home All, HomeZ & commands of G28 and G30 (all for good measure) result in bed being properly homed and at correct height physically and reported. I can confirm 0mm is 0m at the bed and display. The BL repeatability is 0.02mm on repeat probing.
It is only when I invoke a print job that the problem appears. The DWC will state first layer height, e.g., 0.3mm, but will be at whatever height the Z axis was at when print was initiated.
In the start code, I have tested blank, w G28, no G28 (printer is homed), added extraG90, added Mesh or removed it...basically all options. The end result is the same whereby Z axis starts print and current Z height.
Again this can be manipulated. For example, I can home axis, change Z to 20mm (or anything) and start print job. The DWC will say report first layer height @ 0.3mm but is now physically @ 20.3mm. Hope that makes sense?

I hope this is a very simple problem, but has baffled me for over a month. Using Duet V3.3 , Wifi 1.6 and DWC 3.30 and Cura 4.8.0.
Here is the problem statement, when starting a print, the z axis begins printing at whatever Z state the printer is at + first layer height and I cannot figure out why. It is as if the axis gets a G92 for Z after homing because the new Z value is at the print first layer height, but it is off the bed by Z after homing. I can manually add more Z and print again, and it will start at that new Z +first layer height. Mesh is confirmed invoked.

Homing of all axis are very robust. Confirming with command line M28, G30, or stepping to Z=0 and consistently confirms Z=0.
I then tried putting G90 in the start code to make sure an errant G91 was floating around and finally gave up. Please help me figure this out.
Also here is a snapshot of the G code.
;Generated with Cura_SteamEngine 4.8.0
T0
M140 S65
M104 S245
M109 S245
M82 ;absolute extrusion mode
G28 ; home
;G29 S1 ;Load Mesh
G90 ; Absolute Positioning
G1 E1 F300 ;Extrude 1mm
M83 ;relative extrusion mode
G1 F2100 E-0.85
;LAYER_COUNT:121
;LAYER:0
M107
G1 F1800 Z0.6
G0 F4800 X105.874 Y105.579 Z0.6
;TYPE:SKIRT

BTW - the forum posting guide says to use "Up Arrow" to upload file..Forum does not have this feature. I was looking to get copies of my files to share here and wondered if there was a neat feature option to group files from DWC and poked atthat, but saw no path. I intended to hit "cancel", but hit "open" instead without any filename (empty) and poof, my config.g file has vaporized. I searched high and low for any file created in the last 24 hours. This is kind of a cruddy software bug. My Config.backup is shared here, but is a few days old...not sure what state that was in. homez.g homeall.g heightmap.csv bed.g config (2).g

@janjoh I would guess the corner mount like will have it's own artifacts. It may or may not matter, but looks like a spring board and will certainly have a dominant frequency related to the mounting alone. Simply test on a nice solid block of Al or something by mounting in the same fashion and give it a few taps in x, y, z directions and see what you get.

It seems many have had recent trouble getting the latest shipped Wyze V2 variant to allow any mods to work, but it still can be done. The key is that the expected documented Dafang Hack response or even native Firmware updates are different than previously reported.
Upon loading the initial demo.bin boot loader file, the camera seems to lock up with blinking yellow light and never seems to properly finish the firmware upload. The same is true when subsequently adding the Hack Mod directory as the camera basically seemed to no longer load firmware. However after several hours of random SD card write protect events and fiddling at other load sequences attempts and downgrading, etc., I noticed that my router had already connected the camera many hours before. I then simply had to login with ID and PW via Firefox at a new Tab URl and the cam is now able and present anytime I launch DWC Cam tab.
Pretty happy overall and glad to get rid of handicapped Android phone approach.

@engikeneer
Ah - that is a really good solution....thank you for the recommendation. I should have tested this before posting.

As for for Resetting with persistent settings, it is true there could be issues, but the point is that in a known state, it could be an option to hold all attributes on restart. And that would be up to the user to decide. It is always true for any over-ride situation, such as ignore over-travel limits, it could be bad, but when needed, it is a very useful option.

Ver 3.2
After reset (config.g save or M999), heater and Homing functions spin if selected until the HE temp drops below 50C. Everything kicks in around 50C and functions normally.
A work around is to set both HE temp and Bed Temp to desired value first and then activate each heater. The normal use case is when Z Zero is adjusted in Config.g file at steady state temps.
Separately, it would be nice to be able to save conditions before a reset and auto load the current settings on a reset.
Is this normal and is this workaround intentional and why? Just trying to understand the logic.

@Phaedrux
Retried with close attention to all details...no luck. But I did notice that the L1 inductor on the flex PCBA going to the screen was smashed...either blown up (not likely) or just mechanically smashed. Do you know what the value of that is? I looked on the LCDPANEL website and the schematics in GITHUB but this was not detailed anywhere. I should replace that first and then try to troubleshoot from there.
Ill be back!
Thanks again.

Thank you Phaedrux for the quick reply.
I both feel a little foolish for picking the wrong file and hopeful that this would work.
It did not.
Backlight still stays on after erase, flash, reset and power cycle and still no image. The firmware flashed fine with the new .bin and was verified and the check boxes were set so that micro seems to be fine and it is something beyond the micro to the LCD.
Any other thoughts on testing signals/voltages, connectors? The wiki states that hitting reset should turn the backlight off and that does not happen...is this a clue?

Finally unboxed a 7i purchased some time ago from Filastruder. It is a fully integrated version, and beleive silkscreen says V2.0 . I need help in troubleshooting a seemingly failed LCD screen or driver. Sadly this has never been used.

History
Backlight light is on when powered up either from USB or from 4 wire DuetWiFI. It does not turn off with reset test nor after erase and reset. No image is seen. Reset does cause BL to briefly flash off then back on.

Firmware was erased and upgraded to latest V3 7.0 No Logo using Bossa. Connected fine, flashed and then "verified" flash was ok. Erase All, Lock, and Boot from Flash were all checked on interface.
After reset and power off the backlight remains on and no other image or details are displayed just like before. And hitting reset does not turn off backlight but does cause it to momentarily turn off then back on.

Please suggest some troubleshooting next steps if you can think of any.

Thank you

@dc42
My motors spin. I am on Duet2 Wifi

Almost always throws the same error during home with G28 .

Printing has been mostly successful even with error thrown, but occasional print fails right after fault. Today I lost two prints after this error and a third 200 layer print had no issue (with a few of these errors).

The cable has been changed (shielded), connector crimps have been soldered and now debating a motor change until I saw these posts. Im waiting to change motor based on outcome of this thread.

Thank you Veti, yes I added a C and here is my HE config.
M308 S1 P"e0temp" Y"thermistor" T100000 B4725 C7.06e-8 ; RR3define E0 temperature sensor was B4138
M950 H1 C"e0heat" T1 ; heater 1 uses the e0heat pin and sensor 1
M570 H1 P90 T15 ; Heater@1 temp@15 out of range alarm >@90sec
M143 H1 S245 ; set temperature limit for heater 1 to 250C

The M was only missing in the cut and paste, not the actual Config.g. Thanks for checking.

I have a V6 Light HE...if anybody has experience to move on from this, let me know. I need a reason to convince the wife to spend any more $ on this sport. The Heat break is SST and not easily damaged...and cheap! So far PETG and PLA seem to work fine, but I am happy to be convinced of other models (Humera)?.

So after have a sudden bed thermistor open error (did not touch any wiring) and some more time troubleshooting and fixing, I looked hru various references with conflicting info and confirmed B=4275 for the Simtec 104 GT thermistor. HE and Bed have been Auto recalibrated.

PA so far seems about the same from 0.05, 0.10, 0.15, 0.20 and no change vs first picture.

No for twhe real problem all along. With a pretty decent print in progress, the part fails each and every time at layer 26/88 at the exact same spot in the print and with sound of skipping stepper . The part shifts the exact same 10mm of the 20mm block wall distance and prints a wall in the very middle of the part. All motors are cool and there is nothing unique in the print at this point.

I started to look at the G code to see if it is somehow corrupted at that point, but is getting late. Ill also try a slower print to see if motor just needs a different input that instant. More to come.

@Veti said in More Blobbing:

semitec in the duet configurato

I missed the B factor comment above. The configurator still produced a B=4138 value. I look around and saw Duet requires B=4388, tried that and way under temp on print. I will let it cool down and execute a calibration. The stability looked ok.

I may have an odd thermistor, is there a way to tell? It came with the Hot End.

Also dug a little deeper on circumferential blob and turns out Cura places a small extrusion path at the start of the layer right at the end of the path. And then follows up with at the end of the layer to join with the initial small path. This image show the HE after rotating clockwise past the initial extrude.

Thanks for the tip.