I’m working with a big integrated workcell and we’re trying to implement some automated QC for orders coming through our Fluents. Coming from my previous experience with Hamilton STARs, I figured parsing logs would a fairly straightforward way to get all the information we want about our runs. But every time I think I’m getting close to a decent way to parse the logs, I find new “fun” edge cases that I hadn’t covered yet and need to go back to staring at thousands of lines of xml.
My latest stumbling block is matching log events like LLD heights and aspirate/dispense locations to the order from our scheduler that triggered the Fluent method run. I can pass in the order ID to the fluent method, have it available in a variable and can write it into the logs via the Log command with this sort of syntax:
But I found out that these commands get written out to the logs multiple times per actual method run and sometimes even after the actual run is finished. So I went down a bit of a rabbit hole today and ended up finding a post here that pushed me towards Audit Trails that I hadn’t explored before. When I tried the same syntax using the Comment command, I couldn’t get Fluent Control to actually treat OrderID as a variable rather than just a string. Whenever I run this I just get the full string "AT - Start of script for " + OrderID in the audit trail, rather than what I expected with the variable value substituted in.
Is there some other syntax that I can use in the Comment command to achieve this?
I think starting in Fluent Control 3.6 they introduced a “smarter” Log Viewer parser called OLEG (or something akin to it.) Those logs are fantastic for incredibly deep troubleshooting because of it’s thorough firmware & I/O information but I find that I generally do not need that information. Instead I utilize the Audit Trail comment capabilities to generate readable and ergo parseable comments for processes. The Audit Trails come with features out of the box like time stamps, operator info, method & script names. This means that you can comment exactly the information you need and the Fluent inherently captures some of the other important metadata.
The first comment uses a function, the second is just a variable, and the third shows how you can string together more than 1 variable.
The other interesting component is that you can use comments in the microscripts to always return liquid detection heights or arm positional information.
Comments make troubleshooting and optimizations incredibly easy to execute.
Bonus: To push it even further, I was inspired by a conversation with a data scientist at an Open Auto Club meeting to rework my comments so they’re presented in a more intuitive human readable (and therefore AI friendly) format. If you do the aforementioned, you can feed your audit trail to your favorite LLM and have lots of fun.
Just tested the comment quickly in the main script body and that worked, thanks! I’ll definitely try it in microscript later and report back here to build up the record for future LLM/Search crawls.
And I’ll give that smarter log viewer a look, too… we didn’t get any heads-up about any new feature like that when that update came through and I don’t remember spotting anything like that in the changelog, but I was looking more for a solution to the bug that prompted us to upgrade.
Why would I ever expect the syntax to concatenate variable values to strings to be the same between Log and Comment commands or that any changes would be documented somewhere intuitive?
