Advanced Search

You can install ncam and lathemacros together, but only lathemacros will works properly.
The cause is use the same names for different subroutines:(I removed results not matter.)
You can recognize ncam's files by "(author : Fernand Veilleux)" comment, thats lack in lathemacro's.
Ncam (Python 3.0)) works properly and generates good g-code, but LinuxCNC uses subroutines that found first... 
This causes horrible and confusing errors, like :But actually there is no error in ncam.ngc, but only wrong subroutine file is used...

The solution is very simple (rename subroutines and change some lines in python sources), but this must be done by the authors, not by users...

Good day to you Tom
Just curious what was your very first computer and year you got it, and did you build it from scratch.?
Ken

Thank's Todd
I have double and triple checked all of that. very aware of the upper/lower case thing in Linux. installed 3 different keyboards thinking of that first off. I still think Linux may be the path for me if I can just make all the paths come to gather for what i have in mind to end up with.
thanks
Ken

Probe Basic does not show the part at all it only shows the toolpath so im not exactly sure what your post is requesting/stating etc can you be more clear of what part of probe basic you are referring too?

Hi,

I'm running into an issue and hoping you might have found a solution since posting this.

I'm using an NVEM V5 board (RT1052 chip). I successfully flashed the firmware via pyOCD 
(tried multiple firmware versions: remora-rt1052-NVEM-0.2.1.bin, remora-rt1052-0.0.1.bin, 
remora-rt1052.bin - all flashed without errors). Ping to 10.10.10.10 works perfectly and consistently.

However, unlike your case, I'm getting a timeout on my very first config upload attempt - 
not after a successful first upload. 
I've tried:
- My own custom config file
- The unmodified official example configs (both nvem-rt1052.txt and remora-rt1052-basic/ec500-rt1052.txt)
- Uploading with the SWD/ST-Link connection both attached and disconnected during the upload
- Confirmed via tcpdump that the WRQ packet is sent correctly on port 69, but no response ever comes back from the board
- No firewall involved (iptables set to ACCEPT), direct point-to-point Ethernet connection, no router

The script always confirms "Valid JSON config file" and calculates the CRC correctly, 
so it gets stuck at exactly the same point you describe - after everything on the PC side looks fine.

Did you ever find out what caused the board to stop responding to TFTP? 
Was it possibly related to the eStop/enable state getting stuck, as you mentioned the LED stayed 
permanently lit? Any insight into how you (or anyone else) resolved this would be hugely appreciated - 
trying to avoid unnecessary re-flashing if there's a known cause.


Additional update: I ran a UDP port scan to check the TFTP service status directly:

sudo nmap -sU -p 69 10.10.10.10

Result:
PORT STATE SERVICE
69/udp closed tftp

This is significant - "closed" (not "open|filtered", which is the typical ambiguous UDP result) 
means the board actively responds with an ICMP port-unreachable message. This confirms the 
TFTP service itself is never bound/listening on port 69 at all - it's not just that requests go 
unanswered on an otherwise-open port.

I also looked through remora-rt1052.cpp and noticed the TFTP server is initialized via:
IAP_tftpd_init(dmaThread->DMAptr->EDMA_Handle);
in the ST_SETUP state, right after loadModules(). This suggests the TFTP server initialization 
may never complete successfully during startup - which would explain why port 69 shows as actively 
closed rather than just non-responsive.

I've now tested every available NVEM-specific firmware (only remora-rt1052-NVEM-0.2.1.bin exists 
in the Remora-RT1052 repo) as well as the generic 3.1.x versions from Remora-RT1052-cpp 
(which don't even respond to ping on this NVEM V5 board, matching what "disneysw" reported earlier 
in this thread). I'm at the limit of what I can diagnose from the outside - any insight into the 
TFTP server startup sequence would be much appreciated.


Thanks in advance!

Additional update: I ran a UDP port scan to check the TFTP service status directly:

sudo nmap -sU -p 69 10.10.10.10

Result:
PORT STATE SERVICE
69/udp closed tftp

This is significant - "closed" (not "open|filtered", which is the typical ambiguous UDP result) means the board actively responds with an ICMP port-unreachable message. This confirms the TFTP service itself is never bound/listening on port 69 at all - it's not just that requests go unanswered on an otherwise-open port.

I also looked through remora-rt1052.cpp and noticed the TFTP server is initialized via:
IAP_tftpd_init(dmaThread->DMAptr->EDMA_Handle);
in the ST_SETUP state, right after loadModules(). This suggests the TFTP server initialization may never complete successfully during startup - which would explain why port 69 shows as actively closed rather than just non-responsive.

I've now tested every available NVEM-specific firmware (only remora-rt1052-NVEM-0.2.1.bin exists in the Remora-RT1052 repo) as well as the generic 3.1.x versions from Remora-RT1052-cpp (which don't even respond to ping on this NVEM V5 board, matching what "disneysw" reported earlier in this thread). I'm at the limit of what I can diagnose from the outside - any insight into the TFTP server startup sequence would be much appreciated.

little test for the stepdir plugin

www.youtube.com/shorts/2ep5VN4Sf18

You're right. That was the cause of the error.
Thank you very much.

Remeber, usernames and passwords are case sensitive. (Almost everything in Linux is case sensitive.) Is it possible that a glitchy keyboard is messing with your username or password inputs? (If you got a double or dropped character when inputting them either at install or login later.) Is the caps lock or num lock key screwing with your inputs? (Linux tends to default to num lock off at start up.)

i made a vismach model.

Looks like a lot of AI generated stuff so I'm not going to bother with it. Frankly, if you need to rely on AI to build the vismach model then you are most likely better off without it because working with an incorrectly constructed vismach model is only going to make things a LOT more difficult for you.

Generally I think you are trying to get around the tedious legwork of wrapping your head around the basic concepts of how those modified DH parameters work so my advise would be to get out the old paper and pencil and start from the beginning.

Greetings,
This is my first post so I'm hoping I done break any protocols...

I have converted a 1959 vintage Centec AutoMill (3 axis horizontal milling machine) to CNC using LinuxCNC 2.9.10 Debian 13 Trixie PREEMPT-RT on a Raspberry Pi5 with 8 gig of ram, directly controlling three GeckoDrive 201x stepper drives via the Pi's GPIO pins. It is working very well as the Gecko 201x works with 3.3 volt logic and I very pleased with its performance. No need for a MESA board or any kind of logic level shifting.

I recently read that the Micro SD cards used in the Pi are not well suited to handle lots of read/write activity, and over time will fail.

Can anyone tell me if LinuxCNC does a lot of writing/reading of things like temporary files during the running of the machine?

TIA   Greg

for those who are interested here is a new config that has the simulated motion in it

it's based off the lathe fanuc axis gui that linuxcnc comes with

you have two options.  you can just unzip and copy and paste the sim config. into your linuxcnc configs folder and then use the config picker to run it.  that takes 2 min and like 10 mouse clicks.  for those who want to understand it and hopefully add this to their own machines there is the manual option where you can copy the right files into the sim config and actually understand it.

i just used Claude Ai for the whole project and got it to spit out the text file that is in the config.  here is the first bit from the text file.   cheers Andrew 

===============================================================================
 RUNNING THE BIG BLUE CONVERSATIONAL TAB ON A SIMULATED LATHE
 How to graft it onto LinuxCNC's own  sim / axis / lathe-fanucy  sample config
 Written 2026-08-07.  Every step below was built and tested before writing.
===============================================================================

WHY THIS FILE

---

The big-blue-lathe config drives real servos through a Mesa 7i92 and needs a
ClassicLadder E-stop chain, gearbox solenoids and sensors to even come out of
E-stop.  A friend with no hardware cannot jog it or run a program.

So instead of shipping the machine config, we bolt the CONVERSATIONAL TURNING
TAB onto a stock LinuxCNC sim.  You get a machine that homes instantly, jogs,
runs programs, does manual tool changes and simulates a spindle - and the
Turning tab writes exactly the same G-code it writes on the real lathe.

The base is  sim/axis/lathe-fanucy  rather than  sim/axis/lathe , because
lathe-fanucy already ships the T-word / wear-offset remap plumbing that big
blue depends on:  the REMAP = T line, the [PYTHON] section, remap.py and
toplevel.py.  That is most of the fiddly part done for you.


===============================================================================
 TWO WAYS TO DO THIS - PICK ONE
===============================================================================

  ROUTE A - USE THE READY-MADE CONFIG.  Two minutes, nothing to type.
 

---

  If you have  big-blue-sim.zip , everything below has already been done for
  you.  The whole finished config is in it.  On the test PC:

      mkdir -p ~/linuxcnc/configs
      unzip big-blue-sim.zip -d ~/linuxcnc/configs/
      linuxcnc ~/linuxcnc/configs/big-blue-sim/big-blue-sim.ini

  That is it.  Skip to STEP 4 - RUN IT.

  You do NOT need to create the lathe-fanucy sample config first.  The zip
  already contains its remap.py and toplevel.py, which is the only thing that
  was ever taken from it.

  ROUTE B - BUILD IT BY HAND.  Steps 1 to 3 below.
 

---

  Do this if you have not got the zip, or if you want to understand what is
  in it, or if you are redoing this on a future LinuxCNC version.

  The only difference between the two routes is the NAME.  Route A gives you
      ~/linuxcnc/configs/big-blue-sim/big-blue-sim.ini
  and Route B gives you
      ~/linuxcnc/configs/lathe-fanucy/lathe-fanucy.ini
  with identical contents.  Wherever this file says "lathe-fanucy.ini" below,
  read it as "whichever of those two you have".

  NOTE FOR THE BIG BLUE MACHINE ITSELF: copying this text file into the
  big-blue-lathe config folder does nothing on its own - it is only a set of
  instructions.  The sim is a SEPARATE config directory.  Nothing here changes
  or touches the real machine's config.

thank u soo much

@farley,
No double posting.

Excellent. I will add it and a little writeup in the official docs.