Advanced Search

Holzwurm56 wrote:

Hi Tommy, I downloaded the ISO from your first post. Which software did you use to calculate the MD5? I’m using MD5-Check and getting a different MD5. Or did you post a newer version in another thread? The UEFI installation method seems outdated—do I need to disable Secure Boot?
Many thanks,
Hans
 

MD5 is MD5 - if the hash changed due to the program used it wouldn't be a very good hash, ha. My guess is that the checksum wasn't updated after the .iso had been modified. I downloaded it twice and got the same checksum on both files: 512B3E5226CB71127215BCF65C6A9B46 

5280 wrote:

windows 10 ran just fine. 

Just because Windows works doesn't mean anything.
Linux is more sensitive to hardware problems, for example it may refuse to work on a technically efficient but overclocked computer.
Let me tell you a story.
A long time ago I worked in a computer repair shop. One client regularly brought his computer. Windows kept crashing and the disk was full of garbage. After wiping the disk and reinstalling the system, everything worked fine. I've done hundreds of tests and found nothing. The computer was returned to the client and after some time it was in the same condition as before. Until one day I noticed that the processor temperature was a little higher than it should be. Just a few degrees higher, but I decided to replace the processor. From that moment on, I never saw that computer again. The explanation is simple, a hot processor sometimes performed incorrect operations and wrote incorrect results to the disk. The errors kept increasing and after some time an avalanche started...
Why am I talking about this?
Because not everything can be checked and not everything can be repaired.
If your installation media is not damaged, there is no point in investigating the cause of your computer not working.
CNC is not a toy, it is a machine that can cause damages and injure the operator.
Everything must be checked like on airplanes, and if something is suspicious, it must be removed.

Download a different installation image, use a different pendrive. If the problem persists, leave this computer alone.

That reminds me, OP listed Radeon R7 350 4GB at amazon link in first post.

Might be worth checking if installing nonfree firmware fixes it
what does
sudo dmesg | grep gpu
report?

It doesn't matter. If you have it running now, just open a terminal window and run the command. Or doing it before startx should work the same.

When should i run the systemctl get-default
before startx
or
after from with in the OS terminal after everything is running

Can you make the spindle stop fail in a sim config?

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