When the Duet 2 Wifi controller turns on a yellow LED light is powered to indicate that the different axes are not homed. I do this with conditional g-code which I call into the config.g file in the system directory. The lights are currently plugged into the PWM Fan headers on the Duet 2 Wifi. In this instance I’m using Fan header 0 for red, 1 for yellow and 2 for warm white.

Once all the axes are homed, and not before does the yellow LED light turns off, and the warm white LED light turns on. When in situ the warm white light will be under the gantry of my CNC machine and will be used to illuminate the wasteboard.

There LED lights accept a maximum of 12v so I have to careful when I write the code that I don’t send the full 24v through the pins. I also haven’t quite worked out how to write a piece of conditional g-code to turn the red light on while running a job – so for that I’ve simply put the correct codes into my starting and stopping scripts.

That big clunky thing is a prototype of a DIY tangential knife head. Mechanically it works but I haven’t worked out how to control it during a job. I suspect I’ll my a video about that separately.

Since my earlier experiment with LED lights I decided to get a 24v RGBWW LED strip and to install that onto the heat terminals of the Duex5 expansion board.

I’m doing this because all but two PWM fan headers on the Duet 2 Wifi, and all on the Duex expansion board temporarily turn on upon reset. This is a hardware feature and as I was informed by a user called Bearer on the duet forum – Fan headers 0 and 2 have pull down resisters on the gate to unsure they remain off unless driven, but the others are normally for hot-end fans, so that behaviour is a safety feature which would otherwise cool the hot-end if the system is reset and somehow prevented from reading the config file as the fan would remain on.

It doesn’t look particularly great if lights flash randomly when any piece of electronics turns on, so I’m going to move this over to the heat terminals now.

Ok so I’m just going to show you how I’m going to wire this up and the first thing I’m going to do is cut a piece of wire into four equal sections.

I’m using a common anode LED strip – which are more common and can be connected directly to the controller. The black wire goes to the voltage-in terminals via a small section of terminal block, and the other white, blue, red and green go to the various grounds.

I’ll be using heater terminals E2, E3, E4 and E5 – which are PWM enabled so I’ll be able to control the brightness of the LED Lights.

So that’s wired in. These different coloured wire – the green, red, blue and white may not correspond with the colour on the LED.

After wiring everything up I can reboot the controller and we can see the lights do not flash.

I am now going to update my config.g file to include the terminals pin associated with the new LED strip.

Ok here goes. So this is the web interface that I am using in my system file I can go to my config.g file. And there’s quite a bit of stuff here. I’ll talk about this is more detail in different videos but the bit I’m going to talk about is this section – which is about the LED lights. I’m going to ignore these three up here and I’m going to change the setting for these ones here. And swapping from the duex.fan3 to 6 headers to e2 heater. And this one will be the e3 heater… and you can only go up to nine in this case. I don’t know what colours these correspond too so I’m going to delete these and I’ll check these in a bit.

So I’ll just describe what commands do. So M950 has to be used to set the port up – so essentially if I don’t have this written in the config file the pin won’t be used. Unless I’ve enabled it with a different command. Once that’s created I can control it using the M42 command which the switch IO pin. The P number refers to a quick reference like a short cut and the S sets the pin either on or off. And if it’s a PWM enabled terminal you can then go through all the varying voltages that are available. So in my case I’m using a 24v PSU to power the control board, and the maximum volt that can come of these headers is 24v. If

I write S0.5 it’ll be 12v but do check the exact voltage with a meter as I found it’s not exact. I’m now going to save this and check P6 to P9 to see what colour they correspond with.

I’ll just make a note that I’m using the latest version of the reprap firmware which is 3.01 RC6. So it’s a little bit different from version 2 where you have to define the pins by their names.

If I drag the overview this is the the RRF3.0 overview. You can see the pin names on the duet 2 wifi and Duex. This is what they are referring too and this corresponds to the diagram. So in this case this is the expansion board, and e2 heater is defined like that duex.e2.heat. You have to use your imagine with how these are written as I’ve not found an overlay of the diagram of the boards and the pin names.

Ok so M42 P6 S0.1 is green. I’ll write a note of that. I’m going to turn that off with S0. And then P7 S0.1 is warm white. P8 S0.1 is red. P9 S0.1 is blue. So to make yellow is green and red. P6 S0.1 – in fact I’ll put it to full brightness so you can see what that’s like but I’ll keep it low so it doesn’t dazzle. And red is P8. And that is supposedly yellow. It’s not a great yellow. This is a better yellow but this is a dedicated yellow LED so I wonder if you can get these things made up so they have the wavelength of light that you actually want.

So the other thing I have in my config file all the way down here is a M98 which refers to conditional1.g macro file which is where I’ve written a piece of conditional code and…

I’m now going to show you the updated conditional g-code which controls the LED light strip plugged into the duex expansion board. It’s based on the example in i the GCode_Meta_Commands page on the duet website. I start with setting all the headers controlling the LED lights to off with the M42 and S0 commands. I then write a conditional construct starting with if followed by

!move.axes[0].homed || and then followed by pretty much the same text but with a different number which corresponds to the different axes.

The behaviour works in the following way. If axes 0, 1, 2, and 3 are not homed, turn on the yellow LEDs – Else –

Turn on the white LED. And I found I had to write it this way so that all four axes had to be homed before the warm white LED’s are turned on.

The ! means Boolean not – which is a logical prefix operator and invert the up coming inquiry – which I think is an inquiry but I don’t really know what the right terms are.

I still getting my head around this type of programming, but the next thing I want to do is write a new conditional script or expand the old one, to detect when a job is running so the Red LED turns on and other turn off –

so I don’t have to either use the post processor to write M42 commands in the g-code script, or what I actually do now which is write the M42 commands in the start, stop and pause.g macros in the duet’s system files.

So that’s how I installed the LED’s onto the duet 2 wifi and duex expansion board, and the example of conditional g-code I’ve used to controll them. I’m going to leave this video here and I hope you found that interesting. Please remember to sacrifice a thumb and if you have’t done so already, subscribed and press the bell button to get notification of new videos. Thanks again for watching and you’ll catch me in the next one.