Advanced Search

Hi,

Thank you for testing! Found another Python 3 compatibility bug.
The function that modifies the ini file was still using old Python 2
API (io.BytesIO with str argument).

This will be fixed in the next release (2.0b-2) which I will push
to GitHub shortly.

By the way, there's a separate issue — your config folder has a
space in the name ("MILLING MACHINE"). LinuxCNC works with it, but
it can cause problems with some tools. Consider renaming to
"MILLING_MACHINE" for safety.

github.com/cnc-proton/nativecam-py3-gtk3/releases

Best,
Axemas

The main errors:
K0.75 is radius mode while in diameter mode.
I1 is radius mode (X34-X32) while in diameter mode
G96 D2500 ? 2500 m/min surface speed? Cutting steel with carbide  is typically only 1/10 that or less.
Maybe consider G97 S500 just to remove a variable while you are getting used it it?

Assuming a thread major diameter (stock OD) of 32, with you drive line at  X34, I-2. In practice, the major diameter is probably more like P/8 smaller. Somewhere around 31.8mm. Andy has programmed all that into his lathe macros, so you just give it major diameter (32mm) and it takes a first turning path at P/8 smaller before starting threading.
Since this is G7 diameter mode, the final depth K is also in diameter, so that will be 32-30.5 K1.5. Actually it is more likely to be about 30.38, so you will tweak this number to get your thread to fit, if you don't have perfect full profile inserts. Dont be surprised that you need around K1.62 to get the nut to fit.
J0.3 is reasonable. You will need lots of passes. See if you can get the insert to survive at J0.5
The R 1.6 means your cut will get heavier at each pass. I tend to set that at R2 for constant area, of course leading o increased number of passes.
The rest looks good.

G7 G18 G21 G90 G94
G0 X34 Z10
G97 S500 M3 M8
G76 Z-15 P1.5 I-2 K1.5 J0.5 Q29 H2 E0.75 L2

andypugh wrote:

You will need to have different orientations in the CAM tool table and the control tool table, but there is no auto-synching anyway, so that's not a problem.
 

Not that I can tell.

I set all tools to "turret 104" - i.e. back-tools - in Fusion, and make sure all tools are oriented the same way.  Fusion simulation always shows the tool above the part.  I just have to make sure spindle direction is appropriate for the particular tool.

The tool orientation value isn't passed from Fusion to the post, so the 'flip' only happens in LCNC.

I've not tested Fusion's 'turn below center' setting yet, so that behavior and post output remains to be seen.  I think if you select an OD boring tool and create an ID turning toolpath it will automatically reverse the spindle direction and output negative-X values.  Would be rather user-friendly if it works as advertised...

Well, that works nicely with only a minor issue remaining.

Backplot display now follows actual tool orientation, according to the orientation value in the tool table.  Had to swap the orientation M-codes; was confused until I remembered I have the configuration set to BACKTOOL in the INI file (X is up/away).

What's a little odd is that rotating the WCS doesn't alter jog direction on the handwheel.  X+ moves the table up/away, and X- moves the table down/towards the operator regardless of the WCS flip.

Remaining Issue: Something is off in the remap or toolchange.ngc, because G43 isn't automatically applied despite being in the .ngc file.  G43 works in the lathe-fanucy sim, but not on mine for some reason.

Down-facing "normal" tool - T5:
 

Up-facing "back" tool - T2
 
 

Thank you for your valuable feedback; I will look into each and every one of it.

While reaching the limit before generating gcode, just had a look at the operation options. Missing essential selection for ucs, and in general a preamble to be set. It seems corner radius is missing for pocket and contour, to have smooth direction change, and desired cornerradius. Stepover as percentage of the cutter diameter is more preferable than fixed value. The contour operations have no rough dimension input? Zig zag facing, is it using stepover? And the drilling operations, eg grid drill have no selection for cycle, retract, clear z (G98)
As i was not able to test for free, this is just from looking at the interface.



 

1) To operate the contactors from a PID you could use a WCOMP HAL component. Use the "over" and "under" pins to drive the contactors and set up the max and min some small distance above and below zero to prevent hunting.
linuxcnc.org/docs/stable/html/man/man9/wcomp.9.html

2) Before looking at the G76 G-code, make sure that spindle.0.revs increases by exactly 1.0 for every rotation of the spindle.

I made discount

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