Accessing HAL pin from gcode
03 Oct 2016 11:56 #81175
by wn007
Replied by wn007 on topic 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.
Please Log in or Create an account to join the conversation.
03 Oct 2016 12:03 #81176
by andypugh
What is wrong with M66 L0 ?
Replied by andypugh on topic Accessing HAL pin from gcode
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 ?
Please Log in or Create an account to join the conversation.
03 Oct 2016 12:08 #81177
by wn007
Replied by wn007 on topic Accessing HAL pin from gcode
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.
thanks for the quick reply.
Please Log in or Create an account to join the conversation.
03 Oct 2016 12:14 #81178
by andypugh
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.
Replied by andypugh on topic Accessing HAL pin from gcode
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.
Please Log in or Create an account to join the conversation.
03 Oct 2016 12:32 - 03 Oct 2016 12:39 #81181
by wn007
Replied by wn007 on topic Accessing HAL pin from gcode
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.
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.
Last edit: 03 Oct 2016 12:39 by wn007. Reason: additional comment
Please Log in or Create an account to join the conversation.
04 Oct 2016 16:11 #81218
by andypugh
Replied by andypugh on topic Accessing HAL pin from gcode
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
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
Please Log in or Create an account to join the conversation.
04 Oct 2016 19:09 #81229
by wn007
Replied by wn007 on topic Accessing HAL pin from gcode
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.
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.
Please Log in or Create an account to join the conversation.
- Todd Zuercher
-
- Away
- Platinum Member
-
Less
More
- Posts: 4978
- Thank you received: 1377
04 Oct 2016 19:44 #81230
by Todd Zuercher
Replied by Todd Zuercher on topic Accessing HAL pin from gcode
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[...]>)
Please Log in or Create an account to join the conversation.
Time to create page: 0.079 seconds