Help with custom handheld CNC router integration

[camchaney]

Hello! Glad to be here.

I have been working on an open source Handheld CNC Router project for a couple years now. When I first started this project, I made the gCode interpreter and most of the base firmware from scratch because it seemed less complicated than modifying a pre-existing interpreter to fit my needs. Now that I want to do more complex operations, though, it is starting to make more and more sense to just start with a pre-made, reliable gCode interpreter. Given that, grblHAL seems like an awesome choice.

Anywho, I was wondering if I could get some guidance to point me in the right direction for integrating my firmware into grblHAL. These are my main questions/considerations (apologies for any oversights):

• I need to collect sensor readings at a fixed frequency, optimally asynchronously, while all of the other motion control and path planning stuff is happening. I am trying to figure out where the best place to implement this sensing would be. Would it make sense to put it in somewhere in the protocol_execute_realtime function? The sensor readings are happening at around 1000Hz
• Because this CNC machine is "handheld", the effective coordinate system will be constantly changing. There needs to be another layer between the planner and motor control that maps the global coordinates to the device's coordinate system. I am guessing the best way to do this would be to make another kinematics implementation with mapping and motor control functions?
• Does the current SD card plugin allow for data writing as well? It would be nice to be able to log data for debugging

Other things that might be useful to know:

• I'm using a Teensy 4.1
• The sensors are PMW3360 optical flow mouse sensors
• The current device is 2D, but I am planning on implementing grblHAL on the new 3D coreXY version that I'm currently working on

Thanks!

[terjeio]

Would it make sense to put it in somewhere in the protocol_execute_realtime function? The sensor readings are happening at around 1000Hz

No, do not do that. Add your code to the millisecond tasks list instead.

There needs to be another layer between the planner and motor control that maps the global coordinates to the device's coordinate system. I am guessing the best way to do this would be to make another kinematics implementation with mapping and motor control functions?

A kinematics implementation sounds like the best approach. But I am not sure - you may need a control loop continuously correcting the motion which could be tricky with the planner and segment buffers in between.

Does the current SD card plugin allow for data writing as well?

No, but you can open files for writing to the SD card via the VFS. The SD card is mounted as the root filing system when available. And you can send debugging output to a dedicated UART port, or even to the main channel if you want near real-time access.

[camchaney]

No, do not do that. Add your code to the millisecond tasks list instead.

Ok, thank you for the pointer. I've never really worked with this sort of function implementation before so excuse my incompetence, but is this sort of how I would want to set it up? In a new pmw3360.c file (suitable for the plugins folder or in the core?):

long unsigned timeLastPoll = 0;
long unsigned dt = 900;  // (us)

void do_sensing() {
  if (micros() - timeLastPoll >= dt) {
    timeLastPoll = micros();
    // collect sensor data
    // do calcs
    // store relevant measurements in global variables
  }
}

void init_sensing() {
  task_add_systick(do_sensing, NULL);
}

Then I would initialize this task in plugins_init.h:

#if PMW3360_ENABLE
    extern void init_sensing (void);
    init_sensing();
#endif

But I am not sure - you may need a control loop continuously correcting the motion which could be tricky with the planner and segment buffers in between.

Hmm could I not just embed the control logic in the kinematics implementation? I honestly don't entirely have my head wrapped around how those buffers are worked in. Would this be a good use case for the pid functions?

[terjeio]

You should add a new folder for this initially - what to do with your code can be decided later if you want to create a PR for it.

Your do_sensing() function will be called every millisecond so there is no need to check micros(). If you need checking more often then you cannot add to the systick task list, depening on how precise you need the timing to be setting up a timer might be better but that may complicates stuff since a timer callback likely runs in an interrupt context.

Hmm could I not just embed the control logic in the kinematics implementation?

I would guess you need a tight feedback loop so you cannot have many milliseconds worth of pending motion in front of you. E.g. a single segment buffer entry typically holds about 5ms of motion which already is too much?

BTW do you have a working control loop in the code you wrote? Perhaps your best option will be to replace the planner and step generation stages?

[camchaney]

You should add a new folder for this initially - what to do with your code can be decided later if you want to create a PR for it.

Sounds good.

I may be able to work with 1ms polling rate. It's not too far off from 900us. Although, I am likely going to move the sensing to an interrupt in my current firmware anyways.

I would guess you need a tight feedback loop so you cannot have many milliseconds worth of pending motion in front of you.

You're probably right. I don't have the control loop at the moment as I'm still building out the path tracking for the 3D version. I'd prefer not having to replace the entire planner and step generation stages, though I guess that might be unavoidable. Hopefully most of it can be kept intact. One of the main reasons I wanted to switch to grblHAL was to be able to utilize the planning and stepper interrupt functionalities that are already built out.

The way I see it, this is the pipeline I'm going for:
gCode -> path planning -> coordinate transformation mapping -> controls -> kinematics -> drive steppers

And sensing would be happening asynchronously (potentially) in order to provide the state information for the transformation and controls. The transformation and controls would have to be done somewhere in between path planning and step generation. Does that make sense? Idk I'm sure I'm missing a lot here. I'm not exactly sure how that works in with the stepper interrupts and plan buffers.

Would it make sense for sensing and step generation to be put on the same interrupt?

I'm curious to test this out without the controls step and see how well the steppers are able to correct on their own. This is pretty much what I'm doing with the 2D version right now. I need to take a deeper look through the repository and get a better sense for the system architecture, though. I'm sleepy now and probably not thinking straight. I'll save that for tomorrow me...