Advanced Search

Hakan wrote:

I can not see why doing it in one component should be any different
than doing it in four separate components. I'll see what you come up with.
For personalities or configurable pins, check for example the sampler component.

 

Thanks for the tip.
The single axis issue affects both Dominic's and my component.
My take on the multiple drive issue which was confirmed by one of my AI helpers is that because there is not a seperate ethercat slave for each axis, when the ethercat train stops at the station, everybody must get on and off at once but because of the order of the addf's we only let the first slave on and off.  eg the train only stops once and we've asked it to top at 4 stations, and 3 don't exist. I guess I could confirm that by changing the order of the addf's for cia402.

I don't want to stop work on the single station version until its working.
I've got one odd logic issue remaining to solve. It deals with sensing the edge of the enable pin.

I'll try and get a version published tonight (5pm here) seeing people are anxious

Now you are in the middle of your way of fixing it,
but did you try to go to op-enabled without the cia402 component?
Set controlword and watch statusword in halshow for the second drive?
I can not see why doing it in one component should be any different
than doing it in four separate components. I'll see what you come up with.
For personalities or configurable pins, check for example the sampler component.
 

Wow, I just discovered UPS tracking says I get them tomorrow! 
They say it is a 17LB package, the open loop drive + four Nema 23 motors.

you might be able to use a USB modbus interface (serial to rs485)

hmm, mine were in stock and I  had them in about 5 days for the drive only. So I can take my time then

Looking forward to it... 
My 4 axis ethercat open loop steppers order status still "Preparing to ship" since Jan 23. I messaged them once lately and they acted like it will ship soon, even showed me photos of the packaged shipment. This is the same as my previous experience getting products halfway around the globe. No rush so far as I'm concerned, I got too many irons in the fire lately. 

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.