Advanced Search

You MUST set the 7I97 PWMgens offset mode to true or runaways are guaranteed.

The current firmware puts the PWMgen on P1 pin 1

If you want the PWM  on a 7I85 RS-422 output, that would
require different firmware.

Those are two separate issues, first is always (granted wiring is OK) hal/settings issue, the second is a limit switch triggered or inverted issue.
For the first, some checks:
-disconnect one of the analog output wires from mesa, power on the machine and enable shortly = the motor should very slowly turn. Be aware that if wiring is not OK the machine might run away at full speed
-reconnect the wires
-use a DVM set in beep or resistance mode and check between analog ground on the drive and machine ground = there should not be low resistance, usually. machine should be powered off.
-use the DVM and measure the analog output voltage on Mesa or on the drive while LinuxCNC is disabled but the machine is powered on and LinuxCNC is running = there should be no voltage
-
-use the calibration screen to invert the output, or encoder, but NEVER both, test by enabling the machine
-if you still get joint errors, lover the P value to 10 or 5 or 2 and test.

If the inside radius of the step is too small, that produces a weak point in the shaft. Frequently, when a shaft has to be reduced, tapering or rounding the step in the shaft largely prevents that weak point.

Think of the sharp inside corner of the step as being the starting point of a fracture beginning to form. That is where it will break.

electrosteam wrote:

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

I can not confirm, but i read a lot of Creality CR-30 3D printers have a failed motor shaft from factory, not reduced but long, and i do have a CR-30 that is still OK. The belt on those is 10mm wide and tight like a drum, literally.
The reason might also be the reduction on a lathe can leave grooves that might initiate the break due to tension and vibrations, so it seem plausible.
Best way to avoid this would be, granted the shaft is long enough, to make a bearing holder at the end of the shaft.

cnbbom wrote:

Well, with a value of 46872, Linux CNC runs at maximum speed, but if I change it to 50000 I get an error message.

Try 100000 , and also since you say it works better with 46872 try 93744.
This will limit your max velocity in half, use the "Max velocity" slider on screen to limit the speed till you do not get joint errors.
Notice the motor sound, should be much smoother.

cnbbom wrote:

I'd also like to ask a question: on a normal machine that is acceptable for running Linux CNC, what are the minimum and maximum acceptable values ​​for BASE_PERIOD?

There is no such thing, it all depends on what your PC can do safely, and from that set the drive microstepping to achieve the desired machine velocity/speed, if possible, as with low microstepping motors vibrate a lot.
I have a PC that does not skip a beat at 15000 but it's power supply failed (workstation=expensive), most mine do 50000-100000, and i have some bad laptops that are in daily use for over 10 years with base period set at 300000.

tommylight and NWE

Well, with a value of 46872, Linux CNC runs at maximum speed, but if I change it to 50000 I get an error message.

I'd also like to ask a question: on a normal machine that is acceptable for running Linux CNC, what are the minimum and maximum acceptable values ​​for BASE_PERIOD?

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.