Advanced Search

PLL was documented not long ago. Wasn't aware it can stop linuxcnc, that's a bit excessive.
github.com/linuxcnc-ethercat/linuxcnc-et...istributed-clocks.md

This hopefully explains it better...


So per the manual, I have the following control commands: Pin 7 / Pin 8 (Analog in) connected to a Mesa analog output, and jumpered for 0-10V. This is the main control. The VFD doesn't get on/ off commands, it gets speed commands. Pin 9 (Power for a control poti) Unused. Pin 62 (Analog out) Unused Pin 20 (power out for digital inputs) Unused. Pin 28. (Activate VFD) Controlled by Mesa digital output.Pin E4 (Change direction) Controlled by a Mesa digital output.
Pin E3 DC (DC braking) unused.
Pin E2 (Jog at frequency 2) Unused.Pin E1 (Jog at frequency 1) Unused.
Pin 39 (Gnd) Connected. Output Relay
K11 (NO Out) Connected to Mesa inK12 (Common) Connected to Mesa in.

Servo2Go seems to still exist, but I don't see anything like the original Servo2Go ISA bus interface card on their web page.
Jon

Having mostly put the machine together and found ModbusTCP unsuitable, I took another attempt at Ethercat.

1. I installed LinuxCNC 2.9.4 from the ISO on the nearest available beige box (which has a Realtek ethernet card)
2. I installed the r8168-dkms driver
3. I built ethercat from source to exclude EoE as follows:
   1. git clone gitlab.com/etherlab.org/ethercat.git ethercat-master
   2. cd ethercat-master/
   3. git checkout stable-1.6
   4. ./bootstrap (I didn't have autoconf or libtool installed: they are necessary)
   5. ./configure --sysconfdir=/etc/ --disable-8139too --enable-userlib --enable-generic --disable-eoe
   6. make all modules
   7. sudo su
   8. make modules_install install
   9. depmod
   10. exit
   11. sudo nano /etc/ethercat.conf
   12. sudo systemctl enable ethercat.service
   13. sudo systemctl start ethercat.service
   14. sudo systemctl status ethercat.service
   15. sudo chmod 666 /dev/EtherCAT0
   16. sudo nano /etc/udev/rules.d/99-ethercat.rules
   17. sudo udevadm control --reload-rules
4. I installed linuxcnc-ethercat from the repository
5. I installed the CIA402 module:
   1. git clone github.com/dbraun1981/hal-cia402
   2. sudo halcompile --install cia402.comp

And it works very nicely most of the time. See attached ethercat xml file.

I see some "PLL error" failures sometimes, which can only be "solved" by restarting the control process. I've tried adjusting refClockSyncCycles and sync0Shift in accordance with some other threads, but I don't understand what those do or what they should actually be.

The AC servo drives won't work because the wiring currently is only halfway complete, and I want to have the system documented in the intended state before I power anything.

There's no config loaded on to the Mesa cards yet (or a config between the Mesa cards and LinuxCNC), so after talking to my friend who kicked the project off, I've decided to take a slightly different approach, which is I'm going to set up and configure the EStop switch for LinuxCNC first, so I can verify that each of my components work. I will: Document the wiring, wire the switch, confirm the connections, verify the Mesa card functions, establish the appropriate configuration in LinuxCNC for the EStop switch, and use Halscan to verify it works. Once I've confirmed I can get a functional switch in LinuxCNC, I can start taking on something the servo wiring problems. 

That way I'll know the base of the software / hardware stack works well, and I can proceed confidently with wiring the servo drives. It also hopefully gives me a chance to do more research on if my wiring setup will work / get some feedback on my proposed plan of Analog +10v control with the encoder wiring as documented above. Once my documentation is a little more cleaned up, I'll share that too.

Edit: Oh, and I appreciate the advice to focus on what's in use, but I like to see things in the context they exist in, it's helpful for me to conceptualize the whole system - I've already roughly documented all of the existing connections and what they're used for, so it's mostly about trying to figure out how the systems fit together and deciding on the pattern that I want to wire things in to make it so it's easy for me to understand it if I have to work on it in the future.  

Mesa, Pico, Parallel port and EtherCAT are safe.

It's the other stuff I am really interested in. Can we safely sunset those drivers?

Mach 3 always crashed the PC whenever I tried it.

LinuxCNC worked first try.

I was referring to the wiring; LinuxCNC is good.

Software becomes outdated; wiring does not (normally).

Looking at something existing that works is a great way to learn.

A lot of the stuff in that picture is totally unconnected.

I would remove those, at least temporarily, so you can focus on what's actually in use first.

I suppose those AC servo drives probably connect to those parallel and serial port plugs; connect them up and see, perhaps it works as-is.

Though it appears 2 of the drives aren't connected to power, so fix that first.

wiring issue causing a short?

I did not encounter any bugs, but than againe i used it for 15min or so and did not run a programm, ohnly joged it a bit and tryed the simple to test stuff
But that is definetly an opinion strenagsening me in the get rid of it all thinking.

Yes, I saw it.

But with 3 axes it works. That's why I'm asking.

I haven't used Mach3 for more than 10 years (it's an obsolete buggy system), but I thought it was not great / had issues with lathes?

I think the tricky part  with feed override and spindle speed override
is to get along with the GUI

yes, I knew about the 7i96s, yes, I had connected two independent ones when I had a lathe that worked in sync... here I will find an example for one via the axix selector,as a pendant I think it's not a problem. My problem is that I don't know how to connect potentiometers in the hall (if the first three inputs in mode 3 are analog on the 7i77?) how can they recognize it in the hall as spindle override and feed override?

hm2_eth: ERROR: Could not retrieve hardware address (MAC) of 192.168.1.121: Resource temporarily unavailable

Means that there is no communication with the 7I96S