Flame Detector on MKS-DLC32 board

Hello!
So, as I’m on vacation and have free time, I thought I should figure out how to put a flame detector on my laser machine.
The board is an MKS-DLC32 that has a “probe interface” port that, according to the manual, can be configured as a flame detector.

From my research there is a parameter $37 that activates or deactivates the function (1 or 0 respectively)
Although this parameter does not appear in Edit - Machine settings, in the “console” window it appears and if I execute the command to activate or deactivate I get the return “ok” and I can confirm that the command was effectively changed through the command to verify the state of the parameter ($37 in this case).

Turns out nothing happens when I simulate the flame detector signal.

Has anyone, with this card (I’ve seen that there are some working around), managed to get the “probe/flame detector” function to work?

How do you do that?

What is the output of the flame detector?

Were you running a job when you simulated it?

:smile_cat:

This is really interesting.

It’s probably a phototransistor that’s infrared, red or yellow biased to not trigger when exposed to reflected blue laser light.

The Probe Interface would also likely have a pull-up resistor (or an on-chip programmable pull-up) on the data or sense pin.

To activate it, you measure the voltage on the sense pin compared to ground. If the sense data pin is pulled up, you ground it. If the data pin reads zero you apply +5V (or +3.3V). I’d start with a jumper with a 1k resistor in it to avoid a hard short.

I’ll see if I can find a data sheet for the sensor or something interesting on the Makerbase website.

Hello,
Thank you both for your prompt reply.
I’m quite busy with going back to work but I’m working on a clear answer for you for a better understanding.
However, one of the simulations I did was to hook up (directly connect) the “G” (ground) pin of the board to the “S” (signal) pin of the board.

Hi, hope everything is fine with you! :+1:

I hope in this answer to provide all the information I obtained and clarify your doubts. For this you will answer in parts.

To answer your questions, I believe that in the same answer I can answer several questions. (at least I hope so)

The test was carried out as follows, to test it I drew a circle on the LB and set it to make about 20 passes.
While the program was running I did a test by shorting the G (ground or 0) with the S (signal) of the board.
I did another test, this time with the flame detection board, which consisted of lighting a lighter in front of the sensor. (The flame detection board works with the lighter flame)
Always running the “circle” program and always using digital output of detector (these detector as two outputs digital or analogue).
With this I hope to answer to:

:yum:

Now…

Later I realized that I could have burned the board for not having used any resistor.
My reasoning at the time was that as the connector is in precisely the same alignment as the limit switch connectors and these are basically microswitches, the contact was dry (closed).
Fortunately, the board is protected against these “inventions”. :roll_eyes:

Comparing sense (signal) pin with the ground pin = +3.3V, so I simulate the flame detector with a short between Ground and Signal pins.

This is the Makerbase manual:

In chapter X you can see the probe / flame detector connector. But the information is not entirely correct according to my brother who understands much more of these things than I do. This works with ground and not with 5V as described.

This is the the flame detector that i am dealing with:

I came across this knowledge in a Github thread:

From what I’ve been able to find out so far, the card will not be activating the function. This is because simulating the signal from the flame detector directly on the port of the board while a job is in progress, the LB “Console” window does not show any warning or information even when the “show all” option is activated.

1 Like

Don’t know what you mean here… Unless it goes low for active… All voltages are reference to ground unless otherwise stated… You have two probes on a voltmeter, each has to go somewhere…

Was the flame board connected to the controller?

The assumption here is that it responds to a low or 0V input for active.


The documentation you posted stated there is only an on/off value, so it must expect a digital signal, not analog. You can’t enter a trigger temperature.

This text from the manual seems to indicate it a 5V signal to trigger it…

… interface can be used as a flame detection function. The input signal voltage is 5V, the signal interface is S, and a 5V power supply interface is provided to supply power to the modules that need power supply.


The sensor module you posted with a link, has a high output when active. The opposite state you tested and might conflict with the other information about the signal levels.

How did you pick this board? I’d guess it’s likely some do go low when active…

It also states that it will beep… sounds like something the controller should do, but I don’t think it has the hardware to actually beep…

I would think there would be some type of notification from grbl.

:smile_cat:

@jkwilborn
I’m sure I didn’t explain myself well in my previous answer. Which makes it interesting ( I hope you don’t get me wrong because there’s no intention of that, just difficulty expressing in English ) :wink:

However, I will prepare a new answer, with more images attached to make it better understood.
Thank you for your availability :+1:

I’m confident your English is much better than me attempting yours… :wink:

No problem, take your time…

:smile_cat:

Let me try to explain with draws! (images in this case) :roll_eyes: :blush:

1-

In the board manual it says that the signal works with 5v.


In reality it works with 0 or GND.

2-

Yeap.

3-

Precisely.

4-

Yes, I am aware of that. The flame detector has both options, I am, obviously, using the digital output.

5-

This is what I have been trying (apparently unsuccessfully :smiley: ) to explain.
My brother had already told me that, on Github I also read that


Furthermore, it matches what @JohnJohn explained previously.

Apparently I’m using version 1
version01

and apparently I need to install version 2.10 of the firmware

Ok,…
Now,… I’ll just confirm that I’m not using the appropriate version, install an updated version (at least 2.1) and I’ll come back to give feedback. :wink:
I hope (once again) have made me understand and clarify your doubts.

If this is not the case, let me know. I think I’m just going to eat some hamburgers (which, outside of jokes, isn’t even something I enjoy) but it could be a solution for English (even if it’s American English) to start speaking more fluently without having to constantly resort to Google translator. I hope you realized that this entire paragraph is a joke!!! :laughing: :laughing: :laughing:

If it isn’t supported in the firmware, then you are out of luck…

I think they are telling you that it’s a ttl type input. There is nothing there that states what an active state is… One of the things that would have been easy to document.


When you write documentation for one of your creations, it may not seem to you at the time necessary to add that kind of information as it’s pretty clear to you.


Most of these use pull up resistors on the controller itself to make an easy pull to ground switch. It’s very common, since most of the early controllers only had a pull up type internal option. Some of the newer 32bit processors today have both internal pull up and pull down options.

With a pull down option, a metal machine only requires a single line to the switch, using the machine ground for the return path.

If you measure these with no load or driving circuitry, it will read the default state, either high or low. They build these so that with no input, they are held at a known state, usually inactive.

Good luck on the firmware upgrade…

:smile_cat:

I finally did it!

So I’ll leave here some notes and an explanation of how it was possible.
.
Notes to take into account:
1 - Only firmware V2.10_H35_2022_0621_N_ZX_001 supports the “Flame Detector” function through the signal on the “Probe” port.

(Moderator Edit: Corrected Typo at Kuth’s request
Technical reference: Flame detection function · Issue #226 · makerbase-mks/MKS-DLC32 · GitHub)

2 - This firmware is intended for boards with a 3.5" display


however, the board works even without the display. Also works with a 2.4" display

but it becomes unreadable due to the firmware settings being for 3.5"
.
3 - Use a flame sensor with output at 0 in case of alarm. (positive in normal mode)
Otherwise it will have to be changed as happened to me. (Image at the end of the video included in this thread)

What was done:

1 - With MKS board connected to computer, through the software MKS Tool
mkstool01

select
mkstool02

then select

and delete de existing firmware.

2 - Then install the new firmware.
Select the new firmware file

and hit Start

When finished reboot the board.

3 - Copy dlc_cfg.txt file to a 4-16Gb SD card FAT32 formatted.
Open the file and correct the parameters $37=0 to 1 ($37=1) and $38=0 to 1 ($38=1), save the file. ($37 enables de flame sensor, $38 enables buzzer)

Insert the SD card into the slot on the board and reboot again. (If you have a 3,5" display connected you will see some information running.)

(I didn’t include images for this step because I didn’t have the display yet at the time.)

NOTE: Parameter $37 is not visible through software. Only configurable through the dlc_cfg.txt file

Turn off the machine and correctly install the flame sensor to the “Probe” port.
Turn on the machine and run a test. It should work fine.
Have a lighter on hand that lights up better… :innocent:

More details at GitHub forum where i discuss the most of the issue.

I hope I can help someone so that this topic becomes useful.

Special thanks to @JohnJohn for reopening the topic at my request after more than 2 months of inactivity in this topic.
This topic was inactive but the reason for this topic was not.

1 Like

Thank you for reaching out with a solution. Happy to help where I can.

It must have been rattling around in my head last night.
I reflashed my mks-dlc32 last night and it’s working and communicating through wifi.

1 Like