Advanced Search

Here is the corrected suggestion on how to build the modified DH parameter model. The vertical offset (0.75") between J1 and J2 make things a bit more complex then in the 'puma560' sim config.
 
Some explanation on how modified DH parameters work:

- Each parameter set describes the coordinate transformation from one coordinate frame (F0..F6) to the next.
- Each transformation consists of the same sequence (X,Z directions here follow the current coordinate frame!)
      1. Translation along Xn so that the origin of the coordinate frame lies on the rotational axis of the next joint (Jn+1) 
      2. Rotation around Xn   so that Zn is collinear with the rotational axis of the current joint Jn . Note that the direction of Zn and the rotational direction of the physical joint MUST be identical! 
      3. Translation along Zn so that the Xn direction intersects with the rotational axis of the next joint (Jn).
- At the end of each transformation sequence we have created a new coordinate frame Fn+1.
 
Note that with these rules it is not possible to build a transformation from F2 to F3 without rotating J1 by angle theta1 so that the rotational axis of the next joint (J2) intersects with the X vector of F2. This then requires rotating J2 the same amount but in the opposite direction so the lower arm is vertical again. This needs to be corrected in the configuration by either setting a corresponding HOME_OFFSET value for JOINT_1 and JOINT_2 in the INI file or setting the work_offsets accordingly when in JOINT mode (these must then be deactivated when switching to WORLD mode) 

 

Hello Mesa community and PCW,

I am using a Mesa 7I90HD card in a non-LinuxCNC application. My system 
is a custom Java-based front panel application running on a Windows 11 
laptop that communicates to six independent DSP boards via the 7I90HD 
acting as an intelligent I/O interface. I am NOT using LinuxCNC — I am 
implementing the LBP16 protocol directly in Java over a USB-to-RS422 
serial connection to the 7I90HD's J1 RJ-45 connector.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SYSTEM OVERVIEW
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  Windows 11 Laptop (Java LBP16 application)
      ↓  USB port
  USB-to-RS422 converter (FTDI-based)
      ↓  RS-422 to J1 on 7I90HD (115200 baud, LBP16)
  Mesa 7I90HD (Spartan-6 FPGA, HostMot2 firmware)
      ↓  P1 connector (24 signals), P2, P3 Connectors
  6 × DSP boards (I1, I2, I3, V1, V2, V3)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SIGNAL REQUIREMENTS (24 pins total on P1)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Per DSP board (6 boards × 4 signals = 24 pins):
  • UART TX  → DSP SCI RX  (Java sends ASCII setpoints e.g. "1.0", "110")
  • UART RX  ← DSP SCI TX  (DSP sends status/ack back to Java)
  • GPIO OUT → DSP Enable/Disable command
  • GPIO IN  ← DSP Over-Temperature flag (contact closure = HIGH)

All DSP boards use optocoupler isolation between their circuitry 
and the 7I90HD I/O pins.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
QUESTION 1 — mesaflash.exe for Windows 11
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The 7I90HD manual (v1.7, page 19) states: "Linux and Windows utility 
programs mesaflash and mesaflash.exe are provided to write configuration 
files to the 7I90HD EEPROM via the RS-422 interface and LBP16."

My supplied 7i90.zip package contains:
  7i90\utils\linux\  → mesaflash  and  mesaflash3  (Linux binaries)
  7i90\utils\dos\    → nmflash, READHMID, RP32, WP32, enve (DOS tools)

I cannot find mesaflash.exe for Windows anywhere in this package.
The LinuxCNC GitHub (LinuxCNC/mesaflash/releases) does not provide 
pre-built Windows binaries.

QUESTION: Please advise — 
  a) Is mesaflash.exe available from Mesa directly? If so, where?
  b) Can mesaflash be compiled with MSYS2/MinGW-w64 on Windows 11 
     for serial/LBP16 use? Are there any known issues or patches needed?
  c) Is the Ubuntu Live USB approach (boot Linux temporarily, run 
     the supplied mesaflash binary, reboot to Windows) a supported 
     and safe method to flash the 7I90HD?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
QUESTION 2 — Correct bitfile for my application
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

From my supplied bitfiles I have identified:
  • 7i90_Serial_svua8_4.bit  — 4 UART instances (insufficient for 6 boards)
  • 7i90_Serial_svua8_8.bit  — 8 UART instances (covers all 6 boards)

I also received direct confirmation from Mesa tech support that 
"hm2-serial or sserial modes" are appropriate for RS-422 use.

QUESTION: Please confirm —
  a) Is 7i90_Serial_svua8_8.bit the correct bitfile for 6 independent 
     UART TX/RX channels plus GPIO, accessed via LBP16 from a custom 
     host application (no LinuxCNC)?
  b) Are all 8 UART instances in this bitfile standard async UART 
     (compatible with plain SCI on a TI DSP at configurable baud rate), 
     or are they Mesa Smart Serial (sserial) protocol only?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
QUESTION 3 — PIN file for svua8_8
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

My supplied 7i90.zip does NOT include a .pin file for 
7i90_Serial_svua8_8.bit. The .pin file is essential because I need 
to know the exact IO pin numbers for:
  • UART0_TX through UART5_TX  (6 output pins → DSP SCI RX)
  • UART0_RX through UART5_RX  (6 input pins  ← DSP SCI TX)
  • Remaining GPIO available    (for 6 Enable outputs + 6 Temp inputs)

My Java LBP16 driver uses these pin numbers to set the correct bits 
in the DDR register (0x1100), ALT-SRC register (0x1200), and GPIO 
data register (0x1000) in HostMot2 Space 0.

QUESTION: Could anyone supply the .pin file for 
7i90_Serial_svua8_8.bit, or post its UART and GPIO pin assignments?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
QUESTION 4 — HostMot2 UART module register layout
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

My Java driver reads the IDROM at Space 0 address 0x0400 to discover 
each UART module's base address (via GTag identification). I then need 
to access the UART TX FIFO, RX FIFO, and baud rate registers at offsets 
from that base address.

The 7I90HD manual covers GPIO register layout but does not document 
the HostMot2 UART module register offsets. The regmap file in the 
HostMot2 VHDL source should have this, but I cannot easily access it 
from Windows.

QUESTION: Can anyone confirm or share the HostMot2 UART module 
register map? Specifically:
  • Offset from module base for TX data FIFO write register
  • Offset from module base for RX data FIFO read register
  • Offset from module base for baud rate divisor register
  • Baud rate divisor formula for 50 MHz FPGA clock

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ADDITIONAL CONTEXT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

- I have already received helpful technical guidance from Mesa support 
  confirming GPIO register addresses (0x1000, 0x1100, 0x1200 etc.) 
  and the recommendation to use hm2-serial mode for RS-422 links.

- My Java LBP16 driver handles:
  - LBP16 command word encoding (W/A/C/M/S/I/N bit packing)
  - IDROM parsing (Space 0, 0x0400) to discover module addresses
  - GPIO DDR and ALT-SRC configuration at startup
  - Batched GPIO poll + uSTimeStampReg read in a single LBP16 packet
    for precise START/STOP timing measurement

- The 7I90HD is not running as a LinuxCNC slave — it is a standalone  
  LBP16 register-accessible FPGA I/O interface for a custom industrial 
  measurement application. The DSP boards convert received ASCII 
  setpoints (e.g. "1.0A", "110V") into sinusoidal waveforms via their 
  internal DAC for driving power amplifiers.

Thank you very much for any assistance. This forum and the Mesa 
community have been invaluable resources. 

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.