Setting HAL pins from within NGC subroutines

More
10 Sep 2014 15:46 #51001 by DaBit
I know it is possible to read HAL pins from within ngc code (using #<_hal[hal_name]> and FEATURES = <feature mask> in the INI file) since LinuxCNC 2.6.
But is there also a method to set them other than using M6x of defining an M code that executes a script containing 'halcmd setp mypinname value'?

Please Log in or Create an account to join the conversation.

More
10 Sep 2014 18:34 #51013 by BigJohnT
You can set pins in Classicladder.

JT

Please Log in or Create an account to join the conversation.

More
11 Sep 2014 15:07 #51062 by DaBit
I read up a little about ClassicLadder, but I did not see a method to 'mis-use' it for changing the value of HAL pins from within NGC code?

Mind you, I would just prefer to do it from ngc code. Something like this in a remapped M code:

#<_hal[millturn-mode]> = 2
o100 do
o100 while [#<_hal[millturn-busyflag]> NE 0]

I suppose Parseltongue or just a bash script is more suitable. Or just plain M68 E0 Q2 followed by M66 P0 L2 and making the connections in HAL.

Please Log in or Create an account to join the conversation.

More
11 Sep 2014 18:51 #51071 by andypugh

I know it is possible to read HAL pins from within ngc code (using #<_hal[hal_name]> and FEATURES = <feature mask> in the INI file) since LinuxCNC 2.6.
But is there also a method to set them other than using M6x of defining an M code that executes a script containing 'halcmd setp mypinname value'?


No, the only way to set HAL pins in G-code is the M-codes you mentioned. This might be to ensure that things happen in strict sequence, which wouldn't necessarily be the case if the system was looking out into user-space for the values.

If it helps with readability the format
#<my_readable_pin_name> = 1
....
M66 P#<my_readable_pin_name>

should work.

Please Log in or Create an account to join the conversation.

More
11 Sep 2014 19:05 #51074 by DaBit
Yes, and so does a line of comment.

I will use M68/M66. That also allows me to wait for a falling edge on a HAL pin and provides a timeout without additional effort. No big deal.

I was just triggered by the following in the documentation :

This feature was motivated by the desire for stronger coupling between user interface components like GladeVCP and PyVCP to act as paramter source for driving NGC file behaviour. The alternative - going through the M6x pins and wiring them - has a limited, non-mmemonic namespace and is unncessary cumbersome just as a UI/Interpreter communications mechanism.


That made me think that there could also be an alternate method to do ngc->HAL communication.

Please Log in or Create an account to join the conversation.

Time to create page: 0.078 seconds
Powered by Kunena Forum