@usinjin The 'easy' way to do this would be have the Z compensation reported in the Object Model, and use that. However, this isn't currently reported in the Object Model. I asked @dc42, who replied:

We could consider it for 3.6. Easiest would be to report the last computed height correction, which would be the correction at the endpoint of the current segment.

Would that suit your purpose? You could enable segmentation (see M669) would also allow the compensation to be updated more frequently on long, straight moves.

If so, please raise a feature request/enhancement on the firmware Github repository: https://github.com/Duet3D/RepRapFirmware/issues

Otherwise, you're going to need something that can read the XY position, and be able to compute the Z offset (ie have the mesh .csv file), and feed that to the pen motion control, in a timely manner. Something like that might be better done by a Raspberry Pi in SBC mode.

Ian

@ander I think you still have the old heating parameters in the M307 commands in config.g. Try replacing them with the parameters from the M307 commands in config-override.g.

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

Configure the WIRE FEEDER as an extruder and use Open Source Slicer to predict the profile/geometry of the bead.
Limitation : for the below code
G1 X100 E2000 F80
for this code the X axis moves 100 mm at a feedrate of 80mm/min. The WIRE FEEDER extrudes wire at a rate of 80 mm/min for the 2000 mm that is the extruder would be feeding the wire even after the X axis would have stopped. This means that the motion of X axis and the WIRE FEEDER would be coordinated and synchronized at the beginning but not at the end. Is my understanding of this option correct?

Not correct. When a move has both axis motion and extrusion, the feed rate refers to the overall axis motion. The extruder feed rate will be adjusted automatically so that the extrusion starts and stops at the same time as the axis motion, with the specified amount having been extruded..

@gloomyandy 3.5.2 SBC tool distribution board, 4 tools

@droftarts just a note you need the Printer Settings plugin in Cura to enable firmware retraction.

@gloomyandy
You are right, Safari works similar to Chrome (with respect to "privacy").

But that may not stop google from identifying me by other means.

Exactly. That's why they use "fingerprinting", which, in effect, is a huge collection of any characteristics and data they can grab from a client. One data point, for example, once was the access time of the internal HDD (not sure about SSDs, though), measured on a cookie… If you know about buffering, caches and all that internal stuff, it's hard to believe, but they told me this bit could help (a bit) to recognise an already known machine. Not to talk about mac addresses, IPs, CPU (model, clock rate etc.), screen size plus other hardware and OS characteristics. Talking of the OS: digging a bit into what my macOS can tell me, I stopped wondering.

@brian It's possible you deleted it accidentally, or the SD card is failing.

I'd see if you can recover the files from the SD card. There was a thread about that recently, with a recommendation for software to try: https://forum.duet3d.com/post/340947

Ian

@T3P3Tony it was exactly that, my email was not the right one, thank you very much

@dc42 I probably should ditch the mesh calibration. I did use it for the Ziflex build surfaces.. because they did strange things. Now MOSTLY using WhamBam spring steel.

Thank you.

@droftarts I think it would be sufficient to provide some example diagrams:

single toolboard to the print head using a duet3d board as expansion board tool changer with TDB and multiple tool boards

Anything else likely will need extra explanation and/or expert input anyways.

@tom33 said in Reprap G-Code syntax now part of RJ TextEd text editor:

@OwenD is it possible to use it with visual studio code ?

No, I wouldn't think so.
Each editor seems to have their own format for the syntax highlighting files.
There is at least one GCode syntax extension for VS Code
You could create your own
https://code.visualstudio.com/api/language-extensions/syntax-highlight-guide
I note that it uses the same format as YAML

@chrishamm so far so good. It looks like all the reset issues have gone away.

@HeidiH said in Heaters turn ON when powering ON or restarting Duet 3:

I think these are the questions you want answering?

With the first case I got a heater fault warning and a comment on n/a as the temperature on the web interface

This was probably a configuration error, and the heater has been defined with no temperature sensor.

while with the latter case the firmware was not responsive. In both cases, both of my heaters turned on (even without setting-up any input for them), which is not desired.

I think the configuration with the output pins inverted, along with the wiring issue with the SSR, caused this.

Was these above events because I had my heaters wired and configured in a wrong manner, and does the above change avoid this risk?

Yes, I think so. The default state of the heater should now be off.

I had also my heater fault detection set with M143 as described below but it wasn't able to avoid this unwanted heating:
M143 H1 P0 S300 A0
M143 H2 P0 S180 A0

If the logic to turn on and off the heater is reversed, when the firmware tries to turn off the heater (either because it reaches temperature, or there is a fault) it will actually turn the heater on! It doesn't 'know' what is happening or why, just that the temperature is not what is expected.

By 'what is expected', the firmware has a model of how the heater responds, which is created by running M303 heater tuning, and configured by M307 in config.g.

Also, should I have my allowed lowest temperatures be configured with M143, and not only the maxima? Unfortunately I don't figure it out what does the monitor number mean (P in above commands)? Is it somewhat related to the H term?

Generally, you set basic maximum temperature limits with M143. It is possible to set minimum temperatures too, just it is usually not very useful. The H term is used to define which heater has this limit. You can set up to three M143 commands per heater using the P command, and use the A and C parameters to define different actions at different temperatures. For example:

M143 P0 H2 S180 C0 A0 ; Heater 2 temperature too high, generate heater fault M143 P1 H2 S200 C0 A3 ; Heater 2 temperature too high, shut down printer M143 P2 H2 P2 S10 C1 A0 ; Heater 2 temperature too low (below 10C), generate heater fault

Use M570 to configure how accurately you want to maintain the set temperature.

I also tried to read about these issues from: https://docs.duet3d.com/en/User_manual/Troubleshooting/Heater_faults, but based on that I assume the firmware should automatically detect at least bad wiring issues?

It can't automatically detect bad wiring issues, it just tells you when the input (ie turning the heater on and off) doesn't match the predicted output (temperature increase/decrease). This may be because of bad wiring, but it can't tell that is the issue, just that there is something unexpected.

Ian

@qlqlo Most likely, it's the G1 H2 command at line 12 in your homex.g:

G1 H2 X-20 F12000 ; go back a few mm

This causes a diagonal move, as you're telling it to move the 'X' motor on it's own, rather than in the X axis direction. Remove the H2.

Some notes:

You shouldn't use G1 H2 on X and/or Y moves on CoreXY homing sequences, because it moves the individual motor (creating a diagonal move) rather than a move in either the X or Y axis direction, which requires both motors. When you're using G1 H1 moves, you need to make sure both axes hit the endstop, by sending a G1 H1 X.. Y.. move, which will stop as soon as the first endtop is triggered, followed by individual G1 H1 X.. and G1 H1 Y.. to get both to home. As soon as an axis has touched home, you can use a normal G1 X.. or Y.. (no H1 or H2) to move it away from the axis, as it has homed. All homing and these moving away moves should be done in G91 relative position mode.

See https://docs.duet3d.com/User_manual/Machine_configuration/Configuration_coreXY#homing-files

You could also do a basic configuration in the RRF configuration tool to get an example, to show where yours is going wrong: https://configtool.reprapfirmware.org/ This has had some errors in it (including adding the G1 H2 commands that your homing files have) but should be fixed now.

Ian

@turtlecrawler Great, glad you got it working. However, I didn't know what a "Sex bolt style endstop" was, and was a little scared to Google! Eventually I did, and it's this: https://mods.vorondesign.com/details/t1DBVlcUBbdEK6habEsVzg
It's a nozzle touch off probe. You can see the top of it at the back of the bed, just to the left of the Z rail. Looks neat!

Ian

@turtlecrawler let me know if yours squeal while idle.

@dc42 The new RRF version lets me send 31 bytes, but for some reason, sending 34 bytes gives "Error: I2C transmission error". What's interesting is this is usually a fatal error, in that to get the NeoDriver working again requires a power cycle. In this case, it does not seem to interfere with subsequent I2C communications. 31 bytes (9 LEDs) didn't used to work; the best I could do was 28, meaning 8 LEDs (the data being in 3-byte multiples). Now 9 works fine.

In the code below, running with the "var RunCount = 9" changed to "var RunCount = 10" will produce a transmission error, and doesn't update the LEDs, but it doesn't lock up future communications; you can then change it back to 9 and it runs successfully with the desired result. The first 4 bytes of the buffer are overhead information, and the rest are "GRB" triplets, each representing one LED.

var I2CAddr = 0x60 var LED_COUNT = 28 var NeoBufSize = 3 * var.LED_COUNT var RunCount = 9 var BufSize = 4 + 3 * var.RunCount var Buf = vector(var.BufSize, null) set var.Buf[0] = {0x0E} ; base address in NeoDriver set var.Buf[1] = 4 ; Specifies sending a buffer set var.Buf[2] = 0 set var.Buf[3] = 0 ; Offset in NeoDriver internal buffer while iterations < var.RunCount ; Put individual R, G, & B values into Buf array set var.Buf[4 + iterations * 3] = 0 ; Green set var.Buf[5 + iterations * 3] = 0 ; Red set var.Buf[6 + iterations * 3] = 24 ; Blue ;----------------------------------------------------------------------- ; Send the data ;----------------------------------------------------------------------- M260 A{var.I2CAddr} B{0x0E, 1, 0x0F} ; NeoDriver "pin #" G4 P50 M260 A{var.I2CAddr} B{0x0E, 2, 1} ; NeoDriver I2C speed G4 P50 M260 A{var.I2CAddr} B{0x0E, 3, var.NeoBufSize, 0} ; Internal NeoDriver buffer size ;------------------------------------------------------------------------------- M260 A{var.I2CAddr} B{var.Buf} ; Sending buffer data ;------------------------------------------------------------------------------- ; G4 delays seem to prevent NeoDriver locking up with "I2C transmission error" ;------------------------------------------------------------------------------- G4 P100 ;------------------------------------------------------------------------------- ; Show NeoPixels ;------------------------------------------------------------------------------- M260 A{var.I2CAddr} B{0x0E, 5}

@droftarts

Thank you Ian. Good to know I have the latest firmware.

I will replace the heater wiring as it does look a bit dodgy, and will report back with my findings.

@Bridge-Of-Don
I am happy to report that we have today successfully manged to print off a small 'cube'.
We still need to fine tune the heaters both on control (to prevent overshoot) and actual temperature but at least it functions. 😊
We used the 'AstroPrint' web based slicing option and downloaded the G-codes to the PC then 'uploaded' them to DWC, maybe not the most elegant of solutions but it works.
We like the ability to 'fine tune' the slicing within the 'AstroPrint' as hopefully we will learn as we go-along.

I'm away again for a week, then home then away, so will have nowt to report for a little while.

@MaxGyver

A more dodegy approach would be, to physically attach a speed potentiometer of a stepper driver circuit to a small hobby servo motor, the servo motor could than turn the speed of the stepper motor / peristslt pump, it's a bit dodgy but it works, I have done it before..