Thanks for quick reply. I will try this? Does default rpi install have any swap enabled?

neeeed jerk controllll.... hahaha

I suppose having the drive itself in position mode is causing this? The movement is choppy no matter what. I suppose it's because the output is controlling a position step/dir signal rather a speed signal? I wanted to rewire it for speed, but apparently my drive doesn't allow for speed control over digital step/dir signals. I'm sure there must be a way for it to work in position  mode though? 

Hey, you are spot on. I realized this late last night as well. The manuals confirm that this series of drives are designed for 120V inputs.I also confirmed that the power supply going to the chassis is a 277V (single leg of 480-3) so it must be that there is a voltage drop, and then, a rectifier before the capacitor. I attached the picture for today's work, but I think there is an SCR directly below the cap, and to its right is the rectifier. I was expecting a transformer and completely missed the SCR hidden behind the wires. I'm trying not to change the wire layout until I am more comfortable, but I think I am getting there. 

So I think the drives have: DC in, DC out, tach, reset/enable and 10V command. 

I do not believe there is a bridge rectifier. I think its just an SCR and then a couple of diodes. Will take apart the wires and check today but I am getting more and more confident that if I identify the 120V input (native to the SD chassis, without the 480V single leg add on) I should be able to connect 120V to it and make it work. Just need to find me a box of 100W lightbulbs.

The hardware spindle enable can never get set:

net spindle-output => hm2_7i76e.0.7i76.0.0.spinout
net spindle-enable => hm2_7i76e.0.7i76.0.0.spinena << hardware spindle enable
net spindle-ccw => hm2_7i76e.0.7i76.0.0.spindir

# ---setup spindle control signals---

net spindle-vel-cmd-rps <= spindle.0.speed-out-rps
net spindle-vel-cmd-rps-abs <= spindle.0.speed-out-rps-abs
net spindle-vel-cmd-rpm <= spindle.0.speed-out
#net spindle-vel-cmd-rpm-abs <= spindle.0.speed-out-abs
#net spindle-enable <= spindle.0.on << but the signal is not driven

One possibility is to change:
net pdnt.spindle.is-on whb.halui.spindle.is-on spindle.0.on

To
net spindle-enable whb.halui.spindle.is-on

and uncomment this line:

#net spindle-enable <= spindle.0.on

 

 
Hello Everyone, 
I have been working with LCNC for a couple of years now, but I am just now entering the forums. I am currently struggling to solve a CIA402 and Ethercat issue. I have set up Yaskawa Sigma-X servo packs using the CIA402.comp by  dbraun1981  and Ethercat Lcec. My problem is that on startup, the servo packs will transition through preop -> safeop -> op, but after sending the servo on control word one or more of my servos will drop to preOP or preOP E. I can fix this by sending the EtherCAT states OP command in the terminal and trying again. Sometimes I have to repeat this process 4 to 5 times before they all hold the OP state. I am thinking that it is related to distributed clocks or something along those lines. I was able to temporarily resolve the issue by setting the Sync Error counter limit to 0 (Disabled). I would like to use the Sync Error counter as intended, so if someone knows how to fix the desync issue on startup, that would help me out a lot.

I was trying to load gcode file for small engraving of size 200x150mm, gcode file size is 243MB. I tried qtdragon_HD and Axis GUI both crashes while loading the file. Even I tried disbling preview by adding (AXIS,hide) at start of GCODE. But didnt helped. Using Raspberry PI 5, 4GB RAM version.

With ec_igb or ec_igc native driver: interrupt moderation is irrelevant, they use polling not interrupt.
With ec_generic: interrupt moderation is active and you should disable it with

ethtool -C <iface> adaptive-rx off rx-usecs 0 tx-usecs 0

probably as soon as possible on boot, before ethercat starts.
To know which drive you are using, check your erhercat.conf file

Just in case anybody has to deal with similar problems:
I had to investigate a bit further since the spiking came back, but I think it might be working now. The spiking indeed was graphics related, this thread is slightly misplaced now but anyway.

Software rendering seems to work the best with this hardware:
LIBGL_ALWAYS_SOFTWARE=1 QT_OPENGL=software MESA_LOADER_DRIVER_OVERRIDE=llvmpipe \

So OpenGL Mesa this time, not the usual Mesa:)
I don't know if it is a good practice to use software graphics but I'm open to suggestions.

I found another clue.

A Google search for "Intel NIC interrupt moderation" yielded the following advice: this should be disabled, as it can also lead to jitter.

The Cause of Jitter: When enabled, the time between packet interrupts varies depending on traffic flow (sometimes fast, sometimes slow), causing inconsistent packet processing times.

That would at least be worth investigating.

I know you already have two 7i96 cards, but perhaps using only one of them with a 7i78 daughter card connected to the expansion port of the 7i96 might be a better option than the two 7i96 cards to get extra stepgen outputs?

Did you change the IP address on one of the 7i96 cards so that they are not the same? Set the first as 10.10.10.10 and the second as 10.10.10.11. You have to use the Mesa flash utility to set the address on the card. Set the static IP for the nic on your Linuxcnc PC to 10.10.10.100 (or something other than 10.10.10.10 or 10.10.10.11 but in the same range.)

I believe you can use a switch, but the switch and the PCs ethernet port need to be dedicated only to this use. If you want to also have an ethernet network/internet connection you will need a second nic on the pc for that.

Here's a thread with instructions from Peter at Mesa
www.forum.linuxcnc.org/38-general-linuxc...sa-7i92-via-ethernet

Hello,
When I implement the XHC-WHB04B-4 handwheel in LinuxCNC, my milling motor no longer receives a speed command via gcode file or mdi command. 
I had to remove some commands from the *.hal file to prevent errors from occurring at startup. My files are attached.
 

Am I understanding correct your brushed DC servo motors are 140 volts? That leads me to think your analog servo drive is likely designed to operate on 120V power. 120VAC rectified to 170VDC is plenty good.

If the analog servo drive uses a bridge rectifier, then, no, you cannot connect negative to ground. You will have smoke and sparks. Unless it is powered by an isolated 120VAC source (some do it like that) Then they sometimes ground the negative side. I would check how it was wired and keep that the same.

More detailed photos of the servo drives would help a lot.

Your power-up test might get more realistic results if you leave the servo motors wired to the drives and rather mechanically uncouple the motors from the axis drive-train to avoid run-away accidents. 1.5 volts DC should be perfect for the speed command test. If your servo drives have good speed regulation, trying to do this without a motor wired to it would cause it to either go full power or fault because it did not receive speed feedback from the motor.

I have got my repaired 7i76eu board returned from Mesa, Thanks again Peter. I have all the limits and estops showing now on Hal show and they are working correctly. I try to home all or jog and the machine just vibrates and shacks until I hit the estop. I have checked everything I can think of. Except for the inputs for limits and estops etc that weren't working before I could get the machine to move, now I can't???? Everything was hooked up as it was before I don't think anything has changed.