Help/Ideas: grblHAL plugin for AZ/EL control via hamlib (rotctl/d) on waveshare RP2350 eth board

[conoredwards347]

Hi all,

I'm working on a grblHAL plugin to control a 2-axis stepper motor array (Azimuth & Elevation) using a Waveshare RP2350 ETH board as a remote stepper controller client, alongside another pi 3 acting as the remote sdr client. The aim is to integrate this board with satellite tracking software (Gpredict or Satdump) via the Hamlib rotctl/rotctld protocol over TCP/UDP.

The host machine will send tracking requests using Hamlib rotctl protocol, and the plugin will interpret these to move the motors accordingly utilising the grbl hal. I’ve started implementing the motion control part of the plugin and plan to start on the TCP/UDP client next to receive rotctl/d-style commands. The plugin isn't tested yet, and I’d really appreciate any input or suggestions.

Some background:

• I’ve got basic experience with C/C++ from university but nothing as complex as developing a plugin but interested to learn
• I have some equitment for testing, such as a oscillscope (Pico 2000 series - good little scope if you're tight on space and budget)
• Followed the online plugin material and followed steps to intialise and enable
• I’ve looked through the online plugin templates and HAL documentation
• Toolchain is set up for the Waveshare RP2350 ETH board in ubuntu, firmware developed using nvim a (preferred dev environment as ), and I’ve flashed/tested basic code on the hardware successfully
• Testing with a NEMA 17 stepper and a TB6600 driver

If anyone has pointers on:

• Best practices for implementing TCP/UDP clients within the plugin framework
• Handling external commands in the plugin pipeline
• How to build/flash grblHAL for non-standard boards such as mine
• Whether something like this is at all possible or is this a bit of pipe dream

…I’d be grateful! Thanks in advance to the grblHAL community.

[terjeio]

Best practices for implementing TCP/UDP clients within the plugin framework

Since the rotctld seems to be text based using "raw" telnet via a serial stream should be ok. The lwIP based stack already has support for telnet, and the ES-AT plugin also has. I am not familiar with the CH9120 chip, but I would think the ESP-AT plugin code might be useful as a starting point. Anyway, IMO, get yourself a W5500 based board from Wizchip instead and use the lwIP telnet/serial stream already supported by grblHAL. Or you could even start with a Pico W or Pico2 W board if wired ethernet is not required initially. Get a rotctld plugin working first, then add CH9120 support if you decide to go ahead with that.

Handling external commands in the plugin pipeline

The HPGL plugin is an example of how the G-code command parser can be replaced with a different one. You can automatically switch to the rotctld parser when a network client connects since an event is generated on connect/disconnect.

How to build/flash grblHAL for non-standard boards such as mine

Create your own boad map, enable it and required options in CMakeLists.txt and my_machine.h and compile using VSCode.

Whether something like this is at all possible or is this a bit of pipe dream

It is possible. If you decide to add support for the CH9120 chip then implement it as a raw telnet/serial stream in a separate plugin since that would make a rotctld plugin generic and usable with all networking capable grblHAL boards.