wrote:

And even if it doesn't go anywhere this time governments will continue to try again. It's how the American
Government has gotten away with mandating kill switches into all new road vehicle
(2026 forward if I remember correctly). There is another bill that is suppose to repeal it (H.R. 1137) but 
I don't know if it passed or not. Given all the other crap that has gone on I wouldn't be surprised if it
got lost in the noise. 

 

As a side note from an earlier post, NO they have not repealed the stupid vehicle kill switch thing. It's just
the law hasn't been implemented yet.

 

Inadequacies in the milling path should not be compensated for by violations of the limits of jerk and acceleration 

It is not the case that we try to fix inadequacy of the path by spiking the jerk, is that we cannot control the jerk spikes period. This is not because we don't want to or lack of trying, is IMO fundamentally a limitations of the current tp architecture. YangYang is trying work arounds...

Yes, most machines you see on the website do, the one I have most problems with is the sawjets, because of the huge kinematics pivot.
The only issue I found that needs fixing with the latest code, is when I do codes to mill down the table, zigzag style, YangYang will take a look next week, he keeps patching that up. And then it comes back again...

Yes, I need to check it all. I did see previously that cia402 was not waiting for confirmation of homing or something so will watch for that....

Sounds like 100% the right thing!

Its just a snippet of code and not the whole picture.
But I wouldn't switch state before statusword says the drive has switched state.
It would be in some pending_switch_state perhaps.

grandixximo wrote:

You can find more on the youtube channel

Oooh. So this machine runs linuxcnc with jerk limiting?
 

You can find more on the youtube channel

I gave some detailed instructions to Grok last night then slept like a baby.. I always wanted to use a C union to break out status word etc into  bits starts to make it readable.
 
 

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.