Advanced Search

is there any indication that the postamble is being sent?

Does it help if I say that I am as puzzled as you? Those config files look like they should do homing.

Is there any chance you are not running the config you think you are?

It might be worth halscoping the home switch signals, perhaps there is noise on those that looks like valid home switch-on home-switch-off ? (very unlikely, though)

johns00056 wrote:

Thanks for the help. The script to automatically re configure configuration files did not work..

Is there any chance you can zip-up the config folder and attach it here, I will try to work out what went wrong (and hopefully fix the script)

The Melfa seems to be all in-line so that makes the kinematics somewhat simpler.

I think this should be do-able, it sounds like this is a grinding-hob style of machine? I have been cutting gears with LinuxCNC for more than 10 years (since the idea of electronically synching spindles first ocurred to me) (I invented the idea of electronic gear hobbing, but I probably didn't invent it _first_

You could certainly simulate most aspects of such a machine using Vismach, but simulating the actual stock removal falls outside of the capability of Vismach.

Do you have an "articulated" 3D model of the machine?

Rather than set-pos buttons, and calculate button, I would bind recalculaiton to the on-change event of the entry boxes.

Yes, that can be done. I would use GladeVCP because that allows you to automatically run Python code when a control value changes.

My gear hobbing screen has a similar thing, where entering the tooth counts and tooth pitch calculates a number of gear parameters.

There is a zip file here, though I don't know how much help it would be.
wiki.linuxcnc.org/cgi-bin/wiki.pl?Hobbing

You basically need 6 entry boxes, and two/three display boxes.
I would be tempted to add a button to automatically G0 to the centre, once found, and maybe another to set the origin.
(The latter two options would involve interacting with LinuxCNC using the Python Interface (probably using Pythin to create G-code command strings)

Might be a limitation in advanced planning of non-XYZ moves? My understanding is that for non-XYZ coordinated moves, there's no lookahead, so presumably it has to come to a complete stop after each segment.

forum.linuxcnc.org/32-documents/53351-pl...nding-vectors#306151

I'm sure I saw this in the official docs somewhere, but I can't find it at the moment.

ETA: Missed that you already saw that... Assuming it works as expected with single-axis moves, it sure seems like the above is what you're running into.

Yup, that is it.
Not much useful info there, though.

5i25_7i77_5abobd.bit should be correct

Changing A to X and the mdi commands show up, changing back to an angular axis and the mdi commands don't show up.

JT

There is something weird going on, I'm trying to duplicate the issue and some configurations mdi works and some do not.

JT

I thought I was on the right track. I played with the PID coefficients all weekend, but nothing conclusive.
With an M19 R10, the spindle jams and eventually stops, but "orient.is-oriented" never goes to 1.
If I repeat an M19 R5, for example, nothing happens. If I repeat an M19 R30, the spindle ends up running at maximum speed.
In any case, it's rarely reproducible twice in a row.

My Hardinge CHNC is still running Ubuntu 10 with EMC 2.7 with no issues at all. I doubt that Debian 12 would even install on that pc but if it ain't broke don't fix it is my motto.

JT

Hi,

I did try your suggestion, but the result was the same However, after trying to understand the subroutine line-by-line i found something:
https:/github.com/kcjengr/probe_basic/blob/04900f1f6bec0c6ec3e3130adb82514e7f007b8b/configs/probe_basic/subroutines/tool_touch_off.ngc#L49
Doesn't this assume that my "probe home" is at Z0? on my machine "probe home" is at Z450... i tried changing it to Z450 and it seemed to solve the problem...

So, i think the REAL issue is that my Z-axis works "up-side down" compared to other machines(Z0 at table, Z450 at top). I didn't think that would matter, but seeing that Z0 is hardcoded here, i think this will cause other problems for me in the future, so i think i'll change it...