Topics created by zBeeble

@zBeeble Hello, I have a fix that I need to get put into place in DWC that will address this issue.

I delivered m111 p1 s1, and this is the changed repeating output:

WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns 1ResponseTimeout, pending=1 WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Con^?/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578 ): refused conn on port 80 already 4 conns ResponseTimeout, pending=1 WiFi: /hom^?s/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns ResponseTimeout, pending=1 ResponseTimeout, pending=1 ResponseTimeout, pending=1 Debugging enabled for modules: Network(1 - 0xffffffff) WiFi(14 - 0xffffffff) Debugging disabled for modules: Platform(0) Webserver(2) Gcodes(3) Move(4) Heat(5) Kinematics(6) InputShaping(7) unused(8) Print Monitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) Display(15) SbcInterface(16) CAN(17) Expansion(18) ResponseTimeout, pending=1 Bad recv status size ResponseTimeout, pending=1 Bad recv status size ResponseTimeout, pending=1 Bad recv status size ResponseTimeout, pending=1 Bad recv status size ResponseTimeout, pending=1 Bad recv status size WiFi: /home/renz/Projec^?/home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns ResponseTimeout, pending=1 Bad recv status size WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns ResponseTimeout, pending=1 Bad recv status size WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns ResponseTimeout, pending=1 Bad recv status size WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns ResponseTimeout, pending=1 Bad recv status size WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns ResponseTimeout, pending=1 Bad recv status size WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Con^?uet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns ResponseTimeout, pending=1 Bad recv status size WiFi: /home/renz/Projects/^?t 80 already 4 conns ResponseTimeout, pending=1 Bad recv status size WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on po^?/Connection.cpp(578): refused conn on port 80 already 4 conns ResponseTimeout, pending=1 Bad recv status size ResponseTimeout, pending=1 Bad recv status size

@zBeeble If you're needing to figure something out either way, and just wanting to handle printer pausing during print, probably best to use the active and standby approach suggested using M568, but if you were already using variables or have another use case this is an alternative.

See https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands#variables

RRF has variables you can write to and then refer to in gcode by putting the name inside {these}. It also has local variables that stay inside one gcode file, useful for loops and things.

You could have in config.g something to create an empty variable:

if !exists(global.nozt) global nozt = -1

Which creates a global if it doesn't already exist.

Then in your pause.g have something like

set global.nozt = heat.heaters[1].active

before you switch off the tool heater (or switch it to standby) (this assuming your nozzle in the tool is heater 1). Then any subsequent code can know what the temperature had been (by referring to global.nozt) e.g. with G10 P0 S{global.nozt} to switch back on with taht setpoint.

The advantage this has is if you are doing other things with the temperature besides just standby and resume. I have some physical buttons on my printer which heat and feed filament (mainly when doing a manual colour change and flushing some through), so I want the printer to know the extrusion temperature of the filament currently loaded easily, so I write that into a global variable and use it both when resuming after pausing and when heating the tool (potentially from fully cold) to feed some filament.

@gloomyandy had the right pick. Changing Cura's notion of the wipe position to x=230 makes it go back and forth between 230 and 250 --- which is what is desired. Documentation is a bit of a problem for Cura ... welll ... that and complexity.

Thanks ...

@zBeeble said in Clarifying BigTree Filament Sensor Connection.:

@stuartofmt This, based on the filament position w.r.t. the header, agrees with what I have been referencing.

If I had V and GND swapped, would that kill the BigTree? What do you guys who understand the circuit diagram expect?

I did also try the e1stop --- no change there.

15 seconds into the video. Maybe.

@jay_s_uk I have to say, my mind is kinda blown on what this can do. I suppose I'm off on this rabbit hole today.

@dc42 we can always add it in the setting->general along with other UI settings that are already there. Right now, as its hidden, it causes confusion as the feature of hiding it is unknown.

@droftarts thank-you, but ... it's a pretty obvious thing to include in the web control thing --- which is where I posted this.

@zBeeble So... after some time, I finally did run out of filament, and that, then, verified both branches ... "This works" ...

@zBeeble the issue only happens when you reload the web interface. If you use M291 to display a harmless message such as "Printing resumed" in your resume.g file then I think that will replace the filament error message.

@zbeeble One other thing. If you can, use aluminium motor mounts bolted to the frame. You'll find (as I did) that the alumium conducts the heat away from motor - the mount and frame act as a giant heat sink. My 2.3A NEMA 23s and 1.8A NEMA 17s barely get much above ambient even after several hours of throwing 3Kgs of mass around at high speed.

Thank-you for your patience. I believe I have resolved the issue... with a combination of your thoughts and my experimentation (as it should be). For posterity, here's wazzup.

BACKGROUND

The printer in question was built (originally) mid-2014 ... and with Chinese electronics. It was noisy and it ran hot. It's largely a Mendel from reprap.org ... combining some of the Prussia Mendel with some ideas from the Reprap-Pro Mendel and some custom changes suggested by the helpful fellow who printed the initial printed pieces for me (among them, a fine herringbone main gear set).

This I upgraded ~2016 or so --- the duet2wifi was a "new thing" when I did this, if that helps nail down the timeframe. I swapped the Chinese electronics for the duet2wifi, I added a heated and magnetic bed and I made minor improvements in the geometry.

This printer eventually choked on some filament and I didn't get around to fixing it until just recently. I have been collecting supplies to make something with the e3d tool changer (but different), but I haven't started assembly yet.

THIS ITERATION

So I started this iteration to improve a few things... one of the most major: add a BLTouch to the system. I ended up learning first that I had some really sub-optimal motors in play --- that only took 0.4A of max current (for X, Y and E0). I replaced these with 1.5A motors. Seriously, the documentation about selecting motors is good (although I found utube about parallel and serial that seemed to explain that better) ... but I'm relatively sure it wasn't available when I first did this.

After the upgrades, I found the print occasionally getting out of square. The pair of Z-axis motors were 2.4A beasts --- and so I hadn't replaced them in the first go round, but motors are pretty cheap ... so I ordered some more of the 1.5A ones. Then my Z-Axis problems got worse.

THE SCALE PROBLEM

So... here-we-are. The problem. Have you guessed yet? I think Phaedrux was dancing around it above. The original pair of Z-Axis motors were 0.9 degree motors. It would seem it is much harder to drive these fast. This is why the motor multiplier was 5104. I discovered this because after configuring my new motors to move more slowly, my "test cube" was 20x20x40 (and having trouble with layer adhesion).

Of course lightbulbs immediately lit (I didn't actually finish printing the cube --- I got to around 50% --- where it was 20cm-ish high ... and noted that it was only 50% finished and stopped the print). I cleared the bed and reached for the caliper --- 10 cm of commanded movement ... 20 cm of actual movement. Hrmmm.

This is the point I realized the situation. So I changed the multiplier to 2552 and adjusted the speed of that axis to 300mm/min (150 was working for the old config, so it made sense. 180 wasn't). I re-printed my test-cube. (If anyone's curious, with a nod to Star Trek's "Transport Test Cube", I have a 20mm cube that I use for testing the printer).

@chrishamm Thanks for letting me know --- that it's not just some faulty memory of mine.

I thought it might help to post my m92 line.

M92 X100.00 Y100.00 Z5104.00 E666.00

... which all comes from measured movement.

@zbeeble said in BL "not" touching...:

My homez.g:
G91 ; relative positioning G1 H2 Z5 F6000 ; lift Z relative to current position G1 H1 Z-205 F1800 ; move Z down until the endstop is triggered G92 Z0 ; set Z position to axis minimum (you may want to adjust this)

This is the problem.

Remove this

G1 H1 Z-205 F1800 ; move Z down until the endstop is triggered G92 Z0 ; set Z position to axis minimum (you may want to adjust this)

And replace it with this

G1 X150 Y150 F6000 G30

This would be the same for the homeall.g file if it also has a z homing section.

Alter the X150 Y150 to position the probe wherever you want to set Z0. Usually the center of the bed.

But just to be safe, you should go through this to make sure the probe works in a controlled test first.

https://docs.duet3d.com/en/User_manual/Connecting_hardware/Z_probe_testing

@zapta said in Opinions on "FYSETC" ... politely, please.:

@notepad the examples above are of a 6HC. You dispute it using an older WI FI 2. 🙂

trying to have a honest discussion of the morality of these clone whores and the users hellbent on saving $35 at the cost of the originating ecosystem is futile. They will justify their savings with 500 differing variants of logic... all while knowing they are screwing the people who brought this whole thing to the forefront. Its sad.

Whats funny tho is listening to how theyve justified the cost savings in their minds with "How theyre actually improving the whole thing" with "competition" and "options" - utterly laughable.

@dc42 Thanks. Sigh. But you see. deminimis (the amount at which you pay duty) is $20 Canadian. This is about $18 USD. I will be charged $20 for the privilege of duty being figured out by the post. so I will pay $20 USD for the item, $21 USD for the tax, $20 CAD for duty and $3 CAD (roughly) for tax.

... so in CAD, that's 24 + 25 + 20 + 3 = $72

... and the Canadian retailer is selling some seemingly authentic (not the Israeli company) 7i panels (a slight upgrade) for about the same money ... and I get it in a day or two. and I can still think about repairing this panel some day, if that possibility appears.

@zbeeble

The simplest way to go is to do a full erase and install new firmware from scratch. I have a video for that here:
Ugrade RRF