Small victory in the war against the Cincinnati cinturn 12u

I'll log tomorrow, had to make a quick trip across state.

got your list, the only thing i want my turret to be capable of, is use 12 tools, 6id 6od.

Hello sean,

the lines with the T-loop were leftovers which I had not deleted!
In my post from 6.12 these are also no longer present.

I can not imagine that our changers are equivalent, as my changer is on a portal mill and is a complete self-build, just as my coding is somewhat idiosyncratic!

so, I couldn't find the channels in halscope pins or parameters, I am not sure what exactly is going on with that. I compared the vmc sim file versus my file and those parameters are there. I am not sure why, but here are the channels I could grab. I also grabbed a shot of the tool change requests invovled. to me is almost appears as if the car-req-pos-32 is being pipped directly to the car-pos-32

Also one big difference between the 2 in regards to hal configs. I suspect might be at the core of the issue. 

#net tool-prep-loop iocontrol.0.tool-prepare iocontrol.0.tool-prepared  <

---

this line is not commented out in the toolchanger hal file. 
net tool-change-loop iocontrol.0.tool-change iocontrol.0.tool-changed


This line isn't in that configuration at all. and this is in my primary hal file. Per several members here, this look incorrect. 

net T-loop iocontrol.0.tool-prepare => iocontrol.0.tool-prepared

to my eyes that looks like a parameter short circuit, which is exactly the phenomena I am observing. 

 drive.google.com/file/d/1kMbiah0Iw-cmirm.../view?usp=share_link

drive.google.com/file/d/1kMAiR6JeCmf7991.../view?usp=share_link

drive.google.com/file/d/1kGXFQbtzOvW-TyJ...iew?usp=share_link// 


I searched through the source at github and there is no declaration of a T-loop that I could find, and I looked in the hal  carousel component as well and I don't see it there either. the 

github.com/LinuxCNC/linuxcnc/blob/master.../iotask/ioControl.cc

I checked here as well 

github.com/LinuxCNC/linuxcnc/blob/master...task/ioControl_v2.cc

thoughts ?






 

There is no t-loop anywhere other than my primary hal file. I believe this is in error. I have since removed it. I went back to the original configuration line. my current working hal and ini files are going to be attached below. 

Looking at the VMC sim hal file. I see a bunch of IO that doesn't really make a lot of sense, but it appears that many of the pins in question I am missing may be here. So I am trying to discern what I need to remove, and then add to my hal file to get rid of the open signal situation. I originally dismissed most of this because the hal file itself states that it is essential a giant hack to fool the motion control into behaving. I think  all of the missing signals here I am just not entirely sure what needs moving into my hal file and what in particular needs to move into my hal file. I am also not entirely sure what is for the sim and what isn't. 

github.com/LinuxCNC/linuxcnc/blob/master...olchange/sim_vmc.hal

# This is quite a complex HAL file, and it is very unlikely any of it will be relevant to a real machine.

#simulated carousel with 5 Gray-coded outputs
setp carlim.maxv 0.01
net car-vel carlim.in
net car-vel-lim carlim.out carpos.in0

I m not using a servo or stepper, so I do not believe I need the velocity calculations from here to run the solenoid. 

net car-pos carpos.out carpos.in1 vmcgui.carousel

this appears to create a link to the TK animation but it also appears to create the pin car-pos. which is missing from my configuration. I also don;t see where carpos is created at all. 



loadrt conv_float_u32
addf conv-float-u32.0 servo-thread
net car-pos conv-float-u32.0.in  <--- my line  net car-pos-s32  conv-float-s32.0.out  carousel.0.pocket-number

those pins are all present on my system in my hal file if I understand it correctly and are not needed, these are specifically to simulate a real machine

loadrt bin2gray
addf bin2gray.0 servo-thread

this seems uneeded, looks to refer to a number conversion I shouldn't need as I have a binary configuration. 

net sim-pocket-u conv-float-u32.0.out bin2gray.0.in
loadrt bitslice personality=5
addf bitslice.0 servo-thread
net graycode bin2gray.0.out bitslice.0.in

net bit0 bitslice.0.out-00
net bit1 bitslice.0.out-01
net bit2 bitslice.0.out-02
net bit3 bitslice.0.out-03
net bit4 bitslice.0.out-04

all of this appears to be for the sim, but I could be wrong, are these connection required for the BCD and binary encodings. 

# pulse and index output variant (untidy modmaths)
loadrt conv_s32_float count=2
loadrt conv_float_s32 count=3
loadrt near count=3
loadrt scale
addf conv-s32-float.0 servo-thread
addf conv-float-s32.0 servo-thread
addf conv-s32-float.1 servo-thread
addf conv-float-s32.1 servo-thread
addf scale.0 servo-thread
addf near.1 servo-thread
addf near.2 servo-thread
net car-pos conv-float-s32.0.in
net car-pos-int conv-float-s32.0.out conv-s32-float.0.in
net car-pos-float conv-s32-float.0.out near.1.in2
net car-pos near.1.in1
net pulse near.1.out
setp near.1.difference 0.01
setp scale.0.gain 0.1
setp scale.0.offset -1 # to show-off index homing
net car-pos scale.0.in
net car-pos-div10 scale.0.out conv-float-s32.1.in
net car-pos-div10-int conv-float-s32.1.out conv-s32-float.1.in
net car-pos-div10-float conv-s32-float.1.out near.2.in2
net car-pos-div10 near.2.in1
net index near.2.out

Setp near.2.difference 0.009

everything here is where I get a bit lost, this is calling a lot of different items to setup  for modmath for allowing more than say 6 tools in a 12 pocket tool changer and from my limited reading on the subject. I will need to implement this at some point soon. 

So my confusion is stemming from the naming scheme here in the man page, verses what the comments here on the forums indicate as well as the variability in the sample configurations.  Are all of the pins custom named and I just ignore the man page ? I am happy to just use the existing name structures, as it make debugging simpler and allows for following the man pages and following code comments to debug. 


linuxcnc.org/docs/html/man/man9/carousel.9.htmlcarousel.N.pocket-number s32 inThe pocket to move to when the .enable pin goes high. If the value passed is higher than the number of pockets specified in the "pockets" modparam then modulo arithmetic is used. This is intended to allow the use of multiple tools in the same holder, as is sometimes useful with lathes.carousel.N.enable bit inSet this pin high to start movement. Setting it low will stop movementcarousel.N.active bit outindicates that the component is activecarousel.N.ready bit outThis pin goes high when the carousel is in-positioncarousel.N.strobe bit in (default: 1)Use this pin to indicate that the position feedback is valid. Often provided by binary encoderscarousel.N.parity bit inSome encoders supply a parity bit, if this is connected then the parity-error output bit will indicate parity errorscarousel.N.sense-M bit in (M=0..personality)Carousel position feedback pins. In ’index’ mode there will be only 2 pins. sense-0 is the index and sense-1 is the pocket sensor.carousel.N.rev-pulse float inThe duration in seconds for which a ratchet changer (Boxford, Emco) should pulse the reverse pin to lock the holdercarousel.N.fwd-dc float inVelocity or duty cycle when forwards rotation is desiredcarousel.N.rev-dc float inVelocity or duty cycle when reverse rotation is desiredcarousel.N.hold-dc float inDuty cycle when carousel is in-position (to hold against stop)carousel.N.jog-fwd bit inJog the carousel forwards one tool positioncarousel.N.jog-rev bit inJog the carousel in reverse (only if dir = 2). It is very important that these pins should be debounced and should probably also be interlocked to only operate when the machine is idle.carousel.N.motor-fwd bit outIndicates the motor should run forwards (bigger numbers)carousel.N.motor-rev bit outIndicates the motor should run reverse.carousel.N.parity-error bit outIndicates a parity errorcarousel.N.current-position s32 outThis pin indicates the current position feedbackcarousel.N.motor-vel float outThe duty-cycle or velocity to drive a DC motor or stepgen
 

after banging my head on the wall, I decided to look over the Orac hal turret component.I made a derived component. The programming seemed fairly straight forward, it removes the needfor python remaps, gcode and simplify's the entire tool changer logic into something I feel I can debug. I am going to compile and start the debug process tomorrow, but if anyone see's any massive glaring errors, lmk.  I am aware that BCD switch 4  in the C file is not properly defined, I am adding it to the lathe this week. dusted off my books on C and hit the hal components docs all day.