Advanced Search

Kieran wrote:

How's the rigidity of the harmonic drive? 

My 4th axis is based on a 32-size HD reducer, and I've not had any problems with stiffness.  It has a 6" faceplate and is on a 1-1/2 riser, so I can swing approximately 8" diameter parts or stock.  Note that the reducer is mounted in a steel frame/housing - not aluminum - to increase rigidity.

I've never machined 8"dia stock, but I have drilled 3"-4" off the rotary centerline.  1/2" drill in mild steel with no torsional deflection noted - at least not enough to cause the hole to be non-perpendicular or out-of-round.

I expect a 40-series reducer would be fine for a 6" or 8" rotary axis... and perhaps 5hp-10hp spindle class machine?  Like a Tormac 1100/1500, VF-2, or Fadal 3016... but not VF-6 unless you baby the rotary axis.  Probably be fine on any 30-taper machine.

I think this is a post with a kinematic for such a lathe configuration:
forum.linuxcnc.org/show-your-stuff/53476...rical-mapping#307444

Good day hivemind.

I've been struggling with getting my mill up and running. It's running from an Mesa 5i25 / 7i76 (par port) controller, Leadshine HBS86H driver / 86HBM80C-1000 motor (closed-loop) at 70VDC; 1000PpR. And a BEST FC300-2.2G-S2-B4 VFD.
Attached is a zip with the config files.
Eventually i got it mostly functioning.
I got my homing to work.
Got my pendant (old XHC HB04) to work and operate the axis/spindle/feed.
I reserved a few inputs to add limit switches (at end of stroke). Might want to add extra past-home limits too to prevent overshoots. Setting the homing sensors to act as home and limit (PNCConf option) just gave errors when running LinuxCNC( can't start, limit switch active or something along those lines).

What is left:
Speed!. we want it....
I have a high speed spindle on a VFD (0-10v input, no feedback (jet?)). 24000rpm@400hz. No problems there.
When i turn the spindle on, the speed on screen reads as 300rpm at 100% and the VFD runs up to it's 400Hz max. Turning down to 50%, the VFD goes to 200hz and 12000RPM. But the screen reeds 150rpm.
The speed bar under the speed and % reeds " 0                0                  6000"
And the "at speed" dot doesn't turn green. I do have that output from the VFD connected to the board.

How do I get the display to show the true RPM?
Can the 0-10v output from the VFD be connected to the 7i76 as speed feedback?
*****************
Next question:
I also have a relay on TB6-output2 to which the spindle coolant pump is wired. How do I get that 'programed' to turn it on when the spindle is running? (and perhaps add a function to the pendent to manually turn it on/off too?).

TIA,
Niels

Hi all,

For info.
The distro is updated to use Debian 13 and linuxcnc scurve + ethercat.
There where some problems to get ethercat running on linuxcnc, these are now solved.

repository.qtpyvcp.com/repo/linux-distro/

The debian-disk.img.7z is to use directly in qemu vm.
The debian-raw.img.7z is to be copied to usb.
 

So nothing i can do against it right now? :/
 

Thanks! I will look there and see if i can get any wiser.

Edit: Look at that. Now the compensation follows work offset with those changes. Cool. Only the positive coordinates thing left then.

Ok much appreciated.
It's 2:45am I best be getting some sleep.
Guess I'll swap the eeprom.

I will be back at work in a few weeks, and i can look up the manuals for it then. These older ones can be tricky to find digitally, but sometimes one gets lucky.

I am pretty sure the drives need to be in ethercat OP state before they start to act on cia402 commands/changes.
Read/write of PDOs is only in OP state. You can read and write SDOs with "ethercat upload/download " to modify config in PREOP.
lcec and ethercat-conf.xml should bring the slaves to OP state.

Debugging tool is apart from the normal text output from linuxcnc, the system log;
"sudo dmesg" for recent messages and "journalctl" for the history.
Ethercat server puts out quite some informational, warnings and error messages there.
Debug output can be had with the "ethercat debug 1" but then the problem is to decipher that. "ethercat debug 0" resets.

Sadly not. At least so far. But i saw it in motion and for Y both axis where moving. Also when i looked behind the work envelope where the column is traveling i could see the y and x at an angle ( i assume 60° between them). You can see it even a little bit on the picture if the ATC I've posted ealier.

But concluding i dont need to switch the kinematics between Mill and Lathe. That makes things easier. Its year 1998 Integrex 200Y

Sounds like the MAC/cardname/ipaddress/netmask EEPROM has not been programmed

That is correct. The ones i have worked on are mostly newer ones and have straight X and Y axis. Do you have the manuals for it? All the geometry should be specified there. What year is it?

Building 7i92 firmware for a custom board. I've had to play around with

Turn on board everything seems ok, user leds count packets
IP set to 192.168.1.121
Responds to pings
When jumpered for bootp an ip address is received and I can ping it.

This has me stumped 7i92 mac is ff:ff:ff:ff:ff:ff

$ mesaflash --device 7i92 --addr 192.168.1.121 --verbose
Unsupported ethernet device ��������������������z at 192.168.1.121
No 7I92 board found

��������������������z bit will change on each mesaflash run


Wireshark dump

32    7.057855358    192.168.1.20    192.168.1.121    UDP    46    50697 → 27181 Len=4
Frame 32: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) on interface ens5, id 0
Ethernet II, Src: UniversalGlo_3e:7d:ac (cc:52:af:3e:7d:ac), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 192.168.1.20, Dst: 192.168.1.121
User Datagram Protocol, Src Port: 50697, Dst Port: 27181
Data (4 bytes)
    Data: 01420001
    [Length: 4]

33    7.058018908    192.168.1.121    192.168.1.20    UDP    60    27181 → 50697 Len=4
Frame 33: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface ens5, id 0
Ethernet II, Src: Broadcast (ff:ff:ff:ff:ff:ff), Dst: UniversalGlo_3e:7d:ac (cc:52:af:3e:7d:ac)
Internet Protocol Version 4, Src: 192.168.1.121, Dst: 192.168.1.20
User Datagram Protocol, Src Port: 27181, Dst Port: 50697
Data (4 bytes)
    Data: fecaaa55
    [Length: 4]

34    7.060132328    192.168.1.20    192.168.1.121    UDP    46    50697 → 27181 Len=4
Frame 34: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) on interface ens5, id 0
Ethernet II, Src: UniversalGlo_3e:7d:ac (cc:52:af:3e:7d:ac), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 192.168.1.20, Dst: 192.168.1.121
User Datagram Protocol, Src Port: 50697, Dst Port: 27181
Data (4 bytes)
    Data: 885d0000
    [Length: 4]

35    7.060285405    192.168.1.121    192.168.1.20    UDP    60    27181 → 50697 Len=16
Frame 35: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface ens5, id 0
Ethernet II, Src: Broadcast (ff:ff:ff:ff:ff:ff), Dst: UniversalGlo_3e:7d:ac (cc:52:af:3e:7d:ac)
Internet Protocol Version 4, Src: 192.168.1.121, Dst: 192.168.1.20
User Datagram Protocol, Src Port: 27181, Dst Port: 50697
Data (16 bytes)
    Data: ffffffffffffffffffffffffffffffff
    [Length: 16]

I'm guessing the data in the last packet isn't right.

 

hello,

this topic is quite complex if you dive in it.
First of all, the mentioned github repo is intended for 3d printing, so maybe thats why it works with positive coordinates, which is usual for 3d printers.

i would recommend checking out DauntlessAq fork and PR, where he corrected some issues:
github.com/scottalford75/LinuxCNC-3D-Printing/pull/8

There is description of the issues.
 

I would like to suggest a feature to fine tune ohmic probing.
Problem: When I set the probe height to an optimal setting for a thin steel setting, it will be too low for thicker steel, and set for thick steel it has excess travel.
My solution would be to add the material thickness to the plasmac.probe-start-height.
Keep the probe height setting function the same, but add a new setting into each material entry for material thickness.
To try to see if it would work, I used the puddle jump delay setting and used the sum2 function to add that number to the probe height. It seemed to work as expected.
With material thickness added the probe height should be more consistent with the top of the material.

This is the code I added to the custom_postgui.hal file.