Better nozzle with auto change?

[Pixopax]

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.

No, so sensor. I disabled the probing switch from the liteplacer at all, and my last job showed, that it is not needed at all.
I enter the pickup height of the party in the tape section and also edit the height of the pcb. Since I have strip holders, the pickup height is always the same.
The holder has a fairly stronhg spring inside which allows for different part heights.

Louis

[WayOutWest]

four jobs a day is ten years heavy production use.

Alright, I guess I'm the only one around here building ~60 boards per day.

[WayOutWest]

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.

No, so sensor. I disabled the probing switch from the liteplacer at all, and my last job showed, that it is not needed at all.

Ah, sorry to hear that. I actually need the sensor though in order to do LGA parts.

[JuKu]

four jobs a day is ten years heavy production use.

Alright, I guess I'm the only one around here building ~60 boards per day.

I'm talking to the TinyG makers about changing settings on the fly. Basically they should make a temporary copy of the eeprom to memory and on command, use and change the ram copy instead of eeprom. If they don't do it, I might. One way or another, I think that happens before your eeprom wears out.

[WayOutWest]

I'm talking to the TinyG makers about changing settings on the fly. Basically they should make a temporary copy of the eeprom to memory

Yeah, it already does this; it's stored in nvObj_t defined in config.h.

and on command, use and change the ram copy instead of eeprom.

Currently reads are from the ram copy (faster) and writes are to both (so they stay in sync).

If you wanted to temporarily disable eeprom updates, doing it in nv_persist() in config.c would work. That would let you modify the in-ram copy of $zsm (Z-max limit switch enablement) without triggering the is-the-machine-in-the-halt-state check (which happens at the top of write_persistent_value() in persistence.c).

[WayOutWest]

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

Actually this is not correct... I got burned really badly here, and I could recall the pain but not the exact issue -- until just now.

It is not enough to simply make sure the machine is not moving.

I thought so at first but I was wrong. Way wrong.

You also have to make sure that TinyG has replied to all of your commands BEFORE you issue any command that modifies the eeprom, because TinyG disables interrupts including those used for serial port flow control while accessing the eeprom. If you only set eeprom variables once when your program first starts up this is easy -- you don't have to wait for any replies since there are none coming to you. But once you start mixing gcode with configuration variable changes you MUST also keep track of what replies the TinyG produces in response to each and every one of your commands. This is not trivial: for example, a single G38.2 command will provoke TWO replies from TinyG, while most other commands provoke only one (and a few provoke none!)

If you don't carefully track these replies and make sure you have all of them before attempting an eeprom update everything will work fine 99.9% of the time. And then, in the middle of the Big Really Important Placement Job you will get this weird bizzarre failure that you spend a week trying to reproduce. And it will ruin a few boards too.

From here

CAVEAT: At the current time because of various limitations of the Xmega we recommend waiting for each config command to send a response before sending the next command. This gives allows the system to persist the data to EEPROM, during that interval the board cannot reliably receive serial input.

I can confirm that this unreliability is not just theoretical.

The TinyG world is bonkers. I have the scars to prove it.

[Pixopax]

I just placed 40 boards without the Z-Sensor switch, and it worked perfect. So I would recommend disabling it, and either use a placement-Z in the tape settings, or add a field "Component height" to the tapes.
With the last one its easier, just define PCB-Zero and add part heights to the tapes.

Then the software knows how far it should drive the Z when placing.
The Nozzles have a 5mm way with spring, so it will not crash if your part is slightly higher.
You just have to look that you set up the placement-Z right for that part.

[JuKu]

Since I posted this on the OpenPnP forum as well, I mention it here as well: I'm planning to offer a set of nozzles, the adapter and a re-designed holder in the shop later, together with an upgrade kit for the machine. An official announcement will come once I have pictures of the prototypes and pricing.

[Pixopax]

Great!

[mawa]

...With the last one its easier, just define PCB-Zero and add part heights to the tapes.

Then the software knows how far it should drive the Z when placing.
The Nozzles have a 5mm way with spring, so it will not crash if your part is slightly higher.
You just have to look that you set up the placement-Z right for that part.

I've been looking into some documentation of professional P&P machines and found that an additional height value is used for placement added to PCB height + component height. This is to prevent pushing the component too far into the solder paste and squeezing the paste.

I don't know how important that is. Did any one have such an issue yet?