Posts made by skrotz

@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.

@dc42 I did a quick print with this latest firmware (PA 0.12, ei2 input shaping enabled as per usual) and can't say I see a significant difference between this firmware and the previous one on my print, although I'd swear that the previous one still had a tiny bit of "clunkiness" and this one seemed completely normal with no hint of a clunk whatsoever. No hiccups or errors in the M122 report. Like the just previous firmware, I don't see extrusion blobs or zits like were happening before -- I'll need to do some comparison prints with RRF 3.3 and this firmware to see if the minor extrusion issues I feel are present are different from RRF 3.3 or not. All in all, great progress though, and certainly seems ready for more people to start doing prints and comparisons with RRF 3.3 and testing input shaping. Very exciting.

RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta2-inputshaping (2021-08-02 19:33:23) running on Duet WiFi 1.02 or later + DueX5

UPDATE: I did a baseline print with RRF 3.3 to compare with (DAA enabled at 41hz, PA 0.12), and the minor extrusion issues I was seeing in the latest 3.4 print are there as well in the 3.3 print.. it seems like something that could be improved on but it's not introduced by 3.4. So this latest 3.4 seems quite good to go.

@dc42 The print was with input shaping enabled:

M593 P"ei2" F41 S0.10

I'll try and do some more prints with input shaping and PA disabled in various combinations and see how they compare.

To my eye, the width of the X and Y changing seems likely to be due to input shaping.. not necessarily bugs, but just artifacts of the movement changes happening with ei2 input shaping on. The lines that look slightly misaligned or over extruded after the X feel more like a bug that is still rattling around. More prints with various knobs on and off should help identify that potentially.

@dc42 Happy to report significant improvement with this build printing with PA enabled and ei2 input shaping on. As mentioned clunking is greatly improved, and the print quality is significantly better. No major extrusion issues or jaggedness. There are a few layers, for example on the right side of the X (notably near the middle of it) on the calibration cube that seem slightly misaligned or overextruded, and are noticeably different from a 3.3 print. I do also notice that the X and Y of the calibration cube seem noticeably wider than previous prints. I suspect though that these issues are getting into the nitty gritty of input shaping, and away from the egregious bugs I was seeing, which seem fixed so far with this build.

I will try and do some more test prints today with various things enabled/disabled to gather more data for you. Many thanks for the rapid fixes!

oh and M122 reports no hiccups or errors on this print:

=== Move ===
DMs created 83, segments created 35, maxWait 54915ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 11545, completed moves 11545, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1

RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta2-inputshaping (2021-08-02 17:37:04) running on Duet WiFi 1.02 or later + DueX5

@dc42 just starting a print but definite improvement so far. Clunkiness is at least greatly reduced, if not gone. Will see how the print looks in a bit. Sounds much more normal.

@dc42 Yes with input shaping disabled but PA enabled I am getting the clunking noises, different from RRF 3.3.

@dc42 seems like same results on this firmware for me. Clunking sounds, and extrusion issues/jagginess on a calibration cube print with PA and input shaping (ei2). my PA is at 0.12.

sorry in previous posts I've been putting my input shaping as ei3, I meant ei2. It's been ei2 not ei3.

=== Move ===
DMs created 83, segments created 35, maxWait 23643ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 11545, completed moves 11545, hiccups 3024, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1

RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta2-inputshaping (2021-08-01 21:19:05) running on Duet WiFi 1.02 or later + DueX5

seems like the number of hiccups actually went up with this firmware.

@dc42 Sorry to always be the bearer of bad news but no real difference with this firmware from what I can tell, still hearing clunking noises and still extrusion issues and jagginess on the print with PA enabled and EI3 input shaping enabled. I will try and do a test with input shaping disabled soon.

UPDATE: started a print with input shaping disabled, and was getting the clunking, maybe even worse than with input shaping on. Disabled PA and things quieted back to normal. I then turned on input shaping back on (with PA disabled) and it still sounds normal, no clunking. so PA in general seems to be the cause of the clunking. I'll see if I'm still having extrusion blobs/zits with PA disabled but input shaping on.

UPDATE 2: still seeing the same extrusion blobs with PA off and input shaping (ei3) enabled.

stats below are from the print with both PA and input shaping enabled:
=== Move ===
DMs created 83, segments created 35, maxWait 39679ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 11545, completed moves 11545, hiccups 2744, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1

RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta2-inputshaping (2021-08-01 00:01:15) running on Duet WiFi 1.02 or later + DueX5

@dc42 with this latest firmware I also did not see much difference. with PA enabled I still had extruder clunking and issues with over/under extrusion and jaggedness on some layers, especially where the head was moving to print the X and Y of the calibration cube. M122 reports no step errors but lots of hiccups:

=== Move ===
DMs created 83, segments created 35, maxWait 57566ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 11545, completed moves 11545, hiccups 2766, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1

RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta2-inputshaping (2021-07-31 22:03:00) running on Duet WiFi 1.02 or later + DueX5

Input shaping 'ei2' at 41.0Hz damping factor 0.10, min. acceleration 10.0, impulses 0.259 0.619 0.892 with durations (ms) 12.65 12.07 11.78
572
Extruder pressure advance: 0.120, 0.000, 0.000, 0.000

@dc42 any new firmwares to test!? I’m able to do testing more easily on the weekends…

@dc42 I think the breakdown so far for 7-28 3.4 build is:

With No PA and no input shaping, things look normal. No extrusion blobs or zits. Corners bulge a bit due to no PA as one would expect. (Just did this print). Things look identical to RRF 3.3.

With no PA, but EI3 input shaping enabled, I get no clunking or hiccups/errors, but I do get some small occasional extrusion zits/blobs, in the same place each print. Corners bulge a bit more than the print with no PA and no input shaping - probably an artifact from the ei3 input shaping?

With PA at 0.12 and no input shaping, I am getting the clunking noise, usually when printing the gyroid infill. I do not get this clunking with 3.3, it is abnormal. The print has extrusion issues.. lines where the head is moving to print the X or the Y of the cube seem to be over extruded at times, some maybe under extruded. Parts of the X look a bit jagged. (just did this print). M122 reports 2679 hiccups but no errors for MainDDARing move stats.

I assume with PA and EI3 input shaping, I'll get clunking plus the layer shift others are reporting, but I haven't done that print yet on 7-28 3.4.