Advanced Search

Yes, I would expect something like this from ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether ec:b1:d7:6c:a2:da brd ff:ff:ff:ff:ff:ff
    altname enp0s25
    inet 10.10.10.100/8 brd 10.255.255.255 scope global eno1
       valid_lft forever preferred_lft forever
3: wlx74da388d8d1c: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 74:da:38:8d:8d:1c brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.146/24 brd 192.168.1.255 scope global dynamic noprefixroute wlx74da388d8d1c
       valid_lft 49687sec preferred_lft 49687sec
    inet6 2601:644:880:e3de:2f6a:cfcb:a8e0:4106/64 scope global temporary dynamic


As tommylight said, there is a network setup error (no static IP on the interface connected to the 7I92TM)
(notice item 2: on the ip a report above)

Some things to consider.

What Linux distribution is being used.
There may not be pre built packages available for your Linux setup.
Which python version is installed could be a limiting factor.
The Real time kernel version being used.
If there is no prebuilt packages available you will need to build linuxcnc from source.
Are you absolutely 100% sure it’s linuxcnc under the hood ?
If there is any custom hardware in you setup, the big standard linuxcnc sources may not have any suitable drivers.
Then there’s the spec of the computer currently running everything.

I think the first thing you need to do is to confirm 100% that it is “linuxcnc under the hood” and what if any customisations have been made.

First picture, something is very wrong with networking, reply from 192.168.0.141 should never be there.
Chances are you have two sets of IP addresses there, by clicking on "add network" in the network manager, i am sure that is not there, never mentioned ever, it clearly says to edit the "wired connection", the existing one.
Delete the one you added, edit the existing one.

According to the certificates of my three 5um glass scales from china the deviation is between 5 and 10 um (max length 400mm).
But of course the price for these is probably an order of magnitude lower as well.

ip a only shows the WiFi, ip a|grep 10. shows nothing.

I cold booted it and did a continuous ping - didn't even start the UI, and it went offline after the same ~30 seconds.

But then it came back.  started responding to Pings again.

let me try swapping net cables.
 

I got the original Heidenhain production calibration reports with my Maho. The worst of the three, had a worst deviation of 0.4 µm if I recall correctly. It would be interesting to calibrate a chinese 1µm scale and see how accurate they are. I would not be surprised if they easily exceed the accuracy achieved by Heidenhain 50 years ago.

The LEDs look OK (what you would expect if communication was lost
rather than losing power)

It could be a failed 7I92T or something on the host (the ping times are quite flakey)

What does the command

ip a

report

Do you have link and 100BT LEDS on the 7I92T RJ45 connector? (Green and Yellow)?

I would expect ping times to look more like:

peter@peter-HP-EliteDesk-800-G1-USDT:~$ ping 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
64 bytes from 10.10.10.10: icmp_seq=1 ttl=64 time=0.119 ms
64 bytes from 10.10.10.10: icmp_seq=2 ttl=64 time=0.121 ms
64 bytes from 10.10.10.10: icmp_seq=3 ttl=64 time=0.121 ms
64 bytes from 10.10.10.10: icmp_seq=4 ttl=64 time=0.123 ms
64 bytes from 10.10.10.10: icmp_seq=5 ttl=64 time=0.123 ms
64 bytes from 10.10.10.10: icmp_seq=6 ttl=64 time=0.124 ms




 

After years of using the default stepgen timings I've noticed they are much larger than needs be. Using PnCConf Wizard and selecting G540 generates:

DIRSETUP   = 5000
DIRHOLD    = 5000
STEPLEN    = 10000
STEPSPACE  = 10000

www.geckodrive.com/support/g540-manual-rev8
Step Pulse “0” Time2 uSStep Pulse “1” Time1 uSDirection Setup (Before step rising edge)200 nSDirection Setup (Hold after pulse rising edge)200 nS

PNCConf G540 timing will require 20usec per step when it only requires 3usec. I believe the PnCConf Wizard should be generating:

DIRSETUP   = 200
DIRHOLD    = 200
STEPLEN    = 1000
STEPSPACE  = 2000

I realize these timings are not the limitation in most cases. I think stepgen has similarly loose timing but I'm no longer using that. I have not tested mesact to see if this problem is across the board.

 

Just received this Mesa board - my first outing with these.  Previously I'd been using native parallel.

Using TommyLight's network config and a Youtube video on Pncconf I got it configured, but when I start LinuxCNC it runs for maybe 30 seconds, then the card appears to go offline.

Here's a before and after ping: 
 

Here's the UI throwing comms failures
 

Here's the LED status lights on the board
 

And here's the power supply I'm using for testing.  I started out with a 5V 2A brick but switched to this to confirm clean power

 

Has anyone seen this?  Suggestions? or should I ship it back to Mesa?

Thank you,
 

If it runs under both I doubt it would be Linuxcnc, I’d guess it would be a proprietary application that communicates to the controller board. If the driver board communicates via USB it certainly will not be Linuxcnc.

It would be nice if you could link to the appropriate section of the manual.
The best way to find out would be to ask for the Linux sources from the company.

Spam and spammer removed.

Just the spindle?
An and2 component wired before spindle.on should do just fine.
That is all in hal.
So the spindle runs only if the probe trigger is closed and spindle is commnded from hal.

It doesn't. It is an older version of Centroid, If you look up centroid CNC10 and look up the manual, (page 2-1) it can run under Linux or windows, when mine boots, I can see it's Linux.

The LS904 output their analog sin waves:
product.heidenhain.de/JPBC/image/HWP.DE/...06-92_ls_804_904.pdf
You will need EXE's to do the A/D conversion before inputting the signal to the Mesa. Whether you use a three axis EXE board like the one you mentioned or three individual ones is only a packaging issue. On my Maho, I had a similar three axis EXE. One channel was dead, and one was unreliable. I now use the one functioning channel, and two stand alone EXE's.

Those three axis EXE boards are three completely separate channels. There is no electrical connection between them, Not even the supply power or ground are common.

Ich gehe mal davon aus, dass 'probe_screen.py' noch in python2 geschrieben ist. LCNC 2.9 unterstützt nur noch python3.

Beim QtDragon Gui ist probing integriert (Schau mal in den Simulationskonfigurationen):

forum.linuxcnc.org/38-general-linuxcnc-q...obe-screen-ng#282759

[Edit]
Für eine genauere Fehleranalyse könntest Du deine Konfiguration in einem Terminal starten und die Meldungen hier posten.