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.

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.

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.

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[...]>)