Another "what do I need" thread. Vmc retrofit

Something else to play with.
This component just runs through a sequence of setting and re-setting HAL pins. You can have up to 31 steps setting/resetting up to 32 HAL pins.
Each step can wait for up to 32 more HAL pins to be set or reset (in any pattern).to read the manpage.to install it.to start a HAL session and see it in action in a standalone HAL session.

Testing and comments very welcome.

Here is the new, improved, simplified carousel component.

Again, a comp and then a demo hal file and halshow setup:

thewho wrote:

I have also locked through your component Andy and it's all a mystery to me.

The carousel component is moderately simple, though even I don't quite understand the Gray-code conversion bit. The sequencer is a bit less simple.

You don't have to use the sequencer, the carousel component can be run from a G-code subroutine as shown earlier. Or from Classic Ladder.

At it's simplest you can connect iocontrol.0.tool-prep-pocket to carousel.0.pocket-number, iocontrol.0.tool-change to carousel.0.enable and carousel.0.ready to iocontrol.0.tool-changed and you will get something like a tool change sequence.
(With no arm movement or Z axis movement).
That is basically putting the carousel component in the same "gap" in HAL where hal_manualtoolchange normally lives.

What I _don't_ know how to do is put the empty pocket where it needs to be if it isn't already there.

The problem is that what _looks_ like the thing that you want, the #<_current_pocket> G-code parameter doesn't give you the P-number of the tool-in-spindle from the tool-table. It gives you the line it appears on in the tool.tbl file.
There is a workaround to this, but it's slightly painful: The tools must appear in pocket-order in the _text_ version of the tool table. (not necessarily as it appears in the tool-editor). As long as the pocket column of the tool editor is always 1,2,3 etc in the tool editor this should stay consistent (I think).

Given that (significant) "gotcha" you can use a G-code subroutine like this:

O<toolchenge> SUB
M68 E0 Q#<_current_pocket>
M64 P0 ; trigger carousel movement
M66 P0 L1 Q10 ; wait for carousel to stop
M65 P0
O100 IF[ #5399 LT 0] ;timeout
O<toolchange> RETURN
O100 ENDIF
G53 Z -100 ; position spindle to drop tool.
M64 P1 ; move arm
M66 P1 L1 Q 2; wait for arm-out switch
O101 IF[ #5399 LT 0] ;timeout
O<toolchange> RETURN
O101 ENDIF
M64 P2 ; release drawbar
G4 P1 ; wait
G53 Z 0 ; Z to top
M65 P1 ; retract arm
M66 P2 L1 Q2; wait for arm retract switch
O102 IF[ #5399 LT 0] ;timeout
O<toolchange> RETURN
O102 ENDIF
T [#1]
G53 Z 0
M68 E0 Q#<_selected_pocket>
M62 P0 ; trigger carousel movement
M66 P0 L1 Q10 ; wait for carousel to stop
O103 IF[ #5399 LT 0] ;timeout
O<toolchange> RETURN
O103 ENDIF
M65 P0
M64 P1 ; move arm
M66 P1 L1 Q2; wait for arm-out switch
O104 IF[ #5399 LT 0] ;timeout
O<toolchange> RETURN
O104 ENDIF
G53 Z -100 ; pick up tool
M65 P0
M65 P1 ; retract arm
...
O<toolchange> ENDSUB

I actually suspect that in this case it might make more sense to control the changer from G-code than using my new sequencer component. Though if you wanted to you could trigger that with the first M62 P0 (which sets the HAL pin motion.digital-out-00 to 1 ) could start a sequence / timeout that replaces the blue code. (You would then need to read the value of the sequence.0.error pin to be sure it was safe to proceed at various points)

Actually, you could connect sequencer.0.error to halui.program.stop and then any problems in the tool-change sequence ought to stop the program dead.

So using "sequencer' the toolchange sub looks more like:

O<toolchenge> SUB
M68 E0 Q#<_current_pocket>
M64 P0 ; trigger tool sequence
M66 P0 L1 ; wait to be told to move the Z axis
G53 Z-100
M66 P0 L1 ; wait to be told to move the Z axis
G53 Z0
M66 P0 L1 ; wait to be told to move the Z axis
G53 Z-100
M66 P0 L1 ; wait to be told to move the Z axis
G53 Z-100
M6 T[#1] G43
O<toolchange> ENDSUB

This is a simpler G-code sub, but then the complexity largely moves to sequencer.

I haven't mentioned the HAL pin connections for either option yet, which is probably outputs for arm and drawbar and inputs for (at least) both extents of arm travel and drawbar being released.
loadrt sequencer sequence="r1s0t0w10:s1s2t1w2:s3d200m:t2w5:r2s3s4w2:s2....." which means something like:
r1s0t0w10 : reset out-1 (locking pin), set out-0 (carousel enable) wait 10 seconds for in-0 == true (carousel finished)
s1s2t1w2: set out-1 (locking pin), set out-2 (arm extend) wait 2 seconds for arm-extended switch
s2d200m: tell g-code to move to position 1 then wait 200mS
r2t2w5: un-set the motion request pin, wait 5 seconds for in-2 (netted to motion.in-posiiton)

(and so on for the actual sequence)

I forgot to say that (doing it this way) a tool-change is caused by O<toolchange> CALL toolnumber rather than M6 Ttoolnumber.
It is relatively easy to re-map M6 to call the G-code sub, but one step at a time.

thewho wrote:

Is spindle positioning included in your hal component? Or is there another way to do that?

Spindle positioning is separate. Have a look here:

wiki.linuxcnc.org/cgi-bin/wiki.pl?SpindleOrient

(it could be triggered by another pin from the sequencer)

thewho wrote:

You guys will probably laugh at me now but I was investigating the "M3 S10 = 10V output" and found out that S1 =1V, s2 =2V etc. And it seems like I need to scale the output.

it's here in your INI file:

#********************
# Spindle
#********************
[SPINDLE_9]
ENCODER_SCALE = 4096.0
OUTPUT_SCALE = 10.0
OUTPUT_MIN_LIMIT = -10.0
OUTPUT_MAX_LIMIT = 10.0


Set OUTPUT_SCALE to the spindle speed you get for 10V output.
At the moment you are saying that 10rpm is the max speed. (ie, 10rpm = 10V, which is exactly what is happening)