Advanced Search

To late but would have been better and probably cheaper to get DP-HDMI cable with more length, higher quality one should be 20-30$.
Do not install NVIDIA drivers on a machine PC with RT kernel, it does not work to be happy with it, and sometimes at all.
Now some better news, boot with the add on graphic, wait for it to go blank, wait a bit more, after roughly 2-3 minutes press and hold CTRL+ALT and press several times backspace, this should reset the X server and maybe, just maybe switch to working monitor.
Tip 2: connect another monitor to VGA port, boot Linux, go to prefernces and screen or monitors or displays, there chose and turn on the monitor on WiFi link, apply. If it works, reboot to check if the settings stick.
Tip 3: power on the PC with a working monitor, press or beat the right SHIFT key till you get the GRUB menu, hit E, use arrows to go to line containing "quiet splash" or similar and add after it "nomodeset", press F10 to boot, connect the WiFi monitor and disconnect the working one, wait for it to boot.
If any of those do not work, probably the WiFi dongle does not comply with HDMI standard communication, as i doubt the DP-HDMI adapter is not working, although i have seen DP-HDMI cables failing miserably to work on some PC's while worked fine on some other PC's.

Hi, sorry for the delay. Yes, that's exactly what it's about.

I was asking if there’s a restock schedule for some of those boards. I emailed PCW (who I was in contact with during the last months of 2025) and I also sent another one to Sales .

(Sorry PCW, I just realized you were the one who replied right above!) (EDITED)

It would be strange if they ended up in spam, but I'm asking here just to be sure. I just want to know when they'll be available so I can plan ahead and be certain I can buy the boards

Gogonfa wrote:

Hi Hakan,

If LinuxCNC always receives the position feedback ~2 servo cycles late, can I simply “ignore” this by increasing the following-error limits (FERROR / MIN_FERROR), or does this latency actually affect the LinuxCNC motion planner/trajectory execution?

In other words:
Does LinuxCNC only use the feedback for monitoring/fault detection (so the part accuracy is still fine as long as the drive itself tracks well and has near-zero internal following error)?

Or does LinuxCNC actively “react” to the delayed feedback (e.g. by slowing down, modifying the commanded motion, degrading contour accuracy), meaning I cannot machine precise parts even if the servo drive is perfectly tuned?

So the decisive question for me is:
Can I still mill accurate parts with this inherent 2-cycle EtherCAT feedback lag, as long as the servo drive is properly tuned and its internal following error stays low — or does the lag directly reduce machining accuracy?

Thanks a lot for clarifying this.

In position mode it has no impact, the drive is closing the loop. The feedback is just for "knowledge". So you set f error in linuxcnc to something reasonable (about 2mm on my machine cause its impossible to move that far in 2ms). Set the drives f error to something smaller if you need to.

 

More of a general Linux question but it's probably been a decade since I logged into any of my old Linux forums lol. 
My CNC machine is on wheels and my monitor sits on top of a file cabinet next to it. I broke my last monitor absentmindedly pulling the machine out to work on it and have almost done the same with my new monitor. 
My new monitor has HDMI or VGA. 
My computer internal GPU only has displayport. 

I bought an HDMI wireless adapter I would love to try to get working but it hasn't gone so well so far. 
I plugged it into my displayport to HDMI adapter cable but the internal GPU doesn't seem to see it and won't send signal to it. 
I bought an active displayport to HDMI adapter hoping that would fix it but no luck. 
I also have an old quadro 600 card that has a displayport and DVI. I haven't tried a DVI to HDMI yet. I might have an adapter laying around somewhere. 
With the HDMI wireless adapter plugged into the quadro with the active displayport to HDMI adapter it displays the boot manager to boot up but deactivates before it gets to the login screen. 

Now I'm trying to figure out the best way to move forward. I think I could probably figure it out on my own but I think it could take hours more. Possible options I think might be worth persuing. 


1. It seems like there is a way to force a signal to be sent to a displayport but it seems like the displayport still needs to detect something being there before it registers as a device to have that command work? 

2. The built in displayport doesn't display anything on startup with the HDMI wireless adapter into the displayport adapter, into the computer. 
The quadro card does but goes off before the login screen. 
Maybe it would work to force the signal to this port instead?
A semi related topic I found online suggested installing the Nvidia drivers. This is getting into a much bigger box of worms than I had hoped for my little Linux machine but if this would likely solve the problem I would do it. 

3. I think I can find a cheap graphics card online with an HDMI port. If this would be a better option and work out of the box, even just if it saved me needing to mess with installing proprietary drivers or anything I would be open to that as long as I was confident it would work. But if it puts me in the same situation as I have with the Quadro then I might as well just go with that. 

4. if there is an option, a wireless adapter, or anything else that would work better than anyone knows of let me know. 
If it's any help this is the one I currently have. 
www.amazon.com/dp/B0FVXVG3ND?ref=ppx_yo2ov_dt_b_fed_asin_title
It doesn't look like displayport wireless transmitters are really a thing which is kind of interesting. 

 

grandixximo wrote:

For example YangYang is now looking at stopping to destination with vel0 acc0 jerk0 all at the same time at the ends of an arc segment, in the servo-thread we compute next position forward in time, they keep adding up, and this leads to numerical errors, which make the jerk overshoot near the final destination, then you have to clamp down the error smoothly to arrive at destination, within current architecture you have to overshoot, you have to readjust, he has tried multiple avenues to fix this, nothing so far has worked.
How commercial TP fix this? they don't plan forward, they plan from destination backwards at each time increment with dedicated hardware, and deal with feed override changes by re-planning to a different time destination.
You can probably understand how different LinuxCNC is from commercial controllers, they practically work in the complete opposite way...
Many of the issues we are faced with, have similar kind of solutions in the commercial space, they just don't do it how LinuxCNC does it.
When I wrote "we are limited to what we can do", I intended it in the scope of implementing jerk limiting within the current TP, with tangential jerk limiting code that is being enabled with planner_type 1, and some blending and look-ahead improvements, to try and stick to jerk limited motion, without introducing any non-realtime code in servo-thread, sure a complete rewrite you can do whatever, but that is not something you do overnight. And we are also limited by physics, you can't have high-speed accuracy smoothness all at the same time, physics just don't allow this. I understand most here would sacrifice speed, but there is a camp that would like to squeeze out a bit more speed if possible sacrificing some accuracy within what's allowed by the gcode.




 

You'll need to change the TP. I'm not offering a $3000 cnc as a bounty for something you can vibe code overnight

Speaking of, a little bird told me that someone with the skills should request tormachs latest source....

DO IT NOW!

Hi Hakan,

If LinuxCNC always receives the position feedback ~2 servo cycles late, can I simply “ignore” this by increasing the following-error limits (FERROR / MIN_FERROR), or does this latency actually affect the LinuxCNC motion planner/trajectory execution?

In other words:
Does LinuxCNC only use the feedback for monitoring/fault detection (so the part accuracy is still fine as long as the drive itself tracks well and has near-zero internal following error)?

Or does LinuxCNC actively “react” to the delayed feedback (e.g. by slowing down, modifying the commanded motion, degrading contour accuracy), meaning I cannot machine precise parts even if the servo drive is perfectly tuned?

So the decisive question for me is:
Can I still mill accurate parts with this inherent 2-cycle EtherCAT feedback lag, as long as the servo drive is properly tuned and its internal following error stays low — or does the lag directly reduce machining accuracy?

Thanks a lot for clarifying this.

For example YangYang is now looking at stopping to destination with vel0 acc0 jerk0 all at the same time at the ends of an arc segment, in the servo-thread we compute next position forward in time, they keep adding up, and this leads to numerical errors, which make the jerk overshoot near the final destination, then you have to clamp down the error smoothly to arrive at destination, within current architecture you have to overshoot, you have to readjust, he has tried multiple avenues to fix this, nothing so far has worked.
How commercial TP fix this? they don't plan forward, they plan from destination backwards at each time increment with dedicated hardware, and deal with feed override changes by re-planning to a different time destination.
You can probably understand how different LinuxCNC is from commercial controllers, they practically work in the complete opposite way...
Many of the issues we are faced with, have similar kind of solutions in the commercial space, they just don't do it how LinuxCNC does it.
When I wrote "we are limited to what we can do", I intended it in the scope of implementing jerk limiting within the current TP, with tangential jerk limiting code that is being enabled with planner_type 1, and some blending and look-ahead improvements, to try and stick to jerk limited motion, without introducing any non-realtime code in servo-thread, sure a complete rewrite you can do whatever, but that is not something you do overnight. And we are also limited by physics, you can't have high-speed accuracy smoothness all at the same time, physics just don't allow this. I understand most here would sacrifice speed, but there is a camp that would like to squeeze out a bit more speed if possible sacrificing some accuracy within what's allowed by the gcode.

Ok, found it, this should be it
forum.linuxcnc.org/27-driver-boards/3497...iers?start=90#337507

Hakan wrote:

Position feedback from a drive is always two servo cycles behind.
 

Thank you pointing this out, somehow everyone keeps skipping this.
Not a deal breaker, but nice to know.

It's possible some percent of emails get put in the spam bucket
but losing many in a row would not be common.

Who did you email?



 

Ferrite beads on the motor wires near the drive are usually a must, and having an LC filter on the mains side never hurts.

They (PCW) always replies here, and almost always inside of a single day, no idea about e-mails.
What is your exact issue?

You hit the weak point in linuxcnc Ethercat.
Position feedback from a drive is always two servo cycles behind.
Following error due to this is at least axis speed x 2 x servo cycle time.
You can easily verify this.
 

In a terminal:Click on "glxgears" several times (5-10), leave it on for 15-30 minutes while doing something like copy files, watch youtube, etc and post the resulting screenshot.

Thank you very much.
It works perfectly.
Now we are trying to link all the inputs and outputs.