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.