Advanced Search

Which editor are you using?

Looking about on the internet it seems that maybe geany does odd thing in some locales. What's your locale setting?

(eg: unix.stackexchange.com/questions/340469/...ic-encoding-in-geany )

JT wrote:

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

 

Thats more than a bit wierd. 

Any clues from starting LinuxCNC at the command line? It sounds like it is giving up before parsing the MDI_COMMAND lines. 

Hello,I am trying unsuccessfully to create a parametric file for measuring the length and diameter of my tools.I am encountering significant issues with the encoding (UTF-8) of the subs. Either it cannot find the sub, or invisible characters are embedded in my files and LNC refuses to read them. Is there a solution, an editor capable of writing a clean file? Thank you.

Yes, you should change it. Lots of CAM software assumes that Z=0 is top of travel too. If the "safe move" instead rams the cutter into the table, that would be annoying.

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