I believe my BoB is optically isolated ( this is the link to it ). I just would like an example HAL file with my settings. When I measure with my multimeter after using stepconf, I get nothing even after I issue a command like s500 (my axes have all been zeroed). 

I'm replacing a 5i24 PCI card with the ethernet equivalent (7i80HDT): outputs go through a 7i33 + 2 7i37s. A previous posting (but referencing a 7i80HD-16) here said that the SVST4_8 bitfile would appropriately configure the card. Although the file is referenced in the manual, the file (neither .bin or .pin) does not exist in a newly downloaded (8/24/26) file set for the HDT card.
Where can I find a copy of the needed bitfile?
 

   attached find a screen dump of /tmp/isotri.ngc . This file was generated by an execution of polygonpockete.ngc (zipped).  My original goal was to make a log file which listed origin, endpoint, length and tilt of every line in my pocketed figure. This could be used to take advantage of highlighting in the MDI window on my version of linuxcnc.  Length and tilt are stored as comments on lines in the log file where a g0 gcode command to the line's origin and a g1 gcode command to the line's endpoint executed in a MDI window highlights an individual line after the execution ofpolygonpockete.ngc and an erasure of the lines it already highlighted.  To my  surprise the MDI window ignored the length and tilt following the ; and the linuxcnc interpreter went right by the g0 gcode command and executed the list of lines like it was a gcode program, a program containing lots of nasty numbers instead of nasty trigonometry. You'll have to edit polygonpockete.ngc to put the log file where you want it, see (logopen, (log, and (logclose)  The logfile does not contain any curved lines, nor does it contain the shortlines I put into polygonpockete.ngc to discourage the linuxcnc trajectoryplanner from rounding over the vertices.

Hi Aciera!

i solved it, my problem had several culprits.

1. I have a documentaion for my MPG, which told me which keys are generated. i don't know why, but for 3 buttons, the documentation was simply wrong..  While learning the keyd feature, i learned how to grab the sent keys...

2. With the right udev rules, i can load the "keyd virtual keyboard" into the hal-input.
Everything works fine now, 

3. I did not solve my problem that a few keys triggered the ui, i tried with -KRAL Option, no luck, but i remapped the keys with keyd, so ther is no interaction with the ui any more.

Thanks for your help!
I would say i start figuring out how to net the keys in the halui, i think i will need some help there, because all my buttons are push-buttons, with no lock in pressed-state.

Do you think it is helpful for other people how to handle keyd?
I can offer to write a small tutorial for this tool, but only it there are interested people around..

Greets, Tom

Be careful as many KBIC speed controllers have a analog speed control
input that connect directly to line power, so requires an isolated analog
voltage source.

You can use single ended encoders with the 7I96, to do so,
you must set jumpers W2,W3,W4 into the left had position.

This is described in the 7I96 manual on pages 2 and 12
 

I did finally get this problem to show in a sim, with your test program.
It didn't show with 3d_chips.ngc though.

I actually can see the spindle (by the spindle speed display) stops then starts again.

If I put an m5 in the on_abort.ngc file I could get it to always kill the spindle.
That is masking the problem, but would help in the mean time.

I am testing master, which I think you are using too.

I use this one wago 852-111, I used on ethercat, as daisy chain device as ethercat topology concept (I mean on input one output), I do not test a star or other network topology, I use this to split the same PC NIC with, mesa card and internet connection, it is working fine all together, but I do not test like intensive mode for several hours.  

I tried it with a VM and sim config, as well as with a real CNC (PrintNC) on a Pi5, same behaviour.

I installed a recent dev version ( github.com/LinuxCNC/linuxcnc/actions/runs/32728344015 ), and the linuxcncrsh coming with it works as expected. Since this dev version appeared to be a 2.10 pre-release, if the release of 2.10 is in the near future, I can live with using this dev version, don't see the need for opening an issue for 2.9.

Hi,

I currently am trying to control my spindle's speed using my BoB's analog output pin. It provides a max of 0-10 V out. I want to use this signal to control my KBIC speed controller, but it requires an analog voltage that is between 0 and 7 V. I'm not sure as to how to go about doing this. I've looked at the documentation but am still confused. I just want to test to see if it is actually working, so if someone could just slap together a HAL file that is able to do this so that I can test it, I would be really appreciative. I want my spindle to go at a maximum speed of 1400 RPM, and on my BoB the analog out is pin 1.

Thanks,
Logan

Question about sharing index-enable between s_orient and spindle for M19 / G33.1

Hello,

I am continuing my work on spindle orientation with a servo motor and would appreciate some advice about index-enable.

My setup is:

LinuxCNC 2.9.4
Servo spindle motor with encoder
Encoder A/B/Z connected to LinuxCNC
encoder.0.x4-mode TRUE
encoder.0.position-scale 4000
encoder.0.counter-mode 0
BASE_PERIOD = 30000
SERVO_PERIOD = 1000000

I have been working on spindle orientation (M19) and I have found that s_orient is very effective.

With the s_orient version of my HAL, the spindle can be run at relatively high speed (up to about 3000 rpm), stopped at different positions, and then correctly oriented with M19. The previous version using the standard orient component could lose its angular zero reference after running the spindle at high speed.

So I would really like to keep s_orient.

The problem

With the previous HAL using the standard orient component, I had:

net spindle-index-enable encoder.0.index-enable <=> spindle.0.index-enable

This allowed rigid tapping with:

G33.1 Z-5 K1

and M19 also worked reasonably well.

With the new s_orient version, I have:

net orient-index-enable encoder.0.index-enable <=> orient.0.index-enable

This gives a much better and more stable M19, but G33.1 no longer starts correctly.

During a G33.1 test I observed:

spindle.0.index-enable = TRUE
orient.0.index-enable = FALSE
encoder.0.index-enable = FALSE

So the request from spindle.0.index-enable does not reach the encoder.

For comparison, with the old HAL, the direct connection

net spindle-index-enable encoder.0.index-enable <=> spindle.0.index-enable

made rigid tapping work.

Current s_orient connection

The relevant part of the current HAL is:

net spindle-position encoder.0.position
net spindle-position => spindle.0.revs
net spindle-position => orient.0.position
net spindle-position => orient-pid.feedback

net spindle-velocity-feedback-rps encoder.1.velocity => spindle.0.speed-in

net orient-index-enable encoder.0.index-enable <=> orient.0.index-enable

net spindle-phase-a encoder.0.phase-A
net spindle-phase-b encoder.0.phase-B
net spindle-index encoder.0.phase-Z

And:

loadrt s_orient names=orient.0
loadrt pid names=orient-pid
loadrt mux2 names=spindle-mux

addf orient.0 servo-thread
addf orient-pid.do-pid-calcs servo-thread
addf spindle-mux servo-thread

net orient-enable spindle.0.orient => orient.0.enable
net orient-enable => orient-pid.enable
net orient-angle spindle.0.orient-angle => orient.0.angle
net orient-mode spindle.0.orient-mode => orient.0.mode
net orient-command orient.0.command => orient-pid.command

net spindle-oriented orient.0.is-oriented => spindle.0.is-oriented

The PID settings currently are:

setp orient-pid.Pgain 75
setp orient-pid.Igain 0
setp orient-pid.Dgain 0
setp orient-pid.FF0 0
setp orient-pid.FF1 0
setp orient-pid.maxoutput 50
setp orient-pid.deadband 0
setp orient.0.tolerance 2.0
My question

What is the correct way to share the bidirectional index-enable function between:

spindle.0.index-enable
orient.0.index-enable
encoder.0.index-enable

so that both of these work correctly?

M19

and

G33.1

I understand that index-enable is a bidirectional HAL pin, so I suspect that simply OR-ing the signals is not the correct solution.

I also tried checking for tristate-bit, but it is not available/loaded in my LinuxCNC installation, and trying:

halcmd loadrt tristate-bit

failed with:

waitpid failed /usr/bin/rtapi_app tristate-bit
rtapi_app exited without becoming ready
insmod for tristate-bit failed

I would like to keep the s_orient solution because M19 is now very effective and stable, especially after running the spindle at high speed.

I am only looking for the correct way to restore G33.1 / rigid tapping without degrading the s_orient behaviour.

Any advice would be greatly appreciated.

Thank you!