Advanced Search

Yes it can be difficult to sort everything out but you've made a good starting point of labeling what you want to happen from there it's just a matter of writing the code to match. M6 T5 G43 H5 is calling tools 5 and the z offset from the tool table for tool 5.

You could cancel that with a g49, but the issue you're having is you're trying to measure something from the previously loaded tool and if that's getting stored in the pool table that's probably not going to be good for you.

You may want to take the approach to just reset the z work offset at the tool change and measure the new tool from the known tool setter height and have an entry for the material height off of the table which would be your known working location. With this every time you made a tool touch off with a new tool you'd have something easily calculable.

Your first block of code could be written on a single line,
But I think that there might be a problem with your logic.

What does FUW400-5A-75E.gpio.26 actually indicate? It can't mean Low, OK _and_ warn.

Should these use GPIO 26, 27 and 28 maybe?

If not, and you are deriving different meanings from the GPIO with different logic, then you can only have one signal that represents the value of FUW400-5A-75E.gpio.26-not. It's a bit inconsistent insome ways, as you are allowed to to treat in-not and in as separate inputs, despite the fact that they are the same data.

You can not bother with not.0
(possibly, I don't know how your system is set up)

kcjengr.github.io/probe_basic/machine_config.html

Use this for a starting point, then come back with more narrowed down questions and errors, then we can assist better.

Make backups of your working config folder, that's already important even if you were staying with gmoccapy.

Perhaps that action button could be replaced with a mdi button and add in the mdi code for homing both y's?

I'm not familiar enough with dual drive axis too know how the homing would need to be called for that scenario though.

I actually gave up on the project for the time being. I want to run it on hardware that differs significantly from Tormach hardware. I have to learn to mess around in Python to get it to work.

Copy those folders from the sim per the docs

And another thing...

Something to keep in mind is that LCNC doesn't have the same 'modes' that the Fanuc controller you posted a pic of has.  Understanding how physical inputs work is important, of course, but before you tear your hair out it's be useful to understand what you need to control LCNC.

You don't need that selector switch at all to 'access' those modes.  Depending on the GUI you choose, those modes are available on-screen (either via mouse, keyboard, or touchscreen).  And if you want a physical button/knob, you can use one of those - either instead of or in addition to the on-screen control.

The only 'modes' you need to worry about are MANUAL, MDI, and AUTO.  If you are in manual - you can jog.  And you can jog continuous or incremental without switching to a different 'mode'.

Unlike the Fanuc, there is no separate 'EDIT' mode.  G-code files are edited just like any other computer file and then re-loaded; the GUI you choose likely has a built-in file editor page/window.

In addition, many GUIs have scripts/functions running in the background (via python or some other computer magic) that switch between modes automatically for your convenience.

Example: You are in manual mode.  You type something in the MDI entry window, and hit the 'enter' key.  LCNC switches to MDI in the background, executes the command, and switches back to manual mode when the command is done so you can get back to jogging around.

Not all GUI's behave the same, but most do.  And that' something else to make sure you understand:  GUI's are not LCNC.  LCNC is the control software, and the user interface is a separate bit of software that talks back and forth with LCNC.  This is very unfamiliar to those used to Windows machines where the 'software' and user interface all feel like the same thing (even if they aren't).

LCNC's arrangement makes is fairly easy to switch between interfaces, but it can cause confusion for newcomers when a GUI does one thing, and a different GUI does something slightly (or wildly) different.

Getting back to the original premise - what do you want LCNC to do? Are you trying to duplicate the Fanuc control behavior closely, or just the concept of having a FRO with discrete values rather than a variable scale?

If you want a single input to flip between modes, a HAL component called 'multi-switch' works great.  One input, and repeatedly pressing the button cycles through the three modes.  
linuxcnc.org/docs/devel/html/man/man9/multiswitch.9.html

OP – 
NOTE - Yes, learning LCNC can be a challenge – I’ve experienced numerous ‘throw in the towel’ events myself.  And while LCNC is fairly well documented, for beginners what’s missing – especially in the MAN pages – is context.  Throw in new terminology & jargon, and a forum search tool that’s sub-optimal, and you’ve got a situation ripe for frustration.

If you search for some of my earliest posts from a few years ago you’ll run across a few of my tantrums that may feel especially familiar.

It looks like you’re making progress with your original question, but I’ll comment here in case you’ve still got some things to work out.

If I understand your original question, you wanted to know if a multi-position selector switch can be used to return discrete analog voltages to the controller (LCNC).  And can those voltages be used to do something? i.e. mode select, FRO/SRO value, whatever?
I’ve seen two types of this implementation done on non-LCNC control systems:

Selector switch with resistors
Potentiometer with detents

I found the second version (pot with detents) on my Emco control  system.  I bought an Emco external control panel (for simulator use) and discovered that the mode and FRO selector switches were, in fact, simple potentiometers that had an external detent arrangement built in to the knob.  Same pot & knob for both the 6-position mode ‘switch’ and the 15(ish) position FRO ‘switch’.  Just different detent rings behind the knob.

In either hardware case, I think the HAL file magic lies in using a HAL component named wcomp.  If you’re not familiar with LCNC and HAL, ‘components’ are like little mini-programs that create virtual pins with behavior specific to that component.

linuxcnc.org/docs/devel/html/man/man9/wcomp.9.html

Wcomp allows you to set an input value range/window, and then compares the input to the window.  If the input value is within that window the wcomp output goes true (pin goes high).  There are also ‘under’ and ‘over’ outputs available.

I think a series of wcomp instances could be created in HAL – one for each ‘position’ of the switch (pot w/detents or selector switch).  4- position selector = 4 instances of wcomp.

Once the hardware is built, you can check using halshow (a utility in LCNC that shows raw IO values) and determine the voltage at each position. The appropriate wcomp instance is given a reasonable voltage range (to account for variances in supply voltage & pot noise), and the wcomp output is connected – again in HAL – to whatever you need to trigger.

In your case, a mux component for mode or FRO would use the various wcomp ouputs to select the desired outcome.

Of course, there likely many ways to accomplish an analog-to-digital selection scheme without using wcomp - but I can't think of them right this minute.

Coincidentally, a video covering this analog-to-digital input scheme has been put on youtube quite recently.



Hope that helps a little.

To simplify the gantry homing, I would be tempted to physically reverse one
axis (say by inverting one direction pin) and then the INI section for Y and Y2
would be identical.

Rodw,
I tried disabling support in the Sii params to indicate EoE was not even available, and unfortunately this did not alleviate my problem (I tried this before I figured out how to compile the master manually).

However, you bring up a good point - if all of the other drives appear to work fine and only the Kollmorgen one is not, then perhaps it is a poor implementation of EoE on the drive.

I did notice that when getting the IGH sources there are quite a few devies that seem to have direct support - whereas I am operating in "generic" mode. I do wonder if an official device support code/object was in there things would be different.

In your opinion/observations are most people using devices that appear to come with the IGH release, or are most people using the generic mode? 

I will submit a ticket to Kollmorgen to see if they will investigate that.
BTW is there a way to send direct messages to people? I wanted to reach out to ask you something on the side, but can't seem to find a way to send personal messages on the LinuxCNC forum.

Best Regards,
Paul

How do I increase the home search speed and backwards distance travelled after switch triggering? Currently it is very slow on all axis. Please help.
INI and HAL file attached.
Using LinuxCNC 2.9.3 Debian 12 Bookworm PREEMPT-RT ISO on a Mesa 7i96s.

Does Axis open that large file without any delay?

JT