Advanced Search

Hello and thank you for your reply.
My encoder seems good and with the help of AI I modified the SPI to match my setup. I started from your E7000 version and made some cleaning of the main.cpp.
I went too fast and test in Twincat, I can see the device but its stuck in INIT mode yet. not surprising. I think the old eeprom is still there because in twincat, in the device I can see 8 inputs and 8 outputs, what I had on the original board.
I think I need to build the eeprom stuff correctly but I have absolutely no clue how to do it.

My github is up to date.
Do you have more information regading SDos and PDOs ? How to know what to write?

Thank you

HI Fdarling,
I actually tried to modify lcec to work with Yaskawa Sigma7 EtherCAT drive looking at the C program you have shared. I have had a little success.
I added a second domain (domain2) into lcec master but at the same time removed the write Pdos (status, actual_pos) from the lcec XML file. So the domain2 is empty pdos.
After doing this, I could enable the drive using drivecontrol regs. Although I cannot read anything from the drive (ofcourse).
Now the next step is to figure out how to add which domain to use information in the pdo configuration. I am going to try to make it backwards compatible.
I am open to all suggestions and any assistance on how to go about this task.
-automata

I am looking at the code now.
Encoder code from E3000 and E2000, are the only ones that have encoder input code.
I see that I treated it is a 16-bit counter even if TIM2 is a 32-bit counter.
I didn't research all registers, I found the encoder code here github.com/goktugh/EncoderStm32F4/
and was so happy when I found something that worked albeit 16-bit.
I think you need all files with encoder in the name

The initialization codeThere is code to handle an index pulse, you may remove that if it isn't relevant for you.
You get the current position from, it counts by itself. Just to read a register.
From that you can expand to velocity and possible other things, if that is interesting.

When you are confident that the encoder counter is rock solid it's time for spi and ethercat.
Settings are here github.com/MetalMusings/MyOwnEtherCATDev...uino-lan9252/spi.hpp The E7000 code is a good place to start for ethercat with LAN9252.
Verification of SPI is done by following the code to, from there to. SPI works when you successfully can read the test register, and the execution continues.

For the EEPROM, sdos and pdos and all that there is a utility in Utils/EEPROM_generator. Bring up a file manager view and double-click the index.html to open it in a browser. Here you enter SDOs and PDOs.  Save all and unzip all files into lib/soes-esi and it will be picked up be the code if you used the stanza I have. I think you can program the new eeprom with "ethercat sii_write eeprom.bin". I usually copied the esi file to Twincat and programmed it there, but lately I have used siitool with the -m flag, so siitool -m < xml-file > eeprom2.bin and the ethercat sii_write eeprom2.bin and that have work. 

Long post. Take it step by step. Make sure the encoder is rock solid. The ethercat part is pretty flexible once getting to know it.





 

Sorry links removed

now, I don't know how to set the delta y for the second toolbox 4-5-6, because it has a gap between 123 456

youtube.com/shorts/nZJZBoi4e4g

PCW wrote:

I don't take that negative a view of clone cards, if they get more LinuxCNC users,
that's basically a good thing. 

Hats off to PCW here. His tireless support to forum users and his client base is exemplary. He really has embraced the Open Source paradigm and I think his Mesa products are stronger because of it.

There is a new image coming that has some additional fixes.

For issues in the future please post on GitHub as I'm winding back forum use.
github.com/ozzyrob/linuxcnc-rpi-2.9.7-image-issues

I explain a little better.
It's been a hard slog making these images, and like the previous issue I want to keep all the fixes, issues, tips in one place.
So rather then the forum where it's going to be many different threads I'm want a single point of support.
I did try with the previous, one big thread, and an index to that thread but I still kept having to refer people to the index for the same questions.

The making of these images involved learning the RPi guys build them, working out what can and can't be taken out, some stuff is burried in meta packages, so for instance like piwiz it's burried in a meta package, so it is a little trial and error.
I'll take the blame, as when writing the image I was only setting everything via RPi Imager, which people had tried on the 2.9.3 images. So I thought well let's do that, and have it mentioned in the download section, and in the announcement thread. So that kind of didn't work.
It would have been easier if someone offered to help test in the early days but no one put their hand up. Whilst I knew how to get the image going as recommended, I wasn't aware of what happens when you don't follow the recommended way.
In saying that I have realised a few things. The main being to take a little longer to push them out, and to be clearer when explaining.
So guys if you can work with me on this, especially with reporting issues via GitHub, as I get emails when issues are raised, that would be great.
Thanks
Rob

When y'all say the first boot wizard, do you mean `raspi-config` or `piwiz`? Neither of them are starting for me on first boot with a card imaged with the latest Debian Trixie image I downloaded earlier today. I can't imagine I'm supposed to run a machine while logged into user `rpi-first-boot-wizard`, so something is supposed to change. 

I can `useradd` with the best of them, and I even know how to add a `udev` rules file that opens up the permissions on the GPIO. What I don't know is how the image is designed to be used out of the box.

EDIT: Forgot to mention that `piwiz`isn't found when I try to run it from terminal. `raspi-config` is there and usable, though, so I can get the thing on WiFi to update packages.

hi  fdarling ,
Could you share the driver or your modifications to lcec to make a Yaskawa Sigma7 EtherCAT drive to work?
I could get the c file in your tar to compile and I could get the actual position display from a Yaskawa Sigma7 drive on the screen.
The question I have it how to integrate the two domain requirement into the lcec_main.c component.
Hope you can guide me on this.
Thanks,
-automata

I don't take that negative a view of clone cards, if they get more LinuxCNC users,
that's basically a good thing. They really should supply source however, but there is no legal
requirement that they do, it just seems it would make the card more useful, and its practically
a necessity with card having expansion connectors and thus the common need to make custom
configurations.

Note that you should be able to safely test different firmware by writing it to the fallback location
then loading the FPGA from this location, then if the card doesn't work, a power cycle will fix it:

mesaflash --device cardname --addr 10.10.10.10 --write somebitfile.bit --fallback
mesaflash --device cardname --addr 10.10.10.10 --reload  --fallback


Note that this only works on Xilinx based cards ( I think all clone cards are Xilinx based )
DO NOT try this on Mesa Efinix based cards.
 

I have a similar machine but also has Z1-Z2 for backgauges.
Something new about some gui that fits to these types of machines ?

Found my AND8 hal component again! Will post it here for reference.

I think I should update my axis control logic to fault after a timeout of n.nn seconds of greater than n.nn minimum servo amplifier power and less than n.nn minimum joint velocity.

I ran into a situation where the encoder reading was incorrect, joint 6 was cranked against + hard stop, and the motor was holding stalled at max power.

This sounds like a bad way to fry a DC Servo, and we no longer have a spare. This axis has limit switches wired to the servo amp but not to LinuxCNC; I'm surprised the servo amp did not disable. I would spend more time diagnosing that; however, Cybelec couldn't provide manuals to me for these amplifiers because I am outside of their service region. Also, this is the ONLY axis on this machine with limit switches and the reason why I chose to move this one first. Plus, I think I will need to look into hard stop homing for Z1 and Z2, those have no homing or limit switches; only encoder feedback.

I see I need to fix my brake logic: I've been noticing glitches in joint motion and have discovered that when I am moving the joint slowly for longer than my servo-to-brake delay, it will lock the brake momentarily then release it again. I will just need to have it monitor several values besides j6-pwm-cmd. I'm thinking velocity feedback and distance-to-go. This will be directly related to the timeout logic above.

Once I get it right I want to rewrite it in a custom hal component which I plan to reuse on additional joints. The other joints with no brake probably need a parameter to switch off the unlock feature so it does not use the servo enable delays and cut servo amp output during no motion.

The R axis motor gets hot if it has to hold the axis against gravity for extended periods.

Hello.
All the links are broken.
So sad because I'm trying to run ethercat in my CNC and I'm having serious troubles to start them. Sometimes I have no idea if I'm making wrong things or there are problems with the repositories

Regards

Ich hab das alles noch nicht so ganz verstanden das bedeutet also dass die mesa karten dann mit smart serial miteinander verbunden werden oder wie ? Bzw wofür sind dann diese 25 poligen sub d stecker an den mesa karten da smart serial doch nur 8 pins braucht als stecker ? Und weche alternative gibt es zu der 7i77 da diese schon seid drei monaten ausverkauft ist bei den bekannten importeueren ?