You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tl;dr Z_HOVERING should be relative to the height of the board or tape, whichever is higher, in case you have a 10mm thick piece of wood or something that the board and tape are on, hovering should be Xmm above the other stuff, rather than Xmm absolute Z position.
presently, #define Z_HOVERING 10 is an absolute hovering position. but in actuality, assuming people use the homing on their machine (which is ideal) rpt2pnp should be talking about z positions rather than "thickness of board" and thickness of tape.
i envision a future where a printed plastic deck is made for making boards, perhaps something that can be snapped into alignment holes on the printing platform, that has places for tapes and the board or boards. This will ensure relative positioning for the board from the tapes.
The text was updated successfully, but these errors were encountered:
i just realized that the thickness of parts is totally based on the assumption that parts are, in their tape, resting on the same Z position as the board, which will not often be the case. tape will often be pressed onto posts on 3d printed trays, as will the board be on double-sided sticky tape.
the script should ask the user to identify the z-height upon which parts are resting in their tape. this can be done by putting the needle in an empty part slot of a tape and going to the bottom layer.
board height should be gleaned from the Z-coordinates provided when locating the board.
Yep, cardboard thickness should be configurable. Right now, this is constant PNP_TAPE_THICK in gcode-machine.cc
Even if we do this, I think we need to improve the hardware and add some flexibility in the pick/place head to allow some Z-springiness, so that a 0.2mm mishap does not crush the component when placing on the board.
Maybe we might even think of a solenoid-based Z-axis movement which is faster than moving a 3kg build platform up and down and allows for some flex but still height-control with some encoder (details to be figured out :) ) Disadvantage: moving parts in the component rotation mechanism.
tl;dr Z_HOVERING should be relative to the height of the board or tape, whichever is higher, in case you have a 10mm thick piece of wood or something that the board and tape are on, hovering should be Xmm above the other stuff, rather than Xmm absolute Z position.
presently, #define Z_HOVERING 10 is an absolute hovering position. but in actuality, assuming people use the homing on their machine (which is ideal) rpt2pnp should be talking about z positions rather than "thickness of board" and thickness of tape.
i envision a future where a printed plastic deck is made for making boards, perhaps something that can be snapped into alignment holes on the printing platform, that has places for tapes and the board or boards. This will ensure relative positioning for the board from the tapes.
The text was updated successfully, but these errors were encountered: