Nozzle rotation acceleration vs free articulation?
497 views
Skip to first unread message
vespaman
Jan 27, 2024, 12:20:17 PM1/27/24
to OpenPnP
Hi clever guys ;-)
So in the quest for the ever eluding max PnP speed, time has finally come to the nozzles.
The chmt has a silicone tube connection to the nozzles, hence we need to "limit to range".
The chmt has a silicone tube connection to the nozzles, hence we need to "limit to range".
I know some people has just put a 3d printed cap on top of the nema8, and rely on the fact that the motor is tight enough to keep a proper vacuum. I tried this on my machine, and it does not work, I need to seal the axle.
So I 3d printed a cap, and got a seal;
And I'm pretty happy with this - almost no added weight to the nozzles (important, since they are spring loaded).
But:- of course, with a seal, the motors turns with a little bit more friction. Which in turn meant that I had to reduce acceleration, which got me thinking if it is worth the hassle?
Now, I have also enabled "wrap around", so there's potentially way less travel to do.
I do this whole thing, since I run both nozzles with the same tip, so the second pick is sometimes nozzle rotation limited, at least on 0402, where both pockets are open for picking.
In the original setup, I had acceleration set to 100000, feed rate 2000/s (120000/m).
Steppers are 1.8 degree/step. I guess that feed rate is not a significant part of the equation, since it is such a short move.
How does one calculate when "one setup wins over the other"?
E.g. if I have to reduce acceleration to 50000, is that better than the original?
If I understand correctly, there's no need, to rotate the nozzles on pick with this setup(?), so the penalty comes at mainly at vision, right?
If this is true, then I guess, the free articulation trumps acceleration in almost any case?
Am I thinking correct?
 - Micael
vespaman
Jan 27, 2024, 12:52:16 PM1/27/24
to OpenPnP
In addition;
I see that I forgot to mention that I also set the Rotation mode to "Minimal" under nozzle setup.
After writing the above, I do see that I have a suggestion to re-enable the limited articulation in the I&S tab.
But then I read (in the mouse over of "Wrap around"), that I need to set the SET_GLOBAL_OFFSETS_COMMAND. Where can I learn more about how to do this?
 - Micael
mark maker
Jan 28, 2024, 12:12:23 PM1/28/24
to ope...@googlegroups.com
> But then I read (in the mouse over of "Wrap around"), that I need to set the SET_GLOBAL_OFFSETS_COMMAND. Where can I learn more about how to do this?
This is all automatic with I&S. Don't worry, you surely
already have it.
Frankly, I don't really understand your
scenario and how these 3D printed cups are supposed to improve the
situation?
_Mark
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/95cf87bd-ca4c-47fb-b04a-71a9c660b11bn%40googlegroups.com.
vespaman
Jan 28, 2024, 1:03:53 PM1/28/24
to OpenPnP
>This is all automatic with I&S. Don't worry, you surely
already have it.
OK, good!
>Frankly, I don't really understand your
scenario and how these 3D printed cups are supposed to improve the
situation?
Main scenario is that I want the second nozzle pick, to pick as soon as possible. With original, the chmt has a silicon tube that does not allow free articulation, so the nozzles have to rotate before picking.
The cups let's the motor rotate freely, so with the settings above, the second nozzle pick can just pick, regardless of its current angle, only need to wait for the 4mm X-move (without turning the nozzle), if I understand everything correctly. So we don't have to wait for the nozzle turning prior to pick.
(This is 0402 on a ref push pull feeder, with both pockets open, both nozzle picks from the same feeder)
 - Micael
mark maker
Jan 29, 2024, 3:05:18 AM1/29/24
to ope...@googlegroups.com
> Main scenario is that I want the second nozzle pick, to pick as soon as possible. With original, the chmt has a silicon tube that does not allow free articulation, so the nozzles have to rotate before picking. The cups let's the motor rotate freely, so with the settings above, the second nozzle pick can just pick, regardless of its current angle
Ah, I understand, thanks. For those reading along, he is tlking about Rotation Mode:
https://github.com/openpnp/openpnp/wiki/Nozzle-Rotation-Mode
Specifically the Minimal Rotation mode.
I can't say if this will "pay" in the end, if you have to reduce
acceleration rates as a trade-off due to friction. As a matter of
fact, there is another rotation in the Alignment step (assuming
"pre-rotate", as you should). So it is unclear which is worse in
the end.
Clearly, OpenPnP has potential for optimization too (to avoid the cups and friction):
- By looking ahead and rotating both nozzles while moving to the (first nozzle) pick location, and/or while moving back to Alignment. In fact it was one of my goals to allow moving more than three axes at the same time when doing Advanced Motion Control, so that part would actually be ready. But that kind of "looking ahead" is not how the JobProcessor currently works, so don't hold your breath.
- A more low hanging fruit would be a "polarity does not matter"
switch on the Package. So OpenPnP could take any
rotation modulo 180°, effectively halving the average rotation
for those parts, or even more, as we have placement angles in
90° increments and two are halved, and one is even zeroed. And
as those parts (resistors, ceramic caps) are typically the most
numerous in a job, this could actually end up helping quite a
lot. If only I had more spare time...
_Mark
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/887b5286-af61-4d13-ba7b-9478bfbe18fbn%40googlegroups.com.
vespaman
Jan 29, 2024, 4:07:21 AM1/29/24
to OpenPnP
1. OK, I will not hold my breath! :-)
2. Yes, I think you mentioned this in another thread. I know all about time (the lack of) :-) so I am no holding my breath here either. But I agree that this would be very nice.
Today I decided I needed to do some tests, to get at least some feeling what can be achieved, and got to think about the motion planner test, I am not sure if this is similar motion, but if it is, it is very useful for testing the consequences of the rotation.
Moving 2mm without rotation takes about 90ms. With rotation 90 to -90 (and 100000/2000 acc/feedrate), same operation takes ~170ms as per the result of the motion planner test.
If I understood you correctly, the logic behind the rotation is that it is not started until the move to the pick location is started(?).
So I also tested a move from end of drag to first nozzle, first pick location, to see if also that where also held back by the rotation.
This is a slightly longer move that involves both x and y.
Move without rotation: ~125ms. With also rotation 90 to -90, ~170ms.
So, if this test is indicative to real life, it makes me think the total rotation "cost" on this double pick is around 130ms, which is not insignificant.
Incidentally, today, I tried yanking up the acc/feedrate with the cups mounted. And it looked (by the eye) to be working just fine for some reason. Not sure if it really holds together in real life though.
I suppose the only way to know if I'll be loosing steps, is to run a job. That could be a nightmare. :-o
I probably should setup some test job instead, so I don't have to spend half a day to correct 0402 on real boards.
 - Micael
mark maker
Jan 29, 2024, 4:49:19 AM1/29/24
to ope...@googlegroups.com
> If I understood you correctly, the logic behind the
rotation is that it is not started until the move to the pick
location is started(?).
Yes.Â
(I'm also explaining for those reading along:)
For the first nozzle that is usually okay, as it is moving from the last placement location. i.e. a rather long move where rotation can take place in parallel. However, for the second nozzle, this is just the move from one feeder pick location to the other feeder pick location, those can be close together, and if you have two compatible nozzle tips it might even be from the same feeder, so the move is only the between-nozzles offset (plus/minus 2mm for 0402), i.e., not enough time to rotate.
The same happens in Alignment, above the bottom camera.
Technically, if you have two independent rotation motors on the
nozzles (as most machines have), OpenPnP could rotate the second
nozzle in parallel with the first nozzle, i.e., while moving to
the feeders/bottom camera. Advanced Motion Control actually can
do that (it wasn't possible before). But as I said, it would have
to peek ahead in the Job Processor, and that's not too easy...
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/577793b0-e71e-4c42-95c6-01daa5cbdc50n%40googlegroups.com.
vespaman
Jan 29, 2024, 5:53:48 AM1/29/24
to OpenPnP
>But as I said, it would have
to peek ahead in the Job Processor, and that's not too easy...
Yes, that indeed sounds very complicated to add on. And, at least from the point of feeders, I suspect that most machines with not 2 nozzles already have a solution for free rotation. And for the rest of us we can always change this when needed.
So from that perspective, the lower hanging fruit with the "polarity does not matter" is worth more imo, since it will help all set-ups to some extent, lessen the worst case 180deg scenario.
(Also during alignment, I suspect, as well as components that does not handle rotation well in general - e.g. those tact switches that can swivel because the key top is not fixated very securely to the body).
(I suppose a parallel rotation for alignment over up looking camera issues might be easier to solve, looking at it isolated (?), since by then, the components/rotation should be known)
 - Micael
Jan
Jan 29, 2024, 8:20:23 AM1/29/24
to ope...@googlegroups.com
Hi Micael!
Interesting mod you did!
As Mark says, the JobProcessor handles nozzles in series. On the way to
the first pick location, there is a lot of time to perform any rotation
needed. The same on the way from pick to align. But for the second (and
any other) nozzle the distance might be quite short and hence limited by
the rotation. So if you have a polarized part, the penalty at alignment
is still there (depending on pick, pre-rotate setting and place
orientation).
@Mark: how would one request additional movements at the
AsyncGCodeDriver? MoveTo() only provides arguments for four axis. Are
shared rotation situations handled automatically by the AsyncGCodeDriver
or would that have to be done by the caller?
From my current understanding of the JobProcessor everything is - in
theory - there: it's a question if special care for shared rotation
machines has to be added and where the usual move-to-safe-z is happening
(are the rotation information for other nozzles available at safe-z or not?)
Jan
On 29.01.2024 11:53, vespaman wrote:
> >But as I said, it would have to peek ahead in the Job Processor, and
> that's not too easy...
>
> Yes, that indeed sounds very complicated to add on. And, at least from
> the point of feeders, I suspect that most machines with not 2 nozzles
> already have a solution for free rotation. And for the rest of us we can
> always change this when needed.
> So from that perspective, the lower hanging fruit with the "polarity
> does not matter" is worth more imo, since it will help all set-ups to
> some extent, lessen the worst case 180deg scenario.
> (Also during alignment, I suspect, as well as components that does not
> handle rotation well in general - e.g. those tact switches that can
> swivel because the key top is not fixated very securely to the body).
>
> (I suppose a parallel rotation for alignment over up looking camera
> issues might be easier to solve, looking at it isolated (?), since by
> then, the components/rotation should be known)
>
> Â - Micael
> måndag 29 januari 2024 kl. 10:49:19 UTC+1 skrev ma...@makr.zone:
>
> /> If I understood you correctly, the logic behind the rotation is
>> /> Main scenario is that I want the second nozzle pick, to
>> matter" switch on the Package. So OpenPnP could take /any/
>>> https://groups.google.com/d/msgid/openpnp/887b5286-af61-4d13-ba7b-9478bfbe18fbn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/887b5286-af61-4d13-ba7b-9478bfbe18fbn%40googlegroups.com?utm_medium=email&utm_source=footer>.
Interesting mod you did!
As Mark says, the JobProcessor handles nozzles in series. On the way to
the first pick location, there is a lot of time to perform any rotation
needed. The same on the way from pick to align. But for the second (and
any other) nozzle the distance might be quite short and hence limited by
the rotation. So if you have a polarized part, the penalty at alignment
is still there (depending on pick, pre-rotate setting and place
orientation).
@Mark: how would one request additional movements at the
AsyncGCodeDriver? MoveTo() only provides arguments for four axis. Are
shared rotation situations handled automatically by the AsyncGCodeDriver
or would that have to be done by the caller?
From my current understanding of the JobProcessor everything is - in
theory - there: it's a question if special care for shared rotation
machines has to be added and where the usual move-to-safe-z is happening
(are the rotation information for other nozzles available at safe-z or not?)
Jan
On 29.01.2024 11:53, vespaman wrote:
> >But as I said, it would have to peek ahead in the Job Processor, and
> that's not too easy...
>
> Yes, that indeed sounds very complicated to add on. And, at least from
> the point of feeders, I suspect that most machines with not 2 nozzles
> already have a solution for free rotation. And for the rest of us we can
> always change this when needed.
> So from that perspective, the lower hanging fruit with the "polarity
> does not matter" is worth more imo, since it will help all set-ups to
> some extent, lessen the worst case 180deg scenario.
> (Also during alignment, I suspect, as well as components that does not
> handle rotation well in general - e.g. those tact switches that can
> swivel because the key top is not fixated very securely to the body).
>
> (I suppose a parallel rotation for alignment over up looking camera
> issues might be easier to solve, looking at it isolated (?), since by
> then, the components/rotation should be known)
>
> Â - Micael
> måndag 29 januari 2024 kl. 10:49:19 UTC+1 skrev ma...@makr.zone:
>
> that it is not started until the move to the pick location is
> started(?).
> /
> started(?).
>
> Yes.
>
> (I'm also explaining for those reading along:)
>
> For the first nozzle that is usually okay, as it is moving from the
> last placement location. i.e. a rather long move where rotation can
> take place in parallel. However, for the second nozzle, this is just
> the move from one feeder pick location to the other feeder pick
> location, those can be close together, and if you have two
> compatible nozzle tips it might even be from the same feeder, so the
> move is only the between-nozzles offset (plus/minus 2mm for 0402),
> i.e., not enough time to rotate.
>
> The same happens in Alignment, above the bottom camera.
>
> Technically, if you have two independent rotation motors on the
> nozzles (as most machines have), OpenPnP could rotate the second
> nozzle in parallel with the first nozzle, i.e., while moving to the
> feeders/bottom camera. Advanced Motion Control actually *can* do
> Yes.
>
> (I'm also explaining for those reading along:)
>
> For the first nozzle that is usually okay, as it is moving from the
> last placement location. i.e. a rather long move where rotation can
> take place in parallel. However, for the second nozzle, this is just
> the move from one feeder pick location to the other feeder pick
> location, those can be close together, and if you have two
> compatible nozzle tips it might even be from the same feeder, so the
> move is only the between-nozzles offset (plus/minus 2mm for 0402),
> i.e., not enough time to rotate.
>
> The same happens in Alignment, above the bottom camera.
>
> Technically, if you have two independent rotation motors on the
> nozzles (as most machines have), OpenPnP could rotate the second
> nozzle in parallel with the first nozzle, i.e., while moving to the
>> pick as soon as possible. With original, the chmt has a
>> silicon tube that does not allow free articulation, so the
>> nozzles have to rotate before picking. The cups let's the
>> motor rotate freely, so with the settings above, the second
>> nozzle pick can just pick, regardless of its current angle/
>> silicon tube that does not allow free articulation, so the
>> nozzles have to rotate before picking. The cups let's the
>> motor rotate freely, so with the settings above, the second
>>
>> Ah, I understand, thanks. For those reading along, he is
>> tlking about Rotation Mode:
>>
>> https://github.com/openpnp/openpnp/wiki/Nozzle-Rotation-Mode
>> <https://github.com/openpnp/openpnp/wiki/Nozzle-Rotation-Mode>
>>
>> Specifically the Minimal Rotation
>> <https://github.com/openpnp/openpnp/wiki/Nozzle-Rotation-Mode#rotation-modes> mode.
>> Ah, I understand, thanks. For those reading along, he is
>> tlking about Rotation Mode:
>>
>> https://github.com/openpnp/openpnp/wiki/Nozzle-Rotation-Mode
>> <https://github.com/openpnp/openpnp/wiki/Nozzle-Rotation-Mode>
>>
>> Specifically the Minimal Rotation
>>
>> I can't say if this will "pay" in the end, if you have to
>> reduce acceleration rates as a trade-off due to friction. As a
>> matter of fact, there is another rotation in the Alignment
>> step (assuming "pre-rotate", as you should). So it is unclear
>> which is worse in the end.
>>
>> Clearly, OpenPnP has potential for optimization too (to avoid
>> the cups and friction):
>>
>> 1. By looking ahead and rotating /both/ nozzles while moving
>> I can't say if this will "pay" in the end, if you have to
>> reduce acceleration rates as a trade-off due to friction. As a
>> matter of fact, there is another rotation in the Alignment
>> step (assuming "pre-rotate", as you should). So it is unclear
>> which is worse in the end.
>>
>> Clearly, OpenPnP has potential for optimization too (to avoid
>> the cups and friction):
>>
>> to the (first nozzle) pick location, and/or while moving
>> back to Alignment. In fact it was one of my goals to allow
>> moving more than three axes at the same time when doing
>> Advanced Motion Control, so that part would actually be
>> ready. But that kind of "looking ahead" is *not* how the
>> back to Alignment. In fact it was one of my goals to allow
>> moving more than three axes at the same time when doing
>> Advanced Motion Control, so that part would actually be
>> JobProcessor currently works, so don't hold your breath.
>> 2. A more low hanging fruit would be a "polarity does not
>> matter" switch on the Package. So OpenPnP could take /any/
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "OpenPnP" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to openpnp+u...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/openpnp/577793b0-e71e-4c42-95c6-01daa5cbdc50n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/577793b0-e71e-4c42-95c6-01daa5cbdc50n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> --
>> You received this message because you are subscribed to the Google
>> Groups "OpenPnP" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to openpnp+u...@googlegroups.com.
>> To view this discussion on the web visit
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/openpnp/c5747ae8-2190-4f05-abb2-03e5fb152f5bn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/c5747ae8-2190-4f05-abb2-03e5fb152f5bn%40googlegroups.com?utm_medium=email&utm_source=footer>.
vespaman
Jan 29, 2024, 9:02:01 AM1/29/24
to OpenPnP
Hi Jan!
>On the way to
the first pick location, there is a lot of time to perform any rotation
needed.
So the drag operation is opaque here? I suspected the rotation starts only after having done the drag, but that may have been the wrong assumption.
In this case; the penalties are really only on the second nozzle; one penalty for the pick, and one penalty for the alignment?
Turns out that the max feed rate causes me most problem with the nozzles (with my new setup), not so much the acceleration, which I only see when I park it (from jog panel).
During the run of a job, I am not sure when this max speed is happening, apart from doing the run out compensation after nozzle lods, so maybe the impact is not great if I reduce it.
Got to digest some more logs, to get a hang of if max speed is really important in the greater scheme. :-)
 - Micael
mark maker
Jan 29, 2024, 9:12:48 AM1/29/24
to ope...@googlegroups.com
> @Mark: how would one request additional movements at the AsyncGCodeDriver? MoveTo() only provides arguments for four axis. Are shared rotation situations handled automatically by the AsyncGCodeDriver or would that have to be done by the caller?
Yes, OpenPnP has the Location data type which is X, Y, Z, C only (4-axis).Â
But underneath, since I implemented Advanced Motion Control, it is all managed in AxesLocation, which supports an arbitrary number of axes.Â
Furthermore, motion is never immediately executed. Instead the
motion sequence is added to the motion planner. Only when the
situation requires motion to be complete (for instance when we
want to take a camera shot), then we tell the planner that we need
to wait for motion completion. This in turn forces the motion to
actually being processed and ultimately sent to controllers. The
planner can do arbitrary optimization to the path and also
distribute and coordinate the motion commands across multiple
drivers, in parallel. Remember, it actually can do Motion
Blending and other cool stuff (if only the controllers and
serial interfaces were fast enough 😕).
To move in more than 4 axes at a time, one would need to
implement a new MotionOption.Subordinate,
added here:
https://github.com/openpnp/openpnp/blob/develop/src/main/java/org/openpnp/model/Motion.java#L55
But instead of adding a new motion segment, it would have
accumulate AxesLocation coordinates to the previous motion
target, but never change axes that were already there. Somewhere
here:
But that is complicated by things such as backlash compensation. I.e. it would have to undo not only the last but also the second to last motion segment.
Usage in JobProcessor code (pseudo code off the top of my head):
currentPlacement.nozzle.moveTo(currentPlacement.targetLocationOfStep);
for each (upcomingPlacement : upcomingPlacements) {
upcomingPlacement.nozzle.moveTo(upcomingPlacement.targetLocationOfStep, MotionOption.Subordinate);
}
_Mark
mark maker
Jan 29, 2024, 9:43:42 AM1/29/24
to ope...@googlegroups.com
You're right, with the drag operation it is even more
complicated. It now needs to look ahead from the Feed operation
not only into its won Pick operation, but also into those of the
other nozzle(s).
🤯
_Mark
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/207d0e61-abba-4e84-9f34-04fb800dbfe9n%40googlegroups.com.
vespaman
Jan 29, 2024, 10:22:39 AM1/29/24
to OpenPnP
OK, so then, for a typical 2nozzle machine, we have rotational penalties here;
1. going from drag-end to first pick
2. going from first pick to second pick (esp. if picking from same feeder, but likely also if picking from close-by feeder)
3. going from first component alignment to second nozzle/component alignment.
1 & 2 will disappear, going with free articulated nozzle setup. But not 3).
So I did some more tests, using the motion diagnostics. Now testing
the distance of penalty three - rotating a component on the second nozzle
on the way to alignment of component on nozzle 2, starting from nozzle 1
over the camera position.
Interesting enough!
Rotate 180deg, no matter how, the rotation is the limiting factor by far, even with the 100k feed/2000 accel.
Rotate 90deg, still rotation is the limiting factor (only by little, though), with 100k feed and 2000 accel. One could say 90deg is the tipping point; more, and we get penalized.
Now,
if my brain hasn't become too mushy during the day; without my mod, I
can expect 270deg for a part, polarized or not (since we don't have the
"ignore polarization"), and 180deg with my mod (free articulation) worst
case.
If this is true, then there's about 200-300ms to be saved on a full 'round', unless it is all consumed by the added friction (unlikely!). But this is worst case scenario, of course.
I suspect I need to study the logs more, for realistic gains and penalties, but I'm getting a bit fatigue. Logs does that to me. :-) Maybe a coffe will work wonder. I shall test!
 - Micael
mark maker
Jan 29, 2024, 11:32:55 AM1/29/24
to ope...@googlegroups.com
Good discussion. Yeah, I agree with this analysis, and yes, the polarity optimization might already bring the worst case down to rotations that are no longer (much) limiting the speed.
You could always also use real tube decouplers, even my
Liteplacer has one, and I don't believe it has much friction.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f0e144b9-7aa9-4352-acc0-eb4f0f9a6e05n%40googlegroups.com.
vespaman
Jan 29, 2024, 12:00:46 PM1/29/24
to OpenPnP
>You could always also use real tube decouplers, even my
Liteplacer has one, and I don't believe it has much friction.
Yes, I have been meaning to get some of those to test with. But so far, my assumption has been, that they also bring enough friction and also mass, to make my small and weak nema8's struggle.
They could be mounted on top of the head with existing silcone tubing connecting down to the nema8, so they don't add weight to the moving (z) nozzle springs.
I shall see if I can find them closer, time wise, than weeks/months away from China.
 - Micael
mark maker
Jan 29, 2024, 12:19:07 PM1/29/24
to ope...@googlegroups.com
I just went to the workshop quickly and the coupling is really
going very easy, no friction that I can see. Remember, the
original machine needs to twist the silicon rubber tube, which is
not nothing. On the Liteplacer there is also some sort of tubing
(don't know if that is silicon) and the friction of the coupling
is so low that when I twist the tubing, it immediately snaps back
to the original rotation, no "creeping" or "sticking", whatsoever,
i.e. the twisting forces are way higher than any friction present.
Plus the thingy seems to be made out of very light plastic and hardly weighs anything. Even one nut of your head assembly probably weighs more. 🙂
I doubt this is significant at all.
_Mark
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/640d30b3-955b-4e49-bb25-9ed288014b44n%40googlegroups.com.
vespaman
Jan 29, 2024, 1:01:07 PM1/29/24
to OpenPnP
Thanks for checking!
You have me convinced, that I need to prioritize getting them then instead, or as a parallel thing.
 - Micael
vespaman
Jan 29, 2024, 3:24:32 PM1/29/24
to OpenPnP
So, now I read up on the SMC KSH/KSL 05-M5, which is the lightest and with least friction; 0.006Nm and 9 grams according to some data sheet.
The 9 grams is perhaps much for the spring, I think. But the friction feels like way better than my solution.
Maybe I can disassemble them, and make them slightly lighter. :-)Â
Unfortunately, they will not arrive until next week.
There's always room for improvements!
 - Micael
mark maker
Jan 30, 2024, 4:06:29 AM1/30/24
to ope...@googlegroups.com
what is the weight of your motors? do 9 grams really matter?
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4b0963be-44af-41a0-9c65-0693958927f6n%40googlegroups.com.
Jan
Jan 30, 2024, 4:09:10 AM1/30/24
to ope...@googlegroups.com
Thank You very much, Mark! Thats exactely what I was looking for and
what I'm intending to add. We'll then see if the driver rotates all
nozzles on the long moves...
Jan
On 29.01.2024 15:12, 'mark maker' via OpenPnP wrote:
> /> @Mark: how would one request additional movements at the
>
> Yes, OpenPnP has the *Location* data type which is X, Y, Z, C only
> https://groups.google.com/d/msgid/openpnp/f6b32990-8537-4472-8b45-b8de7756fd95%40makr.zone <https://groups.google.com/d/msgid/openpnp/f6b32990-8537-4472-8b45-b8de7756fd95%40makr.zone?utm_medium=email&utm_source=footer>.
what I'm intending to add. We'll then see if the driver rotates all
nozzles on the long moves...
Jan
On 29.01.2024 15:12, 'mark maker' via OpenPnP wrote:
> /> @Mark: how would one request additional movements at the
> AsyncGCodeDriver? MoveTo() only provides arguments for four axis. Are
> shared rotation situations handled automatically by the AsyncGCodeDriver
> or would that have to be done by the caller?/
> shared rotation situations handled automatically by the AsyncGCodeDriver
>
> Yes, OpenPnP has the *Location* data type which is X, Y, Z, C only
> (4-axis).
>
> But underneath, since I implemented Advanced Motion Control, it is all
> managed in *AxesLocation*, which supports an arbitrary number of axes.
>
> But underneath, since I implemented Advanced Motion Control, it is all
>
> Furthermore, motion is never immediately executed. Instead the motion
> sequence is added to the motion planner. Only when the situation
> requires motion to be complete (for instance when we want to take a
> camera shot), then we tell the planner that we need to wait for motion
> completion. This in turn forces the motion to actually being processed
> and ultimately sent to controllers. The planner can do arbitrary
> optimization to the path and also distribute and coordinate the motion
> commands across multiple drivers, in parallel. Remember, it actually can
> do Motion Blending
> <https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-blending>
> Furthermore, motion is never immediately executed. Instead the motion
> sequence is added to the motion planner. Only when the situation
> requires motion to be complete (for instance when we want to take a
> camera shot), then we tell the planner that we need to wait for motion
> completion. This in turn forces the motion to actually being processed
> and ultimately sent to controllers. The planner can do arbitrary
> optimization to the path and also distribute and coordinate the motion
> commands across multiple drivers, in parallel. Remember, it actually can
> do Motion Blending
> and other cool stuff (if only the controllers and serial interfaces were
> fast enough 😕).
>
> fast enough 😕).
>
> AdvancedMotionAnimation
>
> To move in more than 4 axes at a time, one would need to implement a
> new*MotionOption.Subordinate*, added here:
>
> To move in more than 4 axes at a time, one would need to implement a
>
> https://github.com/openpnp/openpnp/blob/develop/src/main/java/org/openpnp/model/Motion.java#L55
>
> But instead of adding a new motion segment, it would have accumulate
> AxesLocation coordinates to the*previous* motion target, but never
> https://github.com/openpnp/openpnp/blob/develop/src/main/java/org/openpnp/model/Motion.java#L55
>
> But instead of adding a new motion segment, it would have accumulate
> change axes that were already there. Somewhere here:
>
> https://github.com/openpnp/openpnp/blob/dd58cf65b0465b426bef8ebd7b87cc7b767ddf7f/src/main/java/org/openpnp/machine/reference/driver/AbstractMotionPlanner.java#L407
>
> But that is complicated by things such as backlash compensation. I.e. it
> would have to undo not only the last but also the second to last motion
> segment.
>
> https://github.com/openpnp/openpnp/blob/dd58cf65b0465b426bef8ebd7b87cc7b767ddf7f/src/main/java/org/openpnp/machine/reference/driver/AbstractMotionPlanner.java#L384-L403
>
> Usage in JobProcessor code (pseudo code off the top of my head):
>
> currentPlacement.nozzle.moveTo(currentPlacement.targetLocationOfStep);
>
> for each (upcomingPlacement : upcomingPlacements) {
> upcomingPlacement.nozzle.moveTo(upcomingPlacement.targetLocationOfStep,*MotionOption.Subordinate*);
>
> https://github.com/openpnp/openpnp/blob/dd58cf65b0465b426bef8ebd7b87cc7b767ddf7f/src/main/java/org/openpnp/machine/reference/driver/AbstractMotionPlanner.java#L407
>
> But that is complicated by things such as backlash compensation. I.e. it
> would have to undo not only the last but also the second to last motion
> segment.
>
> https://github.com/openpnp/openpnp/blob/dd58cf65b0465b426bef8ebd7b87cc7b767ddf7f/src/main/java/org/openpnp/machine/reference/driver/AbstractMotionPlanner.java#L384-L403
>
> Usage in JobProcessor code (pseudo code off the top of my head):
>
> currentPlacement.nozzle.moveTo(currentPlacement.targetLocationOfStep);
>
> for each (upcomingPlacement : upcomingPlacements) {
Jan
Jan 30, 2024, 4:28:11 AM1/30/24
to ope...@googlegroups.com
On 29.01.2024 15:02, vespaman wrote:
> Hi Jan!
> >On the way to the first pick location, there is a lot of time to
> perform any rotation needed.
>
> So the drag operation is opaque here? I /suspected /the rotation starts
> >On the way to the first pick location, there is a lot of time to
> perform any rotation needed.
>
> only after having done the drag, but that may have been the wrong
> assumption.
>
Yes, the JobProcessor currently executes everything sequentially. As
> assumption.
>
part of the Pick step, the required feeder is selected among the
available feeders and then a feed action is executed. If that feed
action requires dragging, its done. After feeding, the nozzle is moved
to the pick location and the part is picked. As part of that move the
rotation takes place because its part of the pick location. The same
happens for the pick on the second nozzle and for the alignment steps.
You'll probably notice, that moving the first nozzle to the camera does
not require anything else, hence its rotation is already part of the
long move. For the second nozzle again, the rotation is only executed
when the nozzle is send to the camera.
As I asked in the other response and as Mark replied, the solution is
to schedule all nozzle rotations after selecting the feeder but before
the feed operation. This way the long move to the feeder - regardless if
thats for a feed or pick operation - will rotate all nozzles and the
nozzles will arrive with the correct rotation. (I'm not aware of any
feed operation that requires the nozzle to be in a certain orientation.
So even opening a blinds feeder with the same nozzle tip shall work.)
For the alignment step, I'd add the same, schedule all nozzles
rotations before starting to move to the camera. This even shall not
harm in the case that alignment is skipped.
Jan
vespaman
Jan 30, 2024, 6:17:25 AM1/30/24
to OpenPnP
> what is the weight of your motors? do 9 grams really matter?
I am pretty sure 9 grams matter to some extent, if I put it on top of the motor. But if I put the 9grams on the fixed part of the head, with the existing silicon tube (just shortened a little) it does not matter.
Each nozzle is pulled up by a spring, so adding more weight means slower moving up. How much, I do not know, it is not fun to find out :-)Â
I have been thinking about adding sensors for this, because then smoothie can report back not only when motors are stopped, but also the fact that the nozzle(s) are up (or up enough).
Now the nozzle Z speed setup it is just the result of Jan's nozzle crash(es), I suspect he did not want to fine tune this much. :-) :-)
Currently, it looks like the Z speed results in ~70ms. Like "it is probably up by now"-time. This might not be the end of the world, but I suspect it can be reduced some. By not optimizing it, time is also lost in the "put nozzle down" moment.
When I look at old logs, it looks like x/y/x/a are all grouped together within the same G400, doing nozzle down, which makes me confused.
->end of feeder drag, drag pin just arrived up;
2023-12-13 11:39:17.820 ReferenceActuator DEBUG: DRAGPIN.read(): 1
2023-12-13 11:39:17.822 AbstractHeadMountable DEBUG: N1.moveTo((505.361436, 260.253213, -10.300000, 90.000000 mm), 1.0)
2023-12-13 11:39:17.822 ReferenceNozzle TRACE: N1.toHeadLocation((505.361436, 260.253213, -10.300000, -67.453924 mm), ...) rotation mode offset 157.453924149721
2023-12-13 11:39:17.822 ReferenceNozzle TRACE: N1.toHeadLocation((505.413261, 260.211480, -10.300000, -67.453924 mm), ...) runout compensation (-0.051825, 0.041733, 0.000000, 0.000000 mm)
2023-12-13 11:39:17.822 ReferenceNozzle DEBUG: N1.pick()
2023-12-13 11:39:17.822 Scripting TRACE: Scripting.on Nozzle.BeforePick
2023-12-13 11:39:17.822 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M204 S14241 G1 X471.37 Y278.45 Â A-67.5 Â Â F74937 ; move to target
2023-12-13 11:39:17.822 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M204S14241G1X471.37Y278.45A-67.5F74937
2023-12-13 11:39:17.822 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-12-13 11:39:17.823 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M204 S139 G1 X471.43 Y278.51 Â Â Â F600 ; move to target
2023-12-13 11:39:17.823 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M204S139G1X471.43Y278.51F600
2023-12-13 11:39:17.824 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-12-13 11:39:17.824 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M204 S90909 G1 Â Z-36.1 Â Â F60000 ; move to target
2023-12-13 11:39:17.824 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M204S90909G1Z-36.1F60000
2023-12-13 11:39:17.825 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-12-13 11:39:17.830 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M400 ; Wait for moves to complete before returning
2023-12-13 11:39:17.830 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M114 ; get position
2023-12-13 11:39:17.830 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M400
2023-12-13 11:39:17.830 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M114
2023-12-13 11:39:18.113 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-12-13 11:39:18.114 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok C: X:471.4300 Y:278.5100 Z:-36.1000 A:-67.5000 B:23.2000 C:0.0000 D:0.0000
2023-12-13 11:39:18.114 GcodeDriver TRACE: Position report: ok C: X:471.4300 Y:278.5100 Z:-36.1000 A:-67.5000 B:23.2000 C:0.0000 D:0.0000
2023-12-13 11:39:18.114 GcodeDriver TRACE: GcodeDriver got lastReportedLocation (X:471.430000, Y:278.510000, ZN:-36.100000, C1:-67.500000, C2:23.200000, LPeel:0.000000, RPeel:0.000000)
2023-12-13 11:39:18.114 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete.
2023-12-13 11:39:17.822 AbstractHeadMountable DEBUG: N1.moveTo((505.361436, 260.253213, -10.300000, 90.000000 mm), 1.0)
2023-12-13 11:39:17.822 ReferenceNozzle TRACE: N1.toHeadLocation((505.361436, 260.253213, -10.300000, -67.453924 mm), ...) rotation mode offset 157.453924149721
2023-12-13 11:39:17.822 ReferenceNozzle TRACE: N1.toHeadLocation((505.413261, 260.211480, -10.300000, -67.453924 mm), ...) runout compensation (-0.051825, 0.041733, 0.000000, 0.000000 mm)
2023-12-13 11:39:17.822 ReferenceNozzle DEBUG: N1.pick()
2023-12-13 11:39:17.822 Scripting TRACE: Scripting.on Nozzle.BeforePick
2023-12-13 11:39:17.822 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M204 S14241 G1 X471.37 Y278.45 Â A-67.5 Â Â F74937 ; move to target
2023-12-13 11:39:17.822 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M204S14241G1X471.37Y278.45A-67.5F74937
2023-12-13 11:39:17.822 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-12-13 11:39:17.823 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M204 S139 G1 X471.43 Y278.51 Â Â Â F600 ; move to target
2023-12-13 11:39:17.823 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M204S139G1X471.43Y278.51F600
2023-12-13 11:39:17.824 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-12-13 11:39:17.824 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M204 S90909 G1 Â Z-36.1 Â Â F60000 ; move to target
2023-12-13 11:39:17.824 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M204S90909G1Z-36.1F60000
2023-12-13 11:39:17.825 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-12-13 11:39:17.830 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M400 ; Wait for moves to complete before returning
2023-12-13 11:39:17.830 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M114 ; get position
2023-12-13 11:39:17.830 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M400
2023-12-13 11:39:17.830 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M114
2023-12-13 11:39:18.113 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-12-13 11:39:18.114 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok C: X:471.4300 Y:278.5100 Z:-36.1000 A:-67.5000 B:23.2000 C:0.0000 D:0.0000
2023-12-13 11:39:18.114 GcodeDriver TRACE: Position report: ok C: X:471.4300 Y:278.5100 Z:-36.1000 A:-67.5000 B:23.2000 C:0.0000 D:0.0000
2023-12-13 11:39:18.114 GcodeDriver TRACE: GcodeDriver got lastReportedLocation (X:471.430000, Y:278.510000, ZN:-36.100000, C1:-67.500000, C2:23.200000, LPeel:0.000000, RPeel:0.000000)
2023-12-13 11:39:18.114 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete.
->wait for vacuum.
 - Micael
vespaman
Jan 30, 2024, 6:37:04 AM1/30/24
to OpenPnP
Hi Jan,
I think you misunderstood me. I
was merely questioning your comment saying "there's a lot of time" while
moving to first pick location.
I think we have established since, that
this not the case, in the current version and on a normal (for many
two-nozzle machine) drag feeder.
And
like I wrote before, I am not really sure about the need to do this
tricky nozzle rotation pre-planning, since there is already a simple
solution to the problem (by adding some kind of swivel junction) if one is interested in better performance.
But that is just my two cents :-)
 - Micael
mark maker
Jan 30, 2024, 7:56:48 AM1/30/24
to ope...@googlegroups.com
> But if I put the 9grams on the fixed part of the head, with the existing silicon tube (just shortened a little) it does not matter.
I'm not sure I understand the situation correctly. If not, the
following might be completely wrong. 😇 A photo with any cover off
might help.
My assumptions: there is a short piece of tube from the Z-movable, rotating hollow shaft, up to a crossbar, where the coupling will be mounted, rigidly in Z (and X, Y).
So if that is true, the tube will be bent to take the Z
compression, and form a sort of snake-line. Quite a
"counter-spring".
And for rotation, you get a sort of "flex connecting rod", i.e. the rotation is "force-squished" through the silicon tubes, on top of the snake-line, likely forming some sort of "squish-spiral".Â
If this is true, it will surely create bad lateral forces on the
coupling, and even if the coupling could still take that
with little friction (long term), a lot of friction will result
from squishing the tubes themselves. I would even expect the
rotation to sputter with the residual sticky friction against
elasticity.
If that is even remotely true, I would definitely put the
couplings directly on the hollow shafts, and then use generous
tube lengths that can take the Z compression, and with some
bend-adjusting (if possible even above and beyond the head) you
can even balance-out half the lateral forces. No rotation
is squished into the tubes.
_Mark
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/920c4f89-809c-4779-81d6-d6807930cc5fn%40googlegroups.com.
mark maker
Jan 30, 2024, 7:59:04 AM1/30/24
to ope...@googlegroups.com
> since there is already a simple solution to the problem (by adding some kind of swivel junction) if one is interested in better performance.
This help in the feeder Pick, but not in Alignment.
_Mark
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8e932aab-3c26-4247-9c9e-644f76ae9233n%40googlegroups.com.
vespaman
Jan 30, 2024, 9:11:57 AM1/30/24
to OpenPnP
I think I understand what you are writing :- that you suggest not do a solution where the tube do both Z and rotation.
But if the friction of the coupling is little (as in; less what I currently have with my 3d printed solution), there's no way it may harm the coupling (the coupling is essentially a ball bearing with two seals).
And if the snake-line is severe, it means that the friction is too high regardless. Remember; these silicon tubes today are doing both Z and rotation up to about 180deg, with some force already.
Or maybe, like you say mount the coupling rigidly on the motors, with some mounting having the non moving part secured to the motor (otherwise it is anyway going to create snake-line).
I agree that it makes sense to let the flex tube be as long as
possible, regardless (within reason). E.g. as it is today (can be seen in my first
post above).
But time will tell! For me, I think I will know better when I have them in my hand. It is very hard to estimate how much 0.006 Nm is, and especially how much force my current solution needs. (I guess I could setup proper measurement, but I'll do that when/if needed).
I should have them hopefully on Friday, if not, Monday.
 - Micael
vespaman
Jan 30, 2024, 9:24:31 AM1/30/24
to OpenPnP
>This help in the feeder Pick, but not in Alignment.
Yes, as I stated already here.
But even so, (did I not also write this, or did I just think about it?), once the pick is done, and it is time for alignment, all nozzles and component data should already be present, since they are already picked then.
In my mind, this is much simpler code, than trying to look up ahead all nozzles/feeders/placements etc ahead.
Perhaps I should also make myself extra clear, that I obviously don't mind if that pre-planning-super-duper code is eventually done, just not on behalf of me. (Being the thread starter and all) :-)
 - Micael
mark maker
Jan 30, 2024, 10:35:53 AM1/30/24
to ope...@googlegroups.com
> Or maybe, like you say mount the coupling rigidly on the motors
You mean on the motor hollow shafts, right?Â
I.e. the underside of the coupling turns with the hollow shaft, the upper side with the tube stays (more or less) put.
Something like this:
https://www.aliexpress.us/item/3256804211715767.html
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/156a11d8-016f-402e-902c-48bf84a128b7n%40googlegroups.com.
mark maker
Jan 30, 2024, 10:53:38 AM1/30/24
to ope...@googlegroups.com
> In my mind, this is much simpler code, than trying to look up ahead all nozzles/feeders/placements etc ahead.
Not sure at all.
You still need to anticipate the pre-rotate option, and if enabled (which is much recommended!) you need the PCB placement angle, including the PCB rotation and even fiducial adjustments, which is also not that easy, i.e., not sure if readily available inside the JobProcessor.
The ideal Job Planner would be able to fully simulate the
whole job, or at least groups of placements. It could then even
account for real world time cost, based on prior measurements on
that machine. This simulation could then also be used to find the
optimized combinations of picks, i.e., avoid that picks from
feeders are far from each other etc. It could also be used to
optimize in which order the nozzles are done. Looking ahead would
be as simple as "playing" that simulation.
Jan has already added a nozzle ordering optimization in the test version, but this too would even be better if it could look ahead.Â
Note, I just merged it into the OpenPnP testing version:
https://github.com/openpnp/openpnp/pull/1574
@Jan, please announce as planned.
_Mark
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/062bc635-a8ef-4321-b8eb-615f5ffdb46en%40googlegroups.com.
vespaman
Jan 30, 2024, 10:56:02 AM1/30/24
to OpenPnP
>You mean on the motor hollow shafts, right?Â
>I.e. the underside of the coupling turns with the hollow shaft, the upper side with the tube stays (more or less) put.
>Something like this:
Well, if you do it like that, then there's no difference to reversing it, by putting the coupler on the other end of the tube, which I intended to do. Both times the tube will twist equally much. But by putting it on the other end, there's no weight on the motor.
If you put the coupler on the hollow axle, and then fixed the outer shell of the coupler to the motor body, you will not get any twist of the tube, only the Z. This is what I thought you meant. :-)
 - Micael
vespaman
Jan 30, 2024, 11:05:05 AM1/30/24
to OpenPnP
>Not sure at all.
If you say so! Like I said, I am not opposed to anything. Maybe "double same nozzle" support can come out of it! ;-) ;-)
 - Micael
Wayne Black
Jan 30, 2024, 11:57:08 AM1/30/24
to OpenPnP
Since I happen to have these items on my desk at the moment heres some pics of the chmt oem head nipple and with the swivel coupler. What's striking is the chmt oem nipple ID. Its tiny. 
Mike Menci
Jan 30, 2024, 11:59:34 AM1/30/24
to ope...@googlegroups.com
My PnP has it this way - fixed tube - nozzle turns with stepper shaft (Nema8 stepper with full shaft)Â
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/80f2145f-7b32-42d5-b8e7-09bbdbe5e987n%40googlegroups.com.
Mike Menci
Jan 30, 2024, 12:05:10 PM1/30/24
to ope...@googlegroups.com
Weyne 
This is a standard air hose M3 or M5 nippleÂ
AliExpress :Â
Sent from my iPhone
On 30 Jan 2024, at 20.59, Mike Menci <mike....@gmail.com> wrote:
My PnP has it this way - fixed tube - nozzle turns with stepper shaft (Nema8 stepper with full shaft)Â
Mike Menci
Jan 30, 2024, 12:05:35 PM1/30/24
to ope...@googlegroups.com
WeyneÂ
This is a standard air hose M3 or M5 nippleÂ
AliExpress :Â
Google !Â
MikeÂ
vespaman
Jan 30, 2024, 12:18:59 PM1/30/24
to OpenPnP
Wayne,
Yes, they are super tiny, and one have to be careful not to destroy the threads, since they are also soft.
The coupler, is that a China nockoff, or is it SMC or something the like?
Did you already run that coupler with your machine, or are you putting it together?
If so;
I know it is a bit hard to compare with your machine, since you are using much better drivers and higher Voltage, but anyway;
What acceleration and speed settings did you use (on rotation)?
 - Micael
mark maker
Jan 30, 2024, 12:40:55 PM1/30/24
to ope...@googlegroups.com
> Well, if you do it like that, then there's no difference to reversing it, by putting the coupler on the other end of the tube, which I intended to do. Both times the tube will twist equally much.
Maybe I misunderstand something.Â
The difference, IMHO, is that the rotation by the motor will directly be decoupled, i.e. it will turn freely. The tube is not twisted, because there is no friction that could transfer the rotation forces.
In the image (source/credit)
below, only the part marked red will rotate, the green parts and
the tube remain still (the tube must only flex with the Z
compression):
> If you put the coupler on the hollow axle, and then fixed the outer shell of the coupler to the motor body, you will not get any twist of the tube, only the Z. This is what I thought you meant. :-)
I don't understand. See above.
_Mark
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ffd7038a-ee2b-4c53-bade-824fb4382242n%40googlegroups.com.
Wayne Black
Jan 30, 2024, 12:50:54 PM1/30/24
to OpenPnP
@Micael,
Coupler; is from one of the aliexpress heads I bought. I just popped it off and put it on the chmt for comparison. Im changing my pneumatics to vacuum ejectors as I have compressed air and supposedly vacuum generation is uspposed to be instantaneous vs pumps that need to 'build' vacuum. I may be testing this today...
@Mark,
Mark, what you can't see, so wouldn't have any idea, is the chmt system has the solenoid valving at the head. I think Micael is refering to the nozzle end vs the valve end for the coupling.Â
Wayne Black
Jan 30, 2024, 12:59:28 PM1/30/24
to OpenPnP
To add to this as Im familiar with the chmt head/pneumatics AND IF I understand the end goal of allowing full rotation of the nozzle...
My .02;
Micaels original mechanical solution is the best all other things staying stock. The compromise being be AB rotation drag. A coupler will definitely rotate more freely because there is no nozzle runout to worry about if sealing is paramount. But as shown in my pics above ways much more. That said you can put the coupler on the solenoid end to mitigate weight on Zdrive.
vespaman
Jan 30, 2024, 1:01:34 PM1/30/24
to OpenPnP
If I put it like this;
If you fix one side of the coupler in a vice and the measure the friction, and then turn it around fix it on the other side in the vice, and measure the torque, you will get the same friction, right?
The friction of the coupler is the same on both sides.
This means that the same amount of force is needed if you turn it around.
So the tube will have meet the same rotational force, no matter where you put the coupler, and no matter how you turn it.
Or, like this;
>The tube is not
twisted, because there is no friction that could transfer the
rotation forces.
Where does the friction go then? There is exactly 0.006NM of friction that has to be consumed between the motor shaft and the tube. (SMC coupler data sheet).
 - Micael
vespaman
Jan 30, 2024, 1:11:26 PM1/30/24
to OpenPnP
Wayne, yes, I am also going for ejector, but only one, and prefabricating the vacuum in the room with compressor, and only have a small chamber inside the chmt, leaving the valves as they are on the chmt head.
(Are you going to change them as well?)
Looking forward to your findings! ;-)
 - Micael
Wayne Black
Jan 30, 2024, 1:35:05 PM1/30/24
to OpenPnP
If you fix one side of the coupler in a vice and the measure the friction, and then turn it around fix it on the other side in the vice, and measure the torque, you will get the same friction, right?
The friction of the coupler is the same on both sides.
This means that the same amount of force is needed if you turn it around.
So the tube will have meet the same rotational force, no matter where you put the coupler, and no matter how you turn it.
Well maybe on paper. But the rotational forces you're talking about are small and in the real world all things are not equal. Your initial post/solution for full sealing and full rotation doesn't account for the nozzle shaft runout. That runout acts as an additional force against motor rotation because the seal housing (youre 3d print) is firmly fixed to the motor itself. Couplers will suffer similar restrictions, tube bending and ect...
vespaman
Jan 30, 2024, 2:04:09 PM1/30/24
to OpenPnP
Wayne, yes, agree. And there's also slightly more mass on one side of the coupler. But it is easy to get tangled up if adding too many details, especially for us non-native English guys.
The quality of the coupler, while also having its issues, should be better, since it specifically optimized for low friction and probably has better materials int its seal. Also, the internal diameter of the couples is less afaict, so less surface-surface friction.
I think the main issue with my 3d printed solution, is that there's a limited amount of seals available in this size, so I had to pick what was available to me.
The ones I am getting, is the ones made for slower motion (up to 500 RPM), maybe I should have opted for the ones for higher speed, since they have 2 ball bearings instead of one.
But time will tell, which solution is the better - and I'll post my
results and solution in this thread. I think I may have to modify the
couplers in a few ways to suit me, and the mounting of them.
 - Micael
Wayne Black
Jan 30, 2024, 11:31:18 PM1/30/24
to OpenPnP
Micael,Â
I hope this doesn't derail you're initial topic, but if you're really interested speed/accuracy on the stock chmt head, you're time might be better spent on the pneumatics. I just did back to back test the oem chmt pump vs a HS15 venturi at 50psi. In a nut shell the venturi is about 10x faster in reaching stable vacuum and the vacuum is much more stable. I was never able to get Openpnp part detection via vac sense to work on my machine, now Im sure it will. I dunno how you're determining picks or not, but doing it via vac at time of pick vs running it over to the camera would also save a lot of time. All of this is just my exp, you mileage may vary...
I scoped this pretty quickly on the bench measuring the raw output of the vac sense board. The yellow is the analog and the blue is pump or solenoid.Â
mark maker
Jan 31, 2024, 3:23:35 AM1/31/24
to ope...@googlegroups.com
Like I said, maybe all of this is a misunderstanding 🙂. A picture says more than 100 words, so here it is:
The way I understand you plan to assemble it is like so, with the
decoupler at the top:
So the rotation forces must be transferred across a
snake-line/spiral of a flexible tube that is bent by Z
compression. I'm also assuming the bent tube will not be able to
rotate freely, the bend will be squishing against the backside of
the head or something, rotation needs to fight against the block,
i.e. the bend in the tube is forced to rotate in the material.
The friction I'm talking about happens inside the
material, i.e. the forces required to deform the tube that way.
Whereas when you simply attach the coupling to the hollow shaft,
the tube rotation remains static and it only needs to compress
with Z. By having a generous tube bend, possibly up and beyond the
head, these compression forces will also be much smaller than in
the clamped and short configuration above.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/411b0f32-e36a-406d-9f31-1b591efc6a1dn%40googlegroups.com.
vespaman
Jan 31, 2024, 3:55:34 AM1/31/24
to OpenPnP
Wayne,
I'm interested in everything! :-)
Waking up this morning, I was thinking, maybe I over complicated my planned "external vacuum" setup. Maybe it is better to to put the ejector inside the chmt, like you are going to do (if I understand you correctly).
I let my pump be always on, at a low PWM during work, and I am using the vacuum sensing (had to fix the smoothie port fw for this, since it was too slow), and it is working fine actually. But I guess a more even vacuum can never hurt!
This amateurish drawing is how I envisioned it half a year ago, when I got some parts for it; (I did learn about drawing stuff like this in school (long time ago), but I guess it did not stick).
Â
1. Compressor
2. Valve
3. Venturi/ejector
4. Digital vacuum meter
5. Large wine making "bottle" (don't know the English term for it, we use a French term Swedishified here)
(All of the above is in another room)
6. Vacuum limiter
7. Local "buffer"
8. Vac. meter
9. Valve, that is using the pump output of the controller.
Vacuum on the line between is higher than the little vacuum the PnP wants, regulated down with 6.
Looking at it now, I think I need another valve after 3, to keep the vacuum locked in.
My fear of putting the ejector inside the chmt, is the noise it produces. But maybe putting it in a small well-muffled box can be a solution. And it will only burst here and there I guess.
Is it necessary with a HS15? I got a HS10 when I picked parts.
Note 1; I'm also putting together a PnP for putting on labels on my products, which also needs vacuum, so that may make my original solution more attractive
Note 2; I am currently using compressed air from the compressor to blow my stencils clean - I know the professionals are sucking their stencils clean, which is something I would also like to do, since it will be cleaner. So also this needs vacuum.
But I'm leaning towards that maybe a "centralised vacuum" is still over-complicating things. It is also more tubes to mange in between rooms etc.
 - Micael
vespaman
Jan 31, 2024, 4:33:20 AM1/31/24
to OpenPnP
HI Mark,
Yes, I understand what you mean. And there's always different ways to skin a cat.
Had the chmt head been larger, and had it not been relying on a spring to pull it up, I agree that it would be better to put it on the motor shaft. (Or:- if it where for a slower machine setup in general)
But I think Wayne's picture shows that, the coupler sticking up like a flag pole (also a tube loop needs to be considered), will not make a good solution. There would ideally need to be some kind of support, otherwise there's significant stress on the flag poles base during my heads violent movements. It is also going to get very close to the "Z-wheels center screws" by the looks of it (colliding?).
What I intend to do, in order to avoid flag pole and weight on the motor, is like this;
Even when I draw it, scales are wrong. The coupler is huge compared to everything else. So I think I'll "modify it" so it blends and interfaces better to its position and connecting tubes.
Yes, this means that the tube will have some meandering, but this ought to be very little; compare with stock solution where up to at least 180deg twisting is accepted.
If the coupler has not begun to turn well before 180 degrees, I will be very disappointed by its performance and re-strategize. :-)
 - Micael
Wayne Black
Jan 31, 2024, 10:14:44 AM1/31/24
to ope...@googlegroups.com
Mark,
You're not misunderstanding and you do have it right.
Micael,
Your diagram is fine :). #5 and 7 are termed 'reservoir' in english. The proposed design does seem overly complicated though. I would have remote compressed air and feed it to local ejector systems; pnp, labeller, what ever...
I have both HS10 and HS15 on hand, I can get some baseline measurements if you like. My plan is to use the HS15 to keep psi < 50
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5486d0d5-3d3b-4e19-a57f-62450964f1d4n%40googlegroups.com.
vespaman
Jan 31, 2024, 11:21:20 AM1/31/24
to OpenPnP
Wayne,
The word I was looking for, is apparently "demijohn" or "carboy" in English. Nothing I ever used, so I thought finally I had a proper use for it. The one I have must be about 70 years old.
Anyway, I have actually no clue about how much/little vacuum I have on my machine, I think that if one has too much, small nozzle tips will be hard to monitor for vacuum level, so that is probably the first step - to see 'where I am at' before ripping it apart.
Maybe i shall take the opportunity to measure what I have on the nozzle tube to start with, since I am anyway working with it.
Given your time-to-vacuum test - is it your intention to run your ejector continuously while there's component on the nozzle(s)? (or will you also have a small reservoir as buffer?)
 - Micael
vespaman
Jan 31, 2024, 11:47:19 AM1/31/24
to OpenPnP
Couldn't resist it. Connected one of my digital meters to the nozzle tube, and got -78kPa, which sounds about right. This is at 40% PWM on the pump.
On your scope pic above, did you run your pump 100%?
 - Micael
Wayne Black
Jan 31, 2024, 12:13:56 PM1/31/24
to ope...@googlegroups.com
did you run your pump 100%?
-Yes
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e32e5e90-a4c9-45c8-8baa-607e064a5ec6n%40googlegroups.com.
Jan
Jan 31, 2024, 4:27:23 PM1/31/24
to ope...@googlegroups.com
Hi Wayne!
You're measurements suggests that the original pump could/should be
enhanced by adding a reservoir. I guess that already 100..250ml should
provide a significant advantage. Did you by change ever tried that?
Related question: how did you guys configured your dwell times? I tried
some numbers but that was more poking around in the fog. Currently I'm
quite happy with 40ms pick dwell time but your graphs suggest that I
shall use rather 250ms. However, I never measured all the delays and
jitter introduced by OpenPnP controlling smoothie controlling the valve.
Jan
On 31.01.2024 05:31, Wayne Black wrote:
> Micael,
> I hope this doesn't derail you're initial topic, but if you're really
> interested speed/accuracy on the stock chmt head, you're time might be
> better spent on the pneumatics. I just did back to back test the oem
> chmt pump vs a HS15 venturi at 50psi. In a nut shell the venturi is
> about 10x faster in reaching stable vacuum and the vacuum is much more
> stable. I was never able to get Openpnp part detection via vac sense to
> work on my machine, now Im sure it will. I dunno how you're determining
> picks or not, but doing it via vac at time of pick vs running it over to
> the camera would also save a lot of time. All of this is just my exp,
> you mileage may vary...
>
> I scoped this pretty quickly on the bench measuring the raw output of
> the vac sense board. The yellow is the analog and the blue is pump or
> solenoid.
> chmt venturi.pngchmt pump.png
> /The friction of the coupler is the same on both sides.
> /
> /This means that the same amount of force is needed if you turn
> it around./
> /So the tube will have meet the same rotational force, no matter
> where you put the coupler, and no matter how you turn it./
> /
> /
> /> Well, if you do it like that, then there's no
You're measurements suggests that the original pump could/should be
enhanced by adding a reservoir. I guess that already 100..250ml should
provide a significant advantage. Did you by change ever tried that?
Related question: how did you guys configured your dwell times? I tried
some numbers but that was more poking around in the fog. Currently I'm
quite happy with 40ms pick dwell time but your graphs suggest that I
shall use rather 250ms. However, I never measured all the delays and
jitter introduced by OpenPnP controlling smoothie controlling the valve.
Jan
On 31.01.2024 05:31, Wayne Black wrote:
> Micael,
> I hope this doesn't derail you're initial topic, but if you're really
> interested speed/accuracy on the stock chmt head, you're time might be
> better spent on the pneumatics. I just did back to back test the oem
> chmt pump vs a HS15 venturi at 50psi. In a nut shell the venturi is
> about 10x faster in reaching stable vacuum and the vacuum is much more
> stable. I was never able to get Openpnp part detection via vac sense to
> work on my machine, now Im sure it will. I dunno how you're determining
> picks or not, but doing it via vac at time of pick vs running it over to
> the camera would also save a lot of time. All of this is just my exp,
> you mileage may vary...
>
> I scoped this pretty quickly on the bench measuring the raw output of
> the vac sense board. The yellow is the analog and the blue is pump or
> solenoid.
>
>
> On Tuesday, January 30, 2024 at 11:04:09 AM UTC-8 micael....@gmail.com
> wrote:
>
> Wayne, yes, agree. And there's also slightly more mass on one side
> of the coupler. But it is easy to get tangled up if adding too many
> details, especially for us non-native English guys.
>
> The quality of the coupler, while also having its issues, should be
> better, since it specifically optimized for low friction and
> probably has better materials int its seal. Also, the internal
> diameter of the couples is less afaict, so less surface-surface
> friction.
> I think the main issue with my 3d printed solution, is that there's
> a limited amount of seals available in this size, so I had to pick
> what was available to me.
>
> The ones I am getting, is the ones made for slower motion (up to 500
> RPM), maybe I should have opted for the ones for higher speed, since
> they have 2 ball bearings instead of one.
>
> But time will tell, which solution is the better - and I'll post my
> results and solution in this thread. I think I may have to modify
> the couplers in a few ways to suit me, and the mounting of them.
>
> Â - Micael
> tisdag 30 januari 2024 kl. 19:35:05 UTC+1 skrev
> black...@blackboxembedded.com:
>
> /If you fix one side of the coupler in a vice and the measure
>
> On Tuesday, January 30, 2024 at 11:04:09 AM UTC-8 micael....@gmail.com
> wrote:
>
> Wayne, yes, agree. And there's also slightly more mass on one side
> of the coupler. But it is easy to get tangled up if adding too many
> details, especially for us non-native English guys.
>
> The quality of the coupler, while also having its issues, should be
> better, since it specifically optimized for low friction and
> probably has better materials int its seal. Also, the internal
> diameter of the couples is less afaict, so less surface-surface
> friction.
> I think the main issue with my 3d printed solution, is that there's
> a limited amount of seals available in this size, so I had to pick
> what was available to me.
>
> The ones I am getting, is the ones made for slower motion (up to 500
> RPM), maybe I should have opted for the ones for higher speed, since
> they have 2 ball bearings instead of one.
>
> But time will tell, which solution is the better - and I'll post my
> results and solution in this thread. I think I may have to modify
> the couplers in a few ways to suit me, and the mounting of them.
>
> Â - Micael
> tisdag 30 januari 2024 kl. 19:35:05 UTC+1 skrev
> black...@blackboxembedded.com:
>
> the friction, and then turn it around fix it on the other side
> in the vice, and measure the torque, you will get the same
> friction, right?
> /
> in the vice, and measure the torque, you will get the same
> friction, right?
> /The friction of the coupler is the same on both sides.
> /
> /This means that the same amount of force is needed if you turn
> it around./
> /So the tube will have meet the same rotational force, no matter
> where you put the coupler, and no matter how you turn it./
> /
> /
> difference to reversing it, by putting the coupler on
> the other end of the tube, which I intended to do./ Both
> times the tube will twist equally much.
>
> Maybe I misunderstand something.
>
> The difference, IMHO, is that the rotation by the motor
> will *directly *be decoupled, i.e. it will turn freely.
>
> Maybe I misunderstand something.
>
> The difference, IMHO, is that the rotation by the motor
> The tube is not twisted, because there is no friction
> that could transfer the rotation forces.
>
> In the image (source/credit
> <https://www.aliexpress.us/item/3256804211715767.html>)
> that could transfer the rotation forces.
>
> In the image (source/credit
> below, only the part marked red will rotate, the green
> parts and the tube remain still (the tube must only flex
> with the Z compression):
>
>
> /> If you put the coupler on the hollow axle, and then
> parts and the tube remain still (the tube must only flex
> with the Z compression):
>
>
> fixed the outer shell of the coupler to the motor body,
> you will not get any twist of the tube, only the Z. This
> is what I thought you meant. :-)/
> you will not get any twist of the tube, only the Z. This
>
> I don't understand. See above.
>
> _Mark
>
> On 30.01.2024 16:56, vespaman wrote:
>>
>> >You mean on the motor hollow *shafts*, right?
> I don't understand. See above.
>
> _Mark
>
> On 30.01.2024 16:56, vespaman wrote:
>>
>>
>> >I.e. the underside of the coupling turns with the
>> hollow shaft, the upper side with the tube stays (more
>> or less) put.
>>
>> >Something like this:
>>
>> Well, if you do it like that, then there's no
>> difference to reversing it, by putting the coupler on
>> the other end of the tube, which I intended to do.
>> Both times the tube will twist equally much. But by
>> putting it on the other end, there's no weight on the
>> motor.
>>
>> If you put the coupler on the hollow axle, and then
>> fixed the outer shell of the coupler to the motor
>> body, you will not get any twist of the tube, only the
>> Z. This is what I thought you meant. :-)
>>
>> Â - Micael
>>
>>
>> --
>> You received this message because you are subscribed
>> to the Google Groups "OpenPnP" group.
>> To unsubscribe from this group and stop receiving
>> emails from it, send an email to
>> openpnp+u...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/openpnp/ffd7038a-ee2b-4c53-bade-824fb4382242n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/ffd7038a-ee2b-4c53-bade-824fb4382242n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> >I.e. the underside of the coupling turns with the
>> hollow shaft, the upper side with the tube stays (more
>> or less) put.
>>
>> >Something like this:
>>
>> Well, if you do it like that, then there's no
>> difference to reversing it, by putting the coupler on
>> the other end of the tube, which I intended to do.
>> Both times the tube will twist equally much. But by
>> putting it on the other end, there's no weight on the
>> motor.
>>
>> If you put the coupler on the hollow axle, and then
>> fixed the outer shell of the coupler to the motor
>> body, you will not get any twist of the tube, only the
>> Z. This is what I thought you meant. :-)
>>
>> Â - Micael
>>
>>
>> --
>> You received this message because you are subscribed
>> to the Google Groups "OpenPnP" group.
>> To unsubscribe from this group and stop receiving
>> emails from it, send an email to
>> openpnp+u...@googlegroups.com.
>> To view this discussion on the web visit
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/openpnp/2927258a-4daa-4586-8680-62c1f6343c3cn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/2927258a-4daa-4586-8680-62c1f6343c3cn%40googlegroups.com?utm_medium=email&utm_source=footer>.
Wayne Black
Jan 31, 2024, 4:54:51 PM1/31/24
to OpenPnP
Hey Jan,
No I never tried the reservoir. I dont recall my particular dwell setttings, but I would turn the pump on/off per pick, not leave it on all time like it sounds Micael is doing. Do you leave the pump on all the time? I cant stand the buzzing of that thing and really quite happy to be getting rid of it.
My machine is basically a 36 in name only now. All the electronics are changed for duet. The head is different the pneumatics are different. The encloure and XY kinematics are the only chmt items now.Â
I need to do a build log, should I do it over on Desktop pnp group or do it here on Openpnp group?
vespaman
Jan 31, 2024, 4:58:02 PM1/31/24
to OpenPnP
Hi Jan,
Speaking for myself (obviously! :-) ), I am nowadays relying 100% on measured vacuum. But I have a fallback, probably around 40ms, that I don't think is ever reached (but don't study my logs on every pick though).
But as I wrote in some other thread, the Smoothie port, relying on "temp sensor code" for vacuum, only updates the vacuum every 50ms (so vacuum never where the limit, dwell time was always hit first), so I had to fix that.
I have my pump running throughout the job, though. (Hence I'm dead tired after a day running panels).
 - Micael
Jan
Feb 1, 2024, 3:09:46 AM2/1/24
to ope...@googlegroups.com
Hi Wayne!
Yes, I keep my vacuum pump running all the time while running a job
(Thanks to Mark that's nowadays easy to setup. Before, the first picks
of the day usually suffered from insufficient vacuum...) I think the
idea of a stable vacuum and just switched the connection to the nozzle
tips is faster and hence more valuable to me then the noise reduction by
switching the pump off between picks. I put my pump on rubber feeds
(https://www.amazon.com/Rubber-Absorber-Isolator-Vibration-Silentblock/dp/B0839GJ5D6/)
that helped. In addition I placed some absorbing material between table
and machine body to damp the vibrations.
From you measurements I think now that I should add a small reservoir
between pump and valves. 4x the air volume between valve and tip of the
nozzle tip is likely sufficient, 10x would be even better to damp the
drop in pressure when picking. This mod is easy to add and shall provide
a more reliable and faster picking.
Yes, I would love to read a build log of your machine. However, you
already mentioned so many modifications you did that I'll likely not
follow. I'm currently quite happy with the few modification I did,
except that I'd like to have a nozzle tip changer...
I'd say that this list is the better place for your build log. To my
understanding the Desktop pnp group is more for people trying to run
small commercial machines with commercial software while here you meet
people building their own machines.
Jan
> https://groups.google.com/d/msgid/openpnp/ffd7038a-ee2b-4c53-bade-824fb4382242n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/ffd7038a-ee2b-4c53-bade-824fb4382242n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/ffd7038a-ee2b-4c53-bade-824fb4382242n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/ffd7038a-ee2b-4c53-bade-824fb4382242n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
Yes, I keep my vacuum pump running all the time while running a job
(Thanks to Mark that's nowadays easy to setup. Before, the first picks
of the day usually suffered from insufficient vacuum...) I think the
idea of a stable vacuum and just switched the connection to the nozzle
tips is faster and hence more valuable to me then the noise reduction by
switching the pump off between picks. I put my pump on rubber feeds
(https://www.amazon.com/Rubber-Absorber-Isolator-Vibration-Silentblock/dp/B0839GJ5D6/)
that helped. In addition I placed some absorbing material between table
and machine body to damp the vibrations.
From you measurements I think now that I should add a small reservoir
between pump and valves. 4x the air volume between valve and tip of the
nozzle tip is likely sufficient, 10x would be even better to damp the
drop in pressure when picking. This mod is easy to add and shall provide
a more reliable and faster picking.
Yes, I would love to read a build log of your machine. However, you
already mentioned so many modifications you did that I'll likely not
follow. I'm currently quite happy with the few modification I did,
except that I'd like to have a nozzle tip changer...
I'd say that this list is the better place for your build log. To my
understanding the Desktop pnp group is more for people trying to run
small commercial machines with commercial software while here you meet
people building their own machines.
Jan
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "OpenPnP" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to openpnp+u...@googlegroups.com
> > <mailto:openpnp+u...@googlegroups.com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/openpnp/2927258a-4daa-4586-8680-62c1f6343c3cn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/2927258a-4daa-4586-8680-62c1f6343c3cn%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/2927258a-4daa-4586-8680-62c1f6343c3cn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/2927258a-4daa-4586-8680-62c1f6343c3cn%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> > --
> > You received this message because you are subscribed to the Google
> > Groups "OpenPnP" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to openpnp+u...@googlegroups.com
> > <mailto:openpnp+u...@googlegroups.com>.
> > To view this discussion on the web visit
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/openpnp/35fddefb-b345-4fe6-9043-637457209b9fn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/35fddefb-b345-4fe6-9043-637457209b9fn%40googlegroups.com?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
Jan
Feb 1, 2024, 3:18:42 AM2/1/24
to ope...@googlegroups.com
Hi Speed-Freak!
If you know, that you never hit the 40ms, why accept the jitter/delay
by measuring the same over and over again? If you take average values
from different nozzle tips you should be able to disentangle the
constant (tubing, nozzle related) part from the nozzle tip related part
using a linear fit and configure fixed dwell times. This can then be
executed by the controller without computer intervention already queuing
the next moves.
(I know, that pick retries are bound to part-on checks. However, speed
requires reliably picks without retries...)
Jan
PS: I guess we're turning your initial question into something
completely different. Maybe it would be a good idea to group vacuum
related stuff into a different topic...
> https://groups.google.com/d/msgid/openpnp/ffd7038a-ee2b-4c53-bade-824fb4382242n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/ffd7038a-ee2b-4c53-bade-824fb4382242n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/ffd7038a-ee2b-4c53-bade-824fb4382242n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/ffd7038a-ee2b-4c53-bade-824fb4382242n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
If you know, that you never hit the 40ms, why accept the jitter/delay
by measuring the same over and over again? If you take average values
from different nozzle tips you should be able to disentangle the
constant (tubing, nozzle related) part from the nozzle tip related part
using a linear fit and configure fixed dwell times. This can then be
executed by the controller without computer intervention already queuing
the next moves.
(I know, that pick retries are bound to part-on checks. However, speed
requires reliably picks without retries...)
Jan
PS: I guess we're turning your initial question into something
completely different. Maybe it would be a good idea to group vacuum
related stuff into a different topic...
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "OpenPnP" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to openpnp+u...@googlegroups.com
> > <mailto:openpnp+u...@googlegroups.com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/openpnp/2927258a-4daa-4586-8680-62c1f6343c3cn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/2927258a-4daa-4586-8680-62c1f6343c3cn%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/2927258a-4daa-4586-8680-62c1f6343c3cn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/2927258a-4daa-4586-8680-62c1f6343c3cn%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> > --
> > You received this message because you are subscribed to the Google
> > Groups "OpenPnP" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to openpnp+u...@googlegroups.com
> > <mailto:openpnp+u...@googlegroups.com>.
> > To view this discussion on the web visit
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/openpnp/8b8255f1-c986-4ac6-b175-bfe36ae5afd9n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/8b8255f1-c986-4ac6-b175-bfe36ae5afd9n%40googlegroups.com?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
vespaman
Feb 1, 2024, 10:21:04 AM2/1/24
to OpenPnP
Hi Jan,
OK, so I might loose some time in those polls.. :-)Â But are there a way to also include the paint marking thickness of the components in your mathematical formula? There's always a little leakage going on there, I'm sure!
Looking in a log sequence, there's typically 1 poll about every 500micro second.
Guess there's a lot of possibilities for improvement here! ;-) ;-)
It takes about 16ms to reach targeted vacuum (137) on a typical 0402 for me.
/ The freak
vespaman
Feb 10, 2024, 9:09:58 AM2/10/24
to OpenPnP
Hi all,
Just a little update, after a what felt like forever delivery time on my SMC rotary couplers, they finally arrived, so yesterday I adapted them to my machine.
Thought I should present some pictures, in addition to my crappy white board sketch :-)
What I did, was to remove the original plastic with a dremel, and replaced it with one of my own. Reason behind this was to reduce the over all size of the solution.
(The smallest rotary coupler was made for 4mm tube, whereas the chmt has 3mm, and also on the screw end (M5) needed to be adapted (here I just printed a M5 to 3mm tube adapter)).
It was a bit tricky to remove the original plastic, but fortunately, even the super tiny seal where unharmed. I used a drill press to press on my own printed housing.
So the result, with only the right one mounted, left side still original chmt.
Initial impression is that this will work. Yes, there is some meandering going on when turning - about on par with the original twisting.
I used the original silicone tube, which has become formed by its static bend over the years. I guess if I changed it to a new one, some less meandering would happen, but I don't think this is an issue really. I should get some tube anyway, since I think it is a little bit too long now, but I don't dare to cut it without being able to go back.
Tests shows no missed steps with full speed and acceleration (100000/120000).
I have held off running some needed 100 boards, just to make sure there's no unforeseen issue with this setup, before I can write this problem off.
I'll post some short video once I have done the next batch.
 - Micael
Wayne Black
Feb 10, 2024, 11:59:50 AM2/10/24
to OpenPnP
Hi Sir Speedy :)
Glad you found a workable solution for yourself. Do you plan on ever using the chmt head cover again? I think you may run into trouble if you do. And I f you do you never be able to use poly air tubing that won't 'meander'.
Another note, On my machine, before the head upgrade, the homing of AB was done via M18 in Duet/RRF. In essence M18 disables the AB steppers and the silicone tubes torsion-ally 'unwinds' bringing the stepper rotation back to its initial position from power up. I don't know if you're doing similar on you machine, but if so is now mute given the 'free' rotation...
vespaman
Feb 10, 2024, 1:34:50 PM2/10/24
to OpenPnP
Hi Wayne,
I don't think I'll put the head cover on, no. I never liked it, because it already with the original setup made the nozzle tubes less free. And also I absolutely hate the color. :-) Plus, it steel, 200grams, trapping heat from the steppers.
But, having said that, I tried it on to see if it still fits, and afaict, it looks to be working?
The meandering is not too much as is. In fact, I think after testing more since my last update, most of it comes from the bend it has acquired over the years, not so much the friction of the coupler. This also means that they still go back to the same "resting position" with motors off, to which they have always had. Force of habit! :-)Â
But yes, this is not really needed any longer.
I wonder if this is really a silicone tube, or some blend? The surface feels like silicone, but it is rather stiff.
I think I'll FDM print a breathing "net like", light-weight cover, using the same grey filament that I printed the front cover in, at some point. But this is pretty far down the never ending todo list - I have gotten used to seeing my machine without the head cover.
 - Micael
Jan
Apr 4, 2024, 3:06:33 PM4/4/24
to OpenPnP
Hi Mark!
May I ask in this context for your help in understanding the OpenPnP code in more details?
As discussed, I'm currently implementing the nozzle pre-rotation feature using your suggestion's. Everything seems to work so fare except the merging of AxisLocations. While digging in the code, I found, that AxisLocations can have any number of axis. I also found that moveTo() in ReferenceHead.java (line 152) converts a Location into an AxisLocation referencing only the relevant four axis. However moveTo() in AbstractMotionPlanner.java (line 149) converts this four axis AxisLocation into an eight axis AxisLocation referencing any axis my machine has. This makes it not obvious to merge with other AxisLocations later. Would you please advice how merging shall be implemented? I see two solutions: 1) not blow it up from four to eight axis in the first place and use a simple AxisLocation.put() or 2) detect for any axis if newLocation and currentLocation are different assuming that an axis is unused if its location does not change and taking all changed axis into a new AxisLocation.
Jan
Jan schrieb am Dienstag, 30. Januar 2024 um 10:09:10 UTC+1:
Thank You very much, Mark! Thats exactely what I was looking for and
what I'm intending to add. We'll then see if the driver rotates all
nozzles on the long moves...
Jan
On 29.01.2024 15:12, 'mark maker' via OpenPnP wrote:
> /> @Mark: how would one request additional movements at the
> AsyncGCodeDriver? MoveTo() only provides arguments for four axis. Are
> shared rotation situations handled automatically by the AsyncGCodeDriver
> or would that have to be done by the caller?/
>
> Yes, OpenPnP has the *Location* data type which is X, Y, Z, C only
> (4-axis).
>
> But underneath, since I implemented Advanced Motion Control, it is all
> managed in *AxesLocation*, which supports an arbitrary number of axes.
>
> Furthermore, motion is never immediately executed. Instead the motion
> sequence is added to the motion planner. Only when the situation
> requires motion to be complete (for instance when we want to take a
> camera shot), then we tell the planner that we need to wait for motion
> completion. This in turn forces the motion to actually being processed
> and ultimately sent to controllers. The planner can do arbitrary
> optimization to the path and also distribute and coordinate the motion
> commands across multiple drivers, in parallel. Remember, it actually can
> do Motion Blending
> <https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-blending>
> and other cool stuff (if only the controllers and serial interfaces were
> fast enough 😕).
>
> AdvancedMotionAnimation
>
> To move in more than 4 axes at a time, one would need to implement a
> new*MotionOption.Subordinate*, added here:
>
> https://github.com/openpnp/openpnp/blob/develop/src/main/java/org/openpnp/model/Motion.java#L55
>
> But instead of adding a new motion segment, it would have accumulate
> AxesLocation coordinates to the*previous* motion target, but never
> change axes that were already there. Somewhere here:
>
> https://github.com/openpnp/openpnp/blob/dd58cf65b0465b426bef8ebd7b87cc7b767ddf7f/src/main/java/org/openpnp/machine/reference/driver/AbstractMotionPlanner.java#L407
>
> But that is complicated by things such as backlash compensation. I.e. it
> would have to undo not only the last but also the second to last motion
> segment.
>
> https://github.com/openpnp/openpnp/blob/dd58cf65b0465b426bef8ebd7b87cc7b767ddf7f/src/main/java/org/openpnp/machine/reference/driver/AbstractMotionPlanner.java#L384-L403
>
> Usage in JobProcessor code (pseudo code off the top of my head):
>
> currentPlacement.nozzle.moveTo(currentPlacement.targetLocationOfStep);
>
> for each (upcomingPlacement : upcomingPlacements) {
> upcomingPlacement.nozzle.moveTo(upcomingPlacement.targetLocationOfStep,*MotionOption.Subordinate*);
> }
>
>
> _Mark
>
>
> On 29.01.2024 14:20, 'Jan' via OpenPnP wrote:
>> Hi Micael!
>> Â Â Â Â Interesting mod you did!
>> Â Â Â Â As Mark says, the JobProcessor handles nozzles in series. On the
>> way to the first pick location, there is a lot of time to perform any
>> rotation needed. The same on the way from pick to align. But for the
>> second (and any other) nozzle the distance might be quite short and
>> hence limited by the rotation. So if you have a polarized part, the
>> penalty at alignment is still there (depending on pick, pre-rotate
>> setting and place orientation).
>> Â Â Â Â @Mark: how would one request additional movements at the
>> AsyncGCodeDriver? MoveTo() only provides arguments for four axis. Are
>> shared rotation situations handled automatically by the
>> AsyncGCodeDriver or would that have to be done by the caller?
>> Â Â Â Â From my current understanding of the JobProcessor everything is -
>> in theory - there: it's a question if special care for shared rotation
>> machines has to be added and where the usual move-to-safe-z is
>> happening (are the rotation information for other nozzles available at
>> safe-z or not?)
>>
>> Â Â Â Â Jan
>>
>> On 29.01.2024 11:53, vespaman wrote:
>>> Â >But as I said, it would have to peek ahead in the Job Processor,
>>> and that's not too easy...
>>>
>>> Yes, that indeed sounds very complicated to add on. And, at least
>>> from the point of feeders, I suspect that most machines with not 2
>>> nozzles already have a solution for free rotation. And for the rest
>>> of us we can always change this when needed.
>>> So from that perspective, the lower hanging fruit with the "polarity
>>> does not matter" is worth more imo, since it will help all set-ups to
>>> some extent, lessen the worst case 180deg scenario.
>>> (Also during alignment, I suspect, as well as components that does
>>> not handle rotation well in general - e.g. those tact switches that
>>> can swivel because the key top is not fixated very securely to the
>>> body).
>>>
>>> (I suppose a parallel rotation for alignment over up looking camera
>>> issues might be easier to solve, looking at it isolated (?), since by
>>> then, the components/rotation should be known)
>>>
>>> Â Â - Micael
>>> måndag 29 januari 2024 kl. 10:49:19 UTC+1 skrev ma...@makr.zone:
>>>
>>> Â Â Â /> If I understood you correctly, the logic behind the rotation is
>>> Â Â Â that it is not started until the move to the pick location is
>>> Â Â Â started(?).
>>> Â Â Â /
>>>
>>> Â Â Â Yes.
>>>
>>> Â Â Â (I'm also explaining for those reading along:)
>>>
>>> Â Â Â For the first nozzle that is usually okay, as it is moving from the
>>> Â Â Â last placement location. i.e. a rather long move where rotation can
>>> Â Â Â take place in parallel. However, for the second nozzle, this is just
>>> Â Â Â the move from one feeder pick location to the other feeder pick
>>> Â Â Â location, those can be close together, and if you have two
>>> Â Â Â compatible nozzle tips it might even be from the same feeder, so the
>>> Â Â Â move is only the between-nozzles offset (plus/minus 2mm for 0402),
>>> Â Â Â i.e., not enough time to rotate.
>>>
>>> Â Â Â The same happens in Alignment, above the bottom camera.
>>>
>>> Â Â Â Technically, if you have two independent rotation motors on the
>>> Â Â Â nozzles (as most machines have), OpenPnP could rotate the second
>>> Â Â Â nozzle in parallel with the first nozzle, i.e., while moving to the
>>> Â Â Â feeders/bottom camera. Advanced Motion Control actually *can* do
>>> Â Â Â that (it wasn't possible before). But as I said, it would have to
>>> Â Â Â peek ahead in the Job Processor, and that's not too easy...
>>>
>>> Â Â Â _Mark
>>>
>>> Â Â Â On 29.01.2024 10:07, vespaman wrote:
>>>>
>>>> Â Â Â 1. OK, I will not hold my breath! :-)
>>>> Â Â Â 2. Yes, I think you mentioned this in another thread. I know all
>>>> Â Â Â about time (the lack of) :-) so I am no holding my breath here
>>>> Â Â Â either. But I agree that this would be very nice.
>>>>
>>>> Â Â Â Today I decided I needed to do some tests, to get at least some
>>>> Â Â Â feeling what can be achieved, and got to think about the motion
>>>> Â Â Â planner test, I am not sure if this is similar motion, but if it
>>>> Â Â Â is, it is very useful for testing the consequences of the rotation.
>>>> Â Â Â Moving 2mm without rotation takes about 90ms. With rotation 90 to
>>>> Â Â Â -90 (and 100000/2000 acc/feedrate), same operation takes ~170ms as
>>>> Â Â Â per the result of the motion planner test.
>>>>
>>>> Â Â Â If I understood you correctly, the logic behind the rotation is
>>>> Â Â Â that it is not started until the move to the pick location is
>>>> Â Â Â started(?).
>>>> Â Â Â So I also tested a move from end of drag to first nozzle, first
>>>> Â Â Â pick location, to see if also that where also held back by the
>>>> Â Â Â rotation.
>>>> Â Â Â This is a slightly longer move that involves both x and y.
>>>> Â Â Â Move without rotation: ~125ms. With also rotation 90 to -90,
>>>> ~170ms.
>>>>
>>>> Â Â Â So, if this test is indicative to real life, it makes me think the
>>>> Â Â Â total rotation "cost" on this double pick is around 130ms, which
>>>> Â Â Â is not insignificant.
>>>>
>>>> Â Â Â Incidentally, today, I tried yanking up the acc/feedrate with the
>>>> Â Â Â cups mounted. And it looked (by the eye) to be working just fine
>>>> Â Â Â for some reason. Not sure if it really holds together in real life
>>>> Â Â Â though.
>>>> Â Â Â I suppose the only way to know if I'll be loosing steps, is to run
>>>> Â Â Â a job. That could be a nightmare. :-o
>>>> Â Â Â I probably should setup some test job instead, so I don't have to
>>>> Â Â Â spend half a day to correct 0402 on real boards.
>>>>
>>>> Â Â Â Â - Micael
>>>>
>>>>
>>>>    måndag 29 januari 2024 kl. 09:05:18 UTC+1 skrev ma...@makr.zone:
>>>>
>>>> Â Â Â Â Â Â Â /> Main scenario is that I want the second nozzle pick, to
>>>> Â Â Â Â Â Â Â pick as soon as possible. With original, the chmt has a
>>>> Â Â Â Â Â Â Â silicon tube that does not allow free articulation, so the
>>>> Â Â Â Â Â Â Â nozzles have to rotate before picking. The cups let's the
>>>> Â Â Â Â Â Â Â motor rotate freely, so with the settings above, the second
>>>> Â Â Â Â Â Â Â nozzle pick can just pick, regardless of its current angle/
>>>>
>>>> Â Â Â Â Â Â Â Ah, I understand, thanks. For those reading along, he is
>>>> Â Â Â Â Â Â Â tlking about Rotation Mode:
>>>>
>>>> https://github.com/openpnp/openpnp/wiki/Nozzle-Rotation-Mode
>>>> <https://github.com/openpnp/openpnp/wiki/Nozzle-Rotation-Mode>
>>>>
>>>> Â Â Â Â Â Â Â Specifically the Minimal Rotation
>>>> <https://github.com/openpnp/openpnp/wiki/Nozzle-Rotation-Mode#rotation-modes> mode.
>>>>
>>>> Â Â Â Â Â Â Â I can't say if this will "pay" in the end, if you have to
>>>> Â Â Â Â Â Â Â reduce acceleration rates as a trade-off due to friction. As a
>>>> Â Â Â Â Â Â Â matter of fact, there is another rotation in the Alignment
>>>> Â Â Â Â Â Â Â step (assuming "pre-rotate", as you should). So it is unclear
>>>> Â Â Â Â Â Â Â which is worse in the end.
>>>>
>>>> Â Â Â Â Â Â Â Clearly, OpenPnP has potential for optimization too (to avoid
>>>> Â Â Â Â Â Â Â the cups and friction):
>>>>
>>>> Â Â Â Â Â Â Â Â 1. By looking ahead and rotating /both/ nozzles while moving
>>>> Â Â Â Â Â Â Â Â Â Â Â to the (first nozzle) pick location, and/or while moving
>>>> Â Â Â Â Â Â Â Â Â Â Â back to Alignment. In fact it was one of my goals to allow
>>>> Â Â Â Â Â Â Â Â Â Â Â moving more than three axes at the same time when doing
>>>> Â Â Â Â Â Â Â Â Â Â Â Advanced Motion Control, so that part would actually be
>>>> Â Â Â Â Â Â Â Â Â Â Â ready. But that kind of "looking ahead" is *not* how the
>>>> Â Â Â Â Â Â Â Â Â Â Â JobProcessor currently works, so don't hold your breath.
>>>> Â Â Â Â Â Â Â Â 2. A more low hanging fruit would be a "polarity does not
>>>> Â Â Â Â Â Â Â Â Â Â Â matter" switch on the Package. So OpenPnP could take /any/
>>>>            rotation modulo 180°, effectively halving the average
>>>> Â Â Â Â Â Â Â Â Â Â Â rotation for those parts, or even more, as we have
>>>>            placement angles in 90° increments and two are halved, and
>>>> Â Â Â Â Â Â Â Â Â Â Â one is even zeroed. And as those parts (resistors, ceramic
>>>> Â Â Â Â Â Â Â Â Â Â Â caps) are typically the most numerous in a job, this could
>>>> Â Â Â Â Â Â Â Â Â Â Â actually end up helping quite a lot. If only I had more
>>>> Â Â Â Â Â Â Â Â Â Â Â spare time...
>>>>
>>>> Â Â Â Â Â Â Â _Mark
>>>>
>>>> Â Â Â Â Â Â Â On 28.01.2024 19:03, vespaman wrote:
>>>>> Â Â Â Â Â Â Â >This is all automatic with I&S. Don't worry, you surely
>>>>> Â Â Â Â Â Â Â already have it.
>>>>> Â Â Â Â Â Â Â OK, good!
>>>>>
>>>>> Â Â Â Â Â Â Â >Frankly, I don't really understand your scenario and how
>>>>> Â Â Â Â Â Â Â these 3D printed cups are supposed to improve the situation?
>>>>>
>>>>> Â Â Â Â Â Â Â Main scenario is that I want the second nozzle pick, to pick
>>>>> Â Â Â Â Â Â Â as soon as possible. With original, the chmt has a silicon
>>>>> Â Â Â Â Â Â Â tube that does not allow free articulation, so the nozzles
>>>>> Â Â Â Â Â Â Â have to rotate before picking.
>>>>> Â Â Â Â Â Â Â The cups let's the motor rotate freely, so with the settings
>>>>> Â Â Â Â Â Â Â above, the second nozzle pick can just pick, regardless of
>>>>> Â Â Â Â Â Â Â its current angle, only need to wait for the 4mm X-move
>>>>> Â Â Â Â Â Â Â (without turning the nozzle), if I understand everything
>>>>> Â Â Â Â Â Â Â correctly. So we don't have to wait for the nozzle turning
>>>>> Â Â Â Â Â Â Â prior to pick.
>>>>> Â Â Â Â Â Â Â (This is 0402 on a ref push pull feeder, with both pockets
>>>>> Â Â Â Â Â Â Â open, both nozzle picks from the same feeder)
>>>>>
>>>>>
>>>>> Â Â Â Â Â Â Â Â -Â Micael
>>>>>
>>>>> Â Â Â Â Â Â Â -- Â Â Â Â Â Â Â You received this message because you are
>>>>> subscribed to the
>>>>> Â Â Â Â Â Â Â Google Groups "OpenPnP" group.
>>>>> Â Â Â Â Â Â Â To unsubscribe from this group and stop receiving emails from
>>>>> Â Â Â Â Â Â Â it, send an email to openpnp+u...@googlegroups.com.
>>>>> Â Â Â Â Â Â Â To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/openpnp/887b5286-af61-4d13-ba7b-9478bfbe18fbn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/887b5286-af61-4d13-ba7b-9478bfbe18fbn%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>>
>>>> Â Â Â -- Â Â Â You received this message because you are subscribed to
>>>> the Google
>>>> Â Â Â Groups "OpenPnP" group.
>>>> Â Â Â To unsubscribe from this group and stop receiving emails from it,
>>>> Â Â Â send an email to openpnp+u...@googlegroups.com.
>>>> Â Â Â To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/openpnp/577793b0-e71e-4c42-95c6-01daa5cbdc50n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/577793b0-e71e-4c42-95c6-01daa5cbdc50n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "OpenPnP" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to openpnp+u...@googlegroups.com
>>> <mailto:openpnp+u...@googlegroups.com>.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/openpnp/c5747ae8-2190-4f05-abb2-03e5fb152f5bn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/c5747ae8-2190-4f05-abb2-03e5fb152f5bn%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
mark maker
Apr 5, 2024, 7:21:10 AM4/5/24
to ope...@googlegroups.com
Maybe you should open a new thread for this. 😉
Regarding the merging:
Good question. I haven't thought this out.Â
Maybe we need to reverse it like so:
Usage in JobProcessor would be the other way around:
for each (upcomingPlacement : upcomingPlacements) {
upcomingPlacement.nozzle.moveTo(upcomingPlacement.targetLocationOfStep, MotionOption.Subordinate);
}
currentPlacement.nozzle.moveTo(currentPlacement.targetLocationOfStep);
Then in the AbstractMotionPlanner.moveTo() if the MotionOpen.Subordinate is given, you only record the subordinate location temporarily. Only record the subordinate axis-coordinates that have changed vs. currentLocation. Do not really plan the motion yet, i.e., stop after simply storing the subordinate location in the AbstractMotionPlanner.
Multiple calls with MotionOpen.Subordinate are combined by
AxesLocation.put() into the temporary subordinate location. NOTE:
machines with shared Z or C axes might overwrite the same physical
axis multiple times. You have to decide which one wins: the first
or last caller i.e. which is to be the left or right argument of
put().
Then when the next non-subordinate moveTo() comes, you take the subordinate location and put() it into the newLocation and then put() the new non-subordinate axesLocation on top.Â
Then also reset the recorded subordinate location, so it starts empty for the next round.
Note this also solves the backlash compensation problem, as it comes before it is even determined.
Much cleaner like that! 😎
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/00bdd901-f11e-44c7-87d6-af13bbf5a874n%40googlegroups.com.
Jan
Apr 11, 2024, 9:32:07 AM4/11/24
to ope...@googlegroups.com
Hi Mark!
I'm digging deeper into the mud and found some new issues, I'd like to
discuss: at present I've implemented pre-rotation as separate steps in
the job processor located between optimization and actual execution. For
picking the pre-rotation is therefore executed even before the feed,
which is nice, because under the assumption, that the move from place to
pick or feed is much longer then from feed to pick, this is efficient.
However, for ReferencePushPullFeeder used as drag feeders, the feed
operation resets the additional rotation axis in line 422 (I've
configured my peeler as such, with additive rotation). This trigger - in
my current implementation - a "subordinated motion queue not empty"
warning, which voids the pre-rotation. Could we move this to the end of
the feed operation or handle the reset asynchronously as this axis is
never used elsewhere and it's safe to reset it at any time?
Jan
On 05.04.2024 13:21, 'mark maker' via OpenPnP wrote:
> Maybe you should open a new thread for this. 😉
>
> Regarding the merging:
>
> Good question. I haven't thought this out.
>
> Maybe we need to reverse it like so:
>
> Usage in JobProcessor would be the other way around:
>
> for each (upcomingPlacement : upcomingPlacements) {
> upcomingPlacement.nozzle.moveTo(upcomingPlacement.targetLocationOfStep,*MotionOption.Subordinate*);
>> https://groups.google.com/d/msgid/openpnp/887b5286-af61-4d13-ba7b-9478bfbe18fbn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/887b5286-af61-4d13-ba7b-9478bfbe18fbn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/887b5286-af61-4d13-ba7b-9478bfbe18fbn%40googlegroups.com?utm_medium=email&utm_source=footer>>.
I'm digging deeper into the mud and found some new issues, I'd like to
discuss: at present I've implemented pre-rotation as separate steps in
the job processor located between optimization and actual execution. For
picking the pre-rotation is therefore executed even before the feed,
which is nice, because under the assumption, that the move from place to
pick or feed is much longer then from feed to pick, this is efficient.
However, for ReferencePushPullFeeder used as drag feeders, the feed
operation resets the additional rotation axis in line 422 (I've
configured my peeler as such, with additive rotation). This trigger - in
my current implementation - a "subordinated motion queue not empty"
warning, which voids the pre-rotation. Could we move this to the end of
the feed operation or handle the reset asynchronously as this axis is
never used elsewhere and it's safe to reset it at any time?
Jan
On 05.04.2024 13:21, 'mark maker' via OpenPnP wrote:
> Maybe you should open a new thread for this. 😉
>
> Regarding the merging:
>
> Good question. I haven't thought this out.
>
> Maybe we need to reverse it like so:
>
> Usage in JobProcessor would be the other way around:
>
> for each (upcomingPlacement : upcomingPlacements) {
> }
>
> currentPlacement.nozzle.moveTo(currentPlacement.targetLocationOfStep);
>
> Then in the AbstractMotionPlanner.moveTo()
> <https://github.com/openpnp/openpnp/blob/dd58cf65b0465b426bef8ebd7b87cc7b767ddf7f/src/main/java/org/openpnp/machine/reference/driver/AbstractMotionPlanner.java#L149> if the MotionOpen.Subordinate is given, you only record the subordinate location temporarily. Only record the subordinate axis-coordinates that have changed vs. currentLocation. Do not really plan the motion yet, i.e., stop after simply storing the subordinate location in the AbstractMotionPlanner.
>
> currentPlacement.nozzle.moveTo(currentPlacement.targetLocationOfStep);
>
> Then in the AbstractMotionPlanner.moveTo()
>
> Multiple calls with MotionOpen.Subordinate are combined by
> AxesLocation.put() into the temporary subordinate location. NOTE:
> machines with shared Z or C axes might overwrite the same physical axis
> multiple times. You have to decide which one wins: the first or last
> caller i.e. which is to be the left or right argument of put().
>
> Then when the next _non_-subordinate moveTo() comes, you take the
> Multiple calls with MotionOpen.Subordinate are combined by
> AxesLocation.put() into the temporary subordinate location. NOTE:
> machines with shared Z or C axes might overwrite the same physical axis
> multiple times. You have to decide which one wins: the first or last
> caller i.e. which is to be the left or right argument of put().
>
> subordinate location and put() it into the newLocation and then put()
> the new _non_-subordinate axesLocation on top.
>> >>>>
>> >>>> Â Â Â -- Â Â Â You received this message because you are
>> subscribed to
>> >>>> the Google
>> >>>> Â Â Â Groups "OpenPnP" group.
>> >>>> Â Â Â To unsubscribe from this group and stop receiving emails
>> from it,
>> >>>> Â Â Â send an email to openpnp+u...@googlegroups.com.
>> >>>> Â Â Â To view this discussion on the web visit
>> >>>>
>> https://groups.google.com/d/msgid/openpnp/577793b0-e71e-4c42-95c6-01daa5cbdc50n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/577793b0-e71e-4c42-95c6-01daa5cbdc50n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/577793b0-e71e-4c42-95c6-01daa5cbdc50n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>> >>>> Â Â Â -- Â Â Â You received this message because you are
>> subscribed to
>> >>>> the Google
>> >>>> Â Â Â Groups "OpenPnP" group.
>> >>>> Â Â Â To unsubscribe from this group and stop receiving emails
>> from it,
>> >>>> Â Â Â send an email to openpnp+u...@googlegroups.com.
>> >>>> Â Â Â To view this discussion on the web visit
>> >>>>
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the
>> Google
>> >>> Groups "OpenPnP" group.
>> >>> To unsubscribe from this group and stop receiving emails from it,
>> >>> send an email to openpnp+u...@googlegroups.com
>> >>> <mailto:openpnp+u...@googlegroups.com>.
>> >>> To view this discussion on the web visit
>> >>>
>> https://groups.google.com/d/msgid/openpnp/c5747ae8-2190-4f05-abb2-03e5fb152f5bn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/c5747ae8-2190-4f05-abb2-03e5fb152f5bn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/c5747ae8-2190-4f05-abb2-03e5fb152f5bn%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>> >>> --
>> >>> You received this message because you are subscribed to the
>> >>> Groups "OpenPnP" group.
>> >>> To unsubscribe from this group and stop receiving emails from it,
>> >>> send an email to openpnp+u...@googlegroups.com
>> >>> <mailto:openpnp+u...@googlegroups.com>.
>> >>> To view this discussion on the web visit
>> >>>
>> >>
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "OpenPnP" group.
>> > To unsubscribe from this group and stop receiving emails from
>> it, send
>> > an email to openpnp+u...@googlegroups.com
>> > <mailto:openpnp+u...@googlegroups.com>.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/openpnp/f6b32990-8537-4472-8b45-b8de7756fd95%40makr.zone <https://groups.google.com/d/msgid/openpnp/f6b32990-8537-4472-8b45-b8de7756fd95%40makr.zone?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/f6b32990-8537-4472-8b45-b8de7756fd95%40makr.zone?utm_medium=email&utm_source=footer>>.
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "OpenPnP" group.
>> > To unsubscribe from this group and stop receiving emails from
>> it, send
>> > an email to openpnp+u...@googlegroups.com
>> > <mailto:openpnp+u...@googlegroups.com>.
>> > To view this discussion on the web visit
>> >
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "OpenPnP" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to openpnp+u...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/openpnp/00bdd901-f11e-44c7-87d6-af13bbf5a874n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/00bdd901-f11e-44c7-87d6-af13bbf5a874n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> --
>> You received this message because you are subscribed to the Google
>> Groups "OpenPnP" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to openpnp+u...@googlegroups.com.
>> To view this discussion on the web visit
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/openpnp/a4fef4f6-f005-4de2-a5a0-5ab9d645d750%40makr.zone <https://groups.google.com/d/msgid/openpnp/a4fef4f6-f005-4de2-a5a0-5ab9d645d750%40makr.zone?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
mark maker
Apr 14, 2024, 10:06:18 AM4/14/24
to ope...@googlegroups.com
I'll answer in the new thread 😉
On 11.04.2024 15:32, 'Jan' via OpenPnP
wrote:
Hi Mark!
vespaman
Aug 24, 2024, 11:36:42 AM8/24/24
to OpenPnP
Hi all,
I was on the fence, if I should start a new thread, or recycle this one.. But I stumbled into something that does not make sense to me, so I need to ventilate.
Probably you are all still on vacation, but who knows. :-)
Here's the thing;Â
Today I needed to prepare my machine for a small "emergency" batch of only 5 panels. And in doing so, I for some reason slowed down the machine to 25%, and was stepping through a job, when I saw that the nozzle turns before picking up a part. I thought this should not be the case, as I have unchecked "limit to range" on axis C1/C2, and have "Minimal Rotation" on the Nozzles.
(I also have "align with part" as well as "wrap around" selected)
I simply have one component, that I am testing with, so I start a job, with only this component non-populated, step to pick/place, using nozzle 1. While placing it is rotating the component 90deg correctly, and then finishes the job.
But:- on every second job (restarting the same job), the nozzle is rotated 180deg (by the looks of it) before picking up this component. The next time I run the job, it will not. And so on. I guess this is somehow related to the fact that the component is rotating 90deg (as it should) on placing, and hence the nozzle is left in different angles, finishing the job.
What am I missing? Why this extra rotation?
 - Micael
0 new messages