Advanced Search

you can use



NOTE: No 'self.execute(..)' command can be used after this.

 

linuxcnc.org/docs/html/remap/remap.html

 

correct, this is explained int he instructions to remove the comments or you will receive errors.

 

Gave the new axis-like UI a spin this morning. Looks and feels good. I noticed the buttons (e-stop and machine-on, in particular) don't have the 3D "I'm pushed" look when they're pushed released. A small thing, but there's no other visual way to tell the state.

I need to come up to speed on modifying these UIs, so I can make changes and flesh it out. (I know, I know... watch the videos. ) The big missing piece for me right now is a probing/touch-off screen. My current probing setup is pyvcp, so clearly it will need to be redone. But I'll bet you already have fully functional probe screens just waiting to be dropped in.

cmorley wrote:

There is a slowly developing version for qt screens:
github.com/LinuxCNC/linuxcnc/commits/qt_ncam/

 

To install NativeCAM from that site, should I download or clone all the linuxcnc package of files?

Regards
Giovanni

I have a couple of user defined remaps that do read and insert timestamps  to a SQL database.
The problem is the interpreter  executes these M-codes before the action is actually performed.
Is there a way to tell the interpreter to only execute these when they actually happen?
The remaps are python routines, hoping that a flag can be set.
Tried setting the remap modalgroup to no avail.

I have 6 machines that can make use of this.
Any help appreciated.

 

Manual, this section:
P05 group Input terminals

I believe I should be able to assemble this code myself with subroutines. Don't want to make something rocket science that isn't.

Example:

Parameters G90, G17 etc.
Variables
Offsets

Subroutines
o100 Sub
code
0100 endsub

o101 Sub
code
o100 endsub

o102 sub
code
o102 endsub

G0 X0 Y0 F70 (Go somewhere you can change the tool, first op work zero)
M6 (change the tool, move to top of part)
G54 Z height (set the height to top of part)

G54
o100 Call
G55
o100 Call
G56
o100 Call
G56
o100 Call
G57
o100 Call

G54
G0 Z1.0 (get too up out of the way)
G0 X0 Y0 (go back to first tool change position, work zero)

o101 Call
G55
o101 Call
G56
o101 Call

and on and on

At the end the tool should stop at the last program Z height.

Please offer any comments. Going to try this without the drivers turned on.

SanzuiWorks wrote:

Reading Work Coordinates When Loading a New NGC File  

When loading a new `.ngc` file in LinuxCNC, is it possible to read the work coordinates at that stage? Since the G-code has not been executed yet, the work coordinates might not be applied.  

Would it be possible to create a custom button, similar to "WCS Sync," that reads the `.ngc` file and sends commands like `G55` to MDI?  

Has anyone implemented something similar, or does LinuxCNC provide a built-in way to achieve this? Any insights or suggestions would be greatly appreciated.

Thanks!
 

You can add this under StatCanon in qt5_graphics.py:

How to install the latest linuxcnc-ethercat on Debian 10 (lcnc2.94)?

ok so heres a pic of the conns. i have verified everything all the way up to them is working. spindle start is on ssr.03, and all the wiring from the mesa to the vfd is tested. as best as i can tell P00.01 should switch between the keypad and remote switching. i can change the frequency from linuxcnc but thats about all. 

the manual is here: www.huanyangvfd.com/wp-content/uploads/2.../FC01-Series-VFD.pdf

 

No tool changer or offset.
I manually move the head to a zero position and insert the new tool. Then I use G54 offset to give it the program height, then run.

Went back and tried to regenerate this, it seems to not be very good at it.
I think I am either going to have to split the operations into separate programs or learn how to assemble this myself. I haven't given up on learning how to take the code, create subroutines and write the code for multiple locations.

Don't think I need the G92s. When I enter the Z location it moves the entire 4 location layout on the screen. Have no idea why.
Anyhow, more to do and learn.

Almost there, I think

thanks

Noted, and quite tricky indeed; thanks for staying the course and helping out so many people. Think the rpi-5-debian-bookworm-6.1.61-rt15-arm64-ext4-2023-11-17-1520.img.xz from linuxcnc.org/iso/ is missing the [rpi5] section in config.txt - I've tried this one several times, and it always kernel panics 0.5s into boot. I must have been using the rpi-5-debian-bookworm-6.12.11-arm64-ext4-2025-01-27-0140.img.xz before - will try that one again.

P.S. of course, after flashing the SD card, then I find the whole-SD backup, d'oh!

Thanks for the reply - didn't get a notification of it, sorry for taking a little while to respond.

Okay noted, I will do my best to configure a cia402.hal file instead of the method i've been doing it...

but good news is that i've been able to move the drive to an "OP"erational state. very happy with even this little progress haha. will post my cia402.hal once i've got it to compile.

can't imagine why not. is this a traditional xyz mill? I have not done this in PB before, but you may be able to simply go into the custom_config.yml and expand the mills tool table columns to include the X and Y offsets and use those for setting up your lathe tools to align them with the work centerline. I can confirm when using stationary offset mounted touch probes this works great. I think if you are just looking to do simple turning (actual turning in X and Z axis only like a traditional lathe) that this would work in that manner.

you may need to adjust the turning post to call tools as a mill post would in order to utilize those X and Y offsets.

I think that the dro control box section will likely soon become a user tab module that can be setup per the users requirement and kept in the config folder. seems too many configurations to keep up with otherwise and really taxes the ui build having to keep so many dro's running and active.

I will take a look and see what would be required for that.