c++ grab in position signal

I suggest not to use this feature, it was an experiment and should be disabled. That said:

Variables of the #<_hal[pinname]> form are evaluated during readahead, which might be finished long before your machine even starts moving

Observing 'current position' or other execution-time values during readahead therefore are meaningless - by the time the pin is looked at the machine might not even have started moving yet. This is not a 'bug', it is the consequence of the interpreter execution model - do not use this feature unless you fully understand the implications.

You can force the interpreter to stop readahead, sync, and then read the pin, which assures that interpreter and motion are in sync. However, this may have consequences on the path as syncing will drain the queue and hence stop blending (and likely stop motion).

Find an example how to do this here: github.com/machinekit/machinekit/tree/ma...remap/stop-lookahead

- Michael

. Variables of the #<_hal[pinname]> form are evaluated during
readahead, which might be finished long before your machine
even starts moving

I suppose this .... I use this code

the program stop only at pos2.


thanks for the link.

You can force the interpreter to stop readahead, sync, and then
read the pin, which assures that interpreter and motion are in
sync. However, this may have consequences on the path as
syncing will drain the queue and hence stop blending (and likely
stop motion).

now this is what exacly happens in my code..... I study your example .....

I have the impression your heading down the wrong alley. This position-compare thing against HAL pins in gcode isnt going to fly IMO.

If you want to know if a given motion has stopped, test with M6x against a pin linked to motion.in-position. Done.

in my case [pin name] is [component.out] connected to custom stop button...

really I use other component.outx component.outy for example. the x y value is bring from ETH TCP connection to other PC. component.inrequest send TCP request. this part work fine. while loop not so good. M66 is connect to other component.control (connect to digital in) that "decide" when the outx and outy are updated. the problem: if press custom stop button the program stop only at pos2. Stop at pos1 only one run later (if I cancel if statement). At the same way outx and outy in hal meter are updated at exact time, but in gcode only one run later.

if I cancell M66, while cicle run "n" time whiteout update component.outx and outy, but in half meter it update at exact time........ I talk about "buffer" ( lookahead ....queue booster and this things) for this reason....

I use component.outx in subroutine ...... each while tour lasts 1 sec. or 0.7 sec. It's only an pick & place machine....

if I cancell M66, while cicle run "n" time whiteout update component.outx and outy, but in half meter it update at exact time........ I talk about "buffer" ( lookahead ....queue booster and this things) for this reason....

About updating of component.outx and outy..... I followed this path:
1- (component.comp) send the new values ​​component.outx and component.outy to g code. sending component.control M66 connected to P5
2-(gcode) after M66 and if statemen, I go to subroutine. I use the values ​​# <_ hal [component.outx]> and # <_ hal [component.outy]>. in the next row I ask new values ​​with M111 set up.
3- (gcode) In the next rowI make a motion. in the next row put down the request with M112
4- (component.comp) after M111 request set to 0 component.outx component.outy .... and then everything returns to repeat from step 1.

reset the values ​​component.outx and component.outy , before sending those new to gcode worked. If send the new values without reset is a problem, because the gcode not see immediately the new one.

I think the buffer ( lookhaed ) centers anything. If I reset the values ​​and then sending them everything is ok . If I upgrade only the gcode updates only after the tour . Write once variable = > buffer , write buffer twice = > 0

I said right or the reason for this change is to be found elsewhere?

I'd like to understand if I saw good , or if it is just a coincidence.

A new little question:

in my delta robot pik & place I entered the tracking of an axis / encoder to run the gcode ago when the position of place . The delta robot runs the place during the motion . This part work ok.

as suggested me andy - pugh I plugged in the kinematic function limit3. In this way I can have a sort of limitation of velocity when delta robot end the traking of external axis/encoder.

Problem: when gcode make the "PLACE" position (exmple in x300, y-50 z-900) , in fact the y-axis moves to achieve the tracking external encoder/axis (example go to x300 y200 z-900). OK, but when swich off enable of external encoder/axis ..... kinematics tends to return to the situation before the axes instantaneously (example to x300 y-50 z-900) in this case limit3 works but unfortunately I can't set limit3 value for all the case. If I set limit3 for all the case, my delta robot work too slowly. In my set limit3 sometime not work at all .... than I receive error axis traking!!!

My idea: when swich off encoder.n.enable, is find the way to pass at kinematics not the actual (y axis value - encoder offset) but a new y position commanded from gcode.

Is possible to do that??

Cancel ..... non sense request.