Help selecting new PC to run Mesa 7I92 Ethernet

More
26 Jun 2019 22:54 #137937 by tommylight


It's my pleasure to share my work with you tommylight
I'll record a video and upload configuration file here soon
The DC Servo motors are ABB controlled by BOSCH Drives
I already followed your procedure to tune motors but I barely get the straight line and it change with the time, that's why I wanted to replace the PC


Thank you very much.
I do not need it personally , I just felt bad that I could not help the user who needed it since I never retrofitted such machine. I have done plenty of other machines.
If you get a nearly straight line, you are very near, just keep adding numbers after, example, 0.23 just add another number like 0.234 and test again, add 0.2345 and test again, till you get a straight line, and you will eventually .
If that line moves after a while on it's own, that is a sign that drives are getting hot ( very rarely ) or motors have issues with brushes, so you should open the back of the motor only to where you can we the brushes and use compressed air to clean them. That will fix the moving f-error line for sure.
The following user(s) said Thank You: AElmasry

Please Log in or Create an account to join the conversation.

More
29 Jun 2019 22:49 #138209 by AElmasry

OK so you have a intel MAC, this means you will need to disable a Ethernet driver feature called "IRQ coalescing" if you have not already. This is described in hm2_eth man page

You can do this temporarily (till the next reboot) with the command:

sudo ethtool -C [your_ethernet_device_name] rx-usecs 0

Where [your_ethernet_device] is eth0,enp0s25 or similar
You can determine the Ethernet device with the command:
ip a

You can check if this works by checking the 7i92 ping times before and
after you run the above ethtool command

Can you post a halscope plot image of the problem you see?
From your description, it does not seem servo thread or PC timing related


This is ping result before doing anything


Then I added the following line to interfaces file:

hardware−irq−coalesce−rx−usecs 0


Then got this ping results
It's almost the same result


Is 0.3 ms a good time for ping result or not?
Attachments:

Please Log in or Create an account to join the conversation.

More
29 Jun 2019 22:54 #138210 by AElmasry

you can also do this in the interfaces
sudo gedit /etc/network/interfaces

#7i92 2019
auto eth0
iface eth0 inet static
address 192.168.1.4
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
dns-nameservers 8.8.8.8 4.4.4.4
hardware-irq-coalesce-rx-usecs 0


then
sudo /etc/init.d/networking restart
if it fails
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start

ofcause as you got the 7i92 jumperd
if yoiu use other networking adresses just correct it


This is how interfaces file looks like now


Do you think the other lines you added can make a diffrence?
Attachments:

Please Log in or Create an account to join the conversation.

More
29 Jun 2019 23:11 #138212 by AElmasry

Thank you very much.
I do not need it personally , I just felt bad that I could not help the user who needed it since I never retrofitted such machine. I have done plenty of other machines.


Yes I remember while I got a very hard time trying to make it work
I spent more than 6 months working around 4 hours per day after my work to get it work
It was 2 years ago
But I left it with some problems and now trying to solve all of its problems
Sure I'll be very happy if I can help others


If that line moves after a while on it's own, that is a sign that drives are getting hot ( very rarely ) or motors have issues with brushes, so you should open the back of the motor only to where you can we the brushes and use compressed air to clean them. That will fix the moving f-error line for sure.

Yes that's exactly my case but it added something new in Y axis, ferror curve in forward is totally different from reverse direction, when I try to fix the reverse ferror I damage the forward direction.
I'll try cleaning the motor brushes and report the feedback.

Please Log in or Create an account to join the conversation.

More
29 Jun 2019 23:30 - 29 Jun 2019 23:31 #138213 by PCW
Well, that's fairly terrible latency (I see a 370 usec there and there may be worse)

Do you have all power management turned off?

If Intel AMT is an option in the BIOS, it should be turned off also

Heres a DC7800:

peter@dc7800:~/linuxcnc/configs$ 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.130 ms
64 bytes from 10.10.10.10: icmp_seq=2 ttl=64 time=0.080 ms
64 bytes from 10.10.10.10: icmp_seq=3 ttl=64 time=0.080 ms
64 bytes from 10.10.10.10: icmp_seq=4 ttl=64 time=0.080 ms
64 bytes from 10.10.10.10: icmp_seq=5 ttl=64 time=0.084 ms
64 bytes from 10.10.10.10: icmp_seq=6 ttl=64 time=0.084 ms
64 bytes from 10.10.10.10: icmp_seq=7 ttl=64 time=0.090 ms
64 bytes from 10.10.10.10: icmp_seq=8 ttl=64 time=0.081 ms
64 bytes from 10.10.10.10: icmp_seq=9 ttl=64 time=0.081 ms
64 bytes from 10.10.10.10: icmp_seq=10 ttl=64 time=0.081 ms
64 bytes from 10.10.10.10: icmp_seq=11 ttl=64 time=0.080 ms

(the first ping is longer because the host needs to do an "ARP who has 10.10.10.10" before the actual data transfer)
Last edit: 29 Jun 2019 23:31 by PCW.

Please Log in or Create an account to join the conversation.

More
30 Jun 2019 21:45 #138258 by tommylight
Side info, from PCW "ARP" is address resolution protocol so it has to send a query to the network to identify the owner of the requested address, in this case 10.10.10.10.
Was it you who asked for help here? I recalled mentioning the user name of the guy who did the retrofit, but he never replied . Now he is back asking for help again. As you might have noticed from my reply back then, I was convinced he will not help, although he was active in the forum at that time. He also did some other retrofits but never helped anyone here.
Never mind, this is not helping you.
I do own a Lenovo Think centre m93 if I am not mistaken and it has very stable low latency, did plenty of testing on it with 7i92 and 6i25.
I have also some Asus Prime Z270A boards, very good and low latency, but still pricy.
Did not check an Asus J1800 board with included processor and a parallel port with Preempt-RT, but with RTAI it works nicely.
On another thread I mentioned an Acer laptop that works perfectly with Preempt and 7i92, also user Pl7i92 mentioned some fujitsu-siemens that he uses.
Add the HP that PCW mentioned and you at least have a bit of room to find something.
BTW, is the PC wired directly to the mesa board? I can't remember if I already asked that.

Please Log in or Create an account to join the conversation.

More
01 Jul 2019 13:51 #138299 by tommylight
Here is the result of the PCW's advice on a Dell Latitude E6510 that has terrible latency !



Without it, it drops the connection at random, with it no dropped connection for over 15 minutes.
I use this laptop strictly for testing, this one should not be used on a machine.
Attachments:

Please Log in or Create an account to join the conversation.

More
01 Jul 2019 13:53 #138300 by tommylight
BTW, if you did not notice, you are using what PL7i92 suggested, not what PCW suggested. Those are different things.
Try the PCW's suggestion and report back.
The following user(s) said Thank You: AElmasry

Please Log in or Create an account to join the conversation.

More
01 Jul 2019 15:51 #138305 by AElmasry

Well, that's fairly terrible latency (I see a 370 usec there and there may be worse)

Do you have all power management turned off?

If Intel AMT is an option in the BIOS, it should be turned off also

Heres a DC7800:

peter@dc7800:~/linuxcnc/configs$ 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.130 ms
64 bytes from 10.10.10.10: icmp_seq=2 ttl=64 time=0.080 ms
64 bytes from 10.10.10.10: icmp_seq=3 ttl=64 time=0.080 ms
64 bytes from 10.10.10.10: icmp_seq=4 ttl=64 time=0.080 ms
64 bytes from 10.10.10.10: icmp_seq=5 ttl=64 time=0.084 ms
64 bytes from 10.10.10.10: icmp_seq=6 ttl=64 time=0.084 ms
64 bytes from 10.10.10.10: icmp_seq=7 ttl=64 time=0.090 ms
64 bytes from 10.10.10.10: icmp_seq=8 ttl=64 time=0.081 ms
64 bytes from 10.10.10.10: icmp_seq=9 ttl=64 time=0.081 ms
64 bytes from 10.10.10.10: icmp_seq=10 ttl=64 time=0.081 ms
64 bytes from 10.10.10.10: icmp_seq=11 ttl=64 time=0.080 ms

(the first ping is longer because the host needs to do an "ARP who has 10.10.10.10" before the actual data transfer)


I diabled all power management and AMT




and got a little bit lower timing



I tried also to disable multiprocessor but got the same results

Attachments:

Please Log in or Create an account to join the conversation.

More
01 Jul 2019 15:56 #138306 by PCW
I would not disable multi-processor

Did you try disabling irq coalescing from the command line as tommylight showed above?
(just to make sure its really disabled for your test)
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

Time to create page: 0.491 seconds
Powered by Kunena Forum