Advanced Search

I measured again

from +5V to DIR+ = 5.13V and drops to exactly 5V when jogging in the negative direction


from +5V to DIR- is always at 0V That's for all channels on TB2 1, 2 and 3

Do you think i got a faulty board, Sorry this is getting so frustrating

The signals are differential but can be used single ended
That is DIR+ and DIR- should both change voltage when
the direction changes but one should change from 0 to 5V and the
other from 5V to 0 (relative to ground)

Measured differentially, you should always measure either
+5V or -5V across the DIR+,DIR- or STEP+,STEP- pins.

Yeah i checked it in halshow under parameters
step_type is 0

Is it possible that you have the incorrect step mode chosen in your hal file?

(step/dir is mode 0)

Hi everyone,I’m very new to LinuxCNC and Mesa boards, so I might be missing something basic here, but I’ve been stuck on this for a while and could really use some guidance.I’m working with a Mesa 7I76EU and setting up stepgens in LinuxCNC. When I use TB3 (channel 4), everything works perfectly. The motor moves in both directions, the direction signal changes correctly, and I can clearly see step pulses on the oscilloscope.The issue is with TB2 (channels 0–3). No matter which channel I use, I don’t get proper behavior. At first, measuring to ground made it seem like there was no voltage at all, which confused me. Then I realized these are differential outputs and started measuring across the pairs instead.On TB2, I can see step pulses across STEP+ and STEP− (about 5V differential), so the channel is definitely active. But the DIR signal (DIR+ to DIR−) stays constant at about 5V and does not change when I reverse direction. Also, the step pulses only show up when jogging in one direction, not both.In HALShow, the stepgen for that channel looks active. Enable is true, velocity command changes sign when I jog forward and backward, and position feedback and counts are updating. So from LinuxCNC’s side, it looks like the commands are being generated correctlyWhat’s confusing me is that TB3 works perfectly under the same setup, but TB2 behaves like this. At this point I’m not sure if this is something I’m misunderstanding about configuration or differential signals, or if it could be a partial hardware issue affecting only TB2.Has anyone run into something like this before? Any suggestions on what I should check next would really help.Thanks a lot

There was a problem with the limits and the estop on the input pins. I got that all figured out and now the machine is working and homing. I just now have to get it all tuned up. Thanks again for all your help.

The hardware spindle enable can never get set:

net spindle-output => hm2_7i76e.0.7i76.0.0.spinout
net spindle-enable => hm2_7i76e.0.7i76.0.0.spinena << hardware spindle enable
net spindle-ccw => hm2_7i76e.0.7i76.0.0.spindir

# ---setup spindle control signals---

net spindle-vel-cmd-rps <= spindle.0.speed-out-rps
net spindle-vel-cmd-rps-abs <= spindle.0.speed-out-rps-abs
net spindle-vel-cmd-rpm <= spindle.0.speed-out
#net spindle-vel-cmd-rpm-abs <= spindle.0.speed-out-abs
#net spindle-enable <= spindle.0.on << but the signal is not driven

One possibility is to change:
net pdnt.spindle.is-on whb.halui.spindle.is-on spindle.0.on

To
net spindle-enable whb.halui.spindle.is-on

and uncomment this line:

#net spindle-enable <= spindle.0.on

 

I have got my repaired 7i76eu board returned from Mesa, Thanks again Peter. I have all the limits and estops showing now on Hal show and they are working correctly. I try to home all or jog and the machine just vibrates and shacks until I hit the estop. I have checked everything I can think of. Except for the inputs for limits and estops etc that weren't working before I could get the machine to move, now I can't???? Everything was hooked up as it was before I don't think anything has changed.

I have a 4 axis router with step/dir servos using a 7i76EU+7i85 to command the servos and read the encoder feedback.  I have the servos reasonably tuned running closed loop.  But I'm seeing a following error spike on homing to index for the W axis (XYZW) on the first attempt at homing the machine after power up.  After the initial encoder position reset on the homing index it will home fine the 2nd try and works after that. If the machine was parked at the W-zero location when Linuxcnc is turned off and started it does not do the following error.  For some reason it seems like Linuxcnc is not ignoring the F-eror on the encoder index reset for the W-axis like it should.  Any Ideas how to fix this?

Here are my main hal and ini config files.
 

I recently got a new probe, and discovered that if I wired it *correctly* it did not work.  I had to wire it backwards, because the small current used to make the light go on when it "hit" was also enough to drive the 7i76E pin, so the probe was always "not hit".  So even if you follow the directions, sometimes it takes more debugging :-P
Always check the voltage at the pin!
 

Thank you for all of your help Peter, I have finished all of my testing now the conclusion is clear.

OK if you have +24V on TB1 pin 5 relative to TB1 pin 8
and no red LED above TB1 when LinuxCNC is not running,
The 7I76EUs field I/O section has failed or been damaged.

23.9v
Thanks

If you measure from
TB1 pin 8 (-) to TB1 PIN 5 (+)
 What do voltage do you get?

 

W1 is in the default position left and the fileld power is correctly conneced
Thanks
George