Creating Toolchain via API (UDP?)

LightBurn Software Questions
1

I am looking to build a toolchain to do writing as quickly as possible.

I use a product called GoToTags that writes NFC tags. My goal is to write the NFC tag and then immediately trigger an etch from a fiber laser.

How I will physically do it (to better help you visualize my method):

  • 3D print a jig for the NFC writer, encase NFC writer in PETG for its protection.
  • Place this NFC writer on the laser bed.
  • Above the NFC writer will be a jig for NFC tag to ensure the correct orientation every time.

I am going to suggest an update to GoToTags to have an option to write a TXT file of what I write on the NFC tag, such as A1B2C3D4. Then what I would like to do is write a Python script to check when the file is updated, then send that to Lightburn to etch from the fiber laser.

These the steps I would like to achieve:

  1. I place a tag on the jig I mentioned above.
  2. GoToTags automatically attempts to write the NFC data on a tag.
    • If failure then it will stop and let me swap out the tag and attempt again.
  3. On a successful NFC write, GoToTags will save a TXT file with the tag data (A1B2C3D4)
  4. Python script will see the TXT file is updated and send data to Lightburn.
  5. Lightburn will etch the code on the tag.
  6. When the tag is written to I will take the tag and package it.
  7. Start process over again

Of course in the future I am looking to automate this process, but for now this method is the easiest for a small scale startup.

The questions I have:

  • Lightburn expects a CSV file for variables, is this a steadfast rule?
  • If the variable changes on the CSV file, does Lightburn know?
  • I saw in this topic someone suggested AutoHotKey, this doesn’t seem like the best method:

One way I would see this work is to force open / force close an .lbrn file in Lightburn as seen in the link above. When you open the file the CSV should already be updated on the load. Then maybe have it auto-burn on load? I have no clue otherwise.

Let me know your thoughts, I would love to see how to make this a reality. Thanks!

2

Re: the post above, the GoToTags software repository can be found at:

I couldn’t link to it in the above post because of the 2 links per post limit on new users.

3

Welcome to the forum. :tada:

The fiber I have (JCZ) doesn’t use udp only the Ruida. I have no idea what tongue the fiber speaks.

Maybe one of the Lightburn can help you out.

:smiley_cat:

1 Like
4

I emailed the support team in hopes to get a response, I have 3rd party resellers who will also need to know the steps to do this. Thanks!

1 Like
5

One of my posts in Beta Section, August 2023:

We do plan to provide an API through Python in the future, but that will take time.

LightBurn currently provides a limited command line interface through UDP commands to do things like launch the program and launch the program + load a file + run the file. ‘SendUDP’ is a helper utility that is currently for Windows only, however the LightBurn “listener socket” should be available on all platforms. SendUDP just sends a UDP command to localhost, port 19840 (and gets replies on port 19841).

Functions available at present:

“LOADFILE:[file path]”
“FORCELOAD:[file path]”
“CLOSE”
“FORCECLOSE”
“START”
“STATUS”
“PING”

6

Rick,

So what you are saying is I can do this for the time being with Python:

  • Python will convert Text from external file and convert it to CSV.
  • Send to Lightburn:
    • “LOADFILE:[file path]” //This will reload the file I want
      • Since the .lbrn file will be saved with that CSV it’ll load it immediately I assume?
    • START //This should automatically start the burn using the CSV file
    • CLOSE //This will close the file
  • Then once the CSV is created, start the Lightburn process again from above?

This is the only way I can see this happening. Let me know if I am wrong. Thanks!

7

That is a flow worth testing to ensure things work as you’d expect here, but in general, yes. :slight_smile:

8

In the future this is planned to be a bit more streamlined for people to develop complex toolchains I assume?

9

We do plan to open greater access, yes. Can not provide further detail at this juncture, but on our ‘to do’ list.

1 Like
10

Here is a very basic example of a Python script that tells Lightburn to ‘Start’ whatever job it has loaded:

import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(b"START", ("127.0.0.1", 19840))

For example,

(1) Have LightBurn open and variable text set to read the first column of “test.txt”.
Disable ‘Require framing before start’ in Device Settings.

(2) Write/Save ‘A1B2C3D4’ to test.txt file using any external program.

(3) Send the ‘START’ UDP message to LightBurn - Python is useful for this (as above).

If you don’t have Python setup just paste the line below into the Win+R Run dialog:
powershell -Command "$c=New-Object System.Net.Sockets.UdpClient; $d=[Text.Encoding]::ASCII.GetBytes('START'); $c.Send($d,$d.Length,'127.0.0.1',19840); $c.Close()"

The job should output immediately with the new text, now you cycle back to (2), rinse and repeat.

image
image1305×1008 76.1 KB

image
image1305×1008 77.5 KB

2 Likes
11

what happens when there are multiple instances of lightburn running? There can only be one instance of the listening port. Maybe those “TABBED WINDOWS” would be appropriate at this time instead of multiple instances.

12

How would you reference the tab? Different ports?

13

I guess it’s first-in-first-served for the LightBurn process that gets allocated the UDP ports by the OS… so make sure the first instance you open is the one you have setup for the task.

I think it was probably anticipated that in an automation situation there would be a separate computer for each machine (they could be headless) with one LightBurn process running at each, listening at their own IP address. So you could command multiple machines from a central computer without any interference between them.

2 Likes
14

When I had a pair of computers on the network using the OMTech, it didn’t seem to know or care where the UDP came from. I could send it commands from either computer..

I just think it hangs out there waiting for any kind of UDP packet that’s addressed to it.

:smiley_cat:

1 Like
15

Good news, everyone! GoToTags is adding a data export option in the next release. Still need a way to parse the data from the JSON it sends BUT this will make it easy to toolchain. Excited to see this happen!

4 Likes
16

Another question about UDP, what if the file isn’t local to that machine? Could I send the file contents over UDP? That would really be useful if I decided to use a Raspberry Pi to run the other processes.

17

If you talk to the Ruida via Ethernet, you talk UDP, there is no other option that I know of.

The data in the UDP packet is the laser data, it’s up to you to send the data to the Ruida.

That means I’m not clear what you’re asking.

:smiley_cat:

18

It was more referencing the Python code demonstrated here:

MESSAGE = “LOADFILE:F:\BeeTest.ai”

What if I don’t want to load a file, but instead send data live. I guess I could do a network storage and modify that on the fly.

19

GoToTags has their implementations live!

I’ll start testing on an interceptor for this, most likely it’ll be Python since I want it available for everyone to use.

20

Retired, not free, so unless it does something magical, I’ll likely pass.

Please post what you get working and it’s limitations, nevertheless.

:smiley_cat:

1 Like