Nozzle rotation acceleration vs free articulation?

[vespaman]

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".

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]

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]

> 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]

>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]

> 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):

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

--
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]

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]

> 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]

>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]

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

>> /> 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/

>>> 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>.

[vespaman]

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]

> @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:

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

[mark maker]

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]

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]

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]

>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]

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]

Thanks for checking!

You have me convinced, that I need to prioritize getting them then instead, or as a parallel thing.

 -  Micael

[vespaman]

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]

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]

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*);

> 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>.

[Jan]

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

> only after having done the drag, but that may have been the wrong
> assumption.
>

Yes, the JobProcessor currently executes everything sequentially. As
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]

> 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.

->wait for vacuum.

 - Micael

[vespaman]

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]

> 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]

> 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]

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.

If indeed the friction is as high as this, then I can always come back to my own 3d printed cups.

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]

>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]

> 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]

> 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]

>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]

>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]

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]

My PnP has it this way - fixed tube - nozzle turns with stepper shaft (Nema8 stepper with full shaft) 

https://grabcad.com/library/modification-of-full-shaft-stepper-nema-8-chamber-for-pnp-vacuum-1

Sent from my iPhone

On 30 Jan 2024, at 20.05, vespaman <micael....@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/80f2145f-7b32-42d5-b8e7-09bbdbe5e987n%40googlegroups.com.

[Mike Menci]

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)