Advanced Search

Kondia FV-1 turret mill, running Gmoccapy 2.9.4.

Y-axis Nema 34 sheared the shaft at the step where the diameter had been reduced from 14 mm to 1/2" (and grubscrew).
Unknown if done by previous owner or factory option.
Drive uses an unsupported pulley with T10 x 25 mm timing belt and significant tension.

Can anyone confirm that this is a recognized risk with this arrangement ?
With a reduced shaft ?

Both Y-axis and X-axis steppers replaced with new ones, with keyed 14 mm shaft.
John.

thanks a lot. tomorrow i try if it works. it is getting to late. the 7i85 board is not connected yet. i first want to make all working. then i will connect the encoders on the motors and connect the 7i85 board. what pins do i use without the 7i85 board to use the pwm?

If you have the limit switches, keep them. It does make for a safer machine. I used seperate min/max/home on my first machine but my next one I used a combined home/min limit switch only with no max limit.

nhof wrote:

Another technical reason Ethercat is fast is that the slaves use custom Ethernet chips which can handle process data 'on the fly' without introducing delays.

That might have more to do with licensing. (the Ethercat license is paid for when purchasing a Ethercat sleve controller like the Lan9252 often used in slaves)

Ooops. Corrected the original post. I did realise I had got this wrong for the purists but was too lazy to battle with the forum editor.

rodw wrote:

Note that CNC is a small subset of Ethercat use as the majority of devices are deployed in factory automation. There are other field bus technologies mentioned in the PDF (and perhaps Mesa's hm2_eth driver) that compete but they are based on standard TCP/IP packets and while Ethercat also uses TCP/IP (perhaps TCP/IP are the wheels on the train). But Ethercat is much more efficient (lean) protocol so it performs better.

A small correction here, Ethercat does not use TCP/IP but instead uses 'raw' Ethernet frames.

Another technical reason Ethercat is fast is that the slaves use custom Ethernet chips which can handle process data 'on the fly' without introducing delays.

Mark wrote:

Has anyon e noticed smoother operation with linuxcnc vs other s when they switched?  
 

Yes, many of my clients and friends, that is the first thing they notice when the machine starts moving after switching from Mach.

Mark wrote:

My liimit switches are only two wire.  Is this going to work? 
 

Yes.

Mark wrote:

I have a threee wire home swithc set up hall sensor
 

Might be to late but, LinuxCNC can use a single switch for Homing and min/max limits, per joint/axis, so you do not need separate switches for limits and home.
3 axis machine = 3 switches total <<<< example
You can also use any combination of switches as you need/want.

bobwolf wrote:

Subject: Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Hi all,

I’d like to open a technical discussion about a project I’ve been working on, io_decoder, focusing on the software solution I've implemented to handle USB communication within LinuxCNC.

 

+1
More hardware support for LinuxCNC.

I am very much interested in this project. I have experience with embedded mcu applications, but zero experience doing development with the USB stack. Last year I was thinking that this type of I/O via USB connection should be developed, but did not find time to start on it.

I like the mechanical format of your boards, for edge-mounting them on a DIN rail.

Ethernet is very good for EMI prone applications, however, there are plenty use cases with less EMI where USB is just fine. For example, I have LinuxCNC reading an industrial position sensor through a cheap USB to RS232 dongle going on about 10 years by now. It substitutes for an encoder, providing feedback for a relatively slow moving PID controlled axis. This is on a setworks on a lumber mill, to set board thickness. The only interference problems they've had was of a mechanical nature, when a log jams in the wrong spot and rams the $2500 USD magnetorestrictive position sensor. It gets all bent out of shape, but lasts more than 5 years.

Got it .  Spindle running and all axis running now just need to tune axis and get limits and encoders set up this is amazing after so many days I think this is going to be worth it because I have more of these conversions to do and I have learned so much it is amazing.  Without even tunning the spindle is behaving really well with no feedbac yet.  I was having trouble in uccnc wtih overshooting and taking awhile to get settled.  Has anyon e noticed smoother operation with linuxcnc vs other s when they switched?  The exciting thing for me is the prospect of ridgid tapping.  .  My liimit switches are only two wire.  Is this going to work?  I have a threee wire home swithc set up hall sensor
 

Mit dieser Anpassung sollte das vollständig durchlaufen

    #2 = [#2 + 1]
   #1 = 0
o101 endwhile

7I76EU firmware for 7I85 on P1, and 1 PWM on P3

 


After doing this I also had a thought that you could use a spare RS-422
output on the 7I85 for the PWM output, so you get a  buffered output
rather than a bare FPGA pin.

 
 Thats a dodecadon lol
I was planning to make rounded corners actually be radiuses in the gcode G2 G3, probably next week, unless you want to oblige, many thanks again Rüdiger!

Reply to PCW with:
"Yes, that's correct:

7i85 encoder card on P1 (first DB25 expansion connector)
PWM on P3 (second DB25 expansion connector) for laser

Or if it's easier, PWM on P1 and 7i85 on P3 - whichever works best for the firmware. i use all 5 stepper outputs. so any port or pin you think is best will do.

I'm a little unconvinced how changing to USB would have an affect on the "wiring nightmare or EMI issues".
At the end of the day one still has to make a connection from the input or output device on a control panel to the interface board.
The wiring nightmare and/or EMI issues will be a creation of the practices used by the person doing the work. In summary these issues are going to be site specific.
From memory Mesa did have a USB interface board, but is now listed as obsolete. It also supported EPP, only mentioned for completeness.

Ich versuche gerade eine while Schleife in einer while Schleife zum laufen zu bringen, die äusere Schleife wird nur ein mal ausgeführt,.

nc-code

F10000
#<radius> = 10
#<anzahlEcken> = 3
#<winkel> = [360 / [#<anzahlEcken>]]
#<verrundung> = 0.001
#<drehungUmC> = 60
#<wiederholungen> = 5

G10 L2 P1 R[#<drehungUmC>]
G64 P[#<verrundung>] Q0.0
#1 = 0
#2 = 0

o101 while [#2 LT [#<wiederholungen>]]
    o201 while [#1 LT [#<anzahlEcken> + 1]]
        g90 g1 x[COS[#1 * #<winkel>] * #<radius>] y[SIN[#1 * #<winkel>] * #<radius>]
        #1 = [#1 + 1]
    o201 endwhile
    #2 = [#2 + 1]
o101 endwhile
m2

ist es überhaupt möglich ?

Gruß
Rüdiger