Advanced Search

I'm looking forward to retrofit an new to me Okuma MC30-VA mill. I already have another okuma will with a Mesa setup that's been a workhorse and never skipped a beat for the last 3 years. It uses Delta ASDA A2 servos (Incremental with home switches) and it's been incredibly accurate and repeatable with properly tuned servos. Even 3D surfacing at high speed, it handles like a champ.

So I need to use absolute servos for this new machine. Looking at delta ASDA A3 servos as the drives have Ethercat support. 
My main concern is not the price of Beckhoff modules. I'm curious to know how the ethercat setup handles the motion control part. In mesa we get the FPGA base step/dir signals and I read the ethercat system uses a target position. So I guess the control loop is closed on the PC with the encoder feedback from the motors. So how fast can you really push an ethercat system without running into following errors and latency errors etc.? I mean like in high speed 3d surfacing ? 

Can anyone offer some advice on which system should I go with or point me to some user experiences?

This machine is in excellent shape I really like to set this up as close to a oem controller.

 

Latency test is only used for testing the pc, don't use the jitter value for BASE_PERIOD, try 50000.

Should i also delete my quotes of your posts?
-
BTW, i am afraid to ask why, but i am also sure you have your reasons.

Hi, did anyone get this to work?
I'm planning to use delta absolute servos for a retrofit, I'm very familiar with mesa hardware and really like to use absolute servo position for homing. 

Hi Endian, I am just getting started with setting up an ax5203 drive and your scripts and configs mentioned in this and previous topics sound really helpful, but they are no longer available on your codeberg. Do you plan on reuploading them somewhere?

I didn't have the SUBROUTINE PATH located in the [RS274NGC] section of the .INI file. That allowed me to use my subroutines with slight modifications..

I would try using a new LAN cable, preferably CAT6

Changing the cable can help a little. You can also try to go even lower with the SPI frequency; it really depends on how fast your servo thread is and as long as your SPI communication is faster than the servo thread, it shouldn't be a problem.

I agree that the wiring would be a mess if you had to wire the TMC directly to the RPi. I was surprised when you said that the H7 version worked but not the F4, as they share the same remora-core repo, which contains the tmc module. I think I found out why: on the SKR (H7), the remora comms is on one SPI channel, and the drivers are on another one. Scotta decided to use SoftwareSPI to communicate with the drivers. On the Octopus pro (F4), the remora comms and the motor drivers share the SPI 1 channel, so my guess is that is causing the issue. To my understanding, the same SPI channel cannot be a master and a slave at the same time, and it is a slave for the Remora component. If you want it to work on the Octopus, you'd have to connect the RPi on a different SPI channel and adapt your platform.ini file accordingly. I don't have a board myself, but as far as I could see on the product datasheet you could use the SPI 3 channel on the J74 header.

Congratulations! Most well deserved. (Infact, you probably deserve much more.)

There was no need to even run PNCconfig. You can simply copy the whole config directory from the old machine to the new machine.

Hello,

since my problems persist and one Y-axis does not move during homing, and I don't give up so easily, I tried “dmesg” and “ethercat slaves -v” again.I see two errors in the output:[  459.958251] EtherCAT WARNING 0-1: Slave did not sync after 5000 ms.[   13.362825] EtherCAT ERROR 1: Failed to calculate bus topology.Otherwise, everything is OK and the drives go to OP.Where could the problem be?I also don't understand why I have to turn off the servos and Linuxcnc and restart them for homing to work. 

I'm putting together my third LinuxCNC system. Using Axis and a Mesa 7i96s

This one will be an almost direct copy of a previous installation I did for my small lathe, this time for a new lathe.

To get started I ran the PCNConf wizard skipping over some of the configuration just to get to the point where LinuxCNC will launch.

Now I'm hoping to simply substitute in a copy of the hal files from my old installation (basically replace the hal files PcnConf made with my old tried and true hal files).

Does this sound like a viable plan?

Possible wrinkles:
One possible wrinkle is that I needed more I/O on the previous 7i96s and I did some sort of "firmware upgrade" to the 7i96s to get more encoders via the expansion port so I will need to do that again. need to see if I can find my notes for that. Also not sure if the old upgrade file is still viable?

Both setups use a Lenovo Yoga, however the latest one  (Chromebook C340) requires a USB-C to dock to get an Ethernet connection. I picked up a dock from Amazon (UGREEN) and have managed to get the Mesa card recognized by LinuxCNC but the mouse (also connected to the dock) seems to go to sleep (often) and I have changed the power saving setting to stop this, but they don't seem to be preventing mouse sleeps. My concern is that the entire dock might be going to sleep including the Ethernet port.

Any advice is welcome.

Congratulations!

Looks like you have a print statement that prints the current axis position somewhere in your code.

Hi
I got tree Stepperonline A6 servo motors up and running in XYZ mode using the attached files. When I close LinuxCNC, however, all three drivers show error ErC 1.1, i.e. Sync Error. When I start LinuxCNC again, the errors disappear. So it is not a big deal, but it is ugly to see that the program was not terminated in a decent way. 

I suppose that there must be some appropriate commands in the shutdown.hal file. I tried a lot of things, but none of them worked. Dies anyone know what to put in the shutdown.hal file to prevent the sync error or is there an other way to prevent this error?

Thanks