Trigger Dig. Out depending on the covered distance
Thank you all very much for your answers and suggestions. I will try to understand them and then post some new questions here, for sure.
And especially thanks to you, andypough, for your HAL Code! I will add, try it out and then report here.
Cheers
Please Log in or Create an account to join the conversation.
your HAL Code
Just to be clear, it isn't HAL code, it is "comp" code to create a custom HAL component using:
linuxcnc.org/docs/html/hal/comp.html
Please Log in or Create an account to join the conversation.
This results in the next question, because the comp file is not compiling as it should.
pin in float xpos "should be connected to the x axis position feedback"
What is the right syntax to connect the feedback to that xpos pin in a comp file?
In the .hal file coming from the Pncconf Wizzard it is connected like this:
net x-pos-fb axis.0.motor-pos-fb <= hm2_5i25.0.stepgen.05.position-fb
and how do I link the "out" pin to one of the physical DO Pins?
Please Log in or Create an account to join the conversation.
What is the error message?This results in the next question, because the comp file is not compiling as it should.
What is the right syntax to connect the feedback to that xpos pin in a comp file?
In the .hal file coming from the Pncconf Wizzard it is connected like this:net x-pos-fb axis.0.motor-pos-fb <= hm2_5i25.0.stepgen.05.position-fb
In that case you can add xpos (etc) to the same net with
net x-pos-fb dashline.0.xpos
and how do I link the "out" pin to one of the physical DO Pins?
net somemeaningfulsignalname dashline.0.out => hm2_5i25.0.7i76.00.digitalout.00
Please Log in or Create an account to join the conversation.
linuxcnc.org/docs/html/hal/basic_hal.html
JT
Please Log in or Create an account to join the conversation.
I wasn't sure if the connection has to be made inside the comp file or the custom.hal
The compiling errors resulted from having some kind of "connection" inside the comp.
Another remaining question, if I look at the Pins via LinuxCNCs HAL-Meter, I see the dashline.0.motion-type changing, but also in the rapid traverse mode(1) the dashline.0.out is toggling.
Are the motion_type and motion_mask from
interpreted as the pins motion-type, motion-mask?if ( (1<< motion_type) & motion_mask)
Please Log in or Create an account to join the conversation.
Another remaining question, if I look at the Pins via LinuxCNCs HAL-Meter, I see the dashline.0.motion-type changing, but also in the rapid traverse mode(1) the dashline.0.out is toggling.
Are the motion_type and motion_mask frominterpreted as the pins motion-type, motion-mask?if ( (1<< motion_type) & motion_mask)
Yes. The standard for HAL pins is to use "-" as the separator, but that is not a legal character for a C variable, so they are substituted by "_" in the code.
If rapid-traverse is type 1 then the default motion-mask is wrong. Try setting it to 12 instead.
The machine I tested on was running a version of LinuxCNC where the motion-type pin was not available.
Please Log in or Create an account to join the conversation.
The function itself is plain c-code, right? So that I can add some things by myself, like turning the output to FALSE if in rapid move. Now it keeps the value at the beginning of the move...
Please Log in or Create an account to join the conversation.
The function itself is plain c-code, right? So that I can add some things by myself, like turning the output to FALSE if in rapid move.
Yes, just C. You probably just need an "else" for the first "if" and maybe want to reset the distance at the same time so that every G1 begins with a bit of "True"
Please Log in or Create an account to join the conversation.