Advanced Search

Hallo spicer,

hab in der axis_mm.ini bei Achse_0 und Achse_1 auf 0 umgestellt. Bei Achse_2 war default eine 0 schon drinnen.
Ich kann obwohl die Fehlermeldung noch ersheint eine Referenzfahrt durchführen. Das einzige was mir nun aufgefallen ist, das wenn ich mein Programm ablaufen lasse und es irgendwo stoppe wird bei einer erneuten  Referenzfahrt dieser Startpunkt als Referenzfahrt genommen wird. Sollte eigentlich so wie in der axis.ngc in der unteren Ecke liegen. Wo finde ich eigendlich das Startprogramm axis.ngc?

MfG.

 

Dear Andy,
Thank you for your reply.

I would like to install central lubrication on the machine.
FUW400-5A-75E.gpio.25.in-not: this bit is connection oil pressure switch.
FUW400-5A-75E.gpio.26.in-not: this bit is connection oil level switch.

I would like to solve this:
If there is not enough oil level, then there should be no lubrication and write it on the screen.
If there is enough oil level, then lubrication can be set periodically, for a given time.
If lubrication has started, then watch whether the pressure switch switches during a given time. If it does not switch, then write it on the screen.

I don't have any relevant experience but... Does the current driver offer spindle orientation for tool changes, and do you need that?
If so, does the now motor support that (I would be surprised if it doesn't, it seems to be a servo drive)

Here's an example of what I found on the back of the Emco selector 'switch' knob.  There was a spring-loaded ball inside the metal knob that engaged the ring divots.

The slot in the ring engaged with the pot anti-rotation tab and the pot clamping nut kept it in place.  Knob with ball was just pressed on top - leading to a not-so-amusing self-disassembly when the knob was removed.

I like this idea so much I may actually do it on my SRO, FRO, and JRO pots, but I think it'd require a pot with a fairly long mounting thread (or a very thin mounting surface).

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