I like that Athena is helping me to spell correct, etc. But changing the question is not such a great idea. .. Tried to edit the question but it keeps changing back. This is not an EZ-Script question. It is a question about the python API, the sleep root command in the python API

Below is some background on the two approaches and our recommendation:

ARC’s Root sleep() Command

- When you call sleep(timeMs) in ARC’s Python API, you’re using a function that’s part of ARC’s core scripting root commands.
- It accepts time in milliseconds (so sleep(50) pauses for 50 ms) and is integrated with ARC’s event scheduling and control system.
- Using ARC’s sleep() ensures that your delay works consistently within the framework and that any ARC-specific handling (such as debugging or internal timing adjustments) is taken into account.

Standard time.sleep() from Python’s time Module

- This is the native sleep function from Python and expects time in seconds (so you’d write time.sleep(0.05) for 50 ms).
- Though it works well in standalone Python scripts, it hasn’t been specifically optimized for ARC’s environment.

So Which Should You Use?

- In Synthiam ARC, if you’re writing your scripts using the ARC API (even in Python), it’s better to use the ARC-provided sleep() root command.
- Doing so removes potential unit confusion (milliseconds vs. seconds) and maintains consistency with the rest of ARC’s scripting environment.
- This ensures that pause operations are handled in a way that’s fully compatible with the robot’s control processes and ARC’s timing architecture.

For example, in ARC Python code you can simply do:

print("Starting delay") sleep(50)     # Pauses for 50 milliseconds print("Delay complete!")

In contrast, using the standard Python approach would require converting milliseconds to seconds:

import time print("Starting delay") time.sleep(0.05)  # Also 50 milliseconds pause print("Delay complete!")

While both work as delays, using sleep(50) ties your code more directly into ARC’s system and avoids additional conversions.

Do you have a specific scenario where timing accuracy or integration with other ARC robot skills is critical? Let me know, and we can dive deeper into any performance or compatibility nuances for your project.