Advanced Search

i used hard stop homing on many machines with mitsubishi/yaskawa servo drives. all of them have a "torque limit" input and a "torque clamped" output. so just connecting

joint.*.homing => servo-*.limit-torque
joint.*.home-sw-in <= servo-*.torque-clamped

does the trick.

and here's the video when i'm using "torque-clamped" for motion.probe-input. with z axis driven by 2mm pitch sync belt on 20 teeth pulley it is able to resolve silkscreen paint thickness on a PCB...

Oh no, something else not quite right with my build. The halrun binary seems to be missing. I will try to find out how that dropped out. I will need it for the project where I plan to use this pi3.

Another latency test. The previous one I shared was run a couple minutes with nothing else running. This time I gave it the works. How about 10mS latency.

Here are the error reports I get trying to wake QtDragon. seems to be a complaint about the ngc path. I'm using run-in-place. I've got to look at this again. Just writing it up gave me more ideas.

Wow, I can hardly believe I did this to a pi 3. The simulation is running. Next I want to check if gpio and a couple other basics work. The latency numbers look a bit sad.
Still no luck starting QtDragon.

Sorry to hear about the accident. That work you shared looks nice. Someone had it about all figured out. Wish I could help out. Dunno, my own wiring schematics are just scribbles on paper.

That is interesting. One of my friends is building cnc plasma tables, he uses his favorite proprietory software (Centroid), along with ClearPath servos. I don't recall whether we ever talked about his homing. Next time I meet him I might remember to ask how his system does it, just out of curiosity.

I am having the same issue, I tried to modify my io.hal file as suggested but i am getting an on/off dance in hal show with no indication of probe trip. I have attached my original hal file as well as the actual one I modified. 

I finally got around to wiring up and adding the logic for my pendant and it now jogs. I even messed with the PID well mostly P so the axis actually move at a reasonable speed without tripping out. This is going super well, I just need to work out a small scaling issue. Seems like it moves about 90% of the command in real life so my encoder counts are likely off. The last big hurdle is getting the gear shifting logic to function and then I'll be off to the races with being able to machine some parts with it. The conversion had a small interruption of purchasing a bum tractor that needed some major work but that is mostly behind me now and I have a bit more room to mess with the mill again.

FWIW Tormach does hard stop homing on their ClearPath machines. I retrofitted my Series 3 with them and honestly it seems to repeat pretty well. Certainly better than 5mm. I haven’t done an experiment to precisely measure it, but I’m fairly certain it’s within a .001” - .002”

I attached dmesg file which is
refClockSyncCycles="-1" version.

(PS)
I have to add this info.
I tested multiple times this refClockSyncCycles="-1"  version.

sometimes (33%?) , No alarm , and I could Power on (servo on) and jog moving.

But sometimes ( 66%?) I can't control servo motor at all from the begining after execute LinuxCNC.
In this case, CiA402 status=0000.  if I pull off and push in  (reconnect physically) EtherCAT cable several times, sometimes get correct status,
and after that I can control servo. ( not all the times )




 

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