c++ grab in position signal
24 Sep 2014 16:06 - 24 Sep 2014 16:09 #51519
by ArcEye
It works fine
Instructions are here
www.linuxcnc.org/docs/devel/html/remap/s...d_sub_ini_features_a
Add to the [RS274NGC] section of the ini file
FEATURES = 8
Below the result
regards
Replied by ArcEye on topic c++ grab in position signal
I open a new thread in Gcode session for #<_hal[e.pin]> not working
It works fine
Instructions are here
www.linuxcnc.org/docs/devel/html/remap/s...d_sub_ini_features_a
Add to the [RS274NGC] section of the ini file
FEATURES = 8
Below the result
regards
Please Log in or Create an account to join the conversation.
24 Sep 2014 17:04 #51524
by bkt
Replied by bkt on topic c++ grab in position signal
I try with your same pin.....
I try with my custom pin .....
I try with my custom pin .....
[EMC]
MACHINE = my-mill
DEBUG = 0
[DISPLAY]
DISPLAY = axis
EDITOR = gedit
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL
MAX_FEED_OVERRIDE = 1.2
INTRO_GRAPHIC = linuxcnc.gif
INTRO_TIME = 5
PROGRAM_PREFIX = /home/k1/linuxcnc/open
INCREMENTS = 5mm 1mm .5mm .1mm .05mm .01mm .005mm
PYVCP=panel.xml
[FILTER]
PROGRAM_EXTENSION = .png,.gif,.jpg Greyscale Depth Image
PROGRAM_EXTENSION = .py Python Script
png = image-to-gcode
gif = image-to-gcode
jpg = image-to-gcode
py = python
[TASK]
TASK = milltask
CYCLE_TIME = 0.010
[RS274NGC]
FEATURES = 8
PARAMETER_FILE = linuxcnc1.var
[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.0
COMM_WAIT = 0.010
BASE_PERIOD = 78125
SERVO_PERIOD = 1000000#loadrt trivkins
loadrt deltakins_A_catch_GFX
loadusr -W ethloop
#loadrt tripodkinswhile [#<_hal[ethloop.fstop] EQ 1]
...
....> Please Log in or Create an account to join the conversation.
24 Sep 2014 21:37 #51530
by bkt
Replied by bkt on topic c++ grab in position signal
ok it works!
... new linuxcnc-dev compiler have found an error on one my comp .... nothing of special ... an unused variable
now with in ini file
one comment about infinite loop in gcode: Now I try it directly, but the same problem I had seen in the past. Linuxcnc trajectory planner (I don't now how it work....) but must have some sort of buffer. In fact, if I run an infinite loop with the variable X#<_hal[e.fpxdue]> that is updated with a command M160 UP and later a M170 DOWN command, must insert an M66 that says when the variable X#<_hal[e.fpxdue]> is updated. Otherwise the gcoge runs n times until for some magic trick decides to refresh the variable X#<_hal[e.fpxdue]> alone. I think that when its buffer is full deletes, and updates of new variables.
... new linuxcnc-dev compiler have found an error on one my comp .... nothing of special ... an unused variable
now with in ini file
[RS274NGC]
FEATURES = 28 ##or 8 or 12 it is the same for my result, this is try.
PARAMETER_FILE = linuxcnc1.var
one comment about infinite loop in gcode: Now I try it directly, but the same problem I had seen in the past. Linuxcnc trajectory planner (I don't now how it work....) but must have some sort of buffer. In fact, if I run an infinite loop with the variable X#<_hal[e.fpxdue]> that is updated with a command M160 UP and later a M170 DOWN command, must insert an M66 that says when the variable X#<_hal[e.fpxdue]> is updated. Otherwise the gcoge runs n times until for some magic trick decides to refresh the variable X#<_hal[e.fpxdue]> alone. I think that when its buffer is full deletes, and updates of new variables.
Please Log in or Create an account to join the conversation.
Time to create page: 0.187 seconds