Advanced Search

Cool

You are welcomed, always.

@CNC_Manni
No double and triple posting, stick to one topic, it makes a mess following what was already answered.

5280 wrote:

why cant they just have a check box do you need a password yes / no and leave it at that
1 frustrated old man
 

As an old man, you should remember mainframe computers occupying several large racks that were operated by many people from many terminals. Linux is derived from Unix, Unix was developed in 1969... This is why in Linux you have to use passwords (and also a complicated permission system). You can't escape it, you have to like it...

ZX81, ZX Spectrum, Commodore 16, Atari 520STFM, XT PC, Toshiba Laptop with EL orange screen, and the first i have built Pentium 1 200MHz.
Many more there, some i still have in working condition, see my channel on youtube:
www.youtube.com/@TomaPC

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.