Advanced Search

I'm happy to report that building the 2.9 branch (incorporating the merged PR mentioned above) from the LinuxCNC github solved the problem - the mdi-command-NN pins show up and function as expected.  Thanks for the fix!

-Rob

Nevermind, I forgot how to correctly read and comprehend English.

I would use an RC filter if in a high noise environment

Also not sure from your description,  whats 24V and whats 5V
no 24V signal should be anywhere near 7I92T I/O pins

Can you do a:

halcmd show all | grep home > beforehome.txt

With LinuxCNC launched and enabled but before being homed

and

halcmd show all | grep home > afterhome.txt

With LinuxCNC launched and enabled after being homed (well at least home button pressed)

and post both berforehome.txt and afterhome.txt here?

Ahh, looks like the index is single ended, maybe that's the issue.

Unfortunately the 7I33, each encoder input is all differential or all single ended

So one thing to try would be to select single ended instead of differential
encoder mode one the 7I33. This is not ideal as it less resistant to noise
but may be OK.

If setting the 7I33 to single ended encode mode works, there is also
the possibility of using custom firmware that puts all the index inputs
on one 7I33 encoder connector  so you could have differential for A,B
but TTL mode for the Index signals.

Another possibility is to add a TTL to differential converter for the index signals
Mesa has such a thing, but its really just 1 chip on a board

(26ls31 or one of the many equivalents)

No, I also watched the Z- Index and spindle index (not as brief as X) but watched the pins in HAL-Show and they do not change either.
Thats why I thought I made a mistake in the HAL.
The 7i33: otherwise the motors rum smooth as the spindle does and are perfectly controllable (motor and spindle)
The encoder cable- most likely- I will check this asap.
Interesting is that the encoders have Ua1 and Ua2 both also inverted, but the Index Ua0 not (also spindle encoder)

 

OK So it looks like the FPGA card is OK.

This leaves the 7I33 and the cable

Do the other index inputs work?
 

HAl and ini files attached.  We are retrofitting linux cnc to work with a Bostomatic 3 axis milling machine using a mesaboard.  We have accomplished a lot however we cannot seem to figure out why our machine does not follow the homing procedure.  Jogging works, we have remapped M6 successfully... we even made a bust using the machine.  However when the home all button is pressed (using AXIS as gui), the only movement that occurs is the home offset or home (parameter) however many units they are set. We used halshow to reveal the signals as a way to hopefully diagnose the problem, but we have found is that some signals are not present and they should be.  For example the pins with the verb homing do not get signalled, but those that end in homed are set after the home-all button is pressed. 
I have read the Homing Configuration in the docs many times through and we have essentially exhausted every combination of home_search_velocity, home_latch_velocity...etc.  The configuration we want to use is one where latch_velocity has an opposite sign than home_search does and we are using the index, and our soft limits are being shared as the home switch. (home_ignore_limits = YES) .  I've been thinking the only solution is to write a custom homing module using homecomp  or an existing one perhaps cia-402.   A response either suggesting other fixes or how to use homecomp would be extremely helpful.  Thank you 

Sounds like you have a 5V power issue

Either to low a power rating or too long or too thin
5V power wires.

The blinking LEDs indicate that the 7I95T is resetting
This indicates marginal 5V power. Note that the 7I95T draws
significantly more power than a 7I96S.

I have the same problem with Raspberry 5 and 7i95T everything works fine when i use 7i96S but when I connect the 7i95T no light in ETH connector the CR15 and CR16 flash. When I turn 5V up to 5.3V then the 7i95T work

I have tested my rpi5 installation with octopus pro. Black pill and ec500 controller all are working. But now I am stuck on skr3.
@scotta @cakeslob please help.

Noticed the release announcement of Linuxcnc 2.9.5 and arm packages for Trixie, has the libgpiod version thing been sorted ?

Anyways thanks for the work guys.

On the bright side I figured out what my problem was. I had followed the documentation with recommended the preconfigured xpatria raspberry pi build and that did make getting everything up and running easy but, I didn't think to git clone the newer Remora developments since that image was released so I was running the older halcompiled remora-spi which I'm sure now was causing me issues. Now that I have pulled the most recent Remora version and compiled remora-spi again with halcompile like the docuementation says to do, although I noticed that in an earlier post it was mentioned that you no longer need the SPI_clk_div=32 after the loadrt remora-spi component in the HAL file but, mine wouldn't come out of estop until I added that back into the line. I also had a grounding issue and some EMI issues that collectively were causing my spindle to throw errors and after that and the correct version of firmware on the Octopus and most recent Remora branch then it looks like I'm good now.