Manual tool change + tool lengh touch off
which hal file?
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.
unlinkp parport.0.pin-10-on-not unlinkp motion.probe-input
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.
CUSTOM.HAL (line 4 to 10)
unlinkp parport.0.pin-10-in-not unlinkp motion.probe-input loadrt debounce cfg=1 addf debounce.0 base-thread setp debounce.0.delay 10 net probe-raw parport.0.pin-10-in-not => debounce.0.0.in net debounce.0.0.out => motion.probe-input
(...) custom.hal:10: Signal name 'debounce:0.0.out must not be the same as pin. 8635 (...)
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:
here is my subprogramm:
o<first-tool> sub G90 G53 G0 Z0 G53 G0 X0 Y0 G91 G38.3 Z-180 F500 G38.5 Z10 F15 #1000=#5063 G90 G53 G0 Z100 G90 G53 G0 X50 Y50 o<first-tool> endsub M02
But even if I copy the fred.ngc example it doesn't work.
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)
unlinkp parport.0.pin-10-in-not unlinkp motion.probe-input loadrt debounce cfg=1 addf debounce.0 base-thread setp debounce.0.delay 10 net probe-raw parport.0.pin-10-in-not => debounce.0.0.in net motion.probe.input <= debounce.0.0.out
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.
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:
o<test> call m2
o<test> sub (debug, We got here) o<test> endsub m2
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.
move to start point of the cut...
o<touchoff> call [0.080] [0.02] [0.06] (Touchoff and start torch)
my touchoff.ngc file:
(#1 pierce height, #2 pierce delay, #3 cut height)
G38.2 Z-1.75 (Probe to find the surface)
G1 Z0.070 (Raise up to Z0)
G92 Z0 (Set Z0)
M66 P0 L1 Q5 (Wait for Arc OK from Torch)
G4 P#2 (Pause for pierce delay)
Z#3 (goto cut height)
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?