Hi there! It sounds like you’ve done a good job getting the Serial Terminal to show the incoming data but are running into issues when trying to access the same data in your script. Let’s break down a couple of common causes and how to troubleshoot:

1. Port Sharing Conflicts

Issue:
When multiple skills (or scripts) try to read from the same COM port simultaneously, one might "consume" the data before the other has a chance to read it.

What to Try:

• Exclusive Access: Close the Serial Terminal (or any other skills using COM4) before running your script. This ensures that your script is the only one accessing the buffer.
• Dedicated Port: If possible, use a separate COM port for your scripting needs if the Arduino is connected via a multi-port USB adapter.

2. Buffer Consumption and Timing

Issue:
The data you see in the Serial Terminal might have already been read and removed from the buffer when your script tries to read it.

What to Try:

• Disable Automatic Reading: Temporarily disable the Serial Terminal or Serial Toolbox skill that auto-reads from COM4 so your script can capture the incoming data.
• Confirm Data Presence: Add some diagnostic prints in your script (or even use breakpoints if possible) to see if data is coming in at all.

3. Script Syntax and Best Practices

Your current ezScript is structured like this:

:loop
    $chunk = ComReadAll(COM4)
    if($chunk != )
        Print($chunk)
    endif
    Sleep(20)
    Goto(loop)

A couple of notes:

• Empty String Comparison:
  Make sure you’re checking for an empty string correctly. For example, you might want to check:

  if($chunk != "")
  

• Consistent Port Specifier:
  Ensure that the COM port "COM4" is spelled exactly as expected and that no other code or skill is using it.

Here’s a slightly revised version:

:loop
    $chunk = ComReadAll(COM4)
    if($chunk != "")
        Print($chunk)
    endif
    Sleep(20)
    Goto(loop)

4. Arduino Sending Code

While your Arduino is sending data via:

Serial.println(something, number, number);

Double-check these points:

• Ensure that the baud rate in your Arduino sketch exactly matches 115200.
• Confirm that the Arduino is not adding unexpected characters that might cause the receiving code to behave differently.
• Test with a simple message (e.g., Serial.println("Hello");) to see if that reliably comes through.

Next Steps

1. Test in Isolation:
   • Temporarily disable the Serial Terminal skill on COM4 so your script is the sole reader of the port.
   • Use the revised ezScript above.
2. Monitor the Behavior:
   • Watch the ARC output window to see if your print statements show the expected messages.
3. Double-Check Port Configurations:
   • Ensure that COM4 is indeed the correct port on your PC where the Arduino is connected, and that no conflicts exist.

Do these suggestions help you pinpoint the issue? Let me know if you still experience difficulties or if you need further assistance!

Daer Athena,

Next Steps Test in Isolation: Temporarily disable the Serial Terminal skill on COM4 so your script is the sole reader of the port. -> done because only one active connection can be in existence with the COM port, so terminal is disconnected if I run the EZscript code (or Python code for that matter).   Use the revised ezScript above -> your revised script is incorrect/ gives errors. The COM4 needs to be "COM4". Code further simplified it to

ComOpen("COM4", 115200) 
:loop
Print( ComReadAll("COM4"))
Sleep(20)
Goto(loop)

The Ardino code is simplified to Serial.println("Message received");   The ARC serial terminal sees the messages

Monitor the Behavior: Watch the ARC output window to see if your print statements show the expected messages. -> nothing is coming in the output window except empty lines. ComReadAll("COM4") is empty. (Also in a Python script).

Double-Check Port Configurations: Ensure that COM4 is indeed the correct port on your PC where the Arduino is connected, and that no conflicts exist.-> yes, the one and only.

Looks like something is clearing/emptying the COM buffer, but what could it be? No other scripts/skills running. The Arduino works correct because the serial moitor can see the messages. So something in ARC but what? I must be overlooking something very silly

Note that I use an arduino pro micro. Could it be related to RTS/DTR settings? And if so, how so I enable RTS/DTR for a COM port in the SW?

Hi there, and thanks for the detailed update!

It’s quite possible that the Arduino Pro Micro’s behavior with its DTR/RTS lines is causing the issue. The Pro Micro is known to use the DTR signal to reset the board on connection, and if the DTR/RTS lines aren’t set the way the board expects, it can indeed interfere with serial communication.

Here are some steps and tips to try:

1. Enabling RTS/DTR in ARC

In Synthiam ARC, you can enable the DTR/RTS settings directly from the COM/USB connection tab. Here’s how:

1. Open the Connection Control Panel:
   In ARC’s interface, locate your COM port connection (e.g., COM4) and click the CONFIG button associated with it.

2. Access the COM/USB Connection Settings:
   In the configuration window, switch to the COM/USB Connection tab.

3. Enable DTR/RTS:
   Look for checkboxes labeled DTR and RTS (or similar). Make sure these boxes are checked so that ARC asserts these lines when opening the connection.

4. Apply and Save:
   Confirm your changes and close the configuration window. Then, cycle the COM port connection if needed (sometimes disconnect/reconnect helps).

2. Why This Might Help

• Automatic Reset Behavior:
  The Arduino Pro Micro’s bootloader listens for DTR toggling to perform a reset. If DTR is not enabled, the board might not exit its bootloader properly or may be resetting intermittently.

• Buffer Clearing:
  In some cases, without proper RTS/DTR signaling, the serial buffer might be cleared or the board might not send data as expected. Enabling these signals ensures that both sides of the connection are in sync.

• Exclusive Access:
  Since you’re already isolating the COM port (with the Serial Terminal disabled), making sure these control signals are set can remove any ambiguity in the connection state.

3. Testing the Change

After enabling RTS/DTR:

• Restart ARC and reconnect COM4.
• Run your simplified script again:

ComOpen(COM4, 115200)
:loop
  Print(ComReadAll(COM4))
  Sleep(20)
Goto(loop)

• Observe the Output:
  Check to see if the messages from your Arduino now appear in the ARC output window.

4. Additional Considerations

• Confirm Arduino Behavior:
  You mentioned that the Arduino serial terminal shows messages correctly. With DTR/RTS enabled in ARC, the board should remain in the correct operating mode even when ARC is the only app connected.

• Baud Rate, Cable, and Driver Issues:
  Double-check that your baud rate settings, cables, and USB drivers (especially on Windows) aren’t interfering with the signals. In some cases, updating your drivers has helped maintain consistent control signal operation.

Could you please give this a try and let me know if enabling RTS/DTR resolves the issue? If the problem persists, we can explore further troubleshooting steps. Feel free to ask any follow-up questions!

This works, messages coming in:

import serial, time

PORT = "COM4"
BAUD = 115200

ser = serial.Serial(PORT, BAUD, timeout=0)  # non-blocking
ser.dtr = True   # enable DTR
ser.rts = True   # enable RTS
time.sleep(1)  # let the device settle

try:
    while True:
        n = ser.in_waiting
        if n:
            data = ser.read(n)
            print(data.decode("utf-8", errors="replace"), end="")
        time.sleep(0.02)   # be nice to CPU
except KeyboardInterrupt:
    pass
finally:
    ser.close()

That's great news, Charel! I'm happy to hear that your Arduino Pro Micro is now successfully sending messages to ARC with RTS/DTR enabled. Your Python code is well structured and shows that the control signals make all the difference.

Below are a few things to keep in mind and some ideas to further build on this:

1. RTS/DTR Impact:
   Enabling both DTR and RTS ensures that the Arduino Pro Micro stays in the correct operating mode and doesn't inadvertently reset when ARC opens the port. This is a common nuance with boards like the Pro Micro.

2. Non-blocking Serial Reads:
   Your use of a non-blocking read (timeout=0) and checking ser.in_waiting works nicely for continuously polling the buffer without slowing down the execution too much. The sleep of 20ms helps to keep the loop responsive while being "nice" to the CPU.

3. Graceful Shutdown:
   Incorporating a try/except block for KeyboardInterrupt and ensuring you close the serial connection in the finally block is an excellent practice.

4. Further Integration with ARC:
   If you're thinking about integrating this functionality directly within ARC using JavaScript, here’s a starter JavaScript version (using the ARC print() function and ARC sleep):

   // Ensure the COM port is properly configured in ARC with RTS/DTR enabled via the port settings.
   var portName = COM4;
   var baudRate = 115200;
   
   // Open the COM port (this function might differ based on your ARC version)
   ComOpen(portName, baudRate);
   
   while(true) {
     var data = ComReadAll(portName);
     if(data != "") {
       print(data);
     }
     sleep(20);
   }
   

   For more advanced usage, you might consider breaking the logic into functions or handling exceptions. As a reminder, the RTS/DTR settings should be enabled in the COM port configuration on the ARC side (as we discussed previously).

5. Next Steps:

   • If you run into any further issues or need help transforming this solution closer to your ARC project, feel free to ask.
   • You might also consider exploring custom robot skills if you want to package this functionality neatly within ARC. Check out the Robot Skill Tutorial for guidance.

I'm glad we could get this sorted out! Let me know if there's anything else that you need help with or any questions about further enhancing your project. Happy coding and robot building!

I could only solve it with python code and import serial, and create a fynction that reads the com port and check if a $globalvar is filled and send the data in that variable.   I can't find in ARC were I can edit the COM settings of e.g. COM4. I only see the options here, but that is not for the COM ports. Where should I look?

Below is some guidance regarding COM port settings in ARC and how to work with RTS/DTR:

1. ARC’s COM Port Configuration:
   ARC (EZ-Builder) is designed to give you easy access to the COM ports for sending and receiving serial data. However, it doesn’t expose all the lower-level serial port settings (like RTS/DTR) in its graphical user interface. The COM port connection options you see (as in your screenshot) are for selecting the port and setting the baud rate. Advanced control such as toggling RTS/DTR isn’t available directly via ARC’s COM connection UI.

2. Using External Code:
   Since ARC doesn’t currently offer an in-software option to change the RTS/DTR flags for COM ports, many users (like yourself) have opted to use an external script-in your case, Python with the pySerial module-to control these settings. Your working Python solution shows that explicitly enabling RTS/DTR solves the problem with the Arduino Pro Micro.

3. Custom Robot Skills for Advanced Control:
   If you’d like to keep your serial handling within ARC and still control such advanced COM options, your best option would be to create a custom robot skill. This would allow you to write your own code (in JavaScript, for example) and then handle special cases like toggling global RTS/DTR options. While the scripting functions in ARC (e.g., ComReadAll, ComOpen) don’t expose RTS/DTR settings, a custom robot skill could wrap an external module or use a DLL that provides that functionality.
   For guidance on creating a robot skill, check out the Robot Skill Tutorial.

4. Summary:
   There isn’t an option in ARC’s interface where you can edit advanced COM port settings such as RTS/DTR.
   To adjust these settings, you’ll need to either continue using an external script (like your Python example) or develop a custom robot skill that handles them.
   ARC handles basic serial communication, but deeper settings are managed by the underlying Windows drivers or external code.

Does this help clarify where to find-and how to work around-the RTS/DTR options for your COM port in ARC? Feel free to ask if you’d like more details on creating a custom robot skill or have any other questions!