Accessing HAL pin from gcode

When you mention doing the calculations in HAL are you saying within the RT Component? Then how would I use the Analog Out to set the value within the g code? I know that M68 will synch analog out with motion so if that could be used then it might work. I was also looking at the source code to try and find a way to either create a new M Code for reading an Analog Input synched with motion or modify / extend M68.

wn007 wrote: I was also looking at the source code to try and find a way to either create a new M Code for reading an Analog Input synched with motion or modify / extend M68.

What is wrong with M66 L0 ?

I have tried M66 E0 L0 and it appears to break blending as in there is a pause between successive triggers. It would be great if I could use it but I don't think it synchronizes with motion like the M62 M63 and M68?

thanks for the quick reply.

wn007 wrote: I have tried M66 E0 L0 and it appears to break blending as in there is a pause between successive triggers. It would be great if I could use it but I don't think it synchronizes with motion like the M62 M63 and M68?
thanks for the quick reply.

It will have to empty the queue. I think that is unavoidable.

Outputs can be queued. There is no ambiguity about what value they will need to have at the point that that G-code line is executed.

Inputs can't be queued as there is no way to know what the value will be in the future when the motion is planned.
I suppose that the requirement to take a measurement could be put in the queue, but the interpreter has no way to know if the read-value will affect subsequent motion.

That makes sense. I am just trying to come up with a way that could work for our purpose. It just may not be doable. One way of course that works it to gen the g code ahead of time and intersperse the trigger points as needed. I am just trying to avoid the extra overhead and complexity with doing it this way.

What if there were 100 Lines of g code prior to the analog input and 100 lines after. By breaking it up this way would it have a chance that the interpreter would not need to empty the queue? Just trying to understand the impact of read ahead and the limitations I am bound by.

I am a bit fuzzy on the details here, but I think that the system actively stops adding to the queue after a M66 and then starts filling it again after the M66 is executed.

M66 is here:
github.com/LinuxCNC/linuxcnc/blob/master...erp_convert.cc#L2979

After all the checking the actual command sent to motion is line 3024

The WAIT command is here:
github.com/LinuxCNC/linuxcnc/blob/master...sk/emccanon.cc#L3136

And that contains a "flush segements()" call. AFAIK that means that the interpreter pauses there until the queue is empty.
Though it isn't obvious to me that this is what it does from the code: github.com/LinuxCNC/linuxcnc/blob/a2f0de...ask/emccanon.cc#L812

Thanks for the reply. I was looking at that same code. Would it be possible to disable the flush segments call in the WAIT function. I am attempting this based on the input_type being (ANALOG_INPUT). Not sure of the ramifications.

Also, I have compiled my changes and it does not look like I am running with those changes. I have a rip environment and that gets executed each time I open a shell. Not sure what I am missing.

Thanks again.

My guess (I am not a programmer an know nothing about the code) is that without the WAIT your analog input value won't get updated when the time comes but will be set to the value when the que is filled. (same problem you were having at the start of the thread with #<_hal[...]>)