Advanced Search

P1 can be used for step/dir with the right firmware (that puts stepgens on those pins)
Mesa Ethernet cards don't use the base thread at all.

latency-histogram --base 100000

Means the base thread _period_ is 100000 ns = 100 us, 1/100us = 10 Khz

SOLVED — root cause: NVEM V5 (at least this clone/revision) has only 2MB of flash, but Remora-RT1052-cpp stores the config at an address beyond that

For anyone hitting the same wall I did — board pings fine with the old firmware but never responds at all (no ping, no ARP, nothing) with any of the newer Remora-RT1052-cpp builds (2.1.1, 3.1.x) — here's what was actually going on, at least on my board.

Board: NVEM V5 clone, silkscreen "1NKR_NVEM_V6", MIMXRT1052CVL5B

The flash chip on my board is a Winbond W25Q16JVSIQ. "16" = 16 Mbit = 2MB. The firmware, however, defines JSON_STORAGE_ADDRESS in source/configuration.h as:

#define JSON_STORAGE_ADDRESS 0x00200000 // beginning of Block 32

0x00200000 is exactly 2MB — i.e. one byte past the end of a 2MB chip. On boot, once the firmware reaches jsonFromFlash() and tries to read the length word at that address, it hard-faults silently (the hard fault handler in this firmware only catches semihosting breakpoints, so a genuine fault just hangs with zero console output). This happens before the main loop ever gets around to servicing the Ethernet/lwIP stack, which is why nothing ever answers on the wire — no ARP, no ICMP, nothing. It looks exactly like a dead ENET/PHY, but it isn't.

How I confirmed it:
- Got a debug UART connection going (LPUART4, 115200 8N1, pins GPIO_B1_00/B1_01 — on my board these come out on connector P6, which is also wired to a MAX3232 for RS232 levels, pins 2/3, pin 1 GND)
- Boot log stopped dead right after "1. Loading JSON configuration file from Flash memory" — no "Flash storage location is empty" message, no crash message, just silence
- Older firmware (0.2.1, no TFTP, config hardcoded) never touches this address at all and boots/pings fine every time — same hardware, same cable, same everything else
- Confirmed the JSON_UPLOAD_ADDRESS (0x001F0000, "Block 31") is already the last valid block on a 2MB chip — Block 32 simply doesn't exist on this flash

Fix: moved JSON_STORAGE_ADDRESS to an address safely within the 2MB range and clear of both the app code and the upload staging area:

#define JSON_STORAGE_ADDRESS 0x001E0000 // Block 30

Rebuilt with MCUXpresso (had to set up the toolchain from scratch, straightforward once the SDK pulls in), reflashed, and the board now boots all the way through — PHY init, JSON load (correctly falls back to default config when flash is empty), full module setup, IDLE state — and pings/TFTP-uploads immediately. Config upload via upload_config.py now works exactly as expected.

Worth checking your own flash chip's part number before assuming it's a hardware/ENET/PHY problem if you're seeing total silence on the network with the C++ firmware — a 2MB chip on these clone boards looks to be common enough that others may be hitting exactly this.

Happy to share the exact board.c / configuration.h diffs if useful.

yep, not intending to use a paraport as i have a Mesa 7i96s. Which brings up a question, if i use the P1 parallel expansion port on the 7i96s, is the base thread still irrelevant? not that i would use that for step.direction, just GPIO.
I guess I really need to learn ALOT more about Linux and command prompt use. I'm a windows user so always gravitate to graphical UI rather than terminal. so just picking histogram from the dropdown i get what i get. I dont know enough about the terminal commands to know any better.
thanx for the help though. 

p.s. not tryin to be an azz but??
latency-histogram --base 100000
( for a 10 KHz base thread )
isnt that 100KHz?? 

Try running the latency test with a slower base thread rate  (or no base thread at all if you do not intend to use a parallel port)

latency-histogram --base 100000

( for a 10 KHz base thread )

or

latency-histogram --nobase

for a servo thread only latency test

cant find any mention of secure boot in the BIOS anywher. and as much as i hate AI, this is what i get when asking google...

  

guess i made a bad hardware choice.
 

this is where i fall flat on my face with linux, cant find an MD5 checksum for linuxcnc_2.9.10-amd64.hybrid.iso anywhere.
this page still shows the 2.9.8 checksums.

here is what i get when using windows command promt:

MD5 hash of c:\linuxcnc_2.9.10-amd64.hybrid.iso:
fc1aa63d54babf5fc840e1b6471cd75a
CertUtil: -hashfile command completed successfully.

tommylight wrote:

Tux, he has huge industrial machines, not the same as small hobby routers/mills, tool wear is a must on those, not something you can choose to use or not use.
 

No matters he want, no matters I want. 
If someone share his work, shares for all, not for himself.

automata wrote:

Hi grandixximo,
We really appreciate your dedication to solve the jerk limiting trajectory planner issue.

+1
And for Grotius as i think he started this journey and got lost along the way...
I have no use for it yet, but i have a 3.5 ton Mazak that should benefit from this whenever i get to actually use the machine.

Does the error report mention "raspi" anywhere?

Tux, he has huge industrial machines, not the same as small hobby routers/mills, tool wear is a must on those, not something you can choose to use or not use.

hmmm that might also be a hardware issue, usually dry capacitors or memory problems, although memory problems will show up during boot in most cases.
You might want to try Linux Mint Debian Edition, after install and reboot:
sudo apt update
sudo apt install linuxcnc-uspace
But this will be an older version of 2.9, not the master version or 2.10
Edit:
if you want to continue with ctrl+alt+F3 , type startx and check what errors it shows up.

Download the ISO again, check the md5sum or sha256 or whatever there is to make sure the ISO is OK, write to usb using DD in Linux or Balena etcher on windows (work on Linux also), try again.
If it fails after all that, disable "secure boot" in BIOS. You can try this first with the existing usb, might just work.

i installed linuxcnc 2.9.10 via the released ISO. when i run the latency histogram from the application menu, it logs me out and pops up the login screen. i login again, and then the latency histogram program wont run at all. neither will the regular latency test. if i reboot, i can run the regular latency test, but if i try the histogram, it logs me out again.
is this a bug or maybe something wrong with my new system? 
i have
this motherboard , basically because i have one in my daily desktop, and it was cheap
this graphics card , because it is AMD not Nvida that was causing issues with scrambled screen
this network card , because it uses the intel chipset rather than the realtek one on the motherboard

 

thanks for the effort.. I think it is called a locked loop I have seen this also.
I have found that if i do a

ctrl + alt + F3

it takes me to the terminal login screen at which point I am able to log in with user name and password that was setup during setup and then do things in terminal mode. terminal mode seems to be working just fine. I have done the updates and the upgrade. per info on terminal screens but nothing past that at this point.

AI says there is fix for this locked loop thing but I have not done it yet. will do it later on.. now i have to learn all the command line stuff if i live that long .?

Thanks again for the help.
Ken

I did some tests with your big-blue-sim.zip.I made following changes:
1. Gmoccapy instead Axis.
2. Increased font size.
3. Removed comments from toolchange.ngc (looks horrible and unnecessary) :

This is some bug when you use gmoccapy's builtin tolchange :

(Need tool prepared -Txx- for toolchange)
This does nothing, only irritate, so I do not investigation now.
As I wrote, in gmoccapy ~/linuxcnc/nc_files/lathe/lathe_profile.ngc is not loading automaticaly and you must load it manually.