Advanced Search

PCW wrote:

The USB Ethernet adapter is likely the main issue here

Running:

sudo chrt 99 ping -i .001 -q -c 60000 10.10.10.10

in a terminal window will give you an idea of the latency of the hosts Ethernet interface

( The command will run for 1 minute and then print timing statistics )

 

PCW, you are correct.

The adapter appears to be the main cause, see results in the previous post. New adapter is much faster.

rodw wrote:

I had a Yoga once. I even ran Linux in it. Nice laptop but no wired internet so not suitable for Mesa cards.
Even if it had one, the power savings features and very limited ability to tweak the BIOS would render it unsuitable.
If it had a PCMCIA card ( don't think it does) you might be able to install a PMCIA network adapter
 

I have another Yoga running LinuxCNC with a Mesa 7i96s and it's working great. for that one I'm using a Lenovo dock with Ethernet port. That dock connects to the Yoga via I forget what they call it but some sort of Lenovo proprietary connector that was used just prior to USB-C for docking stations.

The good news is that I picked up a different USB-C dock this morning and this one (iCan brand) is much faster than the crappy Amazon dock. Results as shown here...

jeff@SM10:~$ sudo chrt 99 ping -i .001 -q -c 60000 10.10.10.10

PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.

--- 10.10.10.10 ping statistics ---
60000 packets transmitted, 60000 received, 0% packet loss, time 60001ms
rtt min/avg/max/mdev = 0.070/0.097/0.629/0.028 ms

So I'm going to keep moving forward until I hit another snag.

Thanks to everyone that responded.

danke für die info.
Deine Videos sind gut, danke dafür.
Mein Problem habe ich gelöst, indem ich die Hardware getauscht habe.
Ich benutze jetzt einen Lenovo W530 .
Der W530 hat auch eine Netzwerk Controller Intel 82579LM verbaut.
Was mich in meiner Vermutung bestätigt das beim Laptop W520 der Netzwerk Controller Intel 82579LM , eine Fehler hat.

Danke der Fall ist gelöst.

---

Thanks for the info.

Your videos are great, thanks for that.

I solved my problem by swapping the hardware.

I'm now using a Lenovo W530.

The W530 also has an Intel 82579LM network controller.

This confirms my suspicion that the Intel 82579LM network controller in the W520 laptop was faulty.

Thanks, the issue is resolved.

grandixximo wrote:

@Aciera
Yes, I think Robert and YangYang will have much to discuss. I will probably mostly be on the sidelines, help YangYang with the English mostly, I think he'll do better than he thinks.

@ihavenofish
spikes you see on the scope are ddt of ddt of ddt, planner_type 1 has been running on real machines, it is not as expetimental as you might think, far from perfect I can agree, I can understand that you don't want to put your hardware on the line.
Not to worry about, I have hardware, you can see at www.aitalmac.com
Anyhow thank you for your inputs, have give me lots to think about!

Videos of it running on a stone bridge saw please!

We all want to see pretty moving pictures. mmmm.


 

Hello everyone,I have a question regarding the use of deadband in the calibration function.I am using a Delta servo motor. Previously, I ran the servo drive in position control mode (pulse train input), using a Mesa 7i77 for feedback control. In that setup, setting the deadband to 0.003 worked well and the motor was able to stay still without hunting.Recently, I changed the servo drive mode to speed control using ±10 V analog input, because I expected smoother motion compared to pulse train control (this was suggested to me earlier). After that, I modified my HAL and INI files to use analog ±10 V output instead of pulses.The problem is that I can no longer get the motor to stay still using deadband.When I apply any value to the deadband, the value of joint0.f-error immediately jumps to the deadband value, and the motor still shows oscillation near zero error. It feels like the deadband is not helping at all—in fact, it seems to make the behavior worse. The motor still dithers or ripples at the error endpoint.My question is:

• Is deadband supposed to be used differently when operating in speed control (analog velocity mode)?
• Is this behavior expected, and if so, what is the correct way to achieve a stable standstill in this mode?
• Should I avoid using deadband entirely in this configuration and rely on other parameters (PID, FF terms, output scaling, etc.) instead?

I would really appreciate any guidance or suggestions on how to properly tune this setup.Thank you in advance.

 
 
 

AI for Python, QT is very good.
I'm currently working on a gcode generator for the fourth axis. It was a lot of work, but I wouldn't have created this program without AI.

 

interesting discussion.
I am of the opinion that the limits of jerk, acceleration and speed should always be adhered to (load on the mechanics...).
If I want a higher or even speed, I have to design the milling path in such a way that a higher or even speed is achieved while taking into account the limits of jerk and acceleration (G64 Pxx, G64.1 for ...).
Inadequacies in the milling path should not be compensated for by violations of the limits of jerk and acceleration.

I would like the discussion to go more towards improving the S-Cutve

@Vegko
I changed your NC code a little (corner radius 0)

Sure, we're glad to get all the help we can get, this is just in the idea phase for now, so even just useful input would be nice, YangYang is not on board yet, it is just my idea at the moment, but I am not forcing it down anyone's throat, this has to be scrutinized by who understands more than me, or have different point of view on things, Grotius YangYang Robert ihavenofish, really I welcome all input, it should not be a fight, the correct solution I hope will arise from the collective experience of the community, and who is willing to share it, for the benefit of all.

My name is Santiago.
The email subject is: 'MESA ELECTRONICS - Argentina Shipping'.

I'm specifically looking for the 7i97T and 7i84U boards.

Not me, but i have a friend that i advised on using Claude for website coding, he swears by it as it was extremely useful to him...after the initial rage.
I would guess it should do a decent job at it for QT stuff as there is more info on the net it can search through, but i would try something different...

Hi Hakan,
just a quick follow-up to my previous reply: I can confirm that extending the LCEC driver to expose the drive’s internal following error works fine with the Delta ASDA-B3 drives.I mapped 0x60F4 (Following error actual value) into the TxPDO and added it as a HAL pin (including scaling to mm). This gives a much more reliable “real” tracking error compared to the LinuxCNC ferror which is affected by the EtherCAT timing delay.For reference:
I patched the LCEC driver , rebuilt linuxcnc-ethercat and had everything working within a couple of minutes. Two additional pins are now available: srv-ferror-raw and srv-ferror (scaled to machine units).

You can also make your own following error check routine in LinuxCNC (HAL-side).
It could even be a more intelligent solution, for example reducing speed/feed when the error becomes significant, instead of immediately throwing a fault.

For anyone who wants to implement this: just clone the linuxcnc-ethercat repo, replace the file in the, build and install it (

@ grandixximo ,
Thank you for the immense amount of time and effort you and your team are putting into this.
Side note, should i contact Grotius by phone and see if he can spare some time, or should i wait for now?

Has anyone tried ai services(claude/chatgpt/gemini) for developing custom user interfaces ?
I have tried ai for gcode generation and the results was almost perfect..

Hakan wrote:

And my brain hurts. 

That, i believe!
Thank you for the detailed explanation.

forum.linuxcnc.org/18-computer/54369-use...hernet-boards#313956
forum.linuxcnc.org/18-computer/54369-use...hernet-boards#313961