Advanced Search

Hi all,

Thanks for all your input—everything is working fine again! There’s still some tweaking to do, but I’m getting there.

For the inputs, I made a small PCB breakout with terminal blocks, each protected by a pair of 0.5W resistors (2x 3K in parallel, so 1.5K total) to protect the Mesa card inputs. This limits the input current to a maximum of 0.016A (16mA) and 0.384W per pair.

I do have one last question. When testing my axis with the PNCconf wizard, I was able to achieve insane speeds—acceleration around 2500 and a max velocity of 15,000 (even higher values just made it wait or go slower). This seemed very promising. However, those values didn’t end up in the generated .ini file.

In reality, I had to limit my velocity to 200 to avoid errors in LinuxCNC, specifically:

hm2_7i76e: 0.stepgen.00.maxvel is too big for current step timings & position-scale, clipping max possible.
hm2_7i76e: 0.stepgen.01.maxvel is too big for current step timings & position-scale, clipping max possible.
hm2_7i76e: 0.stepgen.02.maxvel is too big for current step timings & position-scale, clipping max possible.

By lowering the timing values like this:

DIRSETUP = 6000
DIRHOLD = 6000
STEPLEN = 3000
STEPSPACE = 3000

(from the original 10,000 / 10,000 / 5,000 / 5,000), I could push the velocity up to 250, but then I started getting joint following errors.

So, I think I must be missing something fundamental, because the speeds I got in the wizard are nowhere near what I see in actual LinuxCNC. I don’t need crazy speeds for milling, but jogging 20cm takes a bit too long right now. Is there a way to make it faster, or can someone explain why the wizard speeds were so much higher than what’s actually possible in LinuxCNC?

Thanks!

Many of us use a USB to RS485 converter plus the mb2hal or vfdmod hal module.

Installation step failed
An installation step failed.  You can try to run the failing item again from the menu, or skip it and choose something else.  The failing step is: install the system.

Anyone else see this and found a solution?

Yeah this thread is really the only reference. The first post maybe needs a consolidation of "this is what we do".

I'm curious about tuning these things now that we know they "work". Would like to know how arduous or easy that turns out to be.

S curves. I neeeds it.

So how stable is this at this point for "real work"? I have not been paying attention the last 2-3 months much.

Thanks. I need to do my IO and some fine tuning (servo tuning) and then I see about making a nice organised how to including files and what each line is for.



I need to figure out modbus spindle now. I hope that is easier to follow (I haven't looked at it at all yet)

I finally managed to implement this and it seems to work very well.

What it does:
- Detects the first G5x coordinate system (G54–G59.3) used in a G-code file
- Prints a debug log to the terminal: [DEBUG] G57 on line 4
- Sends the detected G5x via MDI so that the GUI updates to reflect the active work coordinate system

How I implemented it:
I added the following method to the StatCanon class in:
/usr/lib/python3/dist-packages/qt5_graphics.py



Notes:
- Make sure this method is placed inside the StatCanon class with consistent 4-space indentation.
- The initial G54 on line 0 and final G54 at the end (due to GUI reset) are ignored using: self.lineno > 0
- Only the first explicitly used G5x is applied via MDI.
- Verified to work reliably in QtDragon simulator config.

This improves usability by ensuring the GUI’s coordinate system matches what the G-code will actually use.

Tested with:
- LinuxCNC 2.9.4
- QtDragon (QtVCP)
- sim.qtdragon.qtdragon_tool_probe configuration

Let me know if this is helpful or if there’s a cleaner way to hook into the coordinate system logic.

Great info thanks. I will most likely go with the 48v supply I bought , although I will then have to add another step down supply as the board max is 24v so I will need a 48v to 24v and then 24v to 5v I already have. Worthwhile though going by the graph. I don't expect to drive at high speeds either.

Ich habe den Fehler gefunden: es war der doppelte Eintrag "net machine is on.." in der Handrad.hal. und in der Maschinen.hal. Wenn dieser Eintrag in der Maschinen.hal auskommentiert wird, dann funktioniert das Handrad korrekt.

Looks like the ring is past its due date.

(whatever that means)

In general, It's better to post text than a screenshot/picture of screen.

I had trouble installing Verser's v2.9 probing screen for the Axis GUI.  Eventually I decided to try EasyProbe.  Easy enough, except that the pocket probing function has a constant that only works for metric.  But if you change ff_distance from 5 mm to 0.2, it appears that everything works.

EasyProbe allows you to calibrate the probe tip, which avoids the complication of using an indicator to get the probe tip colinear with the axis of the spindle.  The drawback is you must measure with the probe oriented as it was during calibration.  Here's my calibration setup

 

The ring gage is 1.0060 inches
 

After calibration, the I probed the pocket a few times.  The measured diameters varied from the standard by

1. 0.000,014 inches
2. 0.000,006 
3. 0.000,114
4. 0.000,097

I would only believe this to a tenth (+/- 0.000,1 in).  But it's not bad for a probe tip that is off axis by almost 2 thou.

While working with EasyProbe, I encountered manual tool changing for the first time, with rapids set to 200 IPM.  I had also set TOOL_CHANGE_QUILL_UP, which almost smashed the probe into the table.  I had set up the axes using the right hand rule, with +Y moving away from the operator.  This requires that +Z is up.  I turned off the quill-up setting but had several close calls because M6 rapids the spindle to the tool change location, not caring about the Z position.  So I've got to reverse the Y axis so I can take advantage of the quill-up setting.  

Hi, I am just on the way to start my ethercat adventure.
I received my ethercat servos and some beckhoff ethercat interfaces as well.
Now i recognize that I still need something to control my Optidrive E3 VFD over modbus.
Can I use the El6001 Serial Interface or wich Interface do I need?

I would really appreciate any help or hint

best Kai

Hi,

i think you need to update local git clone first. It needs latest updates.

Then build_cmake.

It is capable to switch between the two modes but it is not a 'normal' setup.

Because there are different setups there isn't a 'one size fits all' solution to do this.
In your case I would wire the DC drive as the spindle and the servo as a rotary axis (eg 'C').
Solutions will largely depend on what kind of encoder signal(s) you have and whether those track spindle position at all times or only in either turning or milling modes.
If you have encoder and index feedback from the same source and the encoder position isn't lost when operating the the spindle at max speed then you can home the rotary on startup and don't need to rehome when switching from turning to milling. There is 'caxis.comp' to prevent the spindle unwinding the accumulated rotations for this case. The original version of this can be found in the zip folder in this thread:
forum.linuxcnc.org/10-advanced-configura...ling?start=50#288345

If you do need to rehome the rotary due to lost encoder position then make sure to take note of the bug described in this thread and the workaround presented:
forum.linuxcnc.org/38-general-linuxcnc-q...blem?start=20#324276