Updating Coordinates from external while idle

[MadTooler]

Can UGS receive coordinates and update the current DRO work offsets?

My application is manual movement of an XY gantry while motors are disable, as with M18, while getting new XY values from an RP2040/pico based controller that is reading encoders. When the M17 enable command is sent, or something similar, UGS would take back control of the current coordinates. I could send the updates in numerous ways, I am just not sure what, if any, existing methods of receiving them are available.

I appreciate any advice.

[breiler]

If you want to integrate with UGS in realtime I'd suggest the HTTP-API. See previous discussions here:
#2010
#2040
#1863

[MadTooler]

Thanks for your responses. I appreciate your time and all the work all of you have shared with the community!

I had seen those discussion and assumed that would be the general recommended approach. I am not clear on how to implement them yet. Do you have any examples of setting coordinates instead vs. requesting?

I didn't see any "set" calls for the axis in those examples. However, I did see a send gcode command. Maybe worst case I could send G92 or similar, but that seems like it might be messy.

Another alternative would be to directly change the values on the grblHAL board, but I am not sure if that will be better or worse in the long run for the ecosystem of coprocessors I am knitting together.

[breiler]

There is no specific API endpoint for setting the coordinate, you would need to send that gcode yourself.
You can start the UGS web pendant and inspect the HTTP-communication from the browser developer tools see how such a call should look like.

The call is made from the web pendant from this code: https://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-pendant/src/main/webapp/src/app/services/machine.service.ts#L88

[MadTooler]

I will give it a try. The code you pointed to was what I found. Not sure how to use it yet, but I will do as you suggested and observe the pendant in action.

For now, I will probably be using node-red as a go-between to get serial data over usb from my pico driver, then send http to UGS. It will be interesting to see if it is robust and fast enough.

[MadTooler]

Well, after a blunt force approach to viewing the pendant in action, meaning I don't know what I am doing and started clicking on lots of stuff in Chrome developer tools, I did see about what I was hoping for after clicking on send:
"http://192.168.4.1:8080/api/v1/machine/sendGcode"

I am not sure of the syntax to tack on to get the G92 X##Y## to that http line. I did try sending from the pendant G92 commands, and that works perfect for changing the coordinates. I now need to figure out the rest of the http line and I should be able to cobble together the rest for a proof of concept.

Do you know what I am missing?

[MadTooler]

Ok. I do not understand how this works, but I was able to send a json value to my address "http://192.168.4.1:8080/api/v1/machine/sendGcode" with node-red with success. I really don't know what it is doing different than the numerous manual entries I made, but that is OK. If I ever get to the point, I need to write something more streamlined, I know what to be looking into.

Thanks again!

[MadTooler]

What frequency can I send through the pendant api?

It sort of works, but then with a lot of lag. I started with about 100hz. I probably can get by with 10hz.

[MadTooler]

5hz is about where it is happy without falling behind. I would like a little faster, but 5 just does what is actually needed. I can capture coordinates at a much higher rate with the node-red middle man setup when I need that functionality later.

UPDATE: 8hz seems ok.