Posts made by deckingman

@leone On the video you posted, it looks to me like the extruder is trying to run very much faster than 100mm/minute. My best guess is that either you miss typed the feedrate or you have the steps per wildly out. Posting your config.g as well some information about the extruder and motor would be helpful.

Sadly I learn that 3DFilaprint have ceased trading.
For me, it's the end of a long standing relationship. They used to offer an excellent fast and efficient service, and stocked just about every filament type from every manufacturer. So I need to find another UK based supplier but search results show a myriad of options. Therefore I'd like to know if anyone on these forums has any recommendations (good or bad).

@R006 If you get a warning that a heater could potentially reach a dangerous temperature, then the safest way to address this is to use a less powerful heater. Then if say a MOSFET failed, the heater would get hot, but not dangerously so.

@Derek-F You'll need to redo all your homing files. The origin is now set as the centre of the bed so if you want to probe the bed in the centre, you'll need move the print head to X=0 Y =0. i.e this line "G1 X200 Y200 F6000 ; go to first probe point" needs to be changed to "G1 X0 Y0 F6000 ; go to first probe point

Note that the position of the end stops can stay the same. Note also that any files you previously sliced with the origin set to one corner of the bed will need to be re-sliced because they will contain moves in the range zero to circa 400 whereas with the origin in the slicer set to the centre, the moves need to be in te range minus circa 200 to plus circa 200.

Edit posted while DC was typing. also, it appears my PC has the wrong time set.

@Derek-F

1. M500 stores parameters and should never appear in config.g. M501 reads parameters. If you use config-override.g then it needs to be present at the end of config.g. If you don't use config-override.g then don't use M501.
2. Only config.g and config-override.g if it's present.
3. Something isn't right. The config.g you posted shows M208 for X to be zero and plus circa 400. If you had followed my instructions, these should be circa minus 200, and circa plus 200.

@Derek-F said in Centering a print:

................... I then sent M500 to save the setting.

Ahhh - that could be what's screwing things up for you. When you save settings this way, it writes the values to another file called "config-override.g" which does exactly what the name suggests. That is to say, it overwrites any G or M codes that may be in config.g. When power is applied, the contents of config.g are read and applied, then if your config.g contains an M501 command (which it does) it will read and act upon any commands which are contained in config-override.g. So if you have anything in config-override.g which relates to axis dimensions, offsets, or position, these commands will supersede (overwrite) the previous values which were read from config.g. Which effectively means that editing values in config.g will have no effect (because they are being overridden by commands in config.override.g).

This is why personally, I never use M500, M501 and have no config-override.g file and instead only use config.g. In my opinion, having configuration values stored in two different locations simply leads to confusion and mayhem. You can either do as I do and stop using config-override.g and only use config.g, or make sure that if you make any changes, make then in config-override.g instead of config.g (but sooner or later, you'll forget and it will come back and bite you in the arse).

@Derek-F The bit that's missing is that you haven't said what you set the Xmin and Xmax in M208 to. Also, when you make changes to config g you need to load those changes, either by sending M98 P" config.g" or by cycling the power to the board. Another thing you could try is, cycle the power to the printer but do nothing else. At this point the printer won't be "homed" and the motors will be free to move with no holding current. Then physically move the print head by hand SLOWLY to the left hand edge of the bed and note this X position. This will get around any limits set by M208. Then move the print head SLOWLY to the right hand edge of the bed. Note this position. Take the first reading away from the second, divide the answer by two and set your min and max values using M208. Do this by editing config g. Now cycle the power again to apply those changes. Then home the printer. As a further check, move the print head to X=0 and physically measure the distance from the nozzle to the left and right edges to make sure they are equal.

@Derek-F You're welcome. I probably should have emphasised that you must set the bed dimensions in your slicer to match the axis travel. That is to say, in the example I gave, the X width would be 402 mm.

@Derek-F I don't think you've grasped what @dc42 was trying to tell you. Start by jogging the print head in the X minus direction until it either reaches the edge of the build plate or the minimum gantry travel if the cannot reach the edge. Then send G92 X0. This will "tell" the firmware that this is X=0. Then move the gantry as far as possible in the X plus direction, either until it reaches the edge of the build plate or maximum gantry travel if it cannot reach the edge. Note the displayed X position. This is your allowable axis travel. Now divide that number by two. E.g. if it was 402 mm, you'd have 201. Then ln M208 set X min to be minus 201 and X max to be plus 201. Repeat for the Y axis. You've now set the origin to be the exact centre of the bed. Set your slicer to also have the origin as the centre. Now anything you print will always be exactly centred on the bed.

Expanding on what @stuartofmt has said, it's unlikely that there would be a significant difference in temperatures if your bed conducts heat well (which it should). But in the unlikely event that there are significant differences, then cold spots would likely cause problems with first layer adhesion whereas hot spots are unlikely to cause any significant issues. Therefore, it would make more sense to use a single temperature sensor located at a known cold spot.

@SamKudarauskas said in Configuring mixing hot end on a tool changer:

@Phaedrux On the LCD of printers that run marlin there is an option for mixing hot ends to create a gradient at a specific z range. It can be seen in this teaching tech video at 9:45. I was wondering if this function existed in the DWC and if could also be done using gcode.

Thanks,
Sam

I used to do this years ago by post processing the gcode file using a little python script that I wrote. IIRC I could alter the mixing ratio either every layer, or every "n" layers and for a mixing hot end using up to 5 inputs. I could have a look and see if I can dig that script out if it's any use to you. It might need tweaking to suit a two input hot end.

@SANJR said in INTEGRATING WIRE FEEDER TO THE DUET CONTROLLED WELDER:

@deckingman

Thanks

For a better understanding, lets consider for example

G1 X100 E2000 F50

As per the above the code the X axis moves 100 mm at a rate of 50 mm/min, the extruder feeds the wire for 2000 mm but at a higher feed rate since the 2000 has to be completed at the same time of X100.

Is my understanding correct?

Yes, that correct. You can actually work out the what the feedrate for the extruder must be (in simple terms ignoring accelerations and decelerations). If the head moves 100mm @ 50mm/minute then the time for the move to complete is 2 minutes. If the extruder has to move 2000 mm then it must move at 1000mm/minute (2000mm divided by 2 minutes).

@SANJR said in INTEGRATING WIRE FEEDER TO THE DUET CONTROLLED WELDER:

I have built an custom wire feeder using a stepper motor and configured it as an U axis, hence using multiple motion system

Just configure it as an extruder like @dc42 suggested, rather than as a separate U axis. A normal gcode move such as G1 Xn Yn Enn Fn means move a distance of "n" in the X and Y directions at a feedrate (speed) of "Fn" while extruding (or feeding wire) a distance of Enn. That effectively gives you independent feedrate for the wire feeder because the move will be synchronised. That is to say the wire feed (the E move) will start and end at the same time as the XY move and because the "E" distance will be different to the XY distance, so the feedrate for the wire feeder must vary proportionally.

@charliedrums One other suggestion - try a print without input shaping. I can't offhand think why it should make a difference but who knows?

@charliedrums If you are certain that it is genuine over extrusion after some seemingly random period of time, then the only explanation I can think of is that somehow, something is changing the G1 Xnn Ynn Enn commands that exist in the gcode file to something like G1 Xnn Ynn E(some other value that is always higher). I note that you are using a SBC. Is there any chance that you could run stand alone mode and print directly form an SD card?

@charliedrums Looking at this logically, any print move looks like this. G1 Xnn Ynn Enn. Which means move a certain distance in X and/or Y while extruding a certain amount of filament. What you are saying is that at random times, when printing a gcode that you have printed many times before, that Enn becomes something greater. I.e, the fimant moving through the extruder randomly moves further or faster than it should do. There are many reasons why it might move less (partial blockage, temperature too low, motor or wring issue, missed steps, etc), but none that I can think of that would make the filament move further than it should. So the only logical conclusion is that something else is happening which gives the appearance of over extrusion when in fact it isn't. My best guess, as I've stated before, is that your Z axis isn't moving the full layer height.

I haven't read this entire thread so I might have missed something but another option/thing to check is if the Z axis is moving properly. If the Z axis has some "stiction" or other movement related issue which prevents it from moving the full layer height, then this can seem like over extrusion. i.e. if you extrude enough filament for (say) 0.3mm layer height but the Z axis has only moved (say) 0.1mm, then this can seem like over extrusion.

@droftarts My only bad experience was intermittent loss of CAN connectivity with a 1LC toolboard. It turned out that the issue was with the supplied, pre- wired JST ZH connector (bad crimp most likely). Not sure what Duet could do about that short of making a test rig and "wiggling" the wires around.

@Miss-Rebekah A quick look at duet 2 spec (https://www.duet3d.com/duetwifi) shows two extruder heater outputs at 6A each. 60 watts at 24V is 2.5 Amp so well within rated spec.

@moth4017 I'm curious as to why you are trying to measure relative humidity at these elevated temperatures. Given that RH is inversely proportional to temperature, the reading is likely to be at, or very close to, zero in any case. Absolute humidity would be a better indication and it can be calculated from RH but you need pressure and volume as well. Even then, if my memory serves me correctly, the formula for the calculation is only valid for a range of between 5.5 to 12.2 gms H2O/Kg dry air so it's unlikely to yield usable data at very low values.