Advanced Search

wow... ok.... i thank you.. i understand now more...

but here are some news.....

today i start making a excel... because i wondering why the gear ratios not fit which i get from unimation.... and then.... i get it... i open the gear from joint 2.. count the teeths... suprise... they changed the gears...

i get gear ratio from a puma 250.. i have a puma 200... .. now i open every gear... and count...

when i start with the robot i done this:

open all covers... check encoders.. wiring.. lables.. all what i can get.

then i start in linux counting form index to index pulse and see what was the counting of a/b. ok i get 250 cpr encoder on joint 1 2 3 and 200 cpr on 4 5 6.

then i start with the motors and angles... i measured with inclinometer. parallel i wrote a mail to stäubli and unimation... stäubli give me contact to rp automation. rp automation share some details with me.. they only have what they have.. so all what i get was stuff for different puma 2xx versions.

i calculated then the scales for each axis... it never fit.. i was thinking ok.. lets stay at the values i measured... but today i start opening the gears and i was suprised.... the teeth counting i get doesnt fit my robot.

if i am done with counting every gear.. i come back and try what you wrote.. but i see my failures and i am happy that you teach it to me because now i understand it better..

thank you!

There is not enough info here. What are you trying to do step by step?

I created the original 2.9.2 image, but have not touched it since. I don't have a pi to do anything further. I think Andy may have rebuilt later versions.
We had no choice but to build the kernel from the official pi source back then.
I think there could be better ways to do this as preempt_rt is now supported.

As for Step2:

Draw some simple poses and calculate the expected x,y,z coordinates:
 


Then create a sim config for genserkins and feed in the derived DH parameters. then test the results by setting up the joint positions as in the chosen poses while keepin the angular offset for J1 and J2 in mind (+- 5.49°) :

 
 
 
 
 

I would not worry about it just use it. Keep a spare SD card preconfigured. The only thing you need to do is keep a copy of your ~/linuxcnc folder

I've had a Pi4B running for 4 years on a standard 16gB SD card and it never failed. There is far more transactional data happening there.

It seems like the BF20L has a MT3 spindle. In this case, I would recommend you adopt Tormach TTS tooling.
You will need to buy a genuine Tormach MT3 collet to hold the 3/4" tools. I got mine from littlemachineshop in the USA.
You can premeasure your tools. Tormach sell a tiny granite plate with a hole in it so you can measure the tools with a height gauge.
Enter your tools and their heights into the LinuxCNC tool library
Then if you use QTdragon or probe basic, the probing for a 3D probe is all built in. They will prompt you when to change tools.

If you have shared home/limit switch, you should add a HOME_OFFSET to move off the switch before homing finishes to avoid this.

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?