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

[mpreishuber]

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

[dc42]

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

[chrishamm]

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.

[mpreishuber]

@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?

[chrishamm]

@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.

[Sejl]

@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

[dc42]

@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.

[Sejl]

@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!