Advanced Search

So many great comments!

unknown wrote:

I'm a little unconvinced how changing to USB would have an affect on the "wiring nightmare or EMI issues".

 

I'm Italian. Italians are all dramatic and exaggerated in their statements.
But to get serious: I imagined installing the system near the operator panel, so that all the controls are wired nearby; thus, keeping the wiring and connections clean and organized. Only the USB cable runs from the panel to the PC.

NWE writes
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.

Over the past few months, I've had a lot of free time, and at first it was just a test to see if it worked... and gradually, things took shape, and I saw that there was a viable solution. I started with bit-banging from the Mesa board to control the shift registers... but I wasn't satisfied with the solution.

To reply to rodw:
1. The project started as a personal challenge, and the ones you see in the videos are the boards with "sins of youth" that I had built after the breadboard phase. I'm planning on making some basic kits with the correct versions. For now, I have some old boards.
2. It would be a dream.  But I'd like the project to be further tested by others as well.
3 See point 2. Then I'll get organized, and if it's accepted, they'll include it in some update of the new version.
4 If you compare me to Mesa, you'll make me blush... I'm a hobbyist, they're professionals. 

ciao
Roberto
 

I'm working on a gantry style one currently....though might build a carousel so it's quicker/doesn't eat space.

Rough process is you remap the m6 code, example here github.com/LinuxCNC/linuxcnc/tree/master...emap/rack-toolchange

forum.linuxcnc.org/37-international-linu...version-cnc-software

This can be taken a look at

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.