Below is some guidance on how to approach this refactor as you transition from EZScript to Python in ARC.

Does ARC Already Log Debug Output to a File?

At this time, while ARC’s builtin print (or its equivalent for your language) does timestamp output in the debug console, there isn’t a builtin ARC function that automatically collects all debug console output into a persistent, timeordered log file. In other words, ARC does not automatically save all of your console prints as a log file for you.

Creating a Custom Logging Function in Python

Since you’re already considering adding a common logging function that handles buffering and deals with file locking (using, for example, Python’s portalocker library), you’re on the right track. Python’s standard library even provides a robust logging module that you can customize. Here’s an example of what such a function might look like:

import logging
import portalocker
from datetime import datetime

# Configure the logging module
logging.basicConfig(
    level=logging.DEBUG,  # Change to INFO or another level as desired
    format='%(asctime)s %(levelname)s: %(message)s',
    datefmt='%Y-%m-%d %H:%M:%S',
    handlers=[
        logging.FileHandler("robot_debug.log"),
        logging.StreamHandler()  # This will output to the ARC debug console
    ]
)

def log_message(message, level=logging.INFO):
    try:
        # Optionally, you can add any buffering or lock control if needed.
        # Using portalocker guarantees that our file writes don't conflict.
        with open("robot_debug.log", "a") as log_file:
            portalocker.lock(log_file, portalocker.LOCK_EX)
            timestamped_message = f"{datetime.now():%Y-%m-%d %H:%M:%S} {message}\n"
            log_file.write(timestamped_message)
            portalocker.unlock(log_file)
        # Also output to the debug console using logging module
        logging.log(level, message)
    except Exception as ex:
        # If there is an error writing to the file, we can fallback to a console print
        print("Error logging message: ", ex)
        print(message)

# Example usage similar to your  EZ-Script snippet:
log_message("Open, info, P1")
# Send servo command (example, assuming you have a servo function)
Servo("d4", 1)
# Wait for servo to move (simulate or call a waiting function)
WaitForServoMove("d4", 400)
Release("d4")

A Few Points to Consider

• Using Python’s Logging Module:
  The above example uses Python’s builtin logging module to add timestamps (both to the file and the console). Even though ARC’s debug console automatically adds a timestamp when printing, it doesn’t persist that information in a file.

• Handling File Locking:
  You mentioned that file locking was an issue in EZScript. The Portalocker library is useful in Python to avoid conflicts if multiple processes (or parallel script invocations) attempt to write to the log file at once.

• Central Logging Function:
  Having a centralized logging function (like the one above) helps you ensure that all parts of your Python refactored code write to a common log file and that you have consistent formatting and error handling.

• Integration with ARC Scripting:
  Since ARC supports Python scripting, you can include such a function in one of your common scripts or as part of a custom robot skill. Then, throughout your project, you can call your logging function instead of just print(), ensuring that both the console and file output stay synchronized.

Final Thoughts

Currently, ARC does not offer an automatic log file for the debug output; you’ll need to implement your own using Python’s logging (and optionally file locking) capabilities. This approach will not only replicate what you’ve been doing in EZScript but also give you more control and robustness in your logging process.

Do you have any additional questions or need further suggestions on integrating this custom logging function into your robot’s Python code in ARC?

Logging is a great idea. However, note that no third-party solutions can prevent errors from a locked file. A file is locked when two or more processes attempt to write to it simultaneously. As you can imagine, that can't happen because it would create a mess. It would be like two people typing a sentence simultaneously with two keyboards on the same computer.

Use the Python command.

File.appendStringLine(filename, str)

If multiple processes run, ensure the file is not open for reading while writing. Also, please do not keep the file open in an editor while it is being written to. You can use baretail or a similar program to monitor the lines appended to it.

Thank you for the feedback, and double checking I am not building code while something is already available.

I will create a (simple) Custom Logging Function in Python, basically try to lock the logfile (basic portalocker functionality) to write a log comment and if not possible retry a couple more times later. It is already an improvement to EZ-Script FileWriteLine (where writing to a locked file caused the script to crash/stop)

Actually I have an idea. Let me have a logging function created. That way it can run from any thread so there will not be any locks. I think it’s useful for something like this.

When dealing with reading and writing files, that’s generally handled in a single thread, or thread safe process. But a logging system would need to be resilient to multi threaded writes.

Thank you.

In EZ-scripting, I had something simple as

FileWriteLine( $logfilename, $time + ",info,P1," + "Open" )

that creates a .CSV file with file name/located in $logfilename and 4 columns:

• Time
• Type of log entry, e.g. info, warning, error, debug, etc (but will be happy to use any standard selected)
• Location, where the log entry is generated, which module/console/function/etc
• Description, the actual log entry

Looking forward to a standard ARC Python logging function!