Advanced Search

Hallo zusammen,

ich plane aktuell eine Sammelbestellung für Mesa-Karten (z. B. 7i76e, 6i25, etc.), da sich bei größeren Stückzahlen häufig günstigere Konditionen ergeben – sowohl beim Preis pro Karte als auch beim Versand.

Rahmenbedingungen:

Ziel: mindestens 10 Karten

Bestellung erfolgt gesammelt direkt beim Hersteller
!!!Vorkasse notwendig, damit ich nicht auf den Kosten sitzen bleibe!!!
Ich übernehme die Organisation und den Versand innerhalb Deutschlands

Preise sind noch nicht final, je nach Anzahl & Modell

Wer Interesse hat, bitte folgende Infos per E-Mail an "This email address is being protected from spambots. You need JavaScript enabled to view it.":

Betreff: [Name, Vorname]   [Modell]  [Anzahl]
z.b.:      [Lauterbach, Elias] [7i76e] [3]

Als Text dann den Versandort (Packstation Möglich)

Alles weitere erfolgt dann per E-Mail

Wenn wir genug zusammenbekommen, gebe ich die finalen Preise bekannt und sammle dann das Geld ein, bevor bestellt wird.
Ziel ist eine faire, transparente und zügige Abwicklung.

Viele Grüße
Elias Lauterbach

Something like:

loadrt or2
addf or2.0 servo-thread

net probe-wzl  <= hm2_7i76e.0.7i76.0.0.input-08-not => or2.0.in0
net probe-3d   <= hm2_7i76e.0.7i76.0.0.input-09-not => or2.0.in1
net probe-in     =>  motion.probe-input <= or2.0.out

Notes:

This assumes the "or2" is not already used

(if its already used, you need to add a new instance with the names or count stanza)

Also not sure of the individual 3d and wzl polarities

PCW, thanks a lot for the advice with the smaller resistor! I found one 2.2k with 1W in my boxes and used that today and voilá, it works as it should. Problem solved, I hope. (Don't know if I need noise reduction)Guys, I have no idea how to use sth like mux or mux_generic. I wouldn't even be able to use two inputs - but just out of curiosity , how would you do that in a HAL file if i would use an OR2:
 loadrt or2 count=1
net probe-in     <=  hm2_7i76e.0.7i76.0.0.input-08-not    
net probe-in     =>  motion.probe-input
and the second input hm2_7i76e.0.7i76.0.0.input-09 ? my programming scills are beginner level...
(Yes, I read the example in the LCNC HAL Examples to OR2 but I cannot convert that for my problem.)

Thanks and best regards!
Hanno
 

From what I’ve researched, the Mesa 7i76EU seems like the best option. Here’s why:

It has 32 opto-isolated inputs which should work well with the 24V NPN homing sensors

The 7I76EU inputs work directly with PNP sensors (or switches) NPN sensors will require pull-up resistors.

The sensors might need a pull-down resistor to give clean logic signals when connected to 24V. I already solderd a pc to convert the 30V signal back to a 5V system with opto's

7I76EU isolated inputs do not require any additional components with PNP sensors or switches.
Note that 5V signals will not work when you have 24V field power as the input threshold will be about
12V in this case.

No need for anything else.
7i76 is a daughter card, 7i76E has it's own controller. E means Ethernet.

Nope, 3 axis 4 joint CNC. I doubt EMI could be it, that data cable is shielded, less than a meter long and separate from power, too. But I'll check every wire.

Thanks! I think i will dive into the deep and order a 7i76EU. I don't need that much I/O now, but not sure in the future. I like to play with the idea of having more axis and sensors like endstops to the machine. Also i have coolant pump and airlines for blowing chips away. Its manually controlled at this moment, but automating this is on my list . One last question:

eusurplus.com/index.php?route=product/product&product_id=50

Is referring to a 'daughter' card. Would that imply that i need something extra?

Is this a plasma?

Thank you, that makes it more clear. I will measure all the cabling and ground connections.

I wouldn’t mind rewiring everything — my setup is quite simple, and the CNC machine is fairly small. For me, building and tweaking the CNC is part of the fun of the hobby.

I’ve read that many of you use various Mesa cards. I was hoping the 7i76EU alone would be a good starting point to learn how to work with Mesa hardware. Do you know if that’s the case? I saw some brutal shipment costs (like 200 dollar plus, so i will have to search for an European supplier, i'm in the Netherlands)

If the 7i76EU would allow me to completely move away from the parallel port, that would be a big plus — especially since I’m currently limited by base-thread latency.

[EDIT]

I see a seller with reasonable shipping costs, not sure if its a trusted compane EUSurplus?I think i am planning to switch to a Mesa board and wanted to check if the 7i76EU is the right fit for my setup. This is what I’m working with:

• 3x DM542A stepper drivers (they use step/dir signals)
• 3x LJ12A3-4-Z/BY inductive proximity sensors (used for homing)
• 1x Huanyang VFD (spindle, controllable via 0–10V or RS-485 Modbus (I think because i now use it over USB)

From what I’ve researched, the Mesa 7i76EU seems like the best option. Here’s why:

• It supports up to 5 stepper/servo axes via step/dir signals (perfect for my DM542A drivers)
• It has 32 opto-isolated inputs which should work well with the 24V NPN homing sensors
• It has 16 outputs, which are configurable (sourcing/sinking)
• It includes an analog spindle output (0–10V) for VFD speed control
• It supports RS-485 communication if I decide to use Modbus for the Huanyang VFD
• It isolates field I/O power from logic power, which helps protect the system

Important to note:

• The sensors might need a pull-down resistor to give clean logic signals when connected to 24V. I already solderd a pc to convert the 30V signal back to a 5V system with opto's
• I will need to supply 24V field power to the board 
• I understand the 7i76EU requires a second Ethernet interface on my PC (either a second NIC or a USB↔Ethernet adapter)
• I still need a PREEMPT-RT kernel, but I won't have to worry about tight base-thread latency anymore

Does this sound correct to those of you with experience using this board?Thanks in advance!

 

You would need a stiffer pullup so you get more than 12V at the 7I76E input

I would suggest 2.2K 1/2W

You could also use two separate inputs and an OR or MUX component
(the MUX component has the advantage of ignoring the other input
when not in use, but requires a signal to select which input shouls be active)

Hello again!
My next problem to get my machine running (it's running but not as precise as I want it) has to do with two switches.
My tool length sensor is a quite normal mechanical switch, that is NC and put +24V into input-08-not. That's working perfectly.
If I put my 3d Sensor (NPN-NO) into the line as the picture shows, nothing works. The 10k resistor (R1) before the Tool length switch puts the voltage down to 12.xVolts, the Input-08-not is set to "probing" permanently.
The 3D Sensor does nothing at all, not even the LEDs are active (the output is an open collector, I presume). What about diodes?
 

So, my next thought is to disconnect the two sensors from each other and use another Input of my MEsa 7i76e just for the 3D Sensor. This input should not be inverted for correct funktion. How can I do this with or without using an OR2 funktion?
My lines for the tool length are as follows

#---PROBE-IN ---
net probe-in     <=  hm2_7i76e.0.7i76.0.0.input-08-not    
net probe-in     =>  motion.probe-input

AFAIK, I cannot just net another input to motion.probe-input. But how could a OR2 look like?

Thanks for your help, again!
Hanno
 

If Step/Dir resistor networks or driver chips are being damaged
it means a voltage considerably outside the 0 to 5V range is being
applied to the Step/Dir pins.

First thing I would check is drive grounding and Step/Dir wiring
Routing step/dir lines parallel to servo motor wiring might also
cause enough EMI to damage the drivers.

An intermittent short to 24V wiring is another possibility.

A while ago, my MESA 7i76E broke; one channel just stopped working. I wrote about that here . I then found someone who repaired the card, after which the machine ran fine for half a year. He said he "replaced the resistor network" of the channel.

Today, the exact same issue appeared again. Joint 2 stopped working and after a restart it worked for a minute and went away again. This is exactly the behavior I saw last time.

This time though I was better prepared and had a spare 7i76E ready to replace the other one. After replacing it the machine ran fine - but after an hour the new card displays the same behavior, too! Clearly something is going on that breaks this channel... sometimes.

What would you do to diagnose this? Replace the JMC servo (with the built in controller) and hope for the best?

Hi Todd,

Thanks for your response — I’ll definitely give that a try, as it feels like my last resort with this current setup.

I've already disabled everything I possibly could in the BIOS. The only things I haven't touched yet are the memory timings and voltages. If this doesn’t work either, I’m honestly not sure what else is left to tweak.

I'm also considering switching to a Mesa card, possibly the 7i76EU, but I have zero experience with Mesa hardware. I’ll need to figure out whether it will work with my three DM542A stepper drivers, and also with my VFD, which is currently controlled over USB using: `loadusr -Wn vfd hy_vfd -n vfd -d /dev/ttyUSB0 -p none -r 9600`

Things i disabled next to the obvious, like settings for fixed clock speeds (fclock 1066, bclock 1000) disabling power management and disabling hardware that is not being used (BT, Wireless, serial, audio, fancontrol (disabled fixed on 100%)):

BIOS Settings (set to Disabled):

SMT / Hyperthreading
→ Disables logical cores to reduce cache sharing and latency spikes

C1E, C6, and other C-States
→ Prevents the CPU from entering sleep states, ensuring consistent timing

Streaming Stores Control
→ Avoids aggressive memory write optimizations that can disrupt real-time behavior

DRAM Scrub Time
→ Turns off background memory error checking to avoid unexpected memory bus usage

GMI Encryption Control
→ Disables inter-chiplet encryption on Infinity Fabric to reduce overhead and latency

XGMI TXEQ Mode
→ Prevents signal equalization tuning that could introduce instability or variability

DRAM Map Intervention
→ Disables memory remapping logic that can introduce unpredictable latency

DF Sync Flood Propagation
→ Prevents error broadcasts across chiplets, reducing the chance of system-wide stalls