Advanced Search

Bear with me on this project.  multi axis slaves need to be managed from a single instance so the current cia402.comp will only service the first motor on the slave. I have spent a lot of time writing a new component for cia402 drives and I finally was able to try it on a drive and get movement today but it  was only on the first drive just like the current component. Now I know what I am doing I need to clean up all my debugging code and then refactor it using an array of drives in a single component. I was hoping to use a personality on the component to define the array count but not 100% sure how to set that up to define the pin array.

Its all very promising though!

...unfortunately there is no fault in history alarm.
I'm using the same wire for connecting with twincat or with EK1100 where everything is working properly..
Tomorrow I will try to check sys log.

Init and done Flash up and pwr stays on with w3 in S and M.
I will try the CS low test tomorow.

Do the installed SPI firmware images load properly? (init and done light off)

If you need SPI, these should work unless there is a hardware issue of some kind.

A very simple hardware test would be to assert (ground) /CS
and see if the 7I90HDs MISO pin is driven low

Hi, trying to get my 7I90Hd to talk to my mesaflash request. By now i think i screwed up flashing two spi images to it. At least it is not responding to the PI and spi nor vie epp and Lpt on a PC. I belive to have tried all i foind but nothing.... I now had the idea to flash a bit file for the 7i90hd with epp image to a 7i80db to the secondary eeprom and resolder that to the 7i9hd. Would that work or do borads use uncompatible memory formats in the eeproms? This solution is for me the most easy on.... i  cant jtag an update... so i think this should work.....
I tried sudo mesaflash --device 7i90hd --spi --addr /dev/spidev0.0 -- readhdmi running on the latest Pi5 image 01/2026 
and sudo ... --epp --addr 0x378  and also 0x778 trying jumper 3 in S and P in all combos.... and kind of gave up after all my hours of testing...
Any better idea?
The lpt cable is a 1:1 cable LPT to mesa.

The spi is a pi - mesa 5 cable setup
11(mesa) 23 pi clk
13 - 21 SPIn
15 - 19 SPout
17 - 24 CS0

I also swapped 13 and 14 just to make sure thats also no issue...

NWE wrote:

Thanks, so the secret sauce I seem to be missing, is how to do index-only homing? 

Huh... maybe I just need to use the index signal in place of a homing switch. Sometimes the obvious is obscured by the thought pattern.

Thanks, so the secret sauce I seem to be missing, is how to do index-only homing? On another axis I'm homing to home-switch+index so I see the homing latch on index only after the limit switch is found. Here I think I need to latch on the first (and only) index without first finding the home switch?

Ensuring we never try homing from the wrong side of the index seems like it should be easy on this machine. The operator is already required to park the machine with the upper beam on blocks before shutdown, which always puts it well under the index. I may also program a prominent warning into the GUI to display at homing, reminding the operator that the ram must be more than 1" down from top before homing.

LinuxCNC does support index only homing and seems a
reasonable option on a linear scale with only one index at the end of motion.
 
You would need to guarantee that the axis was not past the index mark
when homing starts...

Looks like the recommended solution is to add physical homing switches.

The Ursviken press brake I'm working on has one index near top of travel for both left and right ram. Then it has a prox sensor near the bottom of travel, only reachable if the tooling is removed, with limited documentation. It appears these might be for bottom limits to avoid over-extending the hydraulic cylinders.

If I were to try homing to only the index signal... has anyone done this successfully? I searched around a bit and did not find much hope.

I'm thinking of maybe trying to add a home-switch-out-pin to each of the two encoders in the Mesa firmware, on index this pin would always go high during positive counting/ negative during negative counting.

Just bringing this up in case anyone has a better solution. I could always add more sensors/switches. I'd like to complete this retrofit without adding additional sensors to the various axis.

Yes that was what I meant. 
Tips is to check what ethercat master writes in the syslog.

I see in the last screenshot it mentions MDI and MDI-X.
Can it be the cable, straight or crossed?

Hello forum

I've set up a new control PC and switched to EtherCAT. I'm using Leadshine EL8 components. Everything works perfectly except for the missing Tool cone.

If I have no tools loaded, the tool cone is displayed correctly.
 

When I have loaded a tool, the tool cone is missing..
 

Despite reviewing the installation instructions multiple times, I cannot find the error. 

 

I try to install an old serial 3m touchscreen but the cursor jumps randomly and the calibrator gives false clicks and is impossible to calibrate. I tried this in a debian 12.
Any help would be appreciated.

Geht mir genauso.
Nur dass das Forum fast einen 1/2 Tag nicht erreichbar ist. Und das jeden tag

Hallo Hakan I supose that You are talking about this commands :sudo systemctl enable ethercat.service
sudo systemctl start ethercat.service
sudo systemctl status ethercat.service
sudo chmod 666 /dev/EtherCAT0
I try them before and also today but with no lack.
But I see that Oriental Motor unit catch a fault whenever I plug rj45 eth.
That situation never happen under twincat.
After summarize everything I wonder what do TwinCat that works properly .
I will try watch history fault in the driver ,maybe it can help.

Jocman wrote:

After restarting the system 5 times (yes, 5), finally linuxcnc "sees" the mesa card, and axys is revived.
 

That is a sure sign something is still not set correctly, it only requires reseting the network from the network manager by clicking on the icon and clicking on the active network from the list.
I set networks for Mesa at least once a week, and it never ever fails to work correctly, but that howto has to be followed to a tee, especially when using two or more network interfaces.