What's the best practice to test G-code during a debug session?



  • Hi everyone 👋

    my name is Mario - obviously I'm new here - and I struggling with executing specific G- & M-commands on a Duet3 board while a debugger is active.

    The firmware debugging itself works fine. I'm able to build and start a debug session directly within Eclipse.
    However, it became tricky for me when I wanted to execute specific G-/M-commands during a debug session.

    I tried to ...
    (1) Send commands using the Duet Software Framework, but I'm not able to get a connection during a debug session.
    (2) Send commands using Pronterface (https://www.pronterface.com), but it didn't work either.
    (3) Load commands from SD cards. This approach works, but to me it is not really nice workflow. So, I really would like to avoid using a SD card

    Here, my actual question is:
    What's the best practice to test single & multiple G- & M-Commands during a debug session?

    Thanks,
    Mario

    Hardware

    • Duet 3 Board (ATSAM70Q20)
    • Segger JLink Plus
    • Raspberry Pi Model 3 B+
    • Notebook (Windows/OSX)

    Software

    • Duet 3 Firmware
      - RepRapFirmware: v3.01-dev
      - RRFLibraries: dev
      - CoreNG: dev
      - FreeRTOS: master
      - DuetWiFiSocketServer: master
    • Segger JLink Remote Server v6.72c
    • Raspberry Pi with DuetPi (downloaded on 2020-05-13)
    • Eclipse 2020-03
    • GNU Tools for Arm Embedded Processor v9.2.1 (0-2019-q4-major)

    Setup

    • Segger connects via SWD ping to the Duet3 board
    • Raspberry Pi connects via USB to the Segger
      • The Raspberry Pi works as remote debug server
    • Eclipse connects via the network to the remote debug server on the Raspberry Pi

    57BB82C4-B75C-49FD-BCB0-93D56D1FD7D3_1_105_c.jpeg


  • administrators

    You could try sending the command via the PanelDue serial port. Caution: it uses 3.3V signal levels; 5V will damage the MCU.


  • administrators

    To trace codes being executed from DSF, stop the service and start it with debugging output:

    sudo systemctl stop duetcontrolserver
    sudo /opt/dsf/bin/DuetControlServer -l debug -r
    

    Whenever you see e.g. HTTP: Sent XXXX in the log, you know that the code has been processed in DCS and that it has been sent to RRF for further execution.



  • @dc42 Thanks for the extremely fast response. Unfortunately, I don't have a PanelDue.
    @chrishamm Starting the DuetControlServer in debug mode might help understanding what's going on.

    What I don't understand is, why the DuetControlServer is not able to connect with the Duet3 board via ribbon cable while a debug session is active. Is this expected behavior or am I missing something here?

    2C7A51CE-99E7-42EF-BDB3-44F8DA65AC65_1_105_c.jpeg


  • administrators

    @mpreishuber DCS works best with low latencies and if it cannot establish a connection to the Duet 3 within a reasonable time, it will terminate again. Of course, if you pause the code execution on the MCU, the board won't be able to answer to DCS.



  • @dc42 said in What's the best practice to test G-code during a debug session?:

    You could try sending the command via the PanelDue serial port. Caution: it uses 3.3V signal levels; 5V will damage the MCU.

    Duet 3 Hardware Overview web page says: "The inputs will tolerate up to 30V. The outputs are 3.3V signals levels with 470R series resistors."

    I would like to know how can you damage MCU with 5V if input is tolerating up to 30V?

    Best regards


  • administrators

    @Sejl said in What's the best practice to test G-code during a debug session?:

    @dc42 said in What's the best practice to test G-code during a debug session?:

    You could try sending the command via the PanelDue serial port. Caution: it uses 3.3V signal levels; 5V will damage the MCU.

    Duet 3 Hardware Overview web page says: "The inputs will tolerate up to 30V. The outputs are 3.3V signals levels with 470R series resistors."

    I would like to know how can you damage MCU with 5V if input is tolerating up to 30V?

    Best regards

    I stand corrected. On Duet 3, PanelDue connects to the IO_0 connector, which is indeed tolerant of 30V on the input pin. On Duet 2 and Duet 085 it tolerates 3.3V maximum.



  • @dc42 said in What's the best practice to test G-code during a debug session?:

    @Sejl said in What's the best practice to test G-code during a debug session?:

    @dc42 said in What's the best practice to test G-code during a debug session?:

    You could try sending the command via the PanelDue serial port. Caution: it uses 3.3V signal levels; 5V will damage the MCU.

    Duet 3 Hardware Overview web page says: "The inputs will tolerate up to 30V. The outputs are 3.3V signals levels with 470R series resistors."

    I would like to know how can you damage MCU with 5V if input is tolerating up to 30V?

    Best regards

    I stand corrected. On Duet 3, PanelDue connects to the IO_0 connector, which is indeed tolerant of 30V on the input pin. On Duet 2 and Duet 085 it tolerates 3.3V maximum.

    Thank you!


Log in to reply