Advanced Search

Yes, that really made a difference! Much more distinct and quicker too.
I wonder if there is a way to upload a short video? All kinds of pictures are possible, yes, but a video?

Here is the only change I made in plasmac.comp.
It made plasmac skip the PROBE_UP sequence for the ohmic probe.
 

Ten 5 mm cuts in 1 mm sheet including probing before the cuts.
It goes down, contact detected and directly up to pierce height and starts the cuts.
 
I like this!

 

I know this may sound a little silly but is there a connection between the breakout board's gnd and the 7i97t ground. Some people have either forgotten this or just didn't know.
Not being familiar with your breakout board but does it require a heart beat pulse to enable the outputs ?

Sorry if this sounds a little too basic.

Many thanks Sven, probably I miss something in my config, maybe in the festo drive. Because when I launch linuxcnc the festo drives goes in error “EtherCAT process data invalid”. I’m not sure of the drive reference method on the festo side.
When I’m able I’ll upload my festo setup from the festo automation suite.
If it’s not a problem for you to share your setup it would be great.


Many thanks again, Lorenzo 
 

Thank you for the detailed explanation and the diagnostic command!
I’ve run the suggested test and got this result:
0001FFFF
As I understand it, that means the P2 outputs are alive and the U22 buffer is fine.
However, the motors still don’t move — there are no step/dir pulses visible on the outputs.
All firmware and HAL configurations are the same as before, when everything was working perfectly.
The P2 connection was made directly through a terminal breakout (type MC-IDC26-H),
and three servo drives were connected in step/dir mode (DB100S type drives).
Could you please advise where else I should look next?
Is there any way to further test the internal stepgens or confirm that the signals are being generated in the FPGA?
Also, which daughtercard would you recommend for connecting three drives via step/dir to the 7i97T - something that would provide a safer or more isolated connection than the raw P2 header?

Ah gotcha Dont know why it didnt cross my mind there may be a multiplication factor somwhere!

I believe this issue has been fixed in 2.9:
github.com/LinuxCNC/linuxcnc/pull/3537

Note that if you are considering to update the currently recommended version is 2.9.7pre:
forum.linuxcnc.org/21-axis/57364-axis-co...-9-6?start=10#336538

The issue with pendants not working in 2.9.5 and 2.9.6 has been identified and a fix has been pushed.
However there is currently a problem with the buildbot so a manually build 2.9.7pre .deb file is available here:
forum.linuxcnc.org/21-axis/57364-axis-co...-9-6?start=10#336658

1. What daughtercard is used to drive the step/dir outputs?

2. A relatively common cause of parallel expansion failure is voltage exceeding the -0.5 to +7V range applied
to any I/O pin (even for an instant). One easy way to do the is to plug in the P2 connector when the system is
powered and there  is no common ground reference between the 7I97T and the connected device.

3. When damage occurs, the typical damaged component would be U22, this can be checked with mesaflash
assuming W21 is in the up position and P2 unconnected, running:

mesaflash --device 7i97t --addr [card_ip_addr] --rpo 0x1008

Should respond with 0x0001FFFF (all P2 pins read high)

if not, its likely that U22 has been damaged

(U22 is ~$1.50 in ones and relatively easily replaced if you have hot air tools)

Hi new here.

Using linuxcnc 2.8.4-1 and having issues with g38.5 commands.  The probe I am using is a magnetic encoder on a rail and spring system to measure distance.  My hal is setup so that a displacement of >0.005in will trigger the probe input.  The gcode starts with a g38.3 to probe the piece to get its location.  Then using g38.5 command to determine the edge of a part by moving in z until the probe falls off.  I've had issues with "probe tripped during non probe move" so I am controlling the activation of the probe input signal with a digital io pin.  I am still getting "probe tripped during non probe move" errors and confused as to why it is still happening.  

Hal config:
#Negate Encoder Position
setp mult2.2.in0 -1.0                    
setp comp.0.in0 0.005                   # Threshold value for encoder
net enable-probe    <=    motion.digital-out-03    =>    and2.1.in1

# Encoder position and comparator
net negated-encoder-out <= mult2.2.out
net negated-encoder-out comp.0.in1       # Connect to comparator input
net encoder-threshold-met    <=    comp.0.out   => and2.1.in0

# AND logic to trigger only during probing motion
net probe-trigger and2.1.out motion.probe-input

Gcode:

M64 P3    (enable probing) 
G38.3 F15 Y1.6  (probe vertically into the part)
G38.5 Z4 F25 (drag off edge) 
M65 P3    (disable probing) 
G4 P0.1 (dwell to make sure the signal was sent to disable probing)
 

Now you have have a label with a LED that has a HAL pin so you can monitor just about anything.



JT

Thank you. I used that however when I get to freecad it doesn't want to engrave all the edges that don't form a closed loop. Even if I separate the groups it soems it still doesn't see closed loops as closed.

I'm missing something.

Thanks again

Thank you guys for the quick fix...  

cheers miniwini

I’ve been working with a Mesa 7i97Т (Ethernet) board for several months, building a custom machine for forming stainless steel strips (bender).
After long tuning and debugging, the system was finally running perfectly — all axes worked, PID loops were tuned, encoder feedback was stable. Everything was ready for production.However, at the very final stage, a strange and critical issue appeared:
→ All step/dir outputs stopped working.
The configuration hadn’t been changed, firmware is the same, LinuxCNC starts normally, encoder feedbacks are alive, analog channels respond, isolated I/Os work — but there are no pulses on stepgen pins anymore.I’ve checked:

• power rails — OK (5 V stable);
• FPGA communication — OK (hm2_7i97.0.readhmid works, pins visible);
• configuration and HAL wiring — unchanged, verified against backups;
• Ethernet communication — stable (no packet loss).

It really looks like something went wrong inside the P2 connector circuitry.
There is no visible damage, but all signals related to the P2 step generators are either completely absent or there are slight jerks on some axes.The issue happened suddenly, after months of correct work.
That’s why I suspect a hardware failure — possibly in the P2 line driver section of the FPGA or the buffer network.I’ve dedicated months learning, configuring and testing this system — and it’s extremely disappointing that such failure occurred when everything was already finished and tested.
Before I try to order a replacement board (delivery will take weeks), I’d like to understand:

• could this be confirmed as a hardware failure on P2?
• are there any known cases of P2 buffer/transceiver damage on 7i97?
• can I temporarily bypass stepgens via another interface (for example, through TB4 SmartSerial → external 7i85S module)?
• any diagnostic HAL tests to check P2 FPGA I/O status?
  
  I really liked the features of this board, but I am also very disappointed at the moment.

Any insights from Mesa developers or users with similar experience would be greatly appreciated.
Thanks in advance.

 I always think of them as rotor blades like a helicopter. That said I will have to give it another try.
The last time I tried it they looked terrible. Lets just say they needed a lot of sanding, to say nothing
about being balanced. I should have taken a picture of them as a what it shouldn't look like. LOL