Manual tool change + tool lengh touch off

axel88 wrote:

which hal file?
/usr/share/emc/tcl/bin/halconfig.tcl?

EDIT: /home/axel/emc2/configs/Portalfrase/Portalfrase.hal looks good, right?

Yes, I came into the forum at a run to make sure you weren't about to do something silly.

(I had to delete your umlauts as the forum refuses to show any message with odd characters at all, including three full stops in a row, and the UK currency symbol)

You can either edit that file, or if it was created by stepconf you can put your new stuff in the custom.hal file where stepconf won't over-write it.

The drawback with putting it in the custom.hal file is that you might need to unlink some connections to insert your new stuff. Would do that.

HAL is one of the most powerful features of EMC2, it allows you to connect any inputs and any outputs together in a completely free way, optionally processing the signals on the way.

1.) By moving the debounce procedure to the custom.hal I've got some errors:

CUSTOM.HAL (line 4 to 10) ERROR:

2.) I've got problems with the subprograms:

I wrote to files: first-tool.ngc and auto-tool-change.ngc and located them in ../emc/nc-files which is defined as the PROGRAM_PREFIX folder in the Portalfrase.ini .

when I run: or the error "File not open" appears.

here is my subprogramm:
But even if I copy the fred.ngc example it doesn't work.

axel88 wrote:

custom.hal:10: Signal name 'debounce:0.0.out must not be the same as pin.

Sorry, I didn't put the signal name in the net statement, so the interpreter is trying to use the first pin name as a signal name

You need something like

net FreelyChosenSignalName debounce.0.0.out => motion.probe-input

The signal names are conceptually equivalent to the colours of the wires in a physical system, you can choose any you want, but it helps understand the system if they match the function. (Also you can't have more than one signal with the same signal name)

The problem might be the hyphen in the name. (Just a guess). Try it without that. The way that filenames get passed through the G-Code interpreter is a bit messy, they get changed to all lower-case and spaces get removed, the same might be true for "operators".

I thought I tried this at first, but so it worked.

The hyphen is not the reason, I've already tried it without and the fred.ngc has none either.

It seems to work if i call o<first-tool> call in a *.ngc file, but I can't run it from the MDI console. But this should be enough for the postprocessor.

Which EMC2 version are you running?

I vaguely recall an improvement in the way it searched for subroutines, but that was rather a long time ago.

I just did a test:

In the ini file I have PROGRAM_PREFIX = /home/andypugh/emc/nc_files

In the nc_files directory I have:
test1.ngc
test.ngc

test1.ngc contains: test.ngc contains: And it all "just works" with version 2.3.5

Incidentally, the dev list was busy last night sorting out an issue with probing in subroutines. I think it is only a problem when the subroutine is called from MDI_COMMAND, but I have asked for clarification. The issue is one of returning before the end of the probe, I think, so not related to your general subroutine problem.

You could use something similar to my touchoff file that I use on my plasma torch.

move to start point of the cut...
o<touchoff> call [0.080] [0.02] [0.06] (Touchoff and start torch)
...


my touchoff.ngc file:

o<touchoff> sub
(#1 pierce height, #2 pierce delay, #3 cut height)
F10
G38.2 Z-1.75 (Probe to find the surface)
G91
G1 Z0.070 (Raise up to Z0)
G90
G92 Z0 (Set Z0)
G1 Z#1
M3 S1
M66 P0 L1 Q5 (Wait for Arc OK from Torch)
G4 P#2 (Pause for pierce delay)
F25
Z#3 (goto cut height)
o<touchoff> endsub
M2

John

axel88 wrote:

It seems to work if i call o<first-tool> call in a *.ngc file, but I can't run it from the MDI console. But this should be enough for the postprocessor.

Ah, yes. I didn't realise that you were calling it from MDI. I just tried it in version 2.4.3 and it worked fine. Perhaps you are using 2.3?