Using G64 with M66 for smooth robot control

Hi, I've been using linuxcnc to control my delta robot arm through HAL pins and M66 commands.
This is my GCODE

I connect custom pins to the motion analog in pins and then set the xyz values in my python or c program.
This works great, but when I try to add G64 blending to make the robot keep its speed it doesn't work.
Obviously this is because the trajectory planner doesn't know the next target point until it's read by M66 in the next gcode loop, so I tried adding the next target point into the gcode as well with 6 analog inputs:

This only works for every other point, because when the gcode loops, the trajectory planner has no information about the next point.

What I would need is to load the next target point into the trajectory planner so that G64 can use it, but not go there with G1. I tried adding O500 continue between the G1s but then the gcode is smart and ignores the second G1.

Is there a way to do this?


 

Where are you reading those positional values from and how far in advance are they known?

The positional values are determined by a camera running object detection.

We're using it for a pick and place system so sometimes the entire move is known ahead of time (when object is being placed) but sometimes i want to change the target depending on camera feedback.

Have you thought about using the python interface to issue MDI commands to the queue instead of running a parametric gcode program?

Yes i played with the python MDI interface but it seemed to me like I couldn't get precise timings for my moves.

We're trying to pick up moving objects from a conveyor belt and MDI seems to have a delay.
Also, we want our robot to be VERY fast and we're going to be pushing it to its limits. MDI doesn't seem to fit into that.

The problem is that M66 is a 'queuebuster' command that halts the interpreter until gcode execution has caught up which makes it impossible to blend moves before it with moves that come after.

The only other possibility to influence axis position during gcode execution is external offsets:
linuxcnc.org/docs/html/motion/external-offsets.html

I'll make some more tests with MDI and see how feasible it is.
Motion blending is a must have for us.

Using MDI with python there's a 20ms delay between sending the command and the robot starting the move. There is also a 20ms delay between each MDI command i can send. So if i want to send 10 points to the robot it'll take 200ms to just send the commands.

This is far from ideal for a realtime application. Is there a parameter I can tune to speed up MDI?

@Hellvetica,

It's what Arciera mentioned before. External offsets could do what you want.
Mdi is just far to slow.

Using a custom trajectory planner:
I can imagine adding gcode lines at runtime including blends trough hal pins at runtime.
And even cancelling existing paht moves, and update them including blend to new target position.



 

I don't think you''ll get much more speed out of the python interface. There is also 'linuxcncrsh' which is written in c++, which might be worth a try (although as such also non-realtime) You can also connect to it over localhost:
linuxcnc.org/docs/html/man/man1/linuxcncrsh.1.html