Advanced Search

Had a quick look, seems OK.

emresensoy wrote:

 
  - 2 free G-Codes per day

 

It says 5 gcodes there, and then 1$ for every gcode.

  We developed a web-based, free G-Code generator for CNC users.

  Features:
  - 13 machining operations (pocket, contour, drilling, slot, counterbore, chamfer and more)
  - Auto cutting parameter suggestion based on material & tool
  - 3D toolpath simulation with interactive viewer
  - Estimated machining time calculation
  - Mobile ready (PWA) - works on your phone
  - 2 free G-Codes per day

  Try it now in your browser: cam232.com/cam.html

  #CNC #CAM #GCode #Manufacturing #Machining #CNCMachining #Industry40 #EgeRobotics #CAM232
 

papagno-source wrote:

I was thinking, can we ask the kernel developers, how can we recompile the kernel, eliminating all the power optimizations, so as to optimize it for RT applications? If we continue like this, soon Linux will only be used for writing emails and using OpenOffice.

There is no need to dive into the kernel. All of the power saving kernel options are already  set in my optimisations via the kernel boot options. You would just shorten your kernel boot string.

Grandixximo proved that a custom 6.3 kernel I built a long time ago no longer makes any difference now we understand how to configure a modern kernel.. Having run most  kernels since 5.10, latency has actually improved. My original J1900 from 8-10 years ago was at around 130k ns jitter is now down to about 50k or less when optimised.

What has changed is all the networking power settings that need to be carefully mitigated. The problem here is by definition networking was never designed to be real time, but to be a forwarding type of communication protocol through hundreds of switches around the internet. So network drivers are not real time.

You could write your own driver using the DDPK www.dpdk.org/ which eliminates the latency from interrupt context switching and uses polling instead. But it still isn't real time. We are not doing High Frequency Trading where every millisecond of latency affects financial returns so this is not necessary in a CNC environment. 

You could use Time Sensitive Networking (TSN) which is now in the kernel and supported by Ethercat but its hardware dependent so your slave needs to support it. tsn.readthedocs.io/

Remember PREMPT_RT is not fast, its deterministic (reliable and on time) which is exactly what we need for our servo thread.

Thanks>
now it looks like this error: ornocnc@tornocnc:~/linuxcnc/configs/MILLING MACHINE$ ncam -i MILLING MACHINE.ini -c mill -t
Error modifying ini file
a bytes-like object is required, not 'str'
/usr/bin/ncam:346: PyGTKDeprecationWarning: The keyword(s) "type, message_format" have been deprecated in favor of "message_type, text" respectively. See: wiki.gnome.org/PyGObject/InitializerDeprecations
dlg = gtk.MessageDialog(parent = None,
/usr/bin/ncam:346: PyGTKDeprecationWarning: The "flags" argument for dialog construction is deprecated. Please use initializer keywords: modal=True and/or destroy_with_parent=True. See: wiki.gnome.org/PyGObject/InitializerDeprecations
dlg = gtk.MessageDialog(parent = None,

I was thinking, can we ask the kernel developers, how can we recompile the kernel, eliminating all the power optimizations, so as to optimize it for RT applications? If we continue like this, soon Linux will only be used for writing emails and using OpenOffice.

check this topic 

If it will not help you. let me know below

Hi Surmetall,

Thanks for the link to Talla83's Discord — I actually know Peter's
videos, really good content. I will join the Discord, sounds like
a great place for quick technical feedback.

And I completely agree about keeping both channels alive. Forum for
long-term knowledge base where people can find solutions years later,
Discord for quick "I am at the machine, something does not work"
situations. Different tools for different needs.

Sorry to hear about your Beckhoff struggles. That is exactly the
kind of retrofit work where LinuxCNC really shines — replacing
expensive proprietary controllers. If I can help with anything
regarding the driver side, let me know.

Regarding the lathe polyline — still polishing a few things, then
I will push to GitHub. I will post here and ping on Discord when
it is ready for testing.

Best,
CNC Proton

Hi,

The fix is now released in version 2.0b-1:

github.com/cnc-proton/nativecam-py3-gtk3/releases/tag/v2.0b-1

Download the new .deb and install it:

sudo apt remove nativecam

sudo apt install ./nativecam_2.0b-1_all.deb

This should resolve the python/python3 issue on Debian 12.

Please let me know if you run into any other problems.

Best,

Thank you, andrax. It seems that the absolute encoder would be a good solution and perhaps using them will prevent any homing failure. The batteries are installed in the boxes of each servo. From the servo manual, the default home offset is 0. Therefore this should be the absolute homing position that the servo knows about - 0x6064 should be around 0 or 2^32. When I execute a home procedure in LinuxCNC, the 0x6064h is indeed around 0, I check it via "ethercat upload" terminal command. Then I close and start LinuxCNC again and the motor does not arrive in the same position as the previous execution of homing. There is a different value on the axis/joint DRO. This is my joint configuration:

4.19 was good. Remember I struggled with 6.x when it came out.
Anyway, what I do now is to have an Intel network card, i210, i217 or i225/i226
and make a modest effort to reduce jitter and latency.
The way I determine it's good enough is when there are no messages in syslog of this kindAll such messages have to go, well one in the beginning is ok, but not more.

I may or may not need to go to isolcpus and so on. On my current plasma system I have no
such tweaks at all. It works good anyway.

I installed nativecam, but when I run ncam --help or another command I always get this error: /usr/bin/env: «python»: No such file or directory, apparently the path it is looking for is different, I am using DEBIAN 12.

I think I don’t fully understand how that would work. The variator is controlled by two contactors. The shortest time that has to be on to actually change the variator state is relatively long. And how would you turn the float from a PID into the contactor signals?

Did I understand you wrong?

Today I tried threading with G76. It did not go very well (see picture). It looks more like a very rough turning pass. I am not sure if I understand the parameters of the cycle. It is supposed to be M32x1.5.

The code I ran was:
With this, the material was not touched at all, so I started at X32.5 instead of X34 (that is where the picture comes from).

Are the parameters I and K relative (and in radius)? I thought starting at X34 is, in radius, 1 mm away from the nominal 32 mm I want, so I = 1, and the pitch is 1.5, so the final depth should be 0.75 mm lower.

The lines in the GUI looked just like “Figure 4. G76 Example” from:
linuxcnc.org/docs/html/gcode/g-code.html#gcode:g76

Can anyone give me the G76 line for an M32x1.5?

papagno-source wrote:

I have question at AI:

ethercat on debian 10 with kernel 4.19 and linuxcnc has less latency than debian 13 with kernel 6.12. Why?
 

Don't forget the hardware manufacturers have been adding  power saving features for years even back with Debian 10. But Linux simply ignored these features but now the kernel has caught up. It had to stay current. Generally, there are settings to disable them.  Also there are a lot of new network cards often part of the motherboard that do not have driver support until Debian 11 or 12 or 13.  So Debian 10 is an unsupported version now so you can;t continue to live in the past. Generally with proper tuning , 4 core and up hardware runs well on the later kernels.

Thanks, endian, for the converter. I tried to integrate my AX5125 into LinuxCNC. I converted the TwinCAT 3 export and tried to get it running in LinuxCNC. I can see the AX5125 as a slave and some of its pins. Unfortunately, I can’t get it from Pre-OP to OP mode. I’m definitely doing something wrong but I’m not sure where to look.

I hope someone can help. Which data do you need? I assume the .xml, .hal, and .ini files?

Is it okay if I post them here, or would it be better to start a separate thread? Thanks in advance.

Greetings
Tom

I don’t think there’s anything wrong with that. As far as I know, Tormach uses LinuxCNC with PathPilot as well, right? As long as the modifications are released again, like you said, everyone benefits!

Wow, I’m absolutely thrilled about the video I can’t wait to test it! Unfortunately, my machine isn’t operational yet; I’m still struggling with the Beckhoff driver. If you need multiple testers with real CNC lathes who can provide faster feedback than on the forum, Peter alias Talla83’s Discord (I assume you know him from his YouTube videos) might be an idea. It’s more like a chat there, and people reply quickly. There are also several lathe users and generally many smart, helpful folks.

This isn’t meant to poach users or replace this forum. I’m happy to be here, and in the long run, knowledge is better preserved here. So please post here as well so other users can find it more easily later. For faster feedback - for example, when you’re at the machine and need input from others - the Discord is hard to beat. Just an idea
The Discord mainly has German-speaking users from Germany, Austria, and Switzerland, but everyone understands and replies in English too.discord.gg/dyd8M9wJ