I’m not sure how many encoders it showed on that page, I will confirm tomorrow. And thanks for the idea with the dummy config.
I will try getting it running tomorrow.

If I run discovery on a 7i92t_7i85x2d config I get:

 

with all 4 encoders on P2

Does pncconf show2 all 8 encoders on the configuration page? like this:

 


( These should be adjusted to the actual number required to avoid wasted transfer/processing time)


For the 7I83 I suspect the easiest current way to add the hal interface code is to make a dummy configuration
for a 7I77 configuration and copy paste the analog hal an analog section from that as an example
(changing the 7i77 name to 7i83 and the sserial channel number as required)

About 8cm-ish. pretty standard dupont wires for breadboards

Hi, I have a bit of a problem getting my initial LinuxCNC config up and running. I’m using a 7i92T (flashed with 7i92t_7i85x2d.bin) connected to a 7i85 and multiple Smart Serial cards (one 7i83, two 7i84, and one 7i73).
I tried getting it configured with PnCconf, aided by this post concerning unlisted Mesa boards:
forum.linuxcnc.org/39-pncconf/52554-disc...ted-mesa-fpga#299687

This mostly worked as expected, but I have two problems. One is that only two of the four encoder interfaces of the 7i85 are shown (this would be okay for now), and I cannot choose the 7i83, which means I am unable to have any PWM channels.
This means I cannot configure the X and Z axes, and because of that I cannot finish the configuration.

I am definitely doing something wrong. If anyone knows what that is, I would be extremely happy if someone could tell me where I am going wrong.

I also attached some pictures of what I am seeing right now.

Hallo,
ich denke NativeCAM ist aktuell das was deinem Wunsch als ShopMill-Alternative am nächsten kommt.
Da gibt es ja im Forum einen längeren Thread wie man das zum Laufen bekommt. Zudem gibt es mittlerweile mehrere Github-Forks von NativeCAM.

Wenn es da aktuell nur um Drehen geht, ist dieser Thread trotzdem interessant: 
forum.linuxcnc.org/qtvcp/58056-latheeasy...-programming?start=0
Da stellt cmorley seine QT-Portierung von NativeCAM vor.

Die Frage ist ja ob die Entwicklung in diese Richtung noch so wichtig ist bzw weitergeht, da es mit FreeCAD ja mitlerweile ein sehr gutes CAD-System gibt (das deutlich mehr kann) welches direkt auf dem LinuxCNC-Rechner läuft.

Viele Grüße 
Michael
 

I used to work with two machines that were stuck using older Ubuntu based Linuxcnc RTAI. Both ran servos, not stepper motors. One was because I could not get newer Linux kernels to work with the ISA IO card the machine was using, the other for extreme low latency to control torque mode servos. The ISA card machine was eventually upgraded to newer Mesa hardware and moved on to current Linux/Linuxcnc releases. The other is still running older RTAI.

I still have a machine running it. Needed for a low latency control for some difficult to tune torque mode servos. (So for the time being that machine is stuck on Linuxcnc 2.7)

Hello,I've been working on this for the last few days and now understand how to add switches graphically under user_buttons/template_main/template_main.ui (see attached photo).However, I don't know how to link the light switch to the output of my Mesa 7i76e, for example. I tried to implement net light => hm2_7i76e.0.7i76e.0.0.output-02 <= qtpyvcp.light in my postgui_hal. Unfortunately, that didn't work. What am I overlooking as a newbie? 
And in addition i´d like to have a nice looking Led right to the button. Red = off, green = on. I could not find one in QT Designer. Alternatively, the button itself could change from red to green.

Translated with DeepL.com (free version)

Thank you for taking the time to look at that.

I will clean that up.

Now that I'm using my ethercat machine daily, I'm seeing some odd issues. Sometimes on startup it will trigger error b2 on the drives rapidly. this is apparently a timing conflict with modbus. Happens every dozen start ups.

Today i had a new one. I homed that machine, and then it began triggering joint errors and limits exceeded despite being nowhere near limits. i had to reboot the computer, and then it was fine.

If the machine starts "fine", it stays fine, but there is some flakeyness with the start up sequence.

Another thing I notice is when I tune my servos perfectly in the omron (usb) software, when they start under linux they are resonating, vibrating like 1 micron in travel. I don't know if that's a linuxcnc thing, and ethercat thing, or just a stupid omron thing.

Other than these quirks though, its great and I would not switch back for anything haha.

need that jerk control......

Hello everyone,sorry for posting a year later. I had a lot going on and put my 5-axis milling machine project on hold.Yesterday I finally managed to recover the 7i95T. Since I’m definitely not the first – and won’t be the last – to flash the wrong firmware, I’ve put together a small guide describing how it worked for me.Thanks, PCW, for describing the procedure — it helped me a lot.Now I’m a bit more familiar with the Mesa cards. Nothing comes from nothing.

Best regards!   

I like the text and button hi lights. I just prefer a darker main background. Very Nice. 

You should not need ui changes for these pins to work.
There is a description on the pins on the page before this one.

Hi Rod,

I think there is a small misunderstanding about what I was trying to say. I’m not claiming that EtherCAT needs heavy tweaking to run at 1 kHz — I fully agree that with decent hardware, a 1 ms servo thread often works out of the box, and EtherCAT as a protocol is designed for that class of cycle times.

My comment was specifically aimed at the earlier “8 kHz on the host” remark. That kind of statement mixes three different layers: the drive’s internal loops (which indeed run at several kHz), the EtherCAT communication cycle, and the LinuxCNC host servo thread. Once you start talking about pushing the host loop into the few-hundred-microsecond range, things like DC setup, cycle stability, NIC behavior (EEE, IRQ coalescing, etc.) and jitter stop being details and become the main engineering problem. That was the point I wanted to make.

When I said Mesa tends to be more “KISS”, I meant it in an architectural sense, not as a value judgment. EtherCAT is a full industrial fieldbus: multi-vendor, DC, flexible topologies, designed for distributed systems — that’s a big strength. The hm2-eth approach is intentionally simpler and focused on talking to the card, with the time-critical I/O timing living in the FPGA. Different tools, different trade-offs.

I also don’t think a fully centralized-in-one-panel setup is where EtherCAT really shines. It still works perfectly fine that way, and in fact I think it’s great that many people run it like this today, because that’s exactly how the LinuxCNC + EtherCAT integration gets exercised, debugged and improved in practice. Its main advantages just show up much more in distributed architectures, with drives and I/O spread across the machine and synchronized via DC.

For context, I’m actually looking at EtherCAT for my own project because it’s a modular machine (about 2 m per module, ~16 m total), where a distributed setup makes a lot of sense. That’s exactly the kind of case where EtherCAT really shines. So my comments are not “against EtherCAT”, but about keeping the architectural layers clear and not mixing up internal drive loops with very high host loop rates.

So yes, EtherCAT at 1 kHz on LinuxCNC works fine in many setups, as you said. My concern was only about the conceptual jump to “8 kHz on the host”, which is a very different class of problem.

Hi,NWE,

That’s a fair point, and I agree: EtherCAT (and the lcec stack) has a much richer network/state model and clearly handles link loss and recovery more gracefully than hm2-eth. That kind of supervision and recovery is a real advantage of EtherCAT as an industrial fieldbus.

My earlier comment wasn’t about network robustness or error recovery, but about where the time-critical control loop lives when people start talking about very high host rates (like “8 kHz on the PC”). Those are somewhat orthogonal aspects: EtherCAT is stronger as a fieldbus and in fault handling, while the Mesa approach keeps the tight I/O timing in the FPGA and is more “KISS” on the host side. Different strengths, different trade-offs.

Thanks for the discussion, and all the best to everyone doing the hard work in the trenches.