Advanced Search

thank you so much. but I still have a problem.


sudo make modules_install install
sudo depmod
sudo echo KERNEL==\"EtherCAT[0-9]*\", MODE=\"0664\" > /etc/udev/rules.d/99-EtherCAT.rules

I got error>> bash: /etc/udev/rules.d/99-EtherCAT.rules no permission
So I fixed to 
echo KERNEL==\"EtherCAT[0-9]*\", MODE=\"0664\" | sudo tee /etc/udev/rules.d/99-EtherCAT.rules

sudo systemctl daemon-reload
sudo systemctl start ethercat

ethercat version
IgH EtherCAT master 1.6.8

ethercat slaves
0  0:0 PREOP + SGDXS-xxxxA0x EtherCAT(CoE) SERVOPACK Rev02.09

and then, I executed LinuxCNC with my simple config.

But nothing has improved. 
I attached dmesg. 

And then , what I did was.. syncToRefClock="true"
>> I got error, and LinuxCNC did not started.

refClockSyncCycles="-1"
>> I got LinuxCNC Terminal output "Failed to get reference clock time: Input/output error" (20 times )
What am I missing ?
 

Thinking aloud trying to wrap my brains around the ram motion pedal interlocks.

1. The ram must never go down unless the operator steps on the pedal.

2. After an e-stop reset it must 'ignore' the first time he steps on the pedal.

3. There are 6 electro-hydraulic spool valves and two servo valves, plus a tonnage regulator.

4. Homing requires use of the foot-pedal. It is ok for the ram to go up while the foot-pedal is depressed.

All valves must coordinate in the correct sequence or we dead-head the pump and stall the 18kw electric motor like right now. It is already doing that when I power the creep-up motion. Maybe I am opening the servo valves too far in creep up. Probably also the tonnage proportional valve. It appears the creep up hydraulic circuit is flow-limited by an orifice.

Up/down motion is primarily selected by reversing the power on the servo valves, secondarily by routing the flow with the correct combination of spool valves.

Valves 6.1, 7.1, 9.1, 10.1 plus servo valves 4.0, 5.0 drop the ram fast using gravity.
Valves 8.5, 8.1, proportional valve 8.4, and servo valves 4.0, 5.0 provide slow down with tonnage for bending the plate.
This constitutes every single hydraulic valve solenoid coil on the machine. Up occurs using most the same coils in a slightly different combination.

I begin to think this has to happen in hal. I wanted to hardwire that one, but I see it will be really hard to accomplish. On the part of the Ursviken schematic I had sort of figured out does that, upon closer study, I see it strictly only locks out all motion when the foot-pedal malfunctions and commands up and down motion simultaneously. The old computer directly powered the servo valves with an analog h-bridge card; that circuit was interrupted only by e-stop... and NOTE! I see the up-order button for the ram bypasses the e-stop circuit. I think it would be a really good idea to hardwire that feature back in.

Currently, I have e-stop cutting power to all drive systems, including the 18kw pump motor. Now I need to decide whether A: the motors stays running after e-stop so up-order still works; or B: up-order momentarily powers the pump motor to power the ram UP.

I think B makes more sense. Anyone have better ideas, or comments, etc?

zippoffs wrote:

But I have the VFD in a faraday cage, ...

I thought that was a joke when i saw the pictures
I should ask WHY but....nevermind
No use, VFD already has it's own Faraday cage inside, the cabling is still outside and those are like antennae emitting interference.
Fix the cabling, separate high from low side of stuff, use short cables, see about proper grounding from Hypertherm website, ground the PC and VFD and spindle, avoid ground loops, ... and stay away from ChatGPT and Faraday cages.
Also, see The Thought Emporium on youtube about Faraday cages, they just posted a video about how hard it is to build one properly.

su make modules_install install

try
sudo make modules_install install

Please correct me if I'm wrong.

I installed LinuxCNC using official image 2.9.4
&
sudo apt install linuxcnc-ethercat

sudo systemctl stop ethercat
sudo systemctl disable ethercat

and I executed the procedures below in home/etherlab directory

git clone gitlab.com/etherlab.org/ethercat

cd ethercat
./bootstrap
./configure --sysconfdir=/etc --disable-eoe=true

I got error message >> error :invalid feature name "eoe=true"
so what I did is ..

./configure --sysconfdir=/etc --disable-eoe

make all modules

Then I followed ---- INSTALL.md (gitlab.com/etherlab.org/ethercat/-/blob/stable-1.6/INSTALL.md)

su make modules_install install

I got error message >> su: user ake does not exist or the user entry does not contain all the required fields.

what should I do ?

I probably do need to go through all my grounding. However, everything functions properly if I run the program with the VFD turned off. So I don't think there is interference coming from the stuff right by the breakout board. But I have the VFD in a faraday cage, and the spindle cable shielding is grounded at both ends. What more can I do to contain the interference? Or do I need a faraday cage around the breakout board?

Do the 220v lines going from the breaker box to the VFD also emit interference?

PCW wrote:

If the encoder counts, its unlikely the index would be missed as the hardware
index processing uses the same digital filter as the A and B signals.
 

Thanks for the nudge in the right direction. I took another look at things and discovered my mistake: I was incorrectly watching for index-enable to go high on index. I went and manually set it high and sure enough, on index, it cleared. Problem solved.

tommylight wrote:

NWE wrote:

Most hard stop home systems I've seen, used steppers.
 

Yes, and not reliable at all, and only used on 3D printers.
Definitely not something used on large machines with motors that can do quite some damage.
 

You're right, I certainly wouldn't want to try it with big powerful servos. I should have included more context: These are small dc servo motors driving Z1 and Z2 on the Ursviken press brake I'm retrofitting. That is the independent left and right motion of the two fingers on the backstop. The whole thing is so overbuilt, these little dc motors are going to smoke before they destroy anything.

I have been studying the machine, and have come to the conclusion Ursviken had to have been using hard stop homing on these. All the other, more powerful axis have homing switches, and only the R axis has limit switches. I have not yet found anyone who has watched one of these homing, running the original Ursviken controller.

If the encoder counts, its unlikely the index would be missed as the hardware
index processing uses the same digital filter as the A and B signals.

I included a photo below of the servo drives I already purchased. We have them mounted on the gantry already. here is a link to them. www.omc-stepperonline.com/a6-series-1000...-ip67-a6-rs1000h2a1- 

NWE wrote:

Most hard stop home systems I've seen, used steppers.

Yes, and not reliable at all, and only used on 3D printers.
Definitely not something used on large machines with motors that can do quite some damage.

Well I found somebody to help with this project and we were chugging away making good progress at it. I dident hear from him in a week or two and he messages me saying he was in a bad accident and just got released from the hospital. its been another week or two and I havent heard back from him. Really sucks hopefuly hes okay but we gotta move forward in the project. Is anyone here still interested in helping? im going to post all of the progress we made below its a google sheets aswell as a few pdfs  docs.google.com/spreadsheets/d/10GAzmrCI...184782#gid=730184782  

Interference issues, as seen on your second picture where the high voltage/power stuff is very close to parallel port/BOB, and messy wiring.
First make sure the grounding is OK, then move low voltage stuff as far from high voltage stuff as possible, use short cables, no spaghetti!

Sorry, I forgot to write, these are DC servo motors. Most hard stop home systems I've seen, used steppers.
I think I will write a hal component homeswitch-hardstop that monitors encoder velocity and latches a home-switch-output when the velocity decelerates faster than decel-limit (or servo motor load exceeds max-load?). The latched home switch output clears when the velocity changes direction and moves farther than min-backoff. These encoders do not have index. The most repeatable home position will be with the motor stalled against hard stop. The instant the motor power is switched off, the axis will likely rebound slightly, probably an unrepeatable distance.

I guess I will need to use the homing method of:
1. Home search velocity toward hard stop. Ouch, not at max power!
2. Home switch output latches on hard stop.
3. Back off home switch; home switch unlatches when it detects reversed motion.
4. Home-latch-velocity toward hard stop.
5. Homing complete; move to home-pos at the speed of home-final-vel.

I see I could use this component as shared home + pos limit switch + neg limit switch.

Hey, is anyone doing hard stop homing? I'm not finding any combination of LinuxCNC + hard stop homing. Google is not my friend today. Llm claims to know everything about it but I'm not buying that. If google doesn't know about it then llm has got to be fabricating it.

I am ready to try coding a halcomp if it doesn't already exist. I just don't got time to reinvent the wheel if someone else has already done it.

I consider hard stop homing to be the least accurate version of homing, but in today's project it will be a lot better and cleaner than rigging up some homing switches. If I can attain 5mm repeatability I will be happy, but I am confident I can do better than that.