Denford Triac carousel toolchange component

Hi

The latest toolchanger collaboration between myself and cncbasher, has been to utilise his carousel tool changer on his Denford Triac Mill.

This is another British school / college machine made in the 1980's / 1990's
A comparatively small machine, but with similar features to those found on industrial machines,
including a BT tool holder 6 tool carousel, powered by air rams, a pneumatic draw bar and a stepper to index.

The tool changer component homes the carousel once the mill has been homed, to establish where tool 1 index is
and from that which tool is in the spindle.
Thereafter a M6Tn command prompts the removal of the current tool from the spindle, rotation of the carousel to the tool
requested and the insertion of that tool in the spindle.

The component uses a modified version of ioControl.cc to automatically update the toolnumber held by linuxcnc and displayed in Axis
This realistically makes the component most easily used within a RIP environment where the new iocontrol can be built in the source tree

Included in the zip are cncbashers config files to demonstrate the connections required in HAL.

The main tuning considerations, in common with many components interfacing with electro-mechanical / pneumatic tool changers,
are appropriate delays to allow relays to open, rams to move to their full extent etc.

The figures in the config files are for cncbashers own machine in conjunction with Mesa boards
If software stepping were used and a normal BOB, the delays may require to be longer.
These can be set using the 3 param pins, shortdelay, longdelay and extralongdelay

cncbasher has been using this for a few weeks and it seems to be very stable, so if of use enjoy

wiki.linuxcnc.org/cgi-bin/wiki.pl?Contri...oolchanger_component

regards

A picture is worth a thousand words- they say

This is what the machine looks like, albeit this is a sophisticated fanuc controlled version.

Andy ,

yes i'm aware of the changes your looking at , and of course following with interest , as no doubt this and the orac toolchanger will require a few head scratchings
but please , not to much pain .. i'm bald enough as it is ...

Dave

We are implementing (I think we finally ended it yesterday) a component to make a toolchange on the machine that we are retrofitting.
One of the things that we found hard to manage/understand is the lack of debug options - maybe because we are unaware of its existence. We made all with rtapi_print_msg(RTAPI_MSG_ERR, and it was quite a pain to understand why the algorithm passed so many time for same code and so on. Also the need to shutdown and power up linuxcnc in every component change, made us work like a robot at the end of the day.

Maybe the new idea that the developers are working on will be better.

Andy Pugh wrote:

You might be interested to know that my plan is to kill iocontrol.cc. Toolchange will be handled by a HAL component specific to the machine, that simply act on tool change request messages.
Initially (and briefly) probably Python/NML but NML is scheduled to be expunged too, replaced by something less horrible.

Yes I have been lurking on the developers lists, watching the ideas take shape.

It would be quite easy to remove ioControl, have a general purpose all in one toolchange component to pass the required signals for manual toolchange, as at present and have a pro-forma interface that variant toolchangers could be built on.

The one thing that will have to be catered for, is real time tool changers.

iocontrol is a userspace component, as is manual_toolchange, I don't know if you are envisaging the new component being userspace or not.

I wrote a userspace version of the Triac tool changer, just to see what the difference was.
The answer is horribly slow by comparison and a real danger of missing fleeting index signals to boot.

So there may still have to be an interface between toolchange signal and implementation of the toolchange, which would go back to the status quo, unless the component
could be written as either realtime or userspace, as required

regards

emcPT wrote:

One of the things that we found hard to manage/understand is the lack of debug options - maybe because we are unaware of its existence. We made all with rtapi_print_msg(RTAPI_MSG_ERR, and it was quite a pain to understand why the algorithm passed so many time for same code and so on. Also the need to shutdown and power up linuxcnc in every component change, made us work like a robot at the end of the day.

Yes it is a pain, I always run from a terminal and litter the code with rtapi_print_msg(RTAPI_MSG_ERR, xxxx) to keep track of where things are.

The other way is to create variables as pins during development so that the values are visible.

You can also construct a simple pyVCP panel and link pins to number widgets, to display values
I made up a complete testing panel for the Triac toolchanger, which not only displayed details of which progress_level you were in, what tool number was set etc. but allowed
the simulation of feedback from the various index switches etc to test a full tool change cycle without even having see the machine.

I wrote HalView because of how difficult it was to stop and start all the time, and then open up Hal Configuration, select the pins required etc to watch values
It sits in the background all the time and connects to the running instance via a redis database server to update pin values
www.linuxcnc.org/index.php/english/forum...ly-in-c?limitstart=0

Another tip
If you are writing a userspace component, be aware that sending error messages with printf("...") tends to result in messages being displayed when the component exits.
However if you use fprintf(stderr,"...") the message is displayed to the terminal immediately.

Happy coding

regards

ArcEye wrote:

emcPT wrote:

The other way is to create variables as pins during development so that the values are visible.


regards

If you make important variables output pins, they can be graphed by Halscope.
So, if your code is of the state machine flavor, such as :
if state == 12 { blah; blah; state = 13}
you can watch the input signals and the state variable and
get a good idea what is happening.

Jon