Better nozzle with auto change?

[mrandt]

Thanks Louis, that looks great!

I think you found a winner in terms of Nozzle holder + auto change

I have tried a bunch of Juki nozzle holder solutions but was never satisfied with the quality. The ball-bearing lock has just too many variables all resulting in runout and problems with tool change.

The holders and nozzles are also rather on the expensive side; obviously because of the fragile mechanisms.. I have ordered some circular magnets to might try and make a magnetic mount for the nozzles, because I still like them.

Meanwhile, I will shop for a Samsung CP40 nozzle holder and nozzles - M5 thread makes it easy to try and the tool holder looks really promising

We could even keep the current Z-probing mechanism; just set a larger backoff to account for the extra spring in the holder... With the Jukis, I was afraid to break the delicate springy tip - the Samsungs + holder look more robust to me.

Cheers
Malte

[JuKu]

I have these on order as well.

[Pixopax]

The spring in the holder is quite strong, the Liteplacer-Z-Probe will trigger before the spring in the holder is compressed.
I disabled the probe, otherwise I cannot change nozzles.
I just look that my z heights on the tapes are set right, then this is no problem.

Also, the rmod-release needs a few changes to have the Z-Axis drive completely up before changing nozzles. In the current build it drives only up to the safe z set in the software, that could be too low for the changer.
If you do not use safe z then you will not have an issue.

What is bad on my changer is the fact, that an unload operation without a nozzle on the holder will lead to a crash.
The holder will then slip under the upper plate of the changer device.
So you have to look that always a nozzle is loaded before you unload one.
I had that yesterday I forgot to put the nozzle back on, was my error

[JuKu]

> The spring in the holder is quite strong, the Liteplacer-Z-Probe will trigger before the spring in the holder is compressed.

One of the reasons the change operation should be built in to the software.

> an unload operation without a nozzle on the holder will lead to a crash.

This is a problem, as running into a holder that already has a nozzle will likely smash a few things out of calibration. there should be a way to figure out which nozzle (if any) is currently on the machine. Maybe put some marks on the holder and nozzles and have the machine identify empty and full holder positions, as well as the nozzle currently on the head. The former might be enough: if there is one and only one empty holder position, it is a relatively safe guess that the missing nozzle is in the machine.

[mrandt]

This is a problem, as running into a holder that already has a nozzle will likely smash a few things out of calibration. there should be a way to figure out which nozzle (if any) is currently on the machine. Maybe put some marks on the holder and nozzles and have the machine identify empty and full holder positions, as well as the nozzle currently on the head. The former might be enough: if there is one and only one empty holder position, it is a relatively safe guess that the missing nozzle is in the machine.

"Guessing" which nozzle is on the holder is not really necessary; is it?

I would simply unload all nozzles before park operation; so default would be no tool on holder during startup.

We could even use upcam and simple pattern matching to check if there is a nozzle on the holder during startup procedure and throw an exception if there is, while LitePlacer software believes there is none... Could only happen after a crash / premature stopping of software.

Before returning / unloading a nozzle to the tool changer, we could use downfacing cam to check the intended slot is empty - but again, a precaution aggainst messed up setup / settings.

[Pixopax]

I would simply unload all nozzles before park operation; so default would be no tool on holder during startup.

That would be nice, but only works if you do not have software crashes..Then you end up with a loaded nozzle. Since I have crashes quite often, that is not safe enough.
To be totally safe the upcam should detect if a nozzle is loaded, and the the downcam could detect which nozzle. But that is surely far off where we are now

[WayOutWest]

http://www.aliexpress.com/snapshot/7390849509.html
and
http://www.aliexpress.com/snapshot/7390849507.html

Does this nozzle style have any kind of z-max sensor?

The one on the Juki nozzles is a real pain, so I'm interested in switching to a different style if it has that and might work better.

[WayOutWest]

Of course it would.

I thought so too, but not in the bonkers TinyG universe.

Changing the limit switch configuration requires writing the EEPROM, and the TinyG refuses to do that once the machine has started moving (you'll get this weird "FILE OPEN" error that makes no sense). This is because AVR/xmega require you to disable interrupts in order to write the eeprom, and if you did that with the motors running, well, disaster.

TinyG does not provide a way to adjust the switch settings without writing the modifications to EEPROM, which would be the obvious way to achieve this.

You might be able to issue an "end job" command, update the switch settings, and then proceed. But writing the eeprom is not guaranteed to work after 80,000 writes. That's a lot, but maybe not enough that you can afford to write the eeprom on every nozzle change.

A hack/workaround might be to use G38.2 moves instead of G0 moves, but there are a lot of bugs in the TinyG G38.2 implementation... be careful.

[JuKu]

You can change the switch setting in the job, just make sure the machine is not moving.

Ten reconfiguration per job gives you 8000 guaranteed jobs. About 200 work days a year, four jobs a day is ten years heavy production use. I don't think TinyG eeprom is the weakest part of the machine.

[martin123]

What about an analog spdt switch controlled by one of the digital pins on the tinyg to just switch of the connection between the board and limit switch.. Can use one of the unused digital outputs,