Advanced Search

Open a terminal and type:
glxgears
if it crashes = change the graphic cars ... that usually can not be done as they are inside the CPU, but if you have a spare PCI-E slot, find an old one and give it a try.
If it runs fine, still i would insist on disabling secure boot and/or trying another ISO/USB.

run the following cammand at the terminal:
systemctl get-default

if it replies with
multi-user.target
then that is what is wrong. Run
sudo systemctl set-default graphical.target

or if it replied with
graphical.target
then this is not the problem, it takes more diagnostics.

Google ai's answer is quite incorrect. I don't see what cpu you got, but with the motherboard you listed, I think any CPU it would be compatible with would have many times more capacity than what LinuxCNC could possibly use.

There are a couple different things that could cause your problem:
1. Possible data error during iso file download and install. Download a second copy and try that or maybe install 7zip which is one program I think of right now which makes it convenient to check sum files in Windows.
2. USB memory device error - try a different one.
3. Motherboard/hardware incompatibility. What you got certainly is fast and powerful enough for LinuxCNC but sometimes odd incompatibilities pop up between hardware/firmware/OS.

doh!!!! thanx for the reminder in how to do basic frequency conversions...LOL

good afternoon Sir
the startx command takes me into the debain program no errors.
windows 10 ran just fine. BUT it was Microsoft windows 10 (UGH)

what a back door just to run the debian OS
but it seems to work
is this something that might need to be looked at by the powers that be.? as a possible fix.

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.