@bot The follow up video is now available

https://www.youtube.com/watch?v=32dTLRNIYmw

@dc42 Can confirm some weirdness. Was running RRF 3.3 release, uploaded new 3.4 combined firmware to duet2 wifi on a Railcore 300ZL. It reset itself after upload and homing and movement seemed ok, but when actually trying to print it seemed to stall or something, with occasional random movements.

I powered off and on and disabled all input shaping (it still had DAA enabled from my default setup, at 40hz). Was able to print a calibration cube after that, don't know if it was disabling the input shaping that did it or the power cycle. However, when printing the gyroid infill it would make a weird clunking noise that I couldn't identify where/what was happening exactly. Cube printed roughly ok however, but somewhat under extruded so maybe it was extruder motor making the clunking.

Just to be sure, I went back to R3.3 stock and things seem to be printing ok again, no clunk noises, on same exact gcode, so definitely looks like it was 3.4 causing some strangeness.

update: R3.3 calibration cube printed normally, and didn't have any underextrusion issues (or at least, something that looked like underextrusion).

@nuroo FYI the calculator has been updated to include a reprap compatible M556 command for skew adjustment and it seems to work.

@dc42 Tried the new firmware, did a full power cycle after installing just in case. Had same clunking noise on printing a calibration cube on the infill. I discovered disabling pressure advance caused it to stop clunking.

Normally I have S 0.12 for PA, with a little experimentation anything at 0.4 or above (ish) seems to cause the clunking noise. If there's specific debug that would help with this, I can try and gather it.

@dc42
M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.4.0beta2-inputshaping ELECTRONICS: Duet WiFi 1.02 or later + DueX5 FIRMWARE_DATE: 2021-07-25 09:41:53

Will try and capture step error data now.

@NeoDue I was seeing major layer shifting on 3.5.0-rc2, like an inch or two at a certain height consistently on a certain print I was doing. Going back to 3.4.6 resolved the issue. Seems like there are still some major kinks to work out in rc2. This was on a railcore II with a duet2 wifi and duex.

@dc42 If there's a code bug it's probably not duex specific, I have the same issue when running the strip from the duet2 wifi.

@dc42 Thanks for the response.. I tried hooking the strip up to duex pwm 1 and it does work, but has the same issue with the first led always being on full green.

To be specific, I hooked up 5v for the led strip to duex pwm1 5v aux, led strip gnd to pwm1 gnd, and the led control line to e2_pwm. Used

M950 E0 C"duex.pwm1" T1 U13

to define the lights. I'm happy it actually worked as my other attempts using something other than conn_lcd ports all failed, but same behavior and seems like if everything is properly 5v this should work, based on my Arduino tests with the strip. Only other thing I can think of is the Q frequency and playing with that, but I did a little previously and it didn't seem to yield any positive changes, but I'll try a bit more on this current setup as it seems most correct. I suppose it could be interference, I might try making a better and shorter cable for things, but the same cabling setup works on the Arduino tests. Seems a little too reliable in how it goes wrong to be interference.

I assume the first led on the strip is probably the last data sent and the closing data, so it seems like it could be a bug with ending of the data send to the strip, if there was a software bug causing this. Makes my software engineer spidey sense tingle.

I have some alitove 5v ws2812b led strips I am experimenting with on my railcore (has duet2 wifi and duex 5, 3.5b4). These strips seem to work ok using 3.3v to control (maybe?) as I can get a small 13 led strip to work when using the following setup:

M950 E0 C"connlcd.5" T1 U13

when hooking up the control line to connlcd.5, and the power of the strip either to 3.3v or 5v (both get same results). However, the first led always has green full on whenever I command anything (even all off), but otherwise all other leds on the strip works fine and do as commanded (and the R and B components of the first led control fine also, it just always has full G on).. I was trying to find a 5v pin I could use to see if it was a 3.3v/5v issue on the control line, like pson or duex.gp1, but those don't seem to work at all (and I'm not sure if they really are 5v or if they should be expected to work with led strips.. nothing happens at all when using them but I don't get any errors on the M950 command setting things up using them) .

My question is, in my setup is there a pin I can use that should be 5v, either on the duet2 wifi or the duex5, to control the strip?

Also.. it kind of just feels like a general bug that the first led doesn't command properly, as everything else seems ok at 3.3v... the specs I can find for my strip seems to indicate it should run ok at 3.3v for power and control, and it basically does except for that pesky first led. I can hook this strip up to an arduino and the first led (and others on the strip) works fine and does as commanded, either at 3.3v or 5v for power, however of course the arduino control line would be at 5v I think. At least I know it's not a hardware issue with the first led, though, as it commands fine on that setup.

Any help is appreciated.

I'm seeing a similar issue, I do see icons for some things, but it is hit or miss. As an example I have two gcode files, both recently generated by Cura 5.2.1, and I have the latest 3.4.1 paneldue firmware... on both files it shows the icon in the DWC web interface, but only one of the files shows an icon on the panel due. Both have the line "Generated with Cura_SteamEngine 5.2.1" at the end of the thumbnail data in the gcode, but only one of them shows "Cura SteamEngine 5.2.1" in the "generated by" column in the DWC web interface. The thumbnail data in both looks correct to my eye, nothing looks out of sorts in either one. I don't see any correlation between files that properly show "generated in Cura" and files that do or don't show an icon on the paneldue. Seems like there is a subtle bug in the metadata creation and/or parsing.

I have the latest RRF cura plugin installed.

@skrotz They were sadistic. Black = 24v, Dark grey = ground, light grey = tach, and white = pwm control. PWM needs to be inverted. Hooking up 24v and ground to an always on fan port and control to fan2 ground works fine. It puts out a ton of air, but the shroud spreads it out less than I expected.

I haven't confirmed tach as working but seems likely it would, although I'm not sure it's useful.

@elmoret Well I mean thirty bucks for something that's basically plug and play if you can make the plug isn't crazy town. I spent a lot more on the railcore kit

Anyway I found this documentation for anyone else wanting to experiment with this:

https://railcore.org/customization/12v_fans.html

I'm guessing, unless bambu was particularly sadistic with their choice of wire colors, that I hook up the white wire to 24v, black to ground, and then dealers choice on which of the grey wires is speed control and tachometer. Seems like I hook the speed control to a fan0/fan1/fan2 ground port and set frequency to 25k to control it.

When I get the chance to rig up some connections I'll post what I find or what blows up for future reference.

I was hoping I could get some advice on this.. I bought the large part cooling fan that is mounted on the side of the bambu x1 and was going to try and use it on my railcore 300zl. I have a standard setup with a duet2 wifi and the duet5x expansion board. 24v power supply.

The fan itself has a 4-pin jst (I think?) connector with black, dark gray light gray, and white wires. It has a sticker stating it's a 24v 0.5a fan. It has a model number but google searches didn't yield much info so far. I'm sure it's variable speed.

So, what would be the best way to connect this on my setup? Seems like these fans would be an easy way for lots of different printers to add extra part cooling, as they are cheap and come in a pretty good form factor with double sided tape already on and everything ready to go.

@nuroo FYI the calculator has been updated to include a reprap compatible M556 command for skew adjustment and it seems to work.

With the latest 3.4 beta 2, doing some experiments with input shaping I still think I'm seeing some extrusion weirdness that was happening with the "alpha" releases put out previously. Here's an example pic:

Left cube is a print from 3.3 with DAA on. Right cube is 3.4 beta 2 with ei3 input shaping on, F44 S0.05. Below is a pic that highlights what looks like small over extrusions to me, where things are definitely not as clean and smooth as with 3.3:

These are repeatable, so it's not a filament issue, happens in the same place each print. I just did a print on 3.4 with input shaping off and confirmed those blips aren't present, the print looked like the 3.3 print.