Conversion of a China portal milling machine from Mach3 hardware controller

This doesn't matter - DHCP/BOOTIP is a network service.
It makes no difference under which operating system the service was implemented. It can be Linux/Unix, Solaris, IBM System i or whatever.
Even Windows or MAC OS - believe it or not - is capable of providing this network service.
The service features are defined in RFC's 1531 and 1541 and all mentioned operating systems are able to meet the requirements mentioned there.
A Linux DHCP server can serve Windows clients and vice versa without causing any problems.
The reason why the Mesa card doesn't play along here may be due to timing behavior or some other peculiarity.
But I think it's important to point out that there can be problems in this area. In this way other users can save time and I will - if there is time - get to the bottom of the matter.
But - and allow me to say this - there is no reason to counter terms like "this is va ery bad info" here.

You certainly know more about LinuxCNC and CAD/CAM in general than I do. However, I earn my money in the field of IT networks and just as I don't question your competence, I expect the same with my expertise.

The 7i76e is not just for linuxcnc and linux. But for our purposes in a real time situation, use of DHCP implies it is on a network with other devices which is a big NO NO for our use of it.

For us and Linuxcnc we want the 7i76e on a totally seperate network with no other devices. So we use a different link setting so the ip address is typically 10.10.10.10 and we set a fixed IP address (usually 10.10.10.1 on our PC with no gateway on that segment.

The network settings and the correct link settings are covered at length in my 7i76e video.

I see your point - but this is when mechanical engineers meet IT specialists.
Being on a network does not automatically mean that you can see and be influenced by the traffic of other devices. Separate VLANS, own collision domains, QoS and other measures enable the convenience that a large network brings with it as well as the certainty of always having sufficient transmission capacity for time-critical tasks.
I know what I'm talking about, because that's my daily bread. I oversee and develop warehouses for a global logistics service provider. The real-time control of hundreds of conveyor belts, switches, labeling machines and scales can only function over a widespread network. I don't even want to talk about the unmanned forklifts, which are also controlled via a network.
So, please let's not talk about latency and network load. I don't run a "normal" network where everyone talks to everyone. My home network is also my development lab and I dare say that the network connection from the LinuxCNC computer to the Mesa card is close to the physical maximum in terms of speed and latency.

And as a side note - what is the FPGA doing on the Mesa card?
Isn't it the case that the FPGA, as a highly specialized component, has the task of relieving the host computer and providing the necessary real-time capability when controlling a CNC machine? At least that's what Mesa says in its sales documentation...

I don't deny that real-time capability plays a significant role in controlling a CNC machine, but the question arises, in the case of a Mesa card, who is really controlling the CNC system?
Really the host computer? Or is it not rather the case that the computer sends commands to the Mesa card, which then takes direct control of the CNC system.
It would be a very interesting experiment to control a Mesa CNC installation with a computer, which is far away somewhere in the world and is only connected via a WAN connection...

In addition to the controversial and ultimately pointless network discussion, I made some progress today.
The X, Y and Z axes can be controlled and moved.
Still without home switches and without the right length of travel, but basically the hardware setup seems to be correct.

A small side note for all users of the probe_basic GUI. Never use locale special characters in the filename of the setup!
Pncconf can e.g. write and read a setup called "Portalfräse". This INI file manually adapted for probe_basic does not work and ends with a weird "character error".

RobertS wrote:

This doesn't matter - DHCP/BOOTIP is a network service.
It makes no difference under which operating system the service was implemented. It can be Linux/Unix, Solaris, IBM System i or whatever.
Even Windows or MAC OS - believe it or not - is capable of providing this network service.
The service features are defined in RFC's 1531 and 1541 and all mentioned operating systems are able to meet the requirements mentioned there.
A Linux DHCP server can serve Windows clients and vice versa without causing any problems.
The reason why the Mesa card doesn't play along here may be due to timing behavior or some other peculiarity.
But I think it's important to point out that there can be problems in this area. In this way other users can save time and I will - if there is time - get to the bottom of the matter.
But - and allow me to say this - there is no reason to counter terms like "this is va ery bad info" here.

You certainly know more about LinuxCNC and CAD/CAM in general than I do. However, I earn my money in the field of IT networks and just as I don't question your competence, I expect the same with my expertise.
 

BootP is not DHCP. The Mesa  Ethernet FPGA cards work with BootP, not DHCP.
DHCP cannot be used because it interferes with real time communications.
 

I don't get it.

At best my job description is "sh1t kicker". You know the guys you get annoyed at because you have to wait in traffic because there's road works going on or some idiot earlier hit a telegraph pole and the road is closed and traffic has to be diverted.

Anyways following the the Mesa 7i92 manual I had no trouble connecting my pc to the 7i92. It's pretty simple, follow the instructions and you will have success. As long as the "network" consists of the Linuxcnc PC, Ethernet cable and Mesa card all is good.

As far as I am aware Linuxcnc does all the trajectory planning (and all the other voodo) and works out the timing, this info is sent to the FPGA to create the signals required for the steppers\servos. Plus the FPGA handles talking to the IO,tho I'm not too sure what role the soft cpu plays.

A grbl board as I understand it gets sent raw gcode via a serial connection (over USB).

Sometimes you just need to forget what you know and follow the instructions. Kind of like trying to get your head around Quantum Mechanics, you need to put all you know about the classical world in a separate box.

What Mesa brings to the Linuxcnc table is mostly  hardware step generation followed by an amazing array of hardware interface.

Linuxcnc remains The Motion Controller at all times.
The trajectory planner creates waypoints which are ultimately translated to  step and direction pulses or other motion method.
With a Mesa card, Linuxcnc just tells a mesa card to generate steps at a particular frequency which it will do forever unless instructed otherwise.
Linuxcnc can change that commanded frequency 1000 times a second.

The alternative is a parallel port BOB and software step generation which puts a lot more pressure on latency as we need to run a much faster base thread to do the pulse generation and the frequency that an be generated is a lot less than the Mesa FGPA can do.
So you can go faster, and much more smoothly with a Mesa card where the base thread does not need to exist.

With your background, you may be interested to know that Linuxcnc supports Ethercat. Unfortunately due to licensing issues, its not built in so its a bit daunting to get going. I've been running ethercat drives on my office desk and am the process of getting them enabled on a real machine. I think the effort will be worth it but I don't think there is any great advantage over Mesa hardware other than fewer wires...
 

Unfortunately no success at all with the VFD and the spindle...
tommylight wrote to my post at the German part this suggestion:


I think that suggestion is right. The only uncertainty I have is with pin 2. The VFD only offers AI and no VI. The old Mach3 controller had an "AVI" connector to which the "VI" cable was connected.
That being said, I've now connected pin 5 & 7 to the "multi-function inputs" M1 & M2. I can program these to the values "Forward" and "Reverse" or "Forward Jogging" and "Forward Reverse". I tried both options, unfortunately no change.
By the way, I can measure 10.5 volts between pin 1 and pin 3. Well, unfortunately I've now reached the end of my wisdom - every idea is welcome!

By the way: If you have a recommendation for a suitable VFD, you are welcome to post it here. Then I have to reconfigure the VFD for the spindle as well, but who cares...

I add my current hal & ini file, may somebody can find an error (not hand edited - except the display, configured by pncconf)