Use case:
We have a PCB assembly that we need to mark a QR code on. The assembly undergoes a programming/flashing step. We have custom scripts that will flash the device, and then record certain (unique) device data to a CSV file. We want to use the CSV file to source a “variable text” in Lightburn. We want the “variable text” to be encoded into a QR code.
Our process flow would be:
flash the device, which would populate the next available row in the CSV.
disconnect the device from the programmer and immediately mark the device with the data that was populated into the CSV
Question:
If Lightburn is setup to mark a QR code that is driven by variable text, can the CSV file be updated/saved in between runs? Will Lightburn see the new changes to the file? Basically, our plan is to continusouly update the CSV file with a new row and hope the Lightburn can keep seeing the new data. If Lightburn opens the file and locks it, we wont be able to edit the file between runs.
It would be greatly appreciated if the behavior can be confirmed. It is critical that it works the way we need it to. We dont want to make the investments if we cant find a solution.
From experimentation I can illustrate how LightBurn behaves, at least on Windows.
LightBurn does not reload/reparse the CSV file at every run. Meaning specifically that the number of rows in the file does not seem to be updated in Variable Text window without explicitly loading the file again.
LightBurn does, however, seem to reflect updated data in the file when referenced. So, let’s say for example, you update a field in a row, then save the file. LightBurn will reflect the data change when “Test” is pressed. Furthermore, If you manually update the “End” field in LightBurn, even new rows in the file can be accessed.
Based on this I see a few potential methods:
Have a single row CSV file that you continue to update after every programming step. Have LightBurn always reference the same row which is being updated in the background. This has the advantage of simplicity and making the updating system solely responsible for what gets burned. Disadvantage would be that the CSV file itself would not provide history. That could be easily remedied by storing history elsewhere.
If the unique device data can be predetermined could you simply pre-populate the CSV file with all relevant data inline with what’s required in a static fashion? Then the only burden would be in making sure that you’re indexing the correct record at the time of burning which would generally be the case unless you had some sort of error in the previous step.
Having said this, my testing may not mimic your exact scenario so keep in mind that things may be different for you.
The other challenge is that LightBurn has really no or very little builtin integration capability if you’re looking to automate this whole process.
Thank you very much for your reply. It is helpful.
Your suggestion of a single row CSV file is workable. We do not necessarily prefer the CSV for history anyway, we would insert into a DB. We cannot pre-populate the CSV because some of the unique information is generated and discovered on the fly during the programming step.
We are considering this UV marker
It comes with a foot switch. I am hoping it can be used to trigger the mark process but worry it will only repeat the last job that was sent to the marker.
It’s unfortunate that LightBurn does not have an extensibility or API for external automation. In my searching, I cannot find any platforms that allow for more automation at this sort of price range.