The ASWStandard Library is made up of two separate libraries, the ASWGlobal and TraceLevel library. To get past the ASWStandard check, both secondary libraries need to listed in the Programs list, and both libraries need to have their subfolders/files present in the “C:\Program Files (x86)\Hamilton\Library\ASWStandard” folder:
My suggestion would be to uninstall the ASWGlobal and TraceLevel libraries from the Programs List, delete the “C:\Program Files (x86)\Hamilton\Library\ASWStandard” folder, then reinstall the ASWStandard library. This will make sure all of the correct folders/files are present.
Why does the Hamilton PDF Report Generator library need access to the “Hamilton PDF Report Generator.log” file?
We need the “Logfiles” folder to be set to write-once, and therefore, the library cannot have continuous access to the “Hamilton PDF Report Generator.log” file.
I just tested with a method in my VM, but as far as I see it only needs access when it is called upon. Just like your regular logfile would have. How do you work with a method and only have the folder to be write-once?
Out of curiosity, what requirement needs this? Is this a local requirement or a IVD requirement? I am developing methods with IVD in mind, so it would be nice to prep for this if needed.
All the files in this folder are write-once, and a new regular log file is generated every time the method is executed. On the other hand, the PDF generator library appends logs to an existing log file.
We need this setup for GMP, and we want to avoid the possibility of modifying regular Trace files.
The log for the PDF report generator is not really needed, but it prevents the method from finishing.
Hi Dan, wanted to revive this topic with a question on returning error messages as strings in order to trace them into the PDF report generator.
We currently have the PDF report enabled in our analytical methods to display user and method information such as who’s logged in, what assay conditions are being performed, how many samples, etc. I’d like to have an “OnAbort” version of the report which gets generated if the method errors out, and have the last error message (causing the abort) to be traced into the PDF somehow. Any guidance on what the best approach for this would be?
You can extract that information from the trace file. There is another topic on here that tells you how to build the name of the specific trace file of th currently active method. Then you can open the file by extracting each row as string and checking whether the sub string “Method has been aborted” is contained therein. The line above that will contain the error that led to the abort.
My recommendation would be to open the .trc as ASCII, set the position to the last row (File: Set Position), get that number and then loop over it, searching each row for the sub-string and counting down by one after each loop, until you get a hit for the sub-string, then loop break. After that reduce the row number by 1 once more and you got the string of interest.
