Case study from last run (speed)

[vespaman]

So while looking into my notes from last run, one of the points was to investigate the overall performance (basically CPH). But the final CPH is a bit random, since it depends on so much (like how far away the feeders are, and if there are special settings on speed for larger components, and perhaps mostly, how many nozzle changes are done (and how quickly), and any kind of stops/pauses.

So I did a case study on  a 0402 cycle (I have  a 2-nozzle chmt), that is, involving both nozzles populating their components.

I have vision after every feed, and in this case the feed happens between nozzle pick one and two (both nozzle tips are 502, increase speed). I feel that a cycle starting with feed is a small bit faster, than when the feed happens between the picks. But life is not always perfect, so I settled for this case.

The part picked, comes from a feeder in the middle of the left bank (ref. pushpull feeder), so also here not the closest, but also not the furthest away).

If I understand the logs correctly, I get in the order of;

(starting after a previous place, so first figure is a bit random of course)

Nozzle one loaded: ~500ms

Feed -> ~1,1 second (!)*

Sprocket hole vision: ~420ms

Nozzle two loaded: ~390ms

Move to upcamera, nozzle 1: ~600ms

Part alignment nozzle 1: ~200ms

Move to upcamera, nozzle 2: ~300ms

Part alignment nozzle 2: ~210ms

Part placed, nozzle 1: ~600ms

Part placed, nozzle 2: ~500ms

Two things comes to mind when I see this. First; how slow the short moves are. While I understand why they are slower relative to the distance, is there a way to improve this (where would I be looking?).

The second thing is the feed time. This obviously also include a short move to position the drag pin, but even so! Looking deeper it a big chunk of it comes down to a delay after drag pin is released, before checking state:

2023-08-01 10:54:35.910 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M817
2023-08-01 10:54:35.910 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> G4P100
2023-08-01 10:54:35.960 ReferenceHead DEBUG: H1.moveToSafeZ(1.0)
2023-08-01 10:54:35.960 AbstractHeadMountable DEBUG: N1.moveToSafeZ(1.0)
2023-08-01 10:54:35.961 AbstractHeadMountable DEBUG: N2.moveToSafeZ(1.0)
2023-08-01 10:54:35.961 AbstractHeadMountable DEBUG: Down Locking.moveToSafeZ(1.0)
2023-08-01 10:54:35.962 AbstractHeadMountable DEBUG: Down Locking.moveTo((27.494394, 203.373082, -10.300000, -90.000000 mm), 1.0)
2023-08-01 10:54:35.963 ReferencePushPullFeeder DEBUG: calibrating sprocket holes pass 0 midPoint is (59.999355, 222.339746, -10.300000, -90.000000 mm)
2023-08-01 10:54:35.963 ReferenceHead DEBUG: H1.moveToSafeZ(1.0)
2023-08-01 10:54:35.963 AbstractHeadMountable DEBUG: N1.moveToSafeZ(1.0)
2023-08-01 10:54:35.963 AbstractHeadMountable DEBUG: N2.moveToSafeZ(1.0)
2023-08-01 10:54:35.963 AbstractHeadMountable DEBUG: Down Locking.moveToSafeZ(1.0)
2023-08-01 10:54:35.963 AbstractHeadMountable DEBUG: Down Locking.moveTo((27.494394, 203.373082, 0.000000, -90.000000 mm), 1.0)
2023-08-01 10:54:35.963 AbstractHeadMountable DEBUG: Down Locking.moveTo((59.999355, 222.339746, 0.000000, -90.000000 mm), 1.0)
2023-08-01 10:54:35.963 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M119 ; DRAGPIN endstop status, 10000)...
2023-08-01 10:54:35.963 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M119
2023-08-01 10:54:36.420 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-08-01 10:54:36.521 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-08-01 10:54:36.521 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << X_min:0 Y_min:0 Z_min:1 pins- (X)P4.4:0 (Y)P4.3:0 (Z)P2.13:1 (Z)P4.2:1
2023-08-01 10:54:36.521 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-08-01 10:54:36.521 GcodeDriver TRACE: actuatorRead response: X_min:0 Y_min:0 Z_min:1 pins- (X)P4.4:0 (Y)P4.3:0 (Z)P2.13:1 (Z)P4.2:1
2023-08-01 10:54:36.521 ReferenceActuator DEBUG: DRAGPIN.read(): 1

The delay is set to 100ms, but the firmware seems to delay 500ms. This must be a fw bug, right? Now, fixing this might not be complicated, but it got me thinking, that it would be better to sample the pin status for up to e.g. 1000ms, and as soon as the pin is reported 'UP', continue. The pin does not arrive up in a fixed time, it depends on the tape, and friction etc. Some time, I actually hear the pin arrive up just when the software has given up.

Would it be possible to do this outside the java code? Or is this design (fixed delay, and then test) because of some underlying construction?

 -  Micael

[mark maker]

Resend?

On 21.08.2023 10:58, mark maker wrote:

Hi vespaman

please send the whole log. The G4 delay depends on what came before. I might be able to study this evening (CET).

On question: do you include a tension relieve move? I.e. after dragging forward, do you retract the pin back to +/- the center of the sprocket hole?

_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/d8224b21-fc68-499a-b918-af7be9687952n%40googlegroups.com.

[vespaman]

That's very kind of you! I have put it up here (at the time/place above, I have inserted some rows for my own comfort, but apart from this it is as pulled form logs directory).

Yes, I have the tension relieve move, different on different tapes/as needed.

 - Micael

[vespaman]

Looking at it again, maybe the peeler plays a part in that delay!? It has "Before actuation" in "machine coordination" checked, but I suspect that might not be directly related (but maybe coordination is not needed?), since I guess this "before actuation" is just the M400/M114 combo prior to peeling. 

If peeler is part of the mystic delay, then it means that we ought to be able to move-on while peeler is still doing its job (as long as drag pin is up, that is). (And maybe it is also possible to speed up peeler if needed)

 - Micael

[mark maker]

Counting "ok"s, it seems the M817 itself takes some ~460ms to respond with ok. The G4 dwell itself is accurate to within one millisecond. This happens multiple times in the log, but not always. Strange.

Sorry, I don't find anything that would give me an idea.

Could be Smoothie STM32 port specific. If I'm not mistaken, the port was done in very short time and some simplifications were made. Maybe there are some fixed sleep times in there, e.g. when changing PWM duty cycles?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8d162cc1-a3bc-406f-a05a-2a09cde06893n%40googlegroups.com.

[mark maker]

Tried to refind where M817 takes less than ~460ms and haven't found it. So maybe I was mistaken and it is simply always the case.

Could be that Matt hardcoded the wait into the Smoothie STM32/CHMT port for safety, so nobody forgets to wait (G4) before moving.

At the time we did not yet have the Axis Interlock in OpenPnP, so forgetting the G4 was not caught!

https://github.com/openpnp/openpnp/wiki/Axis-Interlock-Actuator

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/898d7eec-689a-f6b7-ab1f-03dbbbee7ee3%40makr.zone.

[vespaman]

Well in the FW, no "OK" will not be sent until the delay has timed out, since it is a while() loop that waits for a hardware timer. Therefore, the 817 will not be dealt with until after the time has timed out. The while loop calls ON_IDLE, which does a little here and there, but I can't really see any place where it should/could hang for hundreds of ms. But maybe there is something that does take this long time, and the only thing that I can think of in that case, is the peeler.  The hardware timer may be broken of course, but then I would expect the G4P100 to always result in the same value (or totally random every time).

There are a couple of G4P100 e.g. in the beginning of the log, that times out between 0(!) and 100ms, then we have the ~400ms. So something is broken here.

So:- I think I need to hook up my debugger to fully understand this, will eyeball a bit more though.

But even so, would it be possible to poll for the "drag pin up" condition, much like waiting for the vacuum on pick? This would lead to a more robust and in many cases quicker turn around time (as quick as it can be).

I think I understand why the peeler start might have been setup for machine coordination - maybe it could start too soon, even practically before the drag operation starts. Maybe @Jan knows this? But that is another story.

- Micael

[mark maker]

> But even so, would it be possible to poll for the "drag pin up" condition, much like waiting for the vacuum on pick?

Yep that would likely be an easy addition to the interlock logic. You would have to specify the timeout on the Interlock Actuator.

https://github.com/openpnp/openpnp/wiki/Axis-Interlock-Actuator

I'm a bit confused about how/when the peeler should work. It would perhaps help if you could video the whole pin/peeling/dragging sequence on your machine, ideally so one sees everything happening (probably hard to frame in one view) 😛

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b01ba3d5-98d3-4cbe-b78c-b804178314c9n%40googlegroups.com.

[vespaman]

>I'm a bit confused about how/when the peeler should work.

I can certainly understand that!

It is not so easy to take a good video since there are so many angles to cover, like you said. But here's two where I step through.

The first one is hopefully the easiest to follow, it has the same preconditions as the case study above - 0402, vision after every drag operation, and starting with one 0402 uncovered in its pocket; "pick-drag-peel-vision-pick".  The most inefficient setup (which also is higher risk of tombstoning, since pocket is open for much longer time, susceptible to vibrations etc).

The second one is same as the first, just that here we start without the odd 0402 uncovered, so we start with the drag pin; "drag-peel-vision-pick-pick".

You can hear the peeler motor "weeowh"

Both are suffering from the same involuntary delay.

Here two short videos during feed operation from the feeder menu. One Two.

Hope this makes sense. :-)

[Jan]

Hi Micael!
First of all, if you wont more speed, I'd suggest to remove/disable all
unnecessary vision operations. For me constant feeder pick location
vision is one of them. If the feeder (and homing) is properly setup it
works reliably without any vision.
Concerning the peeler: the initial configuration in deed used the
feeder as separate actuator and it has to be carefully coordinated with
the drag move. Before the pick takes place, the peeling has to be done,
but the peeling can not end before the drag move. In both cases
uncollected cover table might over wise void the pick.
We discussed the coordination of the peeler with the drag move about a
year ago and Mark gratefully implemented the possibility to handle the
peeler as an other axis (in the ReferencePushPullFeeder). This allows
the drag move and the peeler to be in complete sync without any
additional coordination.

Jan

On 21.08.2023 20:20, vespaman wrote:

> it. So maybe I was mistaken and it is simply /always /the case.

>
> Could be that Matt hardcoded the wait into the Smoothie STM32/CHMT
> port for safety, so nobody forgets to wait (G4) before moving.
>
> At the time we did not yet have the Axis Interlock in OpenPnP, so

> forgetting the G4 /was /not caught!
>
> https://github.com/openpnp/openpnp/wiki/Axis-Interlock-Actuator

>>> <https://drive.google.com/file/d/1UyWHY-o8WvbR4hSRhhGv_dMJyDgg4Tio/view?usp=drive_link> (at the time/place above, I have inserted some rows for my own comfort, but apart from this it is as pulled form logs directory).

>>>>> https://groups.google.com/d/msgid/openpnp/d8224b21-fc68-499a-b918-af7be9687952n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/d8224b21-fc68-499a-b918-af7be9687952n%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/8d162cc1-a3bc-406f-a05a-2a09cde06893n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/8d162cc1-a3bc-406f-a05a-2a09cde06893n%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/898d7eec-689a-f6b7-ab1f-03dbbbee7ee3%40makr.zone <https://groups.google.com/d/msgid/openpnp/898d7eec-689a-f6b7-ab1f-03dbbbee7ee3%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

> https://groups.google.com/d/msgid/openpnp/b01ba3d5-98d3-4cbe-b78c-b804178314c9n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/b01ba3d5-98d3-4cbe-b78c-b804178314c9n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan!

Yes, vision on pick is not necessary all the time. I started off with vision "until confident" because I want vision on the first couple of runs each new day I use the machine, just to be sure nothing has happened, but found it a bit tedious to reset before starting, so for now, I have it always on. And while it does take a few hundred ms extra, I feel I "get something" for the time spent.

One thing I have been thinking of, is to create a  script that resets this "until confident" counter, and also make sure the first run starts off with a feed, letting any "odd" component in the pocket go to waste. This should give a more reliable start, and also speed up the continuation of the job.

The drag pin delay is something else. Here, there's no benefit, just time lost, and rather much, so that is the thing I want to remove.

Are you saying that you are nowadays running without coordination on the peeler, and it works good for you with the 100ms delay (or is thisthe more of a speculation that it should/might work without coordination nowadays?) 100ms sounds a bit short for some of my thicker tapes, and it only takes one erratic stop to eat up all the time gained.

I am thinking to do a quick and dirty fix in FW to get the best performance as well as most robust pin management, by delaying until the pin is up. (I know this is best done in openpnp, but I fear it would take me a month to get there. The FW is a matter of hours). I want to wait for the drag pin up to one second or so, but continue as soon as it is up.

- Micael

[Jan]

Hi Micael!

On 28.08.2023 08:59, vespaman wrote:
> One thing I have been thinking of, is to create a  script that resets
> this "until confident" counter, and also make sure the first run starts
> off with a feed, letting any "odd" component in the pocket go to waste.
> This should give a more reliable start, and also speed up the
> continuation of the job.
>

I guess a script thats runs at job start could do that for you.

> The drag pin delay is something else. Here, there's no benefit, just
> time lost, and rather much, so that is the thing I want to remove.
> Are you saying that you are nowadays running without coordination on the
> peeler, and it works good for you with the 100ms delay (or is thisthe
> more of a speculation that it should/might work without coordination
> nowadays?) 100ms sounds a bit short for some of my thicker tapes, and it
> only takes one erratic stop to eat up all the time gained.
>

I have configured the dragpin as actuator and I do have "Before
Actuation" coordination configured. Thats required because the dragpin
state shall not change while the machine is moving. In the driver I've
configured a 100ms delay when the dragpin is released to avoid false
axis interlock errors. I agree that polling would be better. However, it
would be even better to have a separate G-Code to let the controller do
the polling and return either with success or timeout.
The peeler is a different story: if you go the default route and
configure it as actuator, you have to add coordination as actuators are
handled asynchronously to movements. I my smoothie configuration the
peeler is accessed as axis "C" (I use "G0 C6" to drive the peeler 6mm in
my actuator setup).
Alternatively you can claim, that your dragpin can be rotated (assign
it a rotation axis). If this axis is physically driving the peeler, you
automatically get full synchronized movements. One just has to configure
the drag move to start at one angle and end at an other. Then the
controller will execute the drag move fully synchronized with the peeler.
To archive this, you have to
- add a ReferenceControllerAxis that represents the peeler
- assign this axis to the dragpin's rotation axis
- make sure the default "MOVE_TO_COMMAND" and generate G-Code that
contains the data for the new (peeler) axis.

> I am thinking to do a quick and dirty fix in FW to get the best
> performance as well as most robust pin management, by delaying until the
> pin is up. (I know this is best done in openpnp, but I fear it would
> take me a month to get there. The FW is a matter of hours). I want to
> wait for the drag pin up to one second or so, but continue as soon as it
> is up.
>

Then you might add G-Code commands that a) delay/wait until the dragpin
is up (with timeout) and b) delay/wait until the dragpin is down and
automatically switch the pwm to a lower value.
In addition you might add some kind of spiral move to release a stuck
dragpin automatically...

Jan

[vespaman]

Hi Jan,

måndag 28 augusti 2023 kl. 22:46:12 UTC+2 skrev Jan:

I have configured the dragpin as actuator and I do have "Before
Actuation" coordination configured. Thats required because the dragpin
state shall not change while the machine is moving. In the driver I've
configured a 100ms delay

Yes, this is exactly as I have it as well. But what Mark and I was discussing above, was the fact that the 100ms is not 100ms in reality, perhaps because of this setting (below, yellow) being activated (my guess; it might not be related at all, I have not found the reason for the delay issue);

 .. which is why I was asking you about it - if you don't have it checked, you probably have only the "true" 100ms (and it works for you, which is encouraging!).

If you do have it checked, my guess is that you also have the much longer delay that can be seen in the log above.

(This may not bother you, as much as it bothers me, though!)

But:- regardless;

axis interlock errors. I agree that polling would be better. However, it
would be even better to have a separate G-Code to let the controller do
the polling and return either with success or timeout.

Good idea! I will do what you propose, and add a new G-code instead, that is at least a little bit better and cleaner.

Then we can see the actual time the drag pin needs on different tapes.

Then you might add G-Code commands that a) delay/wait until the dragpin
is up (with timeout) and b) delay/wait until the dragpin is down and
automatically switch the pwm to a lower value.

Not sure about b) - there's no way to know if it is down or not, isn't just "not up" available?

And this is already good in the current setup, no?

 

In addition you might add some kind of spiral move to release a stuck
dragpin automatically...

 

Is there any point in doing this in FW (perhaps it is simpler?)?

- Micael

[vespaman]

Hmm, re-reading, updating myself on the log again, I think maybe Mark is correct, in that it is the M817 command that takes time. I will dig deeper.

 - Micael

[vespaman]

OK, Jan,

Now I refreshed myself on the log and code and log again.

The delay we are seeing on M817 (drag pin release) is because the peeler motor is still running (there's a "THEKERNEL->conveyor->wait_for_idle();" prior release. So we have;

1. Drag pin down

2. Move (the dragging), wait for move to finish (M400)

3. Peeler start (G92C0G0C6)

4. Dragpin up (817)

5. [817 waits for all motion to stop before actuating]

6. Pause 100 (G4P100)

  [..]

7. Dragpin reported up (reply on M119)

So, I suppose the question is, if there is a reason for the peeler starting prior to releasing drag pin?

We would save a good amount of time if Drag pin where released before starting peeler. (And maybe (just maybe) it would make the drag pin release better, since there no peeler pulling the peel tape off, which might move the tape slightly (black plastic tape e.g.)).

Now, I still would like the poll of drag pin, but with the current design, it will not speed up anything (at least not more than the 100ms delay), since the peeler motor is running.

 - Micael

[Jan]

Hi Micael!

On 29.08.2023 20:17, vespaman wrote:
> Hi Jan,
>
> måndag 28 augusti 2023 kl. 22:46:12 UTC+2 skrev Jan:
>
> I have configured the dragpin as actuator and I do have "Before
> Actuation" coordination configured. Thats required because the dragpin
> state shall not change while the machine is moving. In the driver I've
> configured a 100ms delay
>
>
> Yes, this is exactly as I have it as well. But what Mark and I was
> discussing above, was the fact that the 100ms is not 100ms in reality,
> perhaps because of this setting (below, yellow) being activated (my
> guess; it might not be related at all, I have not found the reason for
> the delay issue);
>

> Screenshot_20230829_194316.png
>
I have exactely the same actuator configuration and I'm still convinced
that it has to be like that, but I don't use them anymore.

>  .. which is why I was asking you about it - if you don't have it
> checked, you probably have only the "true" 100ms (and it works for you,
> which is encouraging!).
> If you do have it checked, my guess is that you also have the much
> longer delay that can be seen in the log above.
> (This may not bother you, as much as it bothers me, though!)
>

Unfortunately I don't remember if I had issues with that as well before
changing the configuration. Probably I would not have noticed a 100ms
delay... However, I remember that I had to speed up the peeler a lot to
make it as fast as the dragging.

> But:- regardless;
>
> axis interlock errors. I agree that polling would be better.
> However, it
> would be even better to have a separate G-Code to let the controller do
> the polling and return either with success or timeout.
>
>
> Good idea! I will do what you propose, and add a new G-code instead,
> that is at least a little bit better and cleaner.
> Then we can see the actual time the drag pin needs on different tapes.
>
> Then you might add G-Code commands that a) delay/wait until the dragpin
> is up (with timeout) and b) delay/wait until the dragpin is down and
> automatically switch the pwm to a lower value.
>
>
> Not sure about b) - there's no way to know if it is down or not, isn't
> just "not up" available?
> And this is already good in the current setup, no?
>

One might try if "not up" is as good as down. At least the automatic
current reduction would gain about 10ms.

> In addition you might add some kind of spiral move to release a stuck
> dragpin automatically...
>
> Is there any point in doing this in FW (perhaps it is simpler?)?
>

Actually there is not. It could as well be done using a script which is
executed on failed axis interlock. This would allow to make small moves
to try to automatically recover from a stuck drag pin.

Jan

[Jan]

Hi Micael!
Interesting findings! However, I don't understand them yet: my camera
lights are running without any coordination using the same G-Code
semantic and I'm pretty sure the light goes on while the head is still
moving to the (up-looking) camera. I also was under the impression that
coordination is actually only needed because this G-Codes are executed
asynchronously from motion. Could the blocking be related to the G0 used
to operate the peeler?
As an other workaround you might just speed up the peeler...

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/bea9c656-b262-450c-a06a-4fb0463c0f45n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/bea9c656-b262-450c-a06a-4fb0463c0f45n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan,

>>I have exactely the same actuator configuration and I'm still convinced
>>that it has to be like that, but I don't use them anymore.

This got me intrigued; what are you not using anymore, the feeders, the chmt36 or did I miss something .. ?

>>Interesting findings! However, I don't understand them yet: my camera

>>lights are running without any coordination using the same G-Code

>>semantic and I'm pretty sure the light goes on while the head is still

 

If you haven't changed your up led settings, I think you will see in your logs that it is set to on (810) after the move to the camera (also after a M400), so machine is still at this time.

But maybe our setup's has deviated in this area.

This part in my log;

2023-08-01 10:54:37.461 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M400 ; Wait for moves to complete before returning, 10000)...
2023-08-01 10:54:37.461 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M114 ; get position, -1)...
2023-08-01 10:54:37.461 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M400
2023-08-01 10:54:37.461 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M114
2023-08-01 10:54:37.974 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-08-01 10:54:37.975 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok C: X:133.8171 Y:47.1227 Z:-31.7176 A:-22.5329 B:67.5286 C:6.0000 D:0.0000
2023-08-01 10:54:37.975 GcodeDriver TRACE: Position report: ok C: X:133.8171 Y:47.1227 Z:-31.7176 A:-22.5329 B:67.5286 C:6.0000 D:0.0000
2023-08-01 10:54:37.975 GcodeDriver TRACE: GcodeDriver got lastReportedLocation (X:133.817100, Y:47.122700, ZN:-31.717600, C1:-22.532900, C2:67.528600)
2023-08-01 10:54:37.975 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete.
2023-08-01 10:54:37.975 ReferenceActuator DEBUG: UPLED.actuate(true)
2023-08-01 10:54:37.975 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M810 ; UPLED M810 on / M811 off, 10000)...
2023-08-01 10:54:37.976 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M810
2023-08-01 10:54:37.976 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok

 >>As an other workaround you might just speed up the peeler...

Yes, this has come to my mind. I have both peelers like this. I guess the acceleration needs to be increased in this case.

eta_max_rate                                 100000           # mm/min
eta_acceleration                             10000            # mm/sec^2

This might still be needed, since, if the peeler is started after drag pin release, the peeler might still be peeling when the first pick is about to happen, at least if there's no vision. (If there's vision, I suspect peeler will finish just about when pick is to happen)

But:- I'm not sure if the head can move once the peeler has started, so maybe I am just pushing this part of the problem forward?

Another thing might be to manage the drag pin as a separate entity altogether, and let it be operable during machine move. But I'm not sure if this is a good idea, since the way things are now, everything is treated the same, which is always a good thing when it comes to foresee consequences. 

 -  Micael

 

[mark maker]

To clarify, the coordination checkbox being OFF does two things:

1. It does not issue any commands (like M400) to the controller to wait for motion to complete. But the controller might still do that, implicitly upon receiving the M command. As vespaman has found out for M817 with the THEKERNEL->conveyor->wait_for_idle(); I guess this is a matter of how the firmware works. Obviously the wait_for_idle() pattern is safer, in case the user G-code does not contain the M400 when really needed, but it is slower.
   
2. But more importantly, the coordination checkbox does also not flush the motion queue on the OpenPnP side. So the motion queue might already contain some motion, i.e. the OpenPnP code might already have called moveTo() etc. but this motion is not yet sent to the controller, because the planner is still free to apply optimizations, including those we are talking about. Then the actuator is actuated, and because it has the coordination OFF, it is then sent to the controller immediately, so what effectively happens, is the order of commands sent to the controller is swapped around. This, for instance, allows us to actuate the camera light before the motion takes place, i.e. the camera has time to adapt and camera settling will be quicker and safer considering the camera lag would first produce a few black images otherwise, that might be mistaken as settled. The same can be used to actuate automatic feeders in parallel to the motion.
   

_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/660a3930-cbc9-45fc-8bbe-be7753eb7be6n%40googlegroups.com.

[vespaman]

Finally a couple of pennies dropped!

Jan, I know you hinted about this in your first post, I did not pick up on it then - I should have.

I am missing missing the peeling axes for both peelers.

Will add them as described in the push pull feeder manual, and re-test if that changes any order of execution.

 - Micael

[Jan]

Hi Micael!

On 30.08.2023 12:37, vespaman wrote:
[...]

> Will add them as described in the push pull feeder manual, and re-test
> if that changes any order of execution.
>

In the same manual I've found a reference to a discard function that
allows to discard all currently exposed components. You can likely
modify the "Reset_Strip_Feeder.js" example script to automatically
discard all components on all feeders at job start.

Jan

[vespaman]

Hi guys!

So finally today I have had some time to dig into my "lost half second". Here's what I have done:

1. I changed into using the peelers into axis instead of actuators. (This did not really make much difference afaict, maybe I got it wrong?).

2. Removed all wait_for_idle() on switches (actuators), so all actuators are done instantly (this includes up/down/work-light,dragpin,vacuum,blower and buzzer I think.

3.Added controller local drag pin status poll, so controller does not return 'ok' until either the pin is up, or timeout (after 1s).

4. Removed the delay in actuator setup (the original 100ms)

Does it make a difference? Yes! Now I have no delay at all. :-) On the feeder I have tested, it takes about 20ms for the pin to come up. This setup makes me happy, and I think/hope it also makes a more robust feed on my machine.

>>2023-09-16 18:30:00.398 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M817
>>2023-09-16 18:30:00.418 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok

But.. (What I kind of expected..) Now, since the drag pin action is super good/fast, I instead have to wait for the peeler to finish in the next step (this is my interpretation). So obviously, if there's no down vision involved, next step is nozzle two pick, and of course we need to wait for peeler here, hence the M400/M114 combo. Am I understanding this correctly?

I first thought that, in my setup, with vision, there should not be any need to wait for peeler, but after thinking about it, maybe it good to wait out the peeler, to make sure it all is still before doing the vision, there's always a chance the peeler is setup too strong (and slightly pull the tape a bit), esp on black plastic tapes.

So now I really need to speed up the peeler. But I have to admit, I don't really understand the peeler-actuator-axis setup :-o I mean, are they actually treated as axes throughout, or are they basically actuators treated as axes in the peeler logic in the ref-push-pull feeder?

And following that question:- are the "Kinematic Settings" on the peeler Axes valid now, or is it controlled by the limiting settings in FW config alone? I.e. what settings does in fact change the speed of the peelers?

This is my FW settings. @Jan, have you tweaked these, or where did you increase your peeler speed?

# C axis: LPEELER
zeta_steps_per_mm                            69.2642          # may be steps per degree for example
zeta_step_pin                                5.3              # Pin for delta stepper step signal
zeta_dir_pin                                 5.2              # Pin for delta stepper direction
zeta_en_pin                                  nc               # Pin for delta enable
zeta_current                                 0.5              # Z stepper motor current
zeta_max_rate                                100000           # mm/min
zeta_acceleration                            10000            # mm/sec^2
zeta_enable                                  true

# D axis: RPEELER
eta_steps_per_mm                             69.2642          # may be steps per degree for example
eta_step_pin                                 5.7              # Pin for delta stepper step signal
eta_dir_pin                                  5.6              # Pin for delta stepper direction
eta_en_pin                                   nc               # Pin for delta enable
eta_current                                  0.5              # Z stepper motor current

eta_max_rate                                 100000           # mm/min
eta_acceleration                             10000            # mm/sec^2

eta_enable                                   true

- Micael

[Jan]

Hi Micael!

On 16.09.2023 20:57, vespaman wrote:
> Hi guys!
>
> So finally today I have had some time to dig into my "lost half second".
> Here's what I have done:
> 1. I changed into using the peelers into axis instead of actuators.

> (This did not really make much difference afaict, maybe I got it wrong?) > 2. Removed all wait_for_idle() on switches (actuators), so all actuators

> are done instantly (this includes
> up/down/work-light,dragpin,vacuum,blower and buzzer I think.

I'd keep the coodination for the drag pin: we have to make sure the drag
pin is at its target location before it gets actuated. Therefore the
move to the drag location has to be finished before continuing.

> 3.Added controller local drag pin status poll, so controller does not
> return 'ok' until either the pin is up, or timeout (after 1s).

Cool! Can I merge the change back into my CHM-T smoothy firmware?

> 4. Removed the delay in actuator setup (the original 100ms)
>
> Does it make a difference? Yes! Now I have no delay at all. :-) On the
> feeder I have tested, it takes about 20ms for the pin to come up. This
> setup makes me happy, and I think/hope it also makes a more robust feed
> on my machine.
>
> >>2023-09-16 18:30:00.398 GcodeAsyncDriver$WriterThread TRACE:
> [serial://ttyUSB0] >> M817
> >>2023-09-16 18:30:00.418 GcodeDriver$ReaderThread TRACE:
> [serial://ttyUSB0] << ok
>
> But.. (What I kind of expected..) Now, since the drag pin action is
> super good/fast, I instead have to wait for the peeler to finish in the
> next step (this is my interpretation). So obviously, if there's no down
> vision involved, next step is nozzle two pick, and of course we need to
> wait for peeler here, hence the M400/M114 combo. Am I understanding this
> correctly?
> I first thought that, in my setup, with vision, there should not be any
> need to wait for peeler, but after thinking about it, maybe it good to
> wait out the peeler, to make sure it all is still before doing the
> vision, there's always a chance the peeler is setup too strong (and
> slightly pull the tape a bit), esp on black plastic tapes.
>

If you operate the peeler as axis, the coordination is guaranteed to be
done by the controller. The controller will always drive a streight
light between the locations you specified. So, if the peeler is operated
as part of the drag move, the peeling starts and ends exactely with the
drag move. The controller will also make sure, that both axis are
operated at their respectiv limits.
If you wont to operate the peeler as axis, you should make sure to
removed all peeler related actuators (from the feeder setup). If you
have done that, there is no option anymore to coordination or let anyone
wait for the peeler.
I've a 36VA, with just a single peeler, which might make the setup a
little bit easier...

My source code is on github. Feel free to take a look.
I'm using the same controller-wise limits. In OpenPnP I've configured
the same values. Actually, this values are a little bit lower then the
ones I use for the X-axis. I shall increase them to not make the peeler
the limiting factor...

Jan

> onsdag 30 augusti 2023 kl. 21:34:46 UTC+2 skrev Jan:
>
> Hi Micael!
>
> On 30.08.2023 12:37, vespaman wrote:
> [...]
> > Will add them as described in the push pull feeder manual, and
> re-test
> > if that changes any order of execution.
> >
> In the same manual I've found a reference to a discard function that
> allows to discard all currently exposed components. You can likely
> modify the "Reset_Strip_Feeder.js" example script to automatically
> discard all components on all feeders at job start.
>
> 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/921532a6-fc19-43b1-ab02-925fd409c835n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/921532a6-fc19-43b1-ab02-925fd409c835n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan, 

> 2. Removed all wait_for_idle() on switches (actuators), so all actuators

> are done instantly (this includes ...

I'd keep the coodination for the drag pin: we have to make sure the drag
pin is at its target location before it gets actuated. Therefore the
move to the drag location has to be finished before continuing.

The idea is to do all needed coordination in the machine.xml,  instead of having some in the controller as well. When there are coordination in the controller, it easily creates issues like the phantom 500ms delay, that are hard to spot.

The coordination for the drag pin is already set-up as needed in the machine.xml (at least in my set-up).

> 3.Added controller local drag pin status poll, so controller does not

> return 'ok' until either the pin is up, or timeout (after 1s).

Cool! Can I merge the change back into my CHM-T smoothy firmware?

Of course! I have yet to commit it to my git, but I'll try do a clean commit. (Not using git very often, so I tend to forget how to work it)

If you operate the peeler as axis, the coordination is guaranteed to be

done by the controller. The controller will always drive a streight
light between the locations you specified. So, if the peeler is operated
as part of the drag move, the peeling starts and ends exactely with the
drag move. The controller will also make sure, that both axis are
operated at their respectiv limits.
If you wont to operate the peeler as axis, you should make sure to
removed all peeler related actuators (from the feeder setup). If you

OK, I followed the docs, which indicates you should still use actuators, but maybe

the docs are for machines without the real extra axes? That would explain why I did

not see much of a change..

So, you have configured your c-axis directly in the feeder "Auxiliary Actuator"? If I try to do that, I can only see actuators, not the axes.

I can't see a way to configure without actuators involved.

This is how I have it now (the way I understood the docs)

Feeder points to actuator LPEELER;

Actuator points to axis LPeel

 

And this is the axis;

Regards,

 - Micael

[mark maker]

> OK, I followed the docs, which indicates you should still use actuators, but maybe the docs are for machines without the real extra axes? That would explain why I did not see much of a change..

An actuator can be actuated or moved or both.

You still need the Feed actuator for motion, and it is this motion actuator, that is show in the docs you linked.

For coordinated peeling, you need to use the Feed actuator and you need to give it the peeling axis. In your two sided feeder setup, you probably need two different Feed actuators and two different peeler axes, and assign them properly.

All peeling is then done thought the feed motion, fully coordinated with the feeding. Therefore, no actuator coordination is needed for peeling, and the controller can also queue, and seamlessly, and autonomously execute the peeling/feeding, i.e. a few milliseconds are saved on M400/M114 hand-shaking.

Conversely, you need to unassign (and to avoid future confusion, delete) your Auxiliary peeler actuators:

_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/301d4d40-928e-443f-82dd-f1f2c49ac729n%40googlegroups.com.

[Jan]

Hi Micael!

On 17.09.2023 09:31, vespaman wrote:

> Hi Jan,
> > 2. Removed all wait_for_idle() on switches (actuators), so all actuators
> > are done instantly (this includes ...
>
> I'd keep the coodination for the drag pin: we have to make sure the
> drag
> pin is at its target location before it gets actuated. Therefore the
> move to the drag location has to be finished before continuing.
>
>
> The idea is to do all needed coordination in the machine.xml,  instead
> of having some in the controller as well. When there are coordination in
> the controller, it easily creates issues like the phantom 500ms delay,
> that are hard to spot.
> The coordination for the drag pin is already set-up as needed in the
> machine.xml (at least in my set-up).
>

Good! That's how I have it and that's what I still recommend.

> > 3.Added controller local drag pin status poll, so controller does not
> > return 'ok' until either the pin is up, or timeout (after 1s).
>
> Cool! Can I merge the change back into my CHM-T smoothy firmware?
>
>
> Of course! I have yet to commit it to my git, but I'll try do a clean
> commit. (Not using git very often, so I tend to forget how to work it)
>

That's not so difficult either, just Git operations are not that
clear/predicable as with other version systems (I eg. always have
problems with remote branches)...
- just "commit", review your code changes and add a comment to create a
new (local) commit.
- use "push" to synchronize your local commits with github. (you need
to make sure the author of each commit matches the one github expects
otherwise they will be rejected) (That's something I'm fighting with as
well...)

> If you operate the peeler as axis, the coordination is guaranteed to be
>
> done by the controller. The controller will always drive a streight
> light between the locations you specified. So, if the peeler is
> operated
> as part of the drag move, the peeling starts and ends exactely with the
> drag move. The controller will also make sure, that both axis are
> operated at their respectiv limits.
> If you wont to operate the peeler as axis, you should make sure to
> removed all peeler related actuators (from the feeder setup). If you
>
>
> OK, I followed the docs

> <https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder#peeler-axis>, which indicates you should still use actuators, but maybe

> the docs are for machines without the real extra axes? That would
> explain why I did
> not see much of a change..
>
> So, you have configured your c-axis directly in the feeder "Auxiliary
> Actuator"? If I try to do that, I can only see actuators, not the axes.
> I can't see a way to configure without actuators involved.
>
> This is how I have it now (the way I understood the docs)
> Feeder points to actuator LPEELER;

> Feeder setup.png
>
That's what I meant with remove all actuators: the auxiliary actuator is
set true when the drag move starts and false when finished. You can use
any gcode you like and machine coordination as required. However, this
is the traditional way. If you wont to use the peeler as axis, you have
to remove the auxiliary actuator and assign the (new) peeler axis as
drag pin rotation
(https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png).
If I understand the logic correctly, the rotation you specified on the
feeders "Push-Pull Motion" tab is now executed by the "Feed Actuator"
you configured, which is set to your drag pin. So actually the drag pin
is rotated as part of the drag move. The rotation is send to the
controller using the axis letter you configured for the peeler axis. So
on a drag move, the location for x and y together with the rotation
value is send to the controller. The controller will then create a move
sequence by joining all this locations using straight lines. That means,
that the x/y and rotation will be exactly reached before it continues to
the next x/y and rotation. This guarantees, that the drag motion and the
peeling are exactly synchronized.
Yesterday I noticed, that the drag pin has a single rotation axis only.
On your machine you have a single drag pin but two peelers. So in order
to operate both peelers as axes, I see two possibilities: a) operate
both peelers as one using bridges in the controller and as single axis
or b) create two drag pins with exactly the same properties except the
rotation/peeler axis. Then you can use one drag pin together with one
peeler.

Jan

[vespaman]

Hi Mark,

Now I understand! I did not connect the fact that the Feed actuator was the link to the peeler, I was too convinced it was still the Auxiliary. Now that you point it out, I think it is crystal clear. :-)

 - Micael

[vespaman]

Hi Jan,

> Of course! I have yet to commit it to my git, but I'll try do a clean
> commit. (Not using git very often, so I tend to forget how to work it)
>
That's not so difficult either, just Git operations are not that
clear/predicable as with other version systems (I eg. always have
problems with remote branches)...
- just "commit", review your code changes and add a comment to create a
new (local) commit.
- use "push" to synchronize your local commits with github. (you need
to make sure the author of each commit matches the one github expects
otherwise they will be rejected) (That's something I'm fighting with as
well...)

Yes, many times, I end up spending quite some time just to get the hang of it, and the security stuff is always part of it. So I tend to wait too long to commit, which leads to much more work to sort the different changes into good commits.

Luckily, this time, all changes are in files that I have not changed before (well, apart from the config file).

That's what I meant with remove all actuators: the auxiliary actuator is
set true when the drag move starts and false when finished. You can use
any gcode you like and machine coordination as required. However, this
is the traditional way. If you wont to use the peeler as axis, you have
to remove the auxiliary actuator and assign the (new) peeler axis as
drag pin rotation
(https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png).
If I understand the logic correctly, the rotation you specified on the
feeders "Push-Pull Motion" tab is now executed by the "Feed Actuator"
you configured, which is set to your drag pin. So actually the drag pin
is rotated as part of the drag move. The rotation is send to the
controller using the axis letter you configured for the peeler axis. So
on a drag move, the location for x and y together with the rotation
value is send to the controller. The controller will then create a move
sequence by joining all this locations using straight lines. That means,
that the x/y and rotation will be exactly reached before it continues to
the next x/y and rotation. This guarantees, that the drag motion and the
peeling are exactly synchronized.

I see absolutely no reason to keep "the traditional way", now that I understand.  (Maybe if one would like to run the peelers to see if all friction screws are good (not doing involuntary peeling), it might be good to have them still as actuators)

 

Yesterday I noticed, that the drag pin has a single rotation axis only.
On your machine you have a single drag pin but two peelers. So in order
to operate both peelers as axes, I see two possibilities: a) operate
both peelers as one using bridges in the controller and as single axis
or b) create two drag pins with exactly the same properties except the
rotation/peeler axis. Then you can use one drag pin together with one
peeler.

I will try to create two "drag pins" - I don't want both peelers running at the same time.

Onto it now, while I still think I understand.. :-)

Thanks,

 Micael

[vespaman]

OK, so of course, setting up two "drag pins" does not work out of the box.

I simply copied the Drag pin I had, made one for left, and one for right peel.

While operating one, "the other" will report drag pin error. Do any of you have any suggestion on how to solve this?

2023-09-17 17:50:17.902 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M400
2023-09-17 17:50:17.902 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M114
2023-09-17 17:50:18.433 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-17 17:50:18.434 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok C: X:24.0900 Y:21.7500 Z:-0.2000 A:0.0000 B:0.0000 C:0.0000 D:0.0000
2023-09-17 17:50:18.434 GcodeDriver TRACE: Position report: ok C: X:24.0900 Y:21.7500 Z:-0.2000 A:0.0000 B:0.0000 C:0.0000 D:0.0000
2023-09-17 17:50:18.434 GcodeDriver TRACE: GcodeDriver got lastReportedLocation (X:24.090000, Y:21.750000, ZN:-0.200000, C1:0.000000, C2:0.000000, LPeel:0.000000, RPeel:0.000000)
2023-09-17 17:50:18.434 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete.
2023-09-17 17:50:18.434 ReferenceActuator DEBUG: DRAGPIN (Left side peel).actuate(true)
2023-09-17 17:50:18.434 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M816 S100 ; DRAGPIN M816 down @100%, 10000)...
2023-09-17 17:50:18.434 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(G4 P10 ; wait a little bit until the pin is down, 10000)...
2023-09-17 17:50:18.434 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M816 S10 ; switch to hold @10%, 10000)...
2023-09-17 17:50:18.434 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(; DRAGPIN M817 release, 10000)...
2023-09-17 17:50:18.434 GcodeAsyncDriver DEBUG: serial://ttyUSB0 empty command after pre process
2023-09-17 17:50:18.434 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M816S100
2023-09-17 17:50:18.434 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-17 17:50:18.434 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> G4P10
2023-09-17 17:50:18.435 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M816S10
2023-09-17 17:50:18.445 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-17 17:50:18.445 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-17 17:50:18.485 AbstractHeadMountable DEBUG: DRAGPIN (Left side peel).moveTo((73.780000, 40.650985, 0.000000, 0.000000 mm), 0.26)
2023-09-17 17:50:18.485 ActuatorInterlockMonitor TRACE: DRAGPIN (Left side peel) interlock masked by conditionalActuator DRAGPIN (Left side peel) being true handled as ON
2023-09-17 17:50:18.485 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M119 ; DRAGPIN endstop status, 10000)...
2023-09-17 17:50:18.486 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M119
2023-09-17 17:50:18.486 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << X_min:0 Y_min:0 Z_min:1 pins- (X)P4.4:0 (Y)P4.3:0 (Z)P2.13:1 (Z)P4.2:0
2023-09-17 17:50:18.486 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-17 17:50:18.486 GcodeDriver TRACE: actuatorRead response: X_min:0 Y_min:0 Z_min:1 pins- (X)P4.4:0 (Y)P4.3:0 (Z)P2.13:1 (Z)P4.2:0
2023-09-17 17:50:18.486 ReferenceActuator DEBUG: DRAGPIN (Right side peel).read(): 0
2023-09-17 17:50:18.487 AbstractMachine TRACE: Exception caught, executing pending motion: java.lang.Exception: DRAGPIN (Right side peel) interlock confirmation does not match: 0 vs. 1
at org.openpnp.machine.reference.ActuatorInterlockMonitor.interlockActuation(ActuatorInterlockMonitor.java:374)
at org.openpnp.machine.reference.driver.AbstractMotionPlanner.moveTo(AbstractMotionPlanner.java:158)
at org.openpnp.machine.reference.driver.ReferenceAdvancedMotionPlanner.moveTo(ReferenceAdvancedMotionPlanner.java:329)
at org.openpnp.machine.reference.ReferenceHead.moveTo(ReferenceHead.java:154)
at org.openpnp.spi.base.AbstractHeadMountable.moveTo(AbstractHeadMountable.java:243)
at org.openpnp.machine.reference.feeder.ReferencePushPullFeeder.feed(ReferencePushPullFeeder.java:448)
at org.openpnp.gui.FeedersPanel.feedFeeder(FeedersPanel.java:633)
at org.openpnp.gui.FeedersPanel$7.lambda$actionPerformed$0(FeedersPanel.java:585)
at org.openpnp.util.UiUtils.lambda$submitUiMachineTask$0(UiUtils.java:39)
at org.openpnp.spi.base.AbstractMachine$1.call(AbstractMachine.java:578)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
2023-09-17 17:50:18.487 AbstractMachine TRACE: Machine entering idle state.
2023-09-17 17:50:18.487 MessageBoxes DEBUG: Error: java.lang.Exception: DRAGPIN (Right side peel) interlock confirmation does not match: 0 vs. 1

Would it maybe be possible with some sort of regex magic here for example?

So close to PnP Nirvana, yet so far away!

  - Micael

[Jan]

Hi Micael!
Seems your facing an axis interlock problem: as you have two actuators
now operating the same drag pin and both have axis interlock enabled and
read the same drag pins state, you've created a dead locked. If one is
actuated, the other reports, that its not in the up position and hence
the interlock condition is false interrupting the machine.
I don't see a good solution how to fix that. You can either remove the
axis interlock on both actuators or operate both peelers in parallel
with a single actuator or change OpenPnP that it only validates the axis
interlock if the actuator has just been switched off.
Maybe the drag pin read back can be configured as some kind of
interlock in smoothie. If that interlock can be masked by the drag pin
down state, we would have the interlock in hardware...

Jan

> (https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png <https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png>).

> Onto it now, while I still /think/ I understand.. :-)
>
> Thanks,
>  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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan,

Yes, it is clear to me what is happening. Not how to fix it, especially not in smoothie.

Gut feeling is that would be the wrong turn, because then we need to add more complex states in the controller, which I doubt will be a good way going forward. 

I think it is OK to do simple stuff, like polling the state just after pin up/down request, since it is simple to know the intent.

Even trying to free a stuck pin might be OK. 

But adding a state machine for keeping track on state will likely hinder future enhancements of OpenPnP, or create confusion later on. Even with the current OpenPnP, where you are able to move slowly, the head even if pin is down, will stop working.

If there's a proper solution that can be done in smoothie, I could add it, I just don't see it (unless going rogue with ugly presumptions, like "head is closer to the right side, so this must mean right peeler intent" etc).

Maybe it is possible to create a new setup of "virtual" drag pin+up/down sensor. But also that would add states into the controller. I have to think more about that solution...

Is removing interlock really an option? Would you dare to run your machine without? I don't really know how big of an issue that would be, but it sounds really scary to me!

I was hoping there would be a solution with regex, but maybe that is not possible.

  - Micael

[Jan]

Hi Micael!
I'm still convinced, that axis interlock is a valuable feature to
protect the drag pin and to safe us for excessive damage while moving
with the pin down. However, I'm not convinced, that axis interlock as
currently implemented in OpenPnP is already the best solution. It seems
- I've stumbled across this a few times already - that the axis
interlock feature constantly monitors the configured input. That's a
good thing if you wont to make sure a hut or door is closed. However for
the drag pin one only has to verify that it's up when commanded to go
up. Once it is up, it will never go down again on it's own. So we
actually only need to make sure not to move before the pin has reported
that its up now. I'm not sure this can be done in OpenPnP without
modifications and I don't see that smoothie has a maskable interlock
feature. I did not found an interlock feature at all. There are just
kill and suspend/response features. I don't see, that one of them could
be used here.
OpenPnP wise one would need an actuator, that reads a state back and
can throw an exception if the state is not ok. At present I don't think,
that actuators in OpenPnP can give feedback.
Smoothie wise one would need to extend the switch class to read back
the state and somehow prevent further movements. I'm not sure the drag
pin up command can report back any error to OpenPnP.
However, in both cases the recovery of a triggered interlock will be
interesting: one needs to make sure the interlock condition is verified
again before continuing otherwise I could easily overwrite the interlock
condition by resuming which would end in a disaster...
I hope Mark is following and has some more insides what can be done
today using OpenPnP. For now I think running without interlock is the
only think I see. And yes, that shall only be a temporary solution.

Jan

> (https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png <https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png> <https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png <https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png>>).

> https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%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/7e4748a1-7e54-4b10-9833-e22586c0a6b9n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/7e4748a1-7e54-4b10-9833-e22586c0a6b9n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan,

Thanks for your input!

(I'm sure Mark follows when he can, but I think he mentioned having loads to do, so..)

While tempting to simply remove interlock on the drag pin... Knowing myself, I think I sooner or later would end up with a broken drag pin. And I think other people following on with a VB machine (or other brand) will do the same, esp perhaps in the beginning. But temporary maybe, yes.

One way that I have thought of, since yesterday, is to do the scary stuff; disable the interlock on the drag pin, but instead add code to try to un-stick a failed drag pin up, so in my code, after e.g. 200ms without drag pin is up, the controller starts to try to un-stick it by itself.  (I have no idea if un-stick code will be easy to implement at this point in time, but I think it might also be useful going forward, regardless).

Then, if that also fails, I could put the machine into halt.

Of course, the big disadvantage with this solution, is that it takes even more time to solve a drag pin down machine stop. (But hopefully, drag pin errors are less)

Gotta think some more. Luckily, I have a few weeks until I need to put the machine to work again. :-)

 - Micael

[mark maker]

Hi Jan, Micael,

yes, the drag pin interlock is an issue.

There is a way around it:

1. Make the Feed actuators into a Profile actuators by setting that Value Type:
   https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Actuators#actuator-value-type
2. Then add the actual (one and only) Dragpin actuator as Actuator 1 on both profile actuator:
   https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Actuators#actuator-with-profiles
3. This way both Feed actuator will indirectly actuate the same (one and only) Dragpin actuator.
4. Note: to be clear, you now need three actuators, two Feed and one Dragpin.
   
5. The interlock then needs to be defined on the Dragpin actuator, not the Feed actuator.
   

_Mark

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/2f4a7e5f-3d73-4800-9eeb-6ba0f5a6c141n%40googlegroups.com.

[vespaman]

Hi Mark,

This impresses me much! There's so much flexibility in this program.

So, I tried to set it up like you described. And I also removed much of old stuff, hopefully not too much.

But:- My experience now, is similar to before. (But exactly the same).

This is what happens when I press Feed;

2023-09-18 12:17:02.235 AbstractHeadMountable DEBUG: N1.moveToSafeZ(0.26)
2023-09-18 12:17:02.235 ReferencePushPullFeeder DEBUG: feed(N1 N1)
2023-09-18 12:17:02.235 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(G92      C0.0000  ; reset coordinates, -1)...
2023-09-18 12:17:02.235 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((69.695000, 40.613877, 0.000000, 0.000000 mm), 0.26)
2023-09-18 12:17:02.236 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> G92C0
2023-09-18 12:17:02.236 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:17:02.236 ReferenceActuator DEBUG: DRAGPIN.actuate(true)
2023-09-18 12:17:02.236 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M816 S100 ; DRAGPIN M816 down @100%, 10000)...
2023-09-18 12:17:02.236 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(G4 P10 ; wait a little bit until the pin is down, 10000)...
2023-09-18 12:17:02.236 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M816 S10 ; switch to hold @10%, 10000)...
2023-09-18 12:17:02.236 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(; DRAGPIN M817 release, 10000)...
2023-09-18 12:17:02.236 GcodeAsyncDriver DEBUG: serial://ttyUSB0 empty command after pre process
2023-09-18 12:17:02.236 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M816S100
2023-09-18 12:17:02.236 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> G4P10
2023-09-18 12:17:02.237 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:17:02.237 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M816S10
2023-09-18 12:17:02.247 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:17:02.247 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:17:02.287 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((73.780000, 40.613877, 0.000000, 0.000000 mm), 0.26)
2023-09-18 12:17:02.287 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M119 ; DRAGPIN endstop status, 10000)...
2023-09-18 12:17:02.287 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M119
2023-09-18 12:17:02.288 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << X_min:0 Y_min:0 Z_min:1 pins- (X)P4.4:0 (Y)P4.3:0 (Z)P2.13:1 (Z)P4.2:0
2023-09-18 12:17:02.288 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:17:02.288 GcodeDriver TRACE: actuatorRead response: X_min:0 Y_min:0 Z_min:1 pins- (X)P4.4:0 (Y)P4.3:0 (Z)P2.13:1 (Z)P4.2:0
2023-09-18 12:17:02.288 ReferenceActuator DEBUG: DRAGPIN.read(): 0
2023-09-18 12:17:02.288 AbstractMachine TRACE: Exception caught, executing pending motion: java.lang.Exception: DRAGPIN interlock confirmation does not match: 0 vs. 1

at org.openpnp.machine.reference.ActuatorInterlockMonitor.interlockActuation(ActuatorInterlockMonitor.java:374)
at org.openpnp.machine.reference.driver.AbstractMotionPlanner.moveTo(AbstractMotionPlanner.java:158)
at org.openpnp.machine.reference.driver.ReferenceAdvancedMotionPlanner.moveTo(ReferenceAdvancedMotionPlanner.java:329)
at org.openpnp.machine.reference.ReferenceHead.moveTo(ReferenceHead.java:154)
at org.openpnp.spi.base.AbstractHeadMountable.moveTo(AbstractHeadMountable.java:243)
at org.openpnp.machine.reference.feeder.ReferencePushPullFeeder.feed(ReferencePushPullFeeder.java:448)
at org.openpnp.gui.FeedersPanel.feedFeeder(FeedersPanel.java:633)
at org.openpnp.gui.FeedersPanel$7.lambda$actionPerformed$0(FeedersPanel.java:585)
at org.openpnp.util.UiUtils.lambda$submitUiMachineTask$0(UiUtils.java:39)
at org.openpnp.spi.base.AbstractMachine$1.call(AbstractMachine.java:578)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)

2023-09-18 12:17:02.288 AbstractMachine TRACE: Machine entering idle state.

It is like it does not remember that it just activated the drag pin.

The interlock is on the DRAGPIN actuator. There's no interlock on the "Peeler actuators".

Setup like this;

So, then I found that I earlier on had had the interlock conditions on drag pin actuator set to DRAGPIN / SWITCHED OFF at some point.

Before thinking this though, I changed this, and tested a feed. Now I need to change my drag pin....

The feed worked (no peeling took place though), but then, the head moved to sprocket hole vision without pulling the pin up.

Looking in the fresh log, there's now no M817 to pull it up. Is this because I have missed something in my setup, or is this expected because of my stupid test? If I, from the "Machine Controls" pane, "Actuators tab", press H1:DRAGPIN->OFF, it works (releasing the pin).

"Things went really bad log";

2023-09-18 12:39:17.958 AbstractHeadMountable DEBUG: N1.moveToSafeZ(0.26)
2023-09-18 12:39:17.958 ReferencePushPullFeeder DEBUG: feed(N1 N1)
2023-09-18 12:39:17.959 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(G92      C0.0000  ; reset coordinates, -1)...
2023-09-18 12:39:17.959 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((69.695000, 40.548938, 0.000000, 0.000000 mm), 0.26)
2023-09-18 12:39:17.959 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> G92C0
2023-09-18 12:39:17.959 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:17.959 ReferenceActuator DEBUG: DRAGPIN.actuate(true)
2023-09-18 12:39:17.959 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M816 S100 ; DRAGPIN M816 down @100%, 10000)...
2023-09-18 12:39:17.959 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(G4 P10 ; wait a little bit until the pin is down, 10000)...
2023-09-18 12:39:17.959 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M816 S10 ; switch to hold @10%, 10000)...
2023-09-18 12:39:17.959 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M816S100
2023-09-18 12:39:17.959 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(; DRAGPIN M817 release, 10000)...
2023-09-18 12:39:17.959 GcodeAsyncDriver DEBUG: serial://ttyUSB0 empty command after pre process
2023-09-18 12:39:17.959 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> G4P10
2023-09-18 12:39:17.959 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M816S10
2023-09-18 12:39:17.959 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:17.969 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:17.970 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:18.010 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((73.780000, 40.548938, 0.000000, 0.000000 mm), 0.26)
2023-09-18 12:39:18.010 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being true handled as ON
2023-09-18 12:39:18.012 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being true handled as ON
2023-09-18 12:39:18.012 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((73.680000, 40.548938, 0.000000, 0.000000 mm), 0.26)
2023-09-18 12:39:18.012 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being true handled as ON
2023-09-18 12:39:18.015 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being true handled as ON
2023-09-18 12:39:18.015 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M204 S427 G1 X28.13       F2492 ; move to target, 10000)...
2023-09-18 12:39:18.015 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M204S427G1X28.13F2492
2023-09-18 12:39:18.015 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:18.016 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M204 S98 G1 X28.19       F600 ; move to target, 10000)...
2023-09-18 12:39:18.016 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M204S98G1X28.19F600
2023-09-18 12:39:18.016 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:18.017 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M204 S100 G1 X28.14       F600 ; move to target, 10000)...
2023-09-18 12:39:18.017 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M204S100G1X28.14F600
2023-09-18 12:39:18.017 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:18.017 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M204 S98 G1 X28.08       F600 ; move to target, 10000)...
2023-09-18 12:39:18.018 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M204S98G1X28.08F600
2023-09-18 12:39:18.018 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:18.019 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M400 ; Wait for moves to complete before returning, 38462)...
2023-09-18 12:39:18.019 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M114 ; get position, -1)...
2023-09-18 12:39:18.019 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M400
2023-09-18 12:39:18.019 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M114
2023-09-18 12:39:18.318 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:18.318 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok C: X:28.0800 Y:21.6500 Z:-0.2000 A:-90.0009 B:0.0000 C:0.0000 D:0.0000
2023-09-18 12:39:18.318 GcodeDriver TRACE: Position report: ok C: X:28.0800 Y:21.6500 Z:-0.2000 A:-90.0009 B:0.0000 C:0.0000 D:0.0000
2023-09-18 12:39:18.319 GcodeDriver TRACE: GcodeDriver got lastReportedLocation (X:28.080000, Y:21.650000, ZN:-0.200000, C1:-90.000900, C2:0.000000, LPeel:0.000000, RPeel:0.000000)
2023-09-18 12:39:18.319 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete.
2023-09-18 12:39:18.319 ReferenceActuator DEBUG: DRAGPIN.actuate(true)
2023-09-18 12:39:18.319 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M816 S100 ; DRAGPIN M816 down @100%, 10000)...
2023-09-18 12:39:18.319 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(G4 P10 ; wait a little bit until the pin is down, 10000)...
2023-09-18 12:39:18.319 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M816 S10 ; switch to hold @10%, 10000)...
2023-09-18 12:39:18.319 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(; DRAGPIN M817 release, 10000)...
2023-09-18 12:39:18.319 GcodeAsyncDriver DEBUG: serial://ttyUSB0 empty command after pre process
2023-09-18 12:39:18.319 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M816S100
2023-09-18 12:39:18.319 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:18.319 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> G4P10
2023-09-18 12:39:18.320 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M816S10
2023-09-18 12:39:18.330 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:18.330 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:18.370 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(G92      C0.0000  ; reset coordinates, -1)...
2023-09-18 12:39:18.370 ReferenceHead DEBUG: H1.moveToSafeZ(0.26)
2023-09-18 12:39:18.370 AbstractHeadMountable DEBUG: N1.moveToSafeZ(0.26)
2023-09-18 12:39:18.370 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> G92C0
2023-09-18 12:39:18.370 AbstractHeadMountable DEBUG: N2.moveToSafeZ(0.26)
2023-09-18 12:39:18.370 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:18.370 AbstractHeadMountable DEBUG: Down Locking.moveToSafeZ(0.26)
2023-09-18 12:39:18.370 AbstractHeadMountable DEBUG: LPEELER.moveToSafeZ(0.26)
2023-09-18 12:39:18.370 AbstractHeadMountable DEBUG: RPEELER.moveToSafeZ(0.26)
2023-09-18 12:39:18.372 AbstractHeadMountable DEBUG: Down Locking.moveTo((27.274394, 21.723661, -10.300000, -90.000000 mm), 0.26)
2023-09-18 12:39:18.372 ReferencePushPullFeeder DEBUG: calibrating sprocket holes pass 0 midPoint is (59.618575, 40.483898, -10.300000, -90.000000 mm)
2023-09-18 12:39:18.372 ReferenceHead DEBUG: H1.moveToSafeZ(0.26)
2023-09-18 12:39:18.372 AbstractHeadMountable DEBUG: N1.moveToSafeZ(0.26)
2023-09-18 12:39:18.372 AbstractHeadMountable DEBUG: N2.moveToSafeZ(0.26)
2023-09-18 12:39:18.372 AbstractHeadMountable DEBUG: Down Locking.moveToSafeZ(0.26)
2023-09-18 12:39:18.372 AbstractHeadMountable DEBUG: Down Locking.moveTo((27.274394, 21.723661, 0.000000, -90.000000 mm), 0.26)
2023-09-18 12:39:18.372 AbstractHeadMountable DEBUG: LPEELER.moveToSafeZ(0.26)
2023-09-18 12:39:18.372 AbstractHeadMountable DEBUG: RPEELER.moveToSafeZ(0.26)
2023-09-18 12:39:18.372 AbstractHeadMountable DEBUG: Down Locking.moveTo((59.618575, 40.483898, 0.000000, -90.000000 mm), 0.26)
2023-09-18 12:39:18.372 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being true handled as ON
2023-09-18 12:39:18.373 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being true handled as ON
2023-09-18 12:39:18.373 AbstractHeadMountable DEBUG: Down Locking.moveTo((59.618575, 40.483898, -10.300000, -90.000000 mm), 0.26)
2023-09-18 12:39:18.374 Scripting TRACE: Scripting.on Camera.BeforeSettle
2023-09-18 12:39:18.374 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M204 S585 G1 X60.38 Y40.37      F8870 ; move to target, 10000)...
2023-09-18 12:39:18.374 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M204S585G1X60.38Y40.37F8870
2023-09-18 12:39:18.374 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:18.375 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M204 S97 G1 X60.44 Y40.45      F600 ; move to target, 10000)...
2023-09-18 12:39:18.375 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M204S97G1X60.44Y40.45F600
2023-09-18 12:39:18.375 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:18.376 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M400 ; Wait for moves to complete before returning, 38462)...
2023-09-18 12:39:18.376 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M114 ; get position, -1)...
2023-09-18 12:39:18.376 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M400
2023-09-18 12:39:18.376 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M114
2023-09-18 12:39:18.939 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 12:39:18.939 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok C: X:60.4400 Y:40.4500 Z:-0.2000 A:-90.0009 B:0.0000 C:0.0000 D:0.0000
2023-09-18 12:39:18.939 GcodeDriver TRACE: Position report: ok C: X:60.4400 Y:40.4500 Z:-0.2000 A:-90.0009 B:0.0000 C:0.0000 D:0.0000
2023-09-18 12:39:18.940 GcodeDriver TRACE: GcodeDriver got lastReportedLocation (X:60.440000, Y:40.450000, ZN:-0.200000, C1:-90.000900, C2:0.000000, LPeel:0.000000, RPeel:0.000000)
2023-09-18 12:39:18.940 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete.
2023-09-18 12:39:18.940 Scripting TRACE: Scripting.on Camera.BeforeCapture
2023-09-18 12:39:18.958 Scripting TRACE: Scripting.on Camera.AfterCapture
2023-09-18 12:39:18.961 Scripting TRACE: Scripting.on Camera.BeforeCapture
2023-09-18 12:39:18.985 Scripting TRACE: Scripting.on Camera.AfterCapture
2023-09-18 12:39:18.989 AbstractSettlingCamera TRACE: autoSettleAndCapture t=49 auto settle score: 1.420 compute time: 3
2023-09-18 12:39:18.989 Scripting TRACE: Scripting.on Camera.BeforeCapture
2023-09-18 12:39:19.017 Scripting TRACE: Scripting.on Camera.AfterCapture
2023-09-18 12:39:19.021 AbstractSettlingCamera TRACE: autoSettleAndCapture t=81 auto settle score: 0.429 compute time: 3
2023-09-18 12:39:19.021 Scripting TRACE: Scripting.on Camera.BeforeCapture
2023-09-18 12:39:19.060 Scripting TRACE: Scripting.on Camera.AfterCapture
2023-09-18 12:39:19.065 AbstractSettlingCamera TRACE: autoSettleAndCapture t=125 auto settle score: 0.249 compute time: 4
2023-09-18 12:39:19.065 Scripting TRACE: Scripting.on Camera.BeforeCapture
2023-09-18 12:39:19.093 Scripting TRACE: Scripting.on Camera.AfterCapture
2023-09-18 12:39:19.101 AbstractSettlingCamera TRACE: autoSettleAndCapture t=161 auto settle score: 0.201 compute time: 8
2023-09-18 12:39:19.101 AbstractSettlingCamera DEBUG: autoSettleAndCapture in 162 ms
2023-09-18 12:39:19.101 Scripting TRACE: Scripting.on Camera.AfterSettle
2023-09-18 12:39:19.179 AbstractMachine TRACE: Exception caught, executing pending motion: java.lang.Exception: No line of sprocket holes can be recognized
at org.openpnp.machine.reference.feeder.ReferencePushPullFeeder$FindFeatures.invoke(ReferencePushPullFeeder.java:1570)
at org.openpnp.machine.reference.feeder.ReferencePushPullFeeder.performVisionOperations(ReferencePushPullFeeder.java:2480)
at org.openpnp.machine.reference.feeder.ReferencePushPullFeeder.obtainCalibratedVisionOffset(ReferencePushPullFeeder.java:535)
at org.openpnp.machine.reference.feeder.ReferencePushPullFeeder.assertCalibrated(ReferencePushPullFeeder.java:350)
at org.openpnp.machine.reference.feeder.ReferencePushPullFeeder.feed(ReferencePushPullFeeder.java:503)

at org.openpnp.gui.FeedersPanel.feedFeeder(FeedersPanel.java:633)
at org.openpnp.gui.FeedersPanel$7.lambda$actionPerformed$0(FeedersPanel.java:585)
at org.openpnp.util.UiUtils.lambda$submitUiMachineTask$0(UiUtils.java:39)
at org.openpnp.spi.base.AbstractMachine$1.call(AbstractMachine.java:578)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)

2023-09-18 12:39:19.179 AbstractMachine TRACE: Machine entering idle state.
2023-09-18 12:39:19.179 MessageBoxes DEBUG: Error: java.lang.Exception: No line of sprocket holes can be recognized

Thanks,

 - Micael

[mark maker]

This checkbox should be OFF:

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9c00cf51-9714-462f-a9ad-7cbed6124e73n%40googlegroups.com.

[vespaman]

OK, will test that when I have changed the pin.

  - Micael

[vespaman]

So now I unchecked the DRAGPIN OFF checkbox as suggested. (and conditions on drag pin actuator set to DRAGPIN / SWITCHED ON again).

I get the same result as on the first try, by the looks of it;

2023-09-18 15:02:35.711 AbstractHeadMountable DEBUG: N1.moveToSafeZ(0.27)
2023-09-18 15:02:35.711 ReferencePushPullFeeder DEBUG: feed(N1 N1)
2023-09-18 15:02:35.711 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(G92      C0.0000  ; reset coordinates, -1)...
2023-09-18 15:02:35.711 ReferenceHead DEBUG: H1.moveToSafeZ(0.27)
2023-09-18 15:02:35.711 AbstractHeadMountable DEBUG: N1.moveToSafeZ(0.27)
2023-09-18 15:02:35.711 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> G92C0
2023-09-18 15:02:35.711 AbstractHeadMountable DEBUG: N2.moveToSafeZ(0.27)
2023-09-18 15:02:35.711 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 15:02:35.711 AbstractHeadMountable DEBUG: Down Locking.moveToSafeZ(0.27)
2023-09-18 15:02:35.712 AbstractHeadMountable DEBUG: LPEELER.moveToSafeZ(0.27)
2023-09-18 15:02:35.712 AbstractHeadMountable DEBUG: RPEELER.moveToSafeZ(0.27)
2023-09-18 15:02:35.712 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((69.931000, 53.439978, NaN, 0.000000 mm), 0.27)
2023-09-18 15:02:35.712 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being false handled as OFF
2023-09-18 15:02:35.713 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being false handled as OFF
2023-09-18 15:02:35.713 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((69.931000, 53.439978, 0.000000, 0.000000 mm), 0.27)
2023-09-18 15:02:35.714 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M204 S827 G1 X24.39       F11306 ; move to target, 10000)...
2023-09-18 15:02:35.714 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M204S827G1X24.39F11306
2023-09-18 15:02:35.714 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 15:02:35.714 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M204 S98 G1 X24.33       F600 ; move to target, 10000)...
2023-09-18 15:02:35.715 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M204S98G1X24.33F600
2023-09-18 15:02:35.715 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 15:02:35.716 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M400 ; Wait for moves to complete before returning, 37037)...
2023-09-18 15:02:35.716 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M114 ; get position, -1)...
2023-09-18 15:02:35.716 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M400
2023-09-18 15:02:35.716 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M114
2023-09-18 15:02:36.220 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 15:02:36.220 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok C: X:24.3300 Y:34.5400 Z:-0.2000 A:0.0000 B:0.0000 C:0.0000 D:0.0000
2023-09-18 15:02:36.221 GcodeDriver TRACE: Position report: ok C: X:24.3300 Y:34.5400 Z:-0.2000 A:0.0000 B:0.0000 C:0.0000 D:0.0000
2023-09-18 15:02:36.221 GcodeDriver TRACE: GcodeDriver got lastReportedLocation (X:24.330000, Y:34.540000, ZN:-0.200000, C1:0.000000, C2:0.000000, LPeel:0.000000, RPeel:0.000000)
2023-09-18 15:02:36.221 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete.
2023-09-18 15:02:36.221 ReferenceActuator DEBUG: DRAGPIN.actuate(true)
2023-09-18 15:02:36.222 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M816 S100 ; DRAGPIN M816 down @100%, 10000)...
2023-09-18 15:02:36.222 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(G4 P10 ; wait a little bit until the pin is down, 10000)...
2023-09-18 15:02:36.222 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M816 S10 ; switch to hold @10%, 10000)...
2023-09-18 15:02:36.222 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(; DRAGPIN M817 release, 10000)...
2023-09-18 15:02:36.222 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M816S100
2023-09-18 15:02:36.222 GcodeAsyncDriver DEBUG: serial://ttyUSB0 empty command after pre process
2023-09-18 15:02:36.222 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> G4P10
2023-09-18 15:02:36.222 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 15:02:36.222 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M816S10
2023-09-18 15:02:36.232 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 15:02:36.232 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 15:02:36.272 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((74.031000, 53.439978, 0.000000, 0.000000 mm), 0.27)
2023-09-18 15:02:36.272 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M119 ; DRAGPIN endstop status, 10000)...
2023-09-18 15:02:36.273 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M119
2023-09-18 15:02:36.273 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << X_min:0 Y_min:0 Z_min:1 pins- (X)P4.4:0 (Y)P4.3:0 (Z)P2.13:1 (Z)P4.2:0
2023-09-18 15:02:36.273 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 15:02:36.273 GcodeDriver TRACE: actuatorRead response: X_min:0 Y_min:0 Z_min:1 pins- (X)P4.4:0 (Y)P4.3:0 (Z)P2.13:1 (Z)P4.2:0
2023-09-18 15:02:36.273 ReferenceActuator DEBUG: DRAGPIN.read(): 0
2023-09-18 15:02:36.273 AbstractMachine TRACE: Exception caught, executing pending motion: java.lang.Exception: DRAGPIN interlock confirmation does not match: 0 vs. 1

at org.openpnp.machine.reference.ActuatorInterlockMonitor.interlockActuation(ActuatorInterlockMonitor.java:374)
at org.openpnp.machine.reference.driver.AbstractMotionPlanner.moveTo(AbstractMotionPlanner.java:158)
at org.openpnp.machine.reference.driver.ReferenceAdvancedMotionPlanner.moveTo(ReferenceAdvancedMotionPlanner.java:329)
at org.openpnp.machine.reference.ReferenceHead.moveTo(ReferenceHead.java:154)
at org.openpnp.spi.base.AbstractHeadMountable.moveTo(AbstractHeadMountable.java:243)
at org.openpnp.machine.reference.feeder.ReferencePushPullFeeder.feed(ReferencePushPullFeeder.java:448)
at org.openpnp.gui.FeedersPanel.feedFeeder(FeedersPanel.java:633)
at org.openpnp.gui.FeedersPanel$7.lambda$actionPerformed$0(FeedersPanel.java:585)
at org.openpnp.util.UiUtils.lambda$submitUiMachineTask$0(UiUtils.java:39)
at org.openpnp.spi.base.AbstractMachine$1.call(AbstractMachine.java:578)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)

2023-09-18 15:02:36.273 AbstractMachine TRACE: Machine entering idle state.
2023-09-18 15:02:36.273 MessageBoxes DEBUG: Error: java.lang.Exception: DRAGPIN interlock confirmation does not match: 0 vs. 1

  - Micael

[mark maker]

It seems your interlock logic is reversed. You are pushing the pin down, then when the drag is made it complains. But the drag must be allowed with the pin down.

You wrote:

> and conditions on drag pin actuator set to DRAGPIN / SWITCHED ON again

I guess that's wrong. The condition is for the interlock to be effective, not for the dragging.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8d09f600-2fae-4442-b6b2-6dc7f1d88f7en%40googlegroups.com.

[vespaman]

Thank you for your patience, Mark!

Correct, that was wrong! I tried it in "super tired snail pace", to be sure I did not crash the pin again.  And now it drags the tape.

Yet, there's no peel.

Log does not seem to do show any actual movement of C axis ( "Feed (Left side peel)" ).

2023-09-18 17:34:47.861 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete.
2023-09-18 17:34:47.862 ReferenceActuator DEBUG: DRAGPIN.actuate(true)
2023-09-18 17:34:47.862 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M816 S100 ; DRAGPIN M816 down @100%, 10000)...
2023-09-18 17:34:47.862 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(G4 P10 ; wait a little bit until the pin is down, 10000)...
2023-09-18 17:34:47.862 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M816 S10 ; switch to hold @10%, 10000)...
2023-09-18 17:34:47.862 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M816S100
2023-09-18 17:34:47.862 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(; DRAGPIN M817 release, 10000)...
2023-09-18 17:34:47.862 GcodeAsyncDriver DEBUG: serial://ttyUSB0 empty command after pre process
2023-09-18 17:34:47.862 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 17:34:47.862 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> G4P10
2023-09-18 17:34:47.862 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M816S10
2023-09-18 17:34:47.872 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 17:34:47.873 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 17:34:47.913 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((74.031000, 53.439978, 0.000000, 0.000000 mm), 0.08)
2023-09-18 17:34:47.913 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being true handled as ON
2023-09-18 17:34:47.916 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being true handled as ON
2023-09-18 17:34:47.916 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((73.931000, 53.439978, 0.000000, 0.000000 mm), 0.08)
2023-09-18 17:34:47.916 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being true handled as ON
2023-09-18 17:34:47.927 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being true handled as ON
2023-09-18 17:34:47.928 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M204 S40 G1 X28.38       F769 ; move to target, 10000)...
2023-09-18 17:34:47.928 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M204S40G1X28.38F769
2023-09-18 17:34:47.928 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 17:34:47.929 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M204 S10 G1 X28.45       F600 ; move to target, 10000)...
2023-09-18 17:34:47.929 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M204S10G1X28.45F600
2023-09-18 17:34:47.929 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 17:34:47.930 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M204 S9 G1 X28.39       F600 ; move to target, 10000)...
2023-09-18 17:34:47.930 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M204S9G1X28.39F600
2023-09-18 17:34:47.930 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 17:34:47.931 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M204 S10 G1 X28.33       F600 ; move to target, 10000)...
2023-09-18 17:34:47.931 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M204S10G1X28.33F600
2023-09-18 17:34:47.931 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 17:34:47.932 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M400 ; Wait for moves to complete before returning, 125000)...
2023-09-18 17:34:47.933 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M114 ; get position, -1)...
2023-09-18 17:34:47.933 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M400
2023-09-18 17:34:47.933 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M114
2023-09-18 17:34:48.917 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok
2023-09-18 17:34:48.918 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok C: X:28.3300 Y:34.5400 Z:-0.2000 A:-90.0000 B:0.0000 C:0.0000 D:0.0000
2023-09-18 17:34:48.918 GcodeDriver TRACE: Position report: ok C: X:28.3300 Y:34.5400 Z:-0.2000 A:-90.0000 B:0.0000 C:0.0000 D:0.0000
2023-09-18 17:34:48.918 GcodeDriver TRACE: GcodeDriver got lastReportedLocation (X:28.330000, Y:34.540000, ZN:-0.200000, C1:-90.000000, C2:0.000000, LPeel:0.000000, RPeel:0.000000)
2023-09-18 17:34:48.918 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete.
2023-09-18 17:34:48.918 ReferenceActuator DEBUG: DRAGPIN.actuate(false)
2023-09-18 17:34:48.918 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(; DRAGPIN M816 down @100%, 10000)...
2023-09-18 17:34:48.918 GcodeAsyncDriver DEBUG: serial://ttyUSB0 empty command after pre process
2023-09-18 17:34:48.918 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(; wait a little bit until the pin is down, 10000)...
2023-09-18 17:34:48.918 GcodeAsyncDriver DEBUG: serial://ttyUSB0 empty command after pre process
2023-09-18 17:34:48.918 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(; switch to hold @10%, 10000)...
2023-09-18 17:34:48.918 GcodeAsyncDriver DEBUG: serial://ttyUSB0 empty command after pre process
2023-09-18 17:34:48.918 GcodeAsyncDriver DEBUG: serial://ttyUSB0 commandQueue.offer(M817 ; DRAGPIN M817 release, 10000)...
2023-09-18 17:34:48.918 GcodeAsyncDriver$WriterThread TRACE: [serial://ttyUSB0] >> M817
2023-09-18 17:34:48.945 GcodeDriver$ReaderThread TRACE: [serial://ttyUSB0] << ok

 - Micael

[mark maker]

1. Check Issues & Solutions, you might have forgotten the G-Code after adding the axes.
   
2. Check if the axis is assigned.
3. Check you entered the Rotation coordinates, and everything else, as described here:
   https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder#coordinated-peeling

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c8f75398-9146-4db7-8339-3273f055db0en%40googlegroups.com.

[vespaman]

Yay!

It was (3). I had changed to another feeder without the needed changes for the rotation coordinates.

Thanks for all the help, now it is working!  

Now I need to clean up the config, update all feeders and test some more!

I think there are speed improvements to be done on the feeder motor like Jan mentioned. Maybe we can shave off some more.

@Jan, I saw that you have set your feeder rotation to 4 in mid, and 4 on the last position. Is there a reason for this? I copied this, and it works, but maybe it is better (=faster) to do 8 in mid, and nothing else.

Also I think I need to check my kernel governor and HZ setting, since it looks like there are scheduling delays here and there. Can't have that!

- Micael

[Jan]

On 18.09.2023 19:52, vespaman wrote:
[...]

> @Jan, I saw that you have set your feeder rotation to 4 in mid, and 4 on
> the last position. Is there a reason for this? I copied this, and it
> works, but maybe it is better (=faster) to do 8 in mid, and nothing else.

You specify absolute values there. So I'm peeling 4mm while dragging and
the peeler is at rest while releasing the drag pin. (I've set "Additive"
to that the peelers location is internally advanced only and never moves
backwards.)

Jan

[Jan]

Hi Mark!
Thats a cool idea! How is the inheritance of the coordinate system for
profile actuators and the related actuators?
The initial problem/idea why I suggested to have two drag pin actuators
was, that Micael wonts to operate the peeler on the left feeder bank
independently from the peeler on the right. So I thought, that two drag
pins could be setup with one for the left where the rotation axis points
to the left banks peeler and the drag pin for the right references the
right banks peeler. As we wont axis interlock for the drag pin, this
leads to the problem you obviously solved using the profile actuator.
However, I'm wondering wether Micael can have two different
peelers/rotation axis on his single drag pin when using profile
actuators in between.
If the profile actuators can specify rotaion axis and the drag pin does
not, the profile actuators definition could be passed on to the drag
pin. Is that how it works?

Jan

On 18.09.2023 09:12, 'mark maker' via OpenPnP wrote:
> Hi Jan, Micael,
>
> yes, the drag pin interlock is an issue.
>
> There is a way around it:
>

> 1. Make the *Feed* actuators into a *Profile* actuators by setting that
> *Value Type*:
> https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Actuators#actuator-value-type
> 2. Then add the actual (one and only) *Dragpin* actuator as *Actuator
> 1* on both profile actuator:
> https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Actuators#actuator-with-profiles
> 3. This way both *Feed* actuator will /indirectly/ actuate the /same/
> (one and only) *Dragpin *actuator.
> 4. Note: to be clear, you now need /three/ actuators, two *Feed* and
> one *Dragpin*.
> 5. The interlock then needs to be defined on the *Dragpin* actuator,
> /not/ the *Feed* actuator.

>> https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%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/7e4748a1-7e54-4b10-9833-e22586c0a6b9n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/7e4748a1-7e54-4b10-9833-e22586c0a6b9n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/7e4748a1-7e54-4b10-9833-e22586c0a6b9n%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/2f4a7e5f-3d73-4800-9eeb-6ba0f5a6c141n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/2f4a7e5f-3d73-4800-9eeb-6ba0f5a6c141n%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/ff76f1e4-11e6-c1d2-12d9-353adbd2e07d%40makr.zone <https://groups.google.com/d/msgid/openpnp/ff76f1e4-11e6-c1d2-12d9-353adbd2e07d%40makr.zone?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan,

>>You specify absolute values there. So I'm peeling 4mm while dragging and

Absolute? I see, in that case, your setting makes perfect sense. Good I asked before changing all my feeders :-)

Cheers,

 - Micael

[mark maker]

Hi Jan,

I hope I understand the actual question right.

The two Peel rotation axes, as well as the other axes are on the two (west and east) Feed actuators, not the (one and only) Dragpin actuator.

There is no "inheritance of the coordinate system". Only the Feed actuators have the axes assigned, and these are directly assigned to the feeders, i.e., only the two (west and east) Feed actuators are logically moved by the feeder.

The Dragpin actuator is now merely controlling the drag pin itself, i.e., logically it has no motion. A bit like the light or valve actuators, of course those move with their respective camera/nozzles, physically, but not logically.

The ReferencePushPullFeeder now has a short-coming that is on my radar. When you clone a feeder (Auto-Setup), it does not logically know whether it is a west or east feeder, so theoretically, it could clone the wrong Feed actuator and therefore the wrong Peel axis. I'll keep that in mind and add orientation (which is know by means of sprocket hole vs. pick location orientation) as a more dominant criteria for finding the cloning template.

_Mark

[mark maker]

Hmmm... are you sure these are mm?

The way I understand this, it should be degrees, being a rotation axis. The amount of protective film actually gobbled up will depend on the filling-up of the spool, right? There is slip in the coupling with the spool, right?

So you should specify the degrees of rotation needed to gobble up enough film, even when the spool is empty/smallest. This will then gradually be too much when it becomes fuller, but the slip coupling should take care of that. Right?

_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/326a55c8-ae51-499f-8263-e19c11d13bean%40googlegroups.com.

[vespaman]

Hi Mark,

>>The ReferencePushPullFeeder now has a short-coming that is on my radar. When you clone a feeder (Auto-Setup), it does not logically know whether it is a west or east feeder, so theoretically, it could >>clone the wrong Feed actuator and therefore the wrong Peel axis. I'll keep that in mind and add orientation (which is know by means of sprocket hole vs. pick location orientation) as a more dominant

FYI: It also clones the wrong position of the component OCR area, at least on my machine (I guess it might depends on machine geometry).

 - Micael

[Jan]

Hi Mark!
That depends on the configuration: you specify at controller level (and
in OpenPnP) the translation between some arbitrary unit and the amount
of steps, the motor will/shall rotate. For the peeler the default
configuration is to translate mm peeling (for an empty spool) into motor
steps. Therefore I configure the peeling distance in mm (due to the
ability of this configuration, there would be actually no need to
specify the peeling distance).
Yes, the peeler moves all feeders at once and has some slip coupling in
each take up wheel. Therefore only the feeder that is dragging will have
loose tape to be peeled. (It has some short comings because the friction
needs to be setup carefully for each tape and it tends to block when not
use for some time. With that in mind it works fairly well and is easy to
control.)

Jan

>> https://groups.google.com/d/msgid/openpnp/326a55c8-ae51-499f-8263-e19c11d13bean%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/326a55c8-ae51-499f-8263-e19c11d13bean%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/cc938492-e469-e5af-02dc-93d89ae46011%40makr.zone <https://groups.google.com/d/msgid/openpnp/cc938492-e469-e5af-02dc-93d89ae46011%40makr.zone?utm_medium=email&utm_source=footer>.

[Jan]

Hi Mark!
Many thanks for the clarification. I guess I now understand the new
setup: Micael now has two feed actuators setup one for the east and one
for his west side feeder bank. Each is referencing their respective
peeler axis as rotation axis in the location section and configured of
Profile type referencing the same drag pin actuator for dragging. So the
feed/profile actuator provides the information which peeler to move
while dragging and the drag pin actuator still contains the axis
interlock logic as before. Thats a clever setup and completely without
any addition fiddling around!

Jan

On 19.09.2023 09:32, 'mark maker' via OpenPnP wrote:
> Hi Jan,
>

> I hope I understand the /actual /question right.
>
> The two *Peel* rotation axes, as well as the other axes are on the two
> (west and east) *Feed* actuators, not the (one and only) *Dragpin* actuator.
>
> There is no "inheritance of the coordinate system". Only the *Feed*
> actuators have the axes assigned, and these are /directly/ assigned to
> the feeders, i.e., only the two (west and east) *Feed* actuators are

> logically moved by the feeder.
>

> The *Dragpin* actuator is now merely controlling the drag pin itself,

> i.e., logically it has no motion. A bit like the light or valve
> actuators, of course those move with their respective camera/nozzles,
> physically, but not logically.
>

> The ReferencePushPullFeeder now*has a short-coming that is on my radar*.
> When you clone a feeder (Auto-Setup), it does not /logically/ know

> whether it is a west or east feeder, so theoretically, it could clone

> the wrong *Feed* actuator and therefore the wrong *Peel* axis. I'll keep
> that in mind and add *orientation* (which is know by means of sprocket

> https://groups.google.com/d/msgid/openpnp/4a347870-e3bc-3423-1bf4-d2aca6720c0e%40makr.zone <https://groups.google.com/d/msgid/openpnp/4a347870-e3bc-3423-1bf4-d2aca6720c0e%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

> FYI: It also clones the wrong position of the component OCR area, at least on my machine (I guess it might depends on machine geometry).

Are you sure? This should really, really not be the case.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4c55cac8-296c-4515-8141-81f30ac22cban%40googlegroups.com.

[OpenPnP]

Well, maybe it has been fixed since. But when I did my feeder setup, it was an issue (a very small one, but never the less).

 - Micael

[vespaman]

Hi Jan,

After I added the pin-wait code, I found on a small test run, that the drag pin has some serious bounce issues. Since it is very looong bounce time, I figured I could not wait for it, so now the code simply reports "ok" as soon as it is seen up, without any debounce checks taking place.

But instead I added debounce checks when OpenPnP queries the pin a couple of 10th ms later. Normally, the bouncing has stopped by then, but if not I wait up to 100ms here.

I should perhaps enhance that code, since I will always wait for up to 100ms is reported not up, even if pin is supposed to be down (driven down). But I don't think the M219 query is ever sent after a M816 so I might get away with it.

So, I had to do a batch of 50 boards, and I figured it would be faster to throw in some anti sticktion code rather than dealing with it in runtime, so I added a very simple wiggle of X-0.05, then X+0.1, followed by X-0.05 Y-0.05 and lastly Y+0.10 (relative moves). This seems to have an effect, looking in the log, I can see a couple of times where at least the wiggle code where executing (because of the time delay of the "ok" in the log). Now, of course the pin might have been released by itself if I had not had the wiggle code in place. But I get the feeling it does work. I make no distinction between left and right right feeder bank.

During the 50 boards, I still got stuck a couple of times, but every time (apart from one, where the tape had caught a corner of the machine) , I could release it simply by actuating the drag pin on, then off again. When the machine is still, it is easy to see the vibration. I think all (or at least most) of the times it stuck on the right feeder bank, maybe because of the "wiggle start in wrong direction".

So if you want to do the script version, this might be a good starting point.

I will add a little bit more (-0.1/+0.2) in X, and I will also continue a couple of rounds more, now it gives up after the single loop, but there's really no point in doing the loop a couple of times, maybe 3 or so.

So the timeline is currently as such;

release pin, wait up to 100ms. (normally pin is reported up after 20-40ms)

Then, If not sensed up, start first wiggle, wait for motion stop, then wait up to 40ms for pin sensor. Then if still not up, next wiggle, and so on.

But next version will be looping the 6 wiggles for about a second. I can't imagine it will stay stuck after that.

 - Micael

[Jan]

Hi Micael!
Very interesting findings! Seems, that there is much more with the drag
pin then I thought.
I suppose you've added all your code into the controller, did you?
Concerning the bouncing: the bouncing itself is not unexpected. There
is no damping at the upper end so the energy stored in the spring hat to
go somewhere else. Adding some material that absorbs it in a controlled
manner would be perfect, but there is - again - limited space... Do you
know how match the pin bounces back? Would it stuck if you start move
immediately when it reported up?
My major concern with the wiggle was and is, that it masks the actual
problem. So I'd love to get a good indication in the logs that there is
a problem and that the wiggle was required to fix it.
I actually only had problems with the drag pins Y position. X is
something that to my mind can be configured. (I'm always wondering
whether this configuration is speed dependent and hence only run the
machine at 100%.) If the pin gets stuck for me, I have to reconfigure Y
by 0.2..0.3mm. That's leads to my conclusion that the pin can handle
+-0.2mm errors well and that your initial 0.05mm wiggle might be a
little bit small.

Jan

> /> FYI: It also clones the wrong position of the component OCR

> area, at least on my machine (I guess it might depends on

> machine geometry). //
> /

>
> Are you sure? This should really, really not be the case.
>
> _Mark
>
> On 19.09.2023 10:13, vespaman wrote:
>> Hi Mark,
>>

>> >>The ReferencePushPullFeeder now*has a short-coming that is
>> on my radar*. When you clone a feeder (Auto-Setup), it does
>> not /logically/ know whether it is a west or east feeder, so
>> theoretically, it could >>clone the wrong *Feed* actuator and
>> therefore the wrong *Peel* axis. I'll keep that in mind and
>> add *orientation* (which is know by means of sprocket hole vs.

>> pick location orientation) as a more dominant
>>
>> FYI: It also clones the wrong position of the component OCR
>> area, at least on my machine (I guess it might depends on
>> machine geometry).
>>
>>  - Micael
>> tisdag 19 september 2023 kl. 09:32:41 UTC+2 skrev ma...@makr.zone:
>>
>> Hi Jan,
>>

>> I hope I understand the /actual /question right.
>>

>> The two *Peel* rotation axes, as well as the other axes
>> are on the two (west and east) *Feed* actuators, not the
>> (one and only) *Dragpin* actuator.

>>
>> There is no "inheritance of the coordinate system". Only

>> the *Feed* actuators have the axes assigned, and these are
>> /directly/ assigned to the feeders, i.e., only the two
>> (west and east) *Feed* actuators are logically moved by
>> the feeder.
>>
>> The *Dragpin* actuator is now merely controlling the drag

>> pin itself, i.e., logically it has no motion. A bit like
>> the light or valve actuators, of course those move with
>> their respective camera/nozzles, physically, but not
>> logically.
>>

>> The ReferencePushPullFeeder now*has a short-coming that is
>> on my radar*. When you clone a feeder (Auto-Setup), it
>> does not /logically/ know whether it is a west or east
>> feeder, so theoretically, it could clone the wrong *Feed*
>> actuator and therefore the wrong *Peel* axis. I'll keep
>> that in mind and add *orientation* (which is know by means

>>>> https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Actuators#actuator-value-type <https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Actuators#actuator-value-type>

>>>>  2. Then add the actual (one and only) *Dragpin*
>>>> actuator as *Actuator
>>>>     1* on both profile actuator:

>>>> https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Actuators#actuator-with-profiles <https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Actuators#actuator-with-profiles>

>>>>> (https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png <https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png> <https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png> <https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png> <https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png <https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png> <https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png> <https://user-images.githubusercontent.com/9963310/158563736-3c94a813-d7ef-43c6-bf0e-9a9ce76aa34d.png>>).

>>>>> https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/ff80df87-4a60-4259-82f3-7fc7f2546878n%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/7e4748a1-7e54-4b10-9833-e22586c0a6b9n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/7e4748a1-7e54-4b10-9833-e22586c0a6b9n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/7e4748a1-7e54-4b10-9833-e22586c0a6b9n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/7e4748a1-7e54-4b10-9833-e22586c0a6b9n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/7e4748a1-7e54-4b10-9833-e22586c0a6b9n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/7e4748a1-7e54-4b10-9833-e22586c0a6b9n%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/2f4a7e5f-3d73-4800-9eeb-6ba0f5a6c141n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/2f4a7e5f-3d73-4800-9eeb-6ba0f5a6c141n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/2f4a7e5f-3d73-4800-9eeb-6ba0f5a6c141n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/2f4a7e5f-3d73-4800-9eeb-6ba0f5a6c141n%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/ff76f1e4-11e6-c1d2-12d9-353adbd2e07d%40makr.zone <https://groups.google.com/d/msgid/openpnp/ff76f1e4-11e6-c1d2-12d9-353adbd2e07d%40makr.zone> <https://groups.google.com/d/msgid/openpnp/ff76f1e4-11e6-c1d2-12d9-353adbd2e07d%40makr.zone?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/ff76f1e4-11e6-c1d2-12d9-353adbd2e07d%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.
>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/openpnp/4c55cac8-296c-4515-8141-81f30ac22cban%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/4c55cac8-296c-4515-8141-81f30ac22cban%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/14b0c40e-4d07-4edf-a439-a78c90794159n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/14b0c40e-4d07-4edf-a439-a78c90794159n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan,

Yes, I did it in the controller. And, yes, the bouncing is not surprising at all, just something I originally did not consider (and it was hidden in that huge delay of course). I would like to just add a bit of black tape or something to the stop above the drag pin, but it is hard to get to (I think the head, or at least the PCB gotta go in order to do anything to that area), and I am not sure it is worth it. In the end, it seems to work pretty fine (and I don't have the time right now to take it apart).

The only reason that it is easy for me to do FW work, is that I have left  a ethernet jlink in the chmt, so I don't have to "do anything" to change FW.

No, i don't think it bounces that much, but it is relatively heavy and the spring is weak, so it make sense that it is a long time. I don't really see any issues with it, the way I have done it now. But I'd like to (in the future) revisit, and add a check on the M119 in then endstop code, to make sure to do the debounce when the pin is supposed to be up, because if there's  a change some time in the future of OpenPnP it will add an unnecessary 100ms delay.

Yes, I think it would be nice to add it to the logs - while you can actually see it now, if you look closely, it would be better in clear text. I'll probably add that at some point, as a comment on the "ok" message, giving the wiggle distance and direction. I think I will also add it to a LED on my machine, so it lits when a wiggle-free has happened, until the next drag pin actiavation.

I have seen Y issues, but very rarely. I have Y adjusted by vision at least once every work day. Do you?

X is much more prominent here, i suspect it depends on which components one are using. Normally X issues happens for me, when the tape it very thick (and struggle to go down in the waste-slot, pushes back like a spring). This tends to be a bit random.

(Also, I think the previous owner of this machine has "tweaked" the springs in the feeders, or they where simply a bit random from factory, because they are all quite different between themselves.

And yes, maybe 0.05 is an unnecessary step, like you say. I do think that +/-100 is very large, given that the pin will want to go up during the wiggling, so I doubt that more is needed. But I guess future will tell.

I just tested my updated code, (three times of 6 wiggles), and it is much more noticeable, and continues for just over once second it you hold the pin down. I figure if i remove the 0.05 wiggles, it could stay within the second. (not that that is important).

Anyway, the stops (be it drag pin, peel issues, nozzle changes) are killing the flow, so one after another, they must be dealt with.

As a side note - I finally changed to GC10 solder paste - why did I not do that sooner? What a difference! One less problem.

- Micael

torsdag 12 oktober 2023 kl. 21:08:49 UTC+2 skrev Jan:

Hi Micael!

[Thorsten.R]

Hi,

Very interesting everything .

A small note about the GC-10 paste.
I have also used GC-10 for years, but for some time Felder ISO Cream - "Active Clear". This I find even better than the GC-10, this comes with 150 degrees heating temperature and needs a shorter peak phase. The curve can be flatter, especially with 4 layers.. It is even less complicated than the GC-10.
It is also compared in the data sheet with the GC-10.

[vespaman]

Hi Thorsten,

I'm already in heaven :-) but a good alternative is always interesting. I could not really find any data sheet on the "active clear", only some dating back to 2008, which looks to be an older variant, is that the one you are referring to?

 - Micael

[Thorsten.R]

Hi Micael,

https://www.multi-circuit-boards.eu/en/products/smd-stencils/pcb-solder-paste.html

but only a Safety data sheet from 2020.

Felder is an german company.

But especially on my 4-layer PCBs with solid inner layers, this requires a little less temperature, which is important for the FPC sockets and LEDs. The curve is very long so that the temperature is reached. With 2 layers long total =<3 minutes at 150/230 degrees. My experience. :)

[Thorsten.R]

Hi Jan,

You will add the drag pin patch to your FW later, as I use this on my CHMT36.

For me it rarely gets stuck on the thin plastic tapes.

[Jan]

Hi Thorsten!
If you're changing the smoothie code and you're using the peeler as
axis, you might wont to consider adjusting the peelers limits. As port
of this thread I found out, that my peeler is configured slower then the
X axis making it the limiting factor of the drag move.

Jan

On 14.10.2023 01:22, 'Thorsten.R' via OpenPnP wrote:
> Hi Jan,
> You will add the drag pin patch to your FW later, as I use this on my
> CHMT36.
> For me it rarely gets stuck on the thin plastic tapes.
>
>
> Thorsten.R schrieb am Samstag, 14. Oktober 2023 um 01:18:52 UTC+2:
>
>
> Hi Micael,

> https://www.multi-circuit-boards.eu/en/products/smd-stencils/pcb-solder-paste.html <https://www.multi-circuit-boards.eu/en/products/smd-stencils/pcb-solder-paste.html>

> --
> 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/af331dbd-c36f-4a2a-b144-85cc7fa67185n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/af331dbd-c36f-4a2a-b144-85cc7fa67185n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Thorsten.R]

Hi Jan,
I have never dealt with the FW.
I had first tried the proposed in the wiki but that was nothing then your flashed and the purrs like a kitten after a few settings.

The hangers I also have only rarely on the plastic tapes.

Thorsten

[vespaman]

Hi Jan,

So what are your numbers to those?

I checked today, increased my X and Y which where both very low/conservative, to new

X rate 126000, acc 20000, jerk 800000

Y rate 90000, acc 6000, jerk 600000

But peeler is limited in FW config, right? So it will not catch up, I have it at;

rate 100000, acc 10000, jerk 800000.  - so both rate and acceleration is lower than X. I'm not sure how much this has been tweaked, since it is not as simple to find out the actual max speed and more importantly, acceleration. Maybe we can find some 10th of ms there. On my machine now, the actual drag takes 160ms (only the move, pin up/down not included).

If I push X and Y more, I can get it to miss steps, but only when I do repeated (tripple-click) 100mm jogs, on the breaking it seems. Not sure if this is a relevant test, but I don't want to find out during a job.

Still, I am not at stock fw level speed (not surprising) ( spec says 4000CPH with bottom vision for the 48VB, I presume this is with everything optimal (i.e. same nozzle on both holders, 0402, and not too far away feeder etc).)

But also looking at Randys video I timed his stock fw pick with one nozzle to about ~1.7s (clocked by hand, so there's a lot of play here) each place, and tried recreating this on my machine, I hit about 2.4s for what I think is a similar setup.

Roughly 30% slower, but then the 36 according to spec is slightly slower than the 48, so result might be slightly worse than 30% if compared to a stock 48VB.

Do you remember, if the stock fw/sw did emit any logs of interest?

Maybe one thing is, that I have sneak up on X & Y, presumably this might make a mark in the speed performance. (0.03 target tol (maybe this is unnecessary? I am only placing 0402, so nothing small, really)).

I'm getting more and more interested in doing the 100%->10% drag pin limit in FW. While it is only 10ms, it is still 10ms.. :-)

 - Micael

[Jan]

Hi Micael!
I just look up, that the peeler settings are lower then my actual X
axis limits, but did not changed them yet. If you're using the peeler as
axis, you can configure the actual values using the GUI. So it does not
matter what you enter in the config file, just keep the values high
enough and adjust them later. I've now put in the limits of my X axis.
I've my machine on a slightly shaking table and therefor run at reduced
speed. X is at 18e2 mm/s and 18e3 mm/s^2 and Y at 14e2 mm/s and 6e3
mm/s^2. Jerk is don't care as I don't have third order control.
Maybe the Z axis could be operated faster: if you have any good idea
how to measure/detect if the spring can follow, you might drive it
harder. I once destroyed a nozzle by driving Z so hard, that the nozzle
was not up before the XY move started and hence crashed into something.
From the original firmware I backuped, that the motors where configured
to 1600 "Pulse (ppmm)", 800 "Speed (rpm)" and 80 "Acceleration rps2".
Unfortunately I don't know how that translates.
I know, that its very hard to beat the speed of the original firmware.
That's a general warning to everyone willing to convert. No, I've never
seen any log from the Chinese firmware.
I've started tweaking OpenPnPs job processor a little bit to optimize
the movements if multiple nozzles are used. It's currently on hold
because there are multiple feeders affected that could void the general
behavior. I'm using the code for some month now and it provides good
results.
I've no backlash compensation in place. The automatic calibration
procedure shows something like +-0.03mm error, which I think is ok.
Camera and Nozzle calibration error are in the same order, so I think
it's not dominate.
Concerning the drag pin: you only need to switch to ~10% if you wont to
operate it for a longer time (multiple seconds). Within a job its
totally fine to operate it at 100%. So just remove the 10ms and switch
down for the job and maybe have a second actuator for testing.

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/52a1392d-6b73-48c3-bdde-ef201d34b82an%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/52a1392d-6b73-48c3-bdde-ef201d34b82an%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan,

Good to hear about the Job processor stuff!

My goal with the speed optimization stuff I'm doing, is just to do as good as possible - the stock fw is a good reference. 

I think there are places e.g. better placement accuracy etc of openPnP that validates a slightly slower operation, but I want to make sure that is where we are loosing time, and not in places that does not do nothing.

The speed up is already significant from where I was this summer! I wouldn't be surprised if it will land at almost twice the speed of what I had before starting the optimizations, when I'm done. Which means more panels during a work day. :-)

I have been examining the logs, more, and it has some delays here and there, that I can't explain.

Here's the breakdown of one pick/place cycle as of todays setting;

Or, maybe better like this;

As you can see, the "Move to pick position" is way long still. I think this is bc the limit of the peeler max values in FW (Have not yet up'd them) that spills over, so there's still huge gains to be found there!

But then there's some delays that I found that might be hard coded in OpenPnP, or maybe because of my settings? 

In essence;

After drag pin has been activated, there's 40ms delay.

Snippet;

2023-10-28 17:36:11.859 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-10-28 17:36:11.859 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M816S10
2023-10-28 17:36:11.869 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-10-28 17:36:11.869 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok

@start draging 202ms;
>> 40ms delay ??
2023-10-28 17:36:11.909 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((74.661476, 144.397624, 0.000000, 4.000000 mm), 1.0)
2023-10-28 17:36:11.909 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being true handled as ON
2023-10-28 17:36:11.911 ActuatorInterlockMonitor TRACE: DRAGPIN interlock masked by conditionalActuator DRAGPIN being true handled as ON
2023-10-28 17:36:11.911 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((74.596476, 144.397624, 0.000000, 4.000000 mm), 1.0)

After drag pin has been released, there's 30ms delay.

Snippet;

2023-10-28 17:36:12.071 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M817 ; DRAGPIN M817 release
2023-10-28 17:36:12.071 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M817
2023-10-28 17:36:12.092 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok

@Move to pick position 449ms;

>> 30ms delay ??

2023-10-28 17:36:12.122 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> G92      C0.0000  ; reset coordinates
2023-10-28 17:36:12.122 ReferenceHead DEBUG: H1.moveToSafeZ(1.0)
2023-10-28 17:36:12.122 AbstractHeadMountable DEBUG: N1.moveToSafeZ(1.0)

Just before move to pick (only 12ms, but ..)

2023-10-28 17:36:12.123 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M119 ; DRAGPIN endstop status
2023-10-28 17:36:12.124 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M119
2023-10-28 17:36:12.124 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << X_min:0 Y_min:0 Z_min:1 pins- (X)P4.4:0 (Y)P4.3:0 (Z)P2.13:1 (Z)P4.2:1
2023-10-28 17:36:12.124 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-10-28 17:36:12.124 GcodeDriver TRACE: actuatorRead response: X_min:0 Y_min:0 Z_min:1 pins- (X)P4.4:0 (Y)P4.3:0 (Z)P2.13:1 (Z)P4.2:1
2023-10-28 17:36:12.124 ReferenceActuator DEBUG: DRAGPIN.read(): 1
>>12ms delay ??
2023-10-28 17:36:12.136 AbstractHeadMountable DEBUG: N1.moveTo((60.788812, 140.962395, -10.300000, -90.000000 mm), 1.0)
2023-10-28 17:36:12.136 ReferenceNozzle TRACE: N1.toHeadLocation((60.788812, 140.962395, -10.300000, -112.384586 mm), ...) rotation mode offset 22.384585808152167
2023-10-28 17:36:12.136 ReferenceNozzle TRACE: N1.toHeadLocation((60.796028, 140.896249, -10.300000, -112.384586 mm), ...) runout compensation (-0.007216, 0.066146, 0.000000, 0.000000 mm)
2023-10-28 17:36:12.136 ReferenceNozzle DEBUG: N1.pick()

After activating vacuum

(I have  a pick dwell time 20ms on the nozzle tip, nothing on the nozzle head, but I don't this is it)

2023-10-28 17:36:12.542 ReferenceActuator DEBUG: AVAC1.actuate(true)
2023-10-28 17:36:12.542 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> ; H1 N1VAC ACTUATE_BOOLEAN_COMMAND
2023-10-28 17:36:12.542 GcodeAsyncDriver DEBUG: GcodeDriver:ttyUSB0 empty command after pre process
2023-10-28 17:36:12.542 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M800 ; on, open solenoid valve, RED led ON on soleonid
2023-10-28 17:36:12.542 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M800
2023-10-28 17:36:12.542 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
>>50ms delay
2023-10-28 17:36:12.592 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> ; H1 N1VAC ACTUATOR_READ_COMMAND
2023-10-28 17:36:12.592 GcodeAsyncDriver DEBUG: GcodeDriver:ttyUSB0 empty command after pre process
2023-10-28 17:36:12.592 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M105 ; read vacuum

and then finally;

After enabling up LED

@Camera, take picture 131ms;
2023-10-28 17:36:13.072 ReferenceActuator DEBUG: UPLED.actuate(true)
2023-10-28 17:36:13.072 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0] commandQueue offer >> M810 ; UPLED M810 on / M811 off
2023-10-28 17:36:13.072 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M810
2023-10-28 17:36:13.072 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
>>50ms delay?
2023-10-28 17:36:13.122 Scripting TRACE: Scripting.on Camera.BeforeSettle

And regarding the drag pin 10% - it is also very useful when debugging firmware, one less thing to worry about.. So it will stay, but maybe I'll put it into the fw later on, it should be easy.

 - Micael

[Jan]

Hi Micael!
Interesting analysis you did. Yes, I agree, that the move from drag end
location to pick location shall not take as long as pcb to drag start
location or pick location to bottom camera. They are both much further
away compared to the about 40mm in Y between drag pin and nozzle.
In general, I'm with you finding an fixing any issues in the processing
speed. I agree with you that waiting for the machine is not that funny
anymore and if it can be fixed in software, we should do it.
IIRC Mark once mentioned, that the GCodeAsyncDriver (which we likely
all use) has a send and receive queue. It collect everything into the
send queue and somehow decides when to send. This is good, as the driver
can feed the controller with everything he has keeping the controller
busy. This is not so good (yet) for debugging as the reader can not be
easily synced to the writer when looking into the logs. Anyhow, as long
as the writer queue is not empty, the controller gets more data and the
machine is moving as fast as it can (or as commanded).
However, if there is any coordination required, the machine is stopped
and a few write/read cycles are executed until it starts moving again.
This is costly because there are multiple boundaries to be crossed
(Serial -> USB -> kernel driver -> user space -> gcode driver reader
thread -> requesting actuator ... and all the way back). (To my
understanding all this is handled more fluent by Linux compared to
Windows and that's the reason why many of us are using OpenPnP on
Linux.) So my first advice would be to get rid of any unnecessary
coordination requirement.
To find out whats actually happening and where delays are introduced,
I'd suggest, that you look at the gcode, that's send to the controller.
With a certain delay from that, the machine will do something. If you
find any M400 (IIRC that's the command used to make the controller empty
its queue, finish all movements and then acknowledge) I'd suggest to
find out if they are really needed because that's where time is spend.
To my limited understanding, a general flaw in gcode is, that (some?)
M-commands are handled asynchronously from G-commands. That means that
movements (send as G1) are queued and joined as good as possible but
M-commands to operate the vacuum or drag pin are handled asynchronously
requiring a dedicated synchronization in the upper layer (OpenPnP).
Just to recap from the reverse engineering of the Chinese controller
firmware: The entire job is send as a single blob (or as multiple
smaller blobs) only interrupted when really needed, like for vision
operations. As long as we can not have the same functionality (with or
without G-Code), OpenPnP can never be as fast as the Chinese software.
However, OpenPnP is open source, has a better UI and we can modify it as
required. That's a huge difference and - at least for me - outweighs
some of its current performance penalty.

Jan

On 29.10.2023 10:23, vespaman wrote:
> Hi Jan,
> Good to hear about the Job processor stuff!
>
> My goal with the speed optimization stuff I'm doing, is just to do as
> good as possible - the stock fw is a good reference.
> I think there are places e.g. better placement accuracy etc of openPnP
> that validates a slightly slower operation, but I want to make sure that
> is where we are loosing time, and not in places that does not do nothing.
> The speed up is already significant from where I was this summer! I
> wouldn't be surprised if it will land at almost twice the speed of what
> I had before starting the optimizations, when I'm done. Which means more
> panels during a work day. :-)
>
> I have been examining the logs, more, and it has some delays here and
> there, that I can't explain.
> Here's the breakdown of one pick/place cycle as of todays setting;

> Screenshot_20231029_093820.png
> Or, maybe better like this;

> Screenshot_20231029_093944.png
>
>
>
>
> As you can see, the "Move to pick position" is way long still. I think
> this is bc the limit of the peeler max values in FW (Have not yet up'd
> them) that spills over, so there's still huge gains to be found there!
>
> But then there's some delays that I found that might be hard coded in
> OpenPnP, or maybe because of my settings?
>
>
> In essence;

> *After drag pin has been activated, there's 40ms delay. *

> Snippet;
> 2023-10-28 17:36:11.859 GcodeDriver$ReaderThread TRACE:
> [GcodeDriver:ttyUSB0] << ok
> 2023-10-28 17:36:11.859 GcodeAsyncDriver$WriterThread TRACE:
> [GcodeDriver:ttyUSB0] >> M816S10
> 2023-10-28 17:36:11.869 GcodeDriver$ReaderThread TRACE:
> [GcodeDriver:ttyUSB0] << ok
> 2023-10-28 17:36:11.869 GcodeDriver$ReaderThread TRACE:
> [GcodeDriver:ttyUSB0] << ok
> @start draging 202ms;
> >> 40ms delay ??
> 2023-10-28 17:36:11.909 AbstractHeadMountable DEBUG: Feed (Left side
> peel).moveTo((74.661476, 144.397624, 0.000000, 4.000000 mm), 1.0)
> 2023-10-28 17:36:11.909 ActuatorInterlockMonitor TRACE: DRAGPIN
> interlock masked by conditionalActuator DRAGPIN being true handled as ON
> 2023-10-28 17:36:11.911 ActuatorInterlockMonitor TRACE: DRAGPIN
> interlock masked by conditionalActuator DRAGPIN being true handled as ON
> 2023-10-28 17:36:11.911 AbstractHeadMountable DEBUG: Feed (Left side
> peel).moveTo((74.596476, 144.397624, 0.000000, 4.000000 mm), 1.0)
>
>

> *After drag pin has been released, there's 30ms delay.*

> Snippet;
> 2023-10-28 17:36:12.071 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0]
> commandQueue offer >> M817; DRAGPIN M817 release
> 2023-10-28 17:36:12.071 GcodeAsyncDriver$WriterThread TRACE:
> [GcodeDriver:ttyUSB0] >> M817
> 2023-10-28 17:36:12.092 GcodeDriver$ReaderThread TRACE:
> [GcodeDriver:ttyUSB0] << ok
> @Move to pick position 449ms;
> >> 30ms delay ??
> 2023-10-28 17:36:12.122 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0]
> commandQueue offer >> G92      C0.0000  ; reset coordinates
> 2023-10-28 17:36:12.122 ReferenceHead DEBUG: H1.moveToSafeZ(1.0)
> 2023-10-28 17:36:12.122 AbstractHeadMountable DEBUG: N1.moveToSafeZ(1.0)
>
>

> *Just before move to pick (only 12ms, but ..)
> *

> 2023-10-28 17:36:12.123 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0]
> commandQueue offer >> M119 ; DRAGPIN endstop status
> 2023-10-28 17:36:12.124 GcodeAsyncDriver$WriterThread TRACE:
> [GcodeDriver:ttyUSB0] >> M119
> 2023-10-28 17:36:12.124 GcodeDriver$ReaderThread TRACE:
> [GcodeDriver:ttyUSB0] << X_min:0 Y_min:0 Z_min:1 pins- (X)P4.4:0
> (Y)P4.3:0 (Z)P2.13:1 (Z)P4.2:1
> 2023-10-28 17:36:12.124 GcodeDriver$ReaderThread TRACE:
> [GcodeDriver:ttyUSB0] << ok
> 2023-10-28 17:36:12.124 GcodeDriver TRACE: actuatorRead response:
> X_min:0 Y_min:0 Z_min:1 pins- (X)P4.4:0 (Y)P4.3:0 (Z)P2.13:1 (Z)P4.2:1
> 2023-10-28 17:36:12.124 ReferenceActuator DEBUG: DRAGPIN.read(): 1
> >>12ms delay ??
> 2023-10-28 17:36:12.136 AbstractHeadMountable DEBUG:
> N1.moveTo((60.788812, 140.962395, -10.300000, -90.000000 mm), 1.0)
> 2023-10-28 17:36:12.136 ReferenceNozzle TRACE:
> N1.toHeadLocation((60.788812, 140.962395, -10.300000, -112.384586 mm),
> ...) rotation mode offset 22.384585808152167
> 2023-10-28 17:36:12.136 ReferenceNozzle TRACE:
> N1.toHeadLocation((60.796028, 140.896249, -10.300000, -112.384586 mm),
> ...) runout compensation (-0.007216, 0.066146, 0.000000, 0.000000 mm)
> 2023-10-28 17:36:12.136 ReferenceNozzle DEBUG: N1.pick()
>

> *After activating vacuum*

> (I have  a pick dwell time 20ms on the nozzle tip, nothing on the nozzle
> head, but I don't this is it)
> 2023-10-28 17:36:12.542 ReferenceActuator DEBUG: AVAC1.actuate(true)
> 2023-10-28 17:36:12.542 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0]
> commandQueue offer >> ; H1 N1VAC ACTUATE_BOOLEAN_COMMAND
> 2023-10-28 17:36:12.542 GcodeAsyncDriver DEBUG: GcodeDriver:ttyUSB0
> empty command after pre process
> 2023-10-28 17:36:12.542 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0]
> commandQueue offer >> M800 ; on, open solenoid valve, RED led ON on soleonid
> 2023-10-28 17:36:12.542 GcodeAsyncDriver$WriterThread TRACE:
> [GcodeDriver:ttyUSB0] >> M800
> 2023-10-28 17:36:12.542 GcodeDriver$ReaderThread TRACE:
> [GcodeDriver:ttyUSB0] << ok
> >>50ms delay
> 2023-10-28 17:36:12.592 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0]
> commandQueue offer >> ; H1 N1VAC ACTUATOR_READ_COMMAND
> 2023-10-28 17:36:12.592 GcodeAsyncDriver DEBUG: GcodeDriver:ttyUSB0
> empty command after pre process
> 2023-10-28 17:36:12.592 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0]
> commandQueue offer >> M105 ; read vacuum
>
> and then finally;

> *After enabling up LED*

> @Camera, take picture 131ms;
> 2023-10-28 17:36:13.072 ReferenceActuator DEBUG: UPLED.actuate(true)
> 2023-10-28 17:36:13.072 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0]
> commandQueue offer >> M810 ; UPLED M810 on / M811 off
> 2023-10-28 17:36:13.072 GcodeAsyncDriver$WriterThread TRACE:
> [GcodeDriver:ttyUSB0] >> M810
> 2023-10-28 17:36:13.072 GcodeDriver$ReaderThread TRACE:
> [GcodeDriver:ttyUSB0] << ok
> >>50ms delay?
> 2023-10-28 17:36:13.122 Scripting TRACE: Scripting.on Camera.BeforeSettle
>
>
>
> And regarding the drag pin 10% - it is also very useful when debugging
> firmware, one less thing to worry about.. So it will stay, but maybe
> I'll put it into the fw later on, it should be easy.
>
>
>  - 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[mark maker]

Hi Jan, Micael,

if I remember correctly, the CHMT boards usually lack serial hardware flow control, therefore you need to enable so-called "Confirmation Flow Control" in OpenPnP, which takes care of it, but also costs some time, especially since the transmission baudrate is also not so high on CHMT serial (vis-a-vis true USB serial on other controllers). Some users modified their boards and/or the firmware to improve this situation, but I don't recall if you guys are among them.

So if you really want to go down that rabbit hole, you would have to fix that issue too.

Then the next thing would probably be the Actuator machine coordination. Some Actuators can be actuated in uncoordinated fashion without harm. For instance a light can be switched on, before the camera (or its subject, the nozzle) actually arrived at the location to take a shot. But be careful, other actuator such as drag pins, must of course wait! Make sure these are all carefully evaluated and optimized.

Other than that you have to realize that coordination is needed, between controller/machine and computer. You can't do proper computer vision without waiting for the camera or its subject to be at the right location. And conversely, you cannot command the next machine move, before you have the compensatory result of the computer vision.

More "primitive" sensing can be implemented on the controller, vacuum sensing, drag pin confirmation, contact probing etc. some of which you already discussed earlier. To be clear, coordination per se is still needed, but it is much faster/"real time", when on the controller.

As far as I know, the CHMT also has some form of closed loop to detect lost steps on the stepper motors, and compensate for them. This allows it to work right at the limit of the steppers. The Smoothie port does not support that yet, AFAIK, so that would be another venue for improvement. OpenPnP cannot help you there.

It is these "closed loop" / "real time" advantages that make the factory software and firmware faster, as far as I know. Plus an amount of tuning they can really only afford as the manufacturer.

Other than that, I don't see why OpenPnP should be any slower to operate the hardware,

However, to be completely frank: OpenPnP has other shortcomings that may make it slower than factory software (now I'm talking all such software, not only CHMT). As I said numerous times, OpenPnP's JobProcessor does not optimize multi-nozzle placements. It will only optimize the number of needed nozzle tip changes, but not the co-location of feeders/pick locations. So it will needlessly scoot all over the machine to pick parts, instead of choosing feeders that are close together. 

Needless to say, it will also never trade in an extra nozzle tip change in order to facilitate such co-located feeder picks, even if that were much more efficient in the end. Or leave one nozzle empty, if the detour is more expensive than doing the placement first.

Though, I don't know if the CHMT factory software does it any better that way... ?

_Mark

[Jan]

Hi Mark!
Here's what I've learned and remembered form the original Chinese
software and controller.
IIRC their controller does almost everything by itself. They only
stop/coordinate for vision operations which is processed by the software
on the PC or on pick errors.
Their job processor is actually only a list of placements to be
executed. They just loop this list without any optimizations. The part
to nozzle relation is hard coded as well. IIRC they no even search the
list for the next component on the other nozzle. It might look primitive
on first glance but provides the advantage that one can optimize the
order of placements and that one gets always the same result. (I've used
this feature a few times to place tall parts.) IIRC the big guys do the
same: their machines execute preoptimized data and the optimization is
done using expensive add-on software.

Jan

> /may/ make it slower than factory software (now I'm talking all such

> https://groups.google.com/d/msgid/openpnp/479372e2-abf8-44ec-a031-f0126157d985%40makr.zone <https://groups.google.com/d/msgid/openpnp/479372e2-abf8-44ec-a031-f0126157d985%40makr.zone?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Mark and Jan,

Thanks for your inputs!

I'll combine my answer to you both in this message.

First, I realize I have to state what I have done so far (stuff I remember at least!), and where I am at;

1. The serial stuff - yes, I am the guy that did the modification for rts/cts, and you helped increasing the bit rate to 4Mbit in the async driver. I also fixed the issue with the serial corrupting data when sending/receiving at the same time (which seems to be hidden by the use of "Confirmation flow control"). TX/RX is done using DMA.

I have been running 4Mbit since then (obviously without confirmation flow control).

2. Actuators - What I did here, was to remove all coordination in the FW, which means that Led down, Leds up, Led work light, Vac, Vac N1, Vac N2, Blow, Dragpin, Buzzer, XYZBCDen, Camswitch are now all only coordinated by OpenPnP. Like you say, Mark, it is really only the drag pin that could be a serious issue. (I don't have a cam switch on my machine, so I have not tested that). This all works well, I have been running like this though about 50 boards. The original Smoothie code was to always wait for the machine to be still, even if it was just a LED that where to be switched on or off.

3. Also, I added local "smartness" with the drag pin up requests, delaying the 'ok' as long as needed for it to come up, and then also added automatic wiggling (as previsously discussed in this thread). Also works well (50 boards+).

4. Tweaked X/Y and Peeler motion. - this I have only tested on my "test pick-place setup", that I am trying to compare with the video Randy posted in desktop pnp group a few days ago, as I mentioned above. But I am prepared for adjustments here; next time I run a batch (in December, I need to run 100-150 boards, so it will be a good test), I am sure there are things that needs attention.

With the above, my machine is operating way (way!) faster than it was before. Later today (If I can get some quality time with my chmt :-) ), I'll try to see how much I can bump the peeler motors, because the time spent in the "drag end/pin up" to "at pick position, coordinated still" is way more than it should be.

The "delays" that I specified, are all in OpenPnP, or maybe some, due to a mis-configuration on my machine. Since they are all e.g. 50ms I presume they are deliberately put there for some reason (except for maybe the 12ms in "Move to pick" which I guess could be some internal calculation that takes a long time, and no logging is taking place for this). But together they add up about 200ms, which is significant. As far as I can tell, none of them are part of any coordination wait, but just delays. Possibly some are historic, or a fix for a particular machine/issue, or as a result of something that I am not clever enough to see.  ;-)

The snippets that I presented with these "delays" are perhaps a bit short, so I am attaching the full log of the cycle that I investigated, grouped as the charts above, should any of you be interested in it. :-)

Like you Mark, I also think, that OpenPnP should be able to operate as fast as the stock firmware+software. And I think I'll get close to it, if, what I call the "delays" are handled, and my peeler motor is tweaked. But it is hard to prove, since the only real data of stock speeds are videos on youtube and sales brochures from Charmhigh. 4000 CPH for instance - is that a real figure, or just a (not so) random number?

I have never run any jobs on my machine, so I don't have that to compare to either (I started conversion to OpenPnP as soon as I got my machine).

The missing Closed loop support for X and Y is a thing that I want to fix somehow. But maybe this is with the use of external drivers instead. I read somewhere that the built in drivers are made for PWM/dir, so maybe they are not optimal to drive with step/dir. But anyway, that is something that I will deal with going forward, probably not before Christmas.

P.S.

I see that I have an error in the charts legend; the "On PCB move to pick position" should say "On PCB, move to drag start position".

Cheers,

 - Micael

[vespaman]

"I have never run any jobs on my machine, so I don't have that to compare to either (I started conversion to OpenPnP as soon as I got my machine)."

I meant to write that I have never run any jobs on my machine while it had the chinese fw/sw..

 - Micael

[mark maker]

Will look at that log and the underlying code as soon as I have time. Very interesting!

One question: when it says "new start" at the beginning, does this mean new start of OpenPnP or just of a new job, and there was one before?

I'm asking because this is a Java program and it will be slow, in-deed surprisingly slow, the first few times it executes a certain portion of the code. But it will be okay after about three or four iterations (at least in my humble experience), and for jobs with 100+ placements per panel, this initial slowness becomes irrelevant.

The reason is Just In Time (JIT) compilation. The virtual Java code is only loaded and compiled into machine language when it is first called. And even the first compilation is only a rough one, the code paths are further analyzed and "hot" (=often used) code is then further optimized. In the end it can even be faster than normal compiled languages (such as C++)*, because it can optimize the code taking the specific sub-flavor of processor model into consideration, and by employing so-called profile guided optimization.

So in order to benchmark this, you need to "warm up" OpenPnP with at least four placements, and only analyze the log after that, or simply take the second-to-last placement from a larger job.

_Mark

*) C++ and other such languages can be optimized much the same way with considerable extra effort.

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/04083ebd-a95b-4170-add3-b7ef93d7c518n%40googlegroups.com.

[vespaman]

Great!

Regarding "New start" simply a new start of the pick/place sequence, just to start somewhere for the cycle, for me to not loose my place in the full log.

While each of my test runs are only about 4-5 components (0402, so I can only use every other for full log eyballing, because of the double feeds), I have a couple of tests before this, so the machine was warm.

But that was just pure luck, so I will make sure that my test cycles are a bit longer the next time, just to be sure. Thanks for the heads up!

 - Micael

[vespaman]

OK, so I had some time to test a few things, but now I probably will need to stop for the evening.

So my mysterious slow move from drag-end to pick start: (mostly rambling and sorting my own findings, so you can skip this part :-) )

The peeler performance is probably not part of the slow move, this I have validated in different ways, but it can actually be seen in the log. It seems to take 160ms to do a feed regardless of which numbers I put into the feeder, over a certain point. I have tried to up acceleration and top speed, but still 160, which indicates to me that this is the X limiting now. (Have not tried to play with these numbers to confirm).

So this leaves me to believe that the move is actually slow. I tried to remove sneakup, just for fun, on both x and y, with no difference at all. I also increased acceleration on Y, but also that did not make any (significant) difference. I can't believe 449ms (390 without the "delays") is a good value, for moving the head <40mm. Perhaps it is down to the not-closed loop stepper driver. Will have to give it some more thinking.

But:- while studying the logs again, I found another 50ms delay that I missed before. Just at then end;

2023-10-28 17:36:13.816 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M801
2023-10-28 17:36:13.816 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
>> 90ms delay -> 50ms extra delay??  (I have Place Dwell 40ms on the nozzle head, 0 on the nozzle).
2023-10-28 17:36:13.906 AbstractNozzle TRACE: Set rotation mode offset: none.
2023-10-28 17:36:13.906 Scripting TRACE: Scripting.on Nozzle.AfterPlace

 - Micael

[Mike Menci]

Peeler should start as soon as SMT part is taken out of the SMT tape - and next part is than ready to be taken out.  This way there is min time needed for PnP to operate.  

Mike

[Jan]

I just did a small grep on ("WriterThread" or "Scripting") in an old log
file and found

2023-09-26 16:51:31.820 Scripting TRACE: Scripting.on Job.Placement.Starting
2023-09-26 16:51:31.822 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> M204S13418G1Z-13.2F28806
2023-09-26 16:51:31.825 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> G92C0
2023-09-26 16:51:31.827 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> M119
2023-09-26 16:51:31.840 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> M204S6863G1X24Y164.7F56188
2023-09-26 16:51:31.844 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> M400
2023-09-26 16:51:32.199 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> M114
2023-09-26 16:51:32.207 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> M816S100
2023-09-26 16:51:32.209 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> G4P5
2023-09-26 16:51:32.216 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> M816S10
2023-09-26 16:51:32.265 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> M204S1993G1X28.3C4F6491
2023-09-26 16:51:32.268 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> M204S909G1X28F991
2023-09-26 16:51:32.271 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> M400
2023-09-26 16:51:32.420 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> M114
2023-09-26 16:51:32.429 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> M817
2023-09-26 16:51:32.430 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> G4P50
2023-09-26 16:51:32.482 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> G92C0
2023-09-26 16:51:32.484 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:COM5] >> M119
2023-09-26 16:51:32.502 Scripting TRACE: Scripting.on Nozzle.BeforePick

Just for reference: M816 enables the drag pin (with PWM) and M817
releases it. M119 is used to read the drag pin state and is part of the
axis interlock sequence.
As you can see, there are two M400 commands that are used to coordinate
the drag pin going down and up. There are also the two G4P commands I've
configured to let the drag pin move. The M114 commands are there because
I have "Location Confirmation" enabled.
I'd like to point out the following:
- There are a lot of M204 (to configure the acceleration) and
F-parameters (to configure the feed rate) consuming a considerable
amount of bandwidth. (I've Motion Controller Type configured to
ModeratedConstantAcceleration).
- There are two "G92C0" commands resetting the peeler axis location.
(I'm using the ReferencePushPullFeeder, have configured the Peeler as
axis and on the Push-Poll Motion tab Rotation as Additive.) I think that
at least one of the two shall not be there.
- Looking at the acceleration and feedrate, the drag move itself (line
11, just behind M816S10) is slow and the final move to release the drag
pin in the following line is even slower. (Move to drag start uses
acceleration of about 7000, the drag move is at ~2000 and the release at
~900.) Some of the values might be related to the axis configuration:
acceleration on X axis is 18e3mm/s^2 and Peeler is 10e3mm/s^2.
- looking at the timing I also see unexpected delays between drag pin
operation and the following move sequences. There is a delay of ~50ms
between drag pin enabled to next move (line 10 to 11) and ~50ms between
drag pin release and next command (line 16 to 17). Can it be, that "G4P"
is not queued but pauses the entire execution?
- There are move M119 commands reading the drag pin state as strictly
required. As the axis interlock is bound to the drag pin actuator, its
state can only change if the actuator's state is changed. Hence the M119
in line 4 is not needed while the one in line 18 is required and
expected to verify the interlock state before the next move.
According to Marks blog, acceleration is the key to speed. So I'll have
to figure out a) why ModeratedConstantAcceleration reduces the
acceleration that much and b) how to execute drag moves at full
acceleration.

Jan

> __

>
> Will look at that log and the underlying code as soon as I have
> time. Very interesting!
>
> One question: when it says "new start" at the beginning, does
> this mean new start of OpenPnP or just of a new job, and there
> was one before?
>
> I'm asking because this is a Java program and it will be slow,

> /in-deed surprisingly slow/, the first few times it executes a

> certain portion of the code. But it will be okay after about

> /three or four/ iterations (at least in my humble experience),

> and for jobs with 100+ placements per panel, this initial
> slowness becomes irrelevant.
>
> The reason is Just In Time (JIT) compilation. The virtual Java
> code is only loaded and compiled into machine language when it
> is first called. And even the first compilation is only a rough
> one, the code paths are further analyzed and "hot" (=often used)
> code is then further optimized. In the end it can even be faster
> than normal compiled languages (such as C++)*, because it can
> optimize the code taking the specific sub-flavor of processor
> model into consideration, and by employing so-called profile
> guided optimization

> <https://en.wikipedia.org/wiki/Profile-guided_optimization>.

>> shortcomings that /may/ make it slower than factory

>>>> https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%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/04083ebd-a95b-4170-add3-b7ef93d7c518n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/04083ebd-a95b-4170-add3-b7ef93d7c518n%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/2a91d11d-9d8d-4cbf-b6a7-7b12b5aa808an%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/2a91d11d-9d8d-4cbf-b6a7-7b12b5aa808an%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jan]

Hi Mike!
We're using drag feeders. Hence peeling can only take place while or
after draging...

Jan

> __

>
> Will look at that log and the underlying code as soon as I
> have time. Very interesting!
>
> One question: when it says "new start" at the beginning,
> does this mean new start of OpenPnP or just of a new job,
> and there was one before?
>
> I'm asking because this is a Java program and it will be

> slow, /in-deed surprisingly slow/, the first few times it

> executes a certain portion of the code. But it will be okay

> after about /three or four/ iterations (at least in my

> humble experience), and for jobs with 100+ placements per
> panel, this initial slowness becomes irrelevant.
>
> The reason is Just In Time (JIT) compilation. The virtual
> Java code is only loaded and compiled into machine language
> when it is first called. And even the first compilation is
> only a rough one, the code paths are further analyzed and
> "hot" (=often used) code is then further optimized. In the
> end it can even be faster than normal compiled languages
> (such as C++)*, because it can optimize the code taking the
> specific sub-flavor of processor model into consideration,
> and by employing so-called profile guided optimization

> <https://en.wikipedia.org/wiki/Profile-guided_optimization>.

>> shortcomings that /may/ make it slower than factory

>>>> https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%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/04083ebd-a95b-4170-add3-b7ef93d7c518n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/04083ebd-a95b-4170-add3-b7ef93d7c518n%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/35a4cee9-9a96-4e0b-8290-106711ce45a8n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/35a4cee9-9a96-4e0b-8290-106711ce45a8n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jan]

On 31.10.2023 11:44, vespaman wrote:

[...]

> Like you Mark, I also think, that OpenPnP should be able to operate as
> fast as the stock firmware+software. And I think I'll get close to it,
> if, what I call the "delays" are handled, and my peeler motor is
> tweaked. But it is hard to prove, since the only real data of stock
> speeds are videos on youtube and sales brochures from Charmhigh. 4000
> CPH for instance - is that a real figure, or just a (not so) random number?
> I have never run any jobs on my machine, so I don't have that to compare
> to either (I started conversion to OpenPnP as soon as I got my machine).

There is even potential to run faster then with the Chinese software:
IIRC their job processor executes everything (pick, align, place) in the
order nozzle 1 followed by nozzle 2 but the total path traveled might be
shorter if they are swapped...

Jan

>
> tisdag 31 oktober 2023 kl. 09:55:24 UTC+1 skrev ma...@makr.zone:
>

> __

> /may/ make it slower than factory software (now I'm talking all such

>>> https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%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/04083ebd-a95b-4170-add3-b7ef93d7c518n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/04083ebd-a95b-4170-add3-b7ef93d7c518n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[mark maker]

Hi vespaman

I can't explain the various delays (marked by you with "??") happening when nothing is logged (except in cases where there are dwells for vacuum establishment, as you correctly state). 

I have specifically analyzed each occurrence of Thread.sleep() in the whole of OpenPnP, to exclude having missed something.

If this is really a warmed-up Java VM,  I can only guess the computer is not powerful enough, has not enough RAM, i.e. the Garabage Collector would frequently have to run, which could explain the delays. But that's admittedly a wild guess. Please tell us the PC specs.

The other delays, I think, are what you can expect. What you seem to forget in your analysis (your last message) is the nozzle rotation axis A. It goes from +67° to -90°, so a -157° turn, which I guess could be limiting. 

Check out the A axis acceleration and feedrate limit, both in OpenPnP but also in the controller config. Remember it is degrees not millimeters, so larger numbers are normally appropriate.

Then also check out the nozzle Rotation Mode in OpenPnP, e.g. consider MinimalRotation. Caution: This optimization only works if your articulation is free (free-running tubes etc.).

https://github.com/openpnp/openpnp/wiki/Nozzle-Rotation-Mode

I see two optimizations that could be done in OpenPnP:

1. Add a new checkbox on the Package that says "No Polarity", that one could enable for passives etc.
   So OpenPnP would be optimizing the pick location rotation, the bottom vision pre-rotate rotation, the placement rotation to the nearer 180°. This should cut average needed rotations in half for these typically frequent parts (move time is not linear but roughly to the square root, , so expect a 1−121-\sqrt \frac{1}{2}  save, i.e. ~29%.
   
2. DragFeeder, LeverFeeder, PushPullFeeder, BlindsFeeder, HeapFeeder and possible others, already move the head to the feeder to do the feed actuation (drag etc.) or vision. Therefore, the move-to-feeder time is not used to already rotate the nozzle, as it would on other feeder types that use no motion in the feed operation. So an optimization would have to try and "blend" the nozzle rotation into the move to the feeder. Needless to say, this is quite difficult to achieve, must likely be done on each such feeder class, and in some edge cases it could even be counter-productive. So don't count in it anytime soon 🙁

Plus OpenPnP should do more logging especially log each Thread.sleep() it does.

_Mark

On 31.10.2023 18:58, vespaman wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2a91d11d-9d8d-4cbf-b6a7-7b12b5aa808an%40googlegroups.com.

[vespaman]

Hi Mark

Very interesting! 

(Yes, openhab had been up for hours. And I can see the exact same delays every time)

So, the PC is a 1 year old ASUS PN52 with a Ryzen 7 5800H (8c 16t), 16GB RAM. This is a dedicated machine, only running OpenPnP. Linux 64 bit (Manjaro). When I start it, it has 12-something GB free after I have started OpenPnP (before running any job). The governor of the time of the log is Performance, however, I started with Ondemand, and there where no obvious differences between them. The thing is that the delays are always there, at the same exact same lines of the log, and exactly the same amount of time.

Java is openJDK 11.

If memory serves me right, Java has its own memory space settings, that sometimes needs to be changed, no? Could this be a thing to investigate?

Rotation - that makes perfect sense! The shorter the distance, the slower, in effect!

I am sure I cannot grasp the full complexity of the rotations, and when it needs to happen.

Actually I guess "No polarity" is a good thing regardless, even with free articulation, it must be less movement ? (I'm thinking about some bigger components (e.g. push buttons) that can suffer from turning).

I will do some test with the rotation later on today, also test MinimalRotation.

Cheers,

 - Micael

[mark maker]

That PC is more than enough.

> The thing is that the delays are always there, at the same exact same lines of the log, and exactly the same amount of time.

That's really mysterious. I mean, yes, OpenPnP needs some crunching time too, but surely not 40ms!?

Can you please send the machine.xml?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7c60407e-bb58-4ecb-9cbb-e9435de436ean%40googlegroups.com.

[vespaman]

Here's the machine.xml.

When I say they are always there, well, obviously I haven't checked every row in every log :-) But for instance, I randomly picked a log, and randomly searched for M816S10 in that log and got;

2023-10-11 19:13:57.110 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M816S100
2023-10-11 19:13:57.111 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-10-11 19:13:57.111 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> G4P10
2023-10-11 19:13:57.111 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M816S10
2023-10-11 19:13:57.121 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-10-11 19:13:57.121 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-10-11 19:13:57.161 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((74.034000, 92.550000, 0.000000, 4.000000 mm), 1.0)

.. Same delay, same place, as you can see!

  - Micael

[mark maker]

Hmmm... not sure it would actually run the advanced Motion Blending code when you don't have 3rd order control on any driver, but please switch off the Allow uncoordinated? in the Motion Planner tab on the machine. If it does compute Motion Blending it might actually take some time.

https://github.com/openpnp/openpnp/wiki/Motion-Planner#settings

Any change?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/71945528-6548-4276-a2dc-c22f94144609n%40googlegroups.com.

[vespaman]

OK, no, that did not make any difference. I ran, and checked the delays 'after drag pin down', 'after drag pin up' and also 'before vacuum' (40/30/50ms respectively).

 - Micael

[mark maker]

Hi all,

I've made a new test version of OpenPnP which adds some timing related logging. Whenever OpenPnP deliberately sleeps, it is traced to the log, so these obvious cases  can be excluded.

https://github.com/openpnp/openpnp/pull/1593

I still don't see how this would explain the pauses in the log, but in the absence of any other ideas, this should at least exclude the possibility that I somehow missed one of these.

Allow some minutes to deploy.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d0dc987f-f00e-4a0c-8082-324f031ba17dn%40googlegroups.com.

[mark maker]

Unfortunately it doesn't build the installer at the moment... 😭 ... hope Jason will be able to help. Need to go now.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/632d716a-a88f-4cd2-9a59-c9d8549cf1b9%40makr.zone.

[vespaman]

Hi Mark,

Waking up today, my brain gave me a present; a pattern of the delays! :-)

It might not solve the mystery, but at least a good clue. Here's the pattern;

Every time an actuator is called, is time zero. Then controller takes on the requested duty, and at some point, returns "ok". Now, if the duty took less than 50ms, the delay comes in until 50ms has been reached from time zero.

E.g. Camera up light, returns immediately, so the full 50ms is delay. But for the drag pin down, we have 100%+10% with 10ms delay inserted between them (G code), so the actuation takes 10ms, leaving a delay in OpenPnP of 40ms.

Same with drag pin up; it normally takes 20ms to pull it, hence 20ms in controller, then 30ms delay in OpenPnP.

The 12ms in the midst of "@Move to pick position 449ms" cannot be explained by this, but I always thought this was maybe not the same kind of "delay". Maybe it is just doing something that takes time here.

Last night I tested to run the machine with full articulation, and it cut a considerable time (after a while the nozzle started to fail to pick components, naturally), at least 100ms where shaved.

So I will (resin-)print a cap for my Nema8 motors, so both nozzle can be freely rotated going forward! :-)

 - Micael

[mark maker]

Hi Micael,

> Waking up today, my brain gave me a present; a pattern of the delays! :-)

I had the same train of thought, but after analyzing the code yesterday, I don't see how this can manifest in OpenPnP. The serial writer and reader threads are completely decoupled from the main task thread. They both communicate through queues, and I don't see how or why the task thread should wait on the queue in that instance.

For instance: 

The main task is logging this

2023-10-28 17:36:11.859 GcodeAsyncDriver DEBUG: GcodeDriver:ttyUSB0 empty command after pre process

Then the reader and writer threads are talking.

2023-10-28 17:36:11.859 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M816S100   
2023-10-28 17:36:11.859 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> G4P10       

2023-10-28 17:36:11.859 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-10-28 17:36:11.859 GcodeAsyncDriver$WriterThread TRACE: [GcodeDriver:ttyUSB0] >> M816S10   
2023-10-28 17:36:11.869 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok
2023-10-28 17:36:11.869 GcodeDriver$ReaderThread TRACE: [GcodeDriver:ttyUSB0] << ok

But actually, the next thing in the main task should not be delayed, it should come immediately, i.e., the logging should actually appear intertwined:

2023-10-28 17:36:11.909 AbstractHeadMountable DEBUG: Feed (Left side peel).moveTo((74.661476, 144.397624, 0.000000, 4.000000 mm), 1.0)

I really don't understand.

I must be missing something, so please, if possible, do another run with the new test version that has added logging.

Thankfully Jason fixed the deploy overnight, and I made a new PR with yet more logging on the read queue, that is successfully deployed.

https://github.com/openpnp/openpnp/pull/1595

Afterwards, please send me the full log.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5d8e7810-c604-4e96-b174-7b92d8c84c57n%40googlegroups.com.

[vespaman]

Yes, I am sure the reason behind it is not obvious, but at least for me, the sum of 50ms gives me a little clarity, since I last night saw that the delay after drag pin up (30ms) did sometimes differ in my older logs (which is understandable now, since the drag pin can fluctuate time-wise on its way up).

I will certainly run the test code, but I need to rush out now, so probably no result until ~lunch time.

- Micael

[Jan]

Hi Micael!
I just checked the log file again and found two things:
- all lines you marked with "delay" are following an actuator action.
Four actions are boolean actuators being actuated (write only) and one
is reading a boolean actuator (drag pin state). May it be, that the
calling code does not continue when actuating an actuator or is now
woken correctly once the actuation has been done? Due to the write only
nature I'd expect that the calling code can continue queuing move work
and does not need to wait at all.
- I'm not sure your blower setup is correct:

2023-10-28 17:36:13.765 ReferenceActuator DEBUG: BLOW.actuate(2.0)
2023-10-28 17:36:13.765 GcodeAsyncDriver DEBUG: [GcodeDriver:ttyUSB0]
commandQueue offer >> M812 S0 ; BLOW M812 at [%]
2023-10-28 17:36:13.765 GcodeAsyncDriver$WriterThread TRACE:
[GcodeDriver:ttyUSB0] >> M812S0

If my interpretation is correct, M812S0 switches the blower off. So
probably the 2.0 argument is not correctly converted into GCode...

Jan

On 31.10.2023 11:44, vespaman wrote:

> __

> /may/ make it slower than factory software (now I'm talking all such

>>> https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%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/04083ebd-a95b-4170-add3-b7ef93d7c518n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/04083ebd-a95b-4170-add3-b7ef93d7c518n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Mark!

What did you do!!?!?! You must have found the cap that contained all of OpenPnP's bad spirits, and let them out! :-)

New version has no delays, and everything is faster!

(Some tweaks has been done on my machine since last checkpoint (the last pie chart message above), but this is still with limited articulation (have not had time to print needed parts yet), so most of this is due to new OpenPnP ;

Now the single nozzle drag+pick+place is down to 1675ms (previously 2344). I wouldn't be surprised if this is on par with stock fw+sw.

Running test setup

 - Micael

[mark maker]

Ouch! Bad mistake by me. 😭 So sorry!

@other users: I am sorry to say this affects all users. Please read.

The culprit was now made visible by the new logging:

2023-11-02 13:16:25.007 SimulationModeMachine TRACE: BLOW-OFF simulate actuation, sleep 5ms

This sleep should actually only happen for simulated machines. It was even 50ms before, and I now reduced it to 5ms which already helps a lot, as you reported, Micael.

The code doesn't disable the sleep when not in simulation mode (a curly brackets nesting mistake). Fixed here:

https://github.com/openpnp/openpnp/pull/1596

All users, please upgrade, you will get 50ms faster per actuation in the newest test version (or the remaining 5ms compared to yesterday's version).

Thank you Micael for relentlessly insisting on this, and then having the patience to follow it through, always ready to test one more thing. I hope more users follow your shining example! 😎 🥇

_Mark

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/59d56ca5-0699-41e2-be7f-45d88a97b54dn%40googlegroups.com.

[vespaman]

Mark,

So good to hear! I am glad I could be of help, but you are the hero.

This new version actually highlighted a new issue in the chmt smoothie port - the vacuum sensing is not sampled quickly enough, afaict after eyeballing the code quickly, it is default to be sampled every 200ms so pick dwell time is always hit instead. (It makes sense, since this is temperature sensors in the 3d printing world).

 - Micael

[mark maker]

Thanks back, and btw. veeery nice CHMT+OpenPnP demo video. This sets the new benchmark, I guess! 😛

https://drive.google.com/file/d/1DfZY4dLoCS5wJ1iTXK9bT644_vKga-4_/view?usp=drive_link

Hope you leave it there for posterity, or upload it to YT or the likes.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d7c538fb-6d9c-4aa8-8d6b-d95ca43faa55n%40googlegroups.com.

[Jan]

That's incredible! Much more fluent now as what I've seen so far.
Definitively the benchmark!
Btw: did you still have coordination enabled for the up-looking cameras
light?

Jan

On 02.11.2023 16:10, 'mark maker' via OpenPnP wrote:
> Thanks back, and btw. veeery nice CHMT+OpenPnP demo video. This sets the
> new benchmark, I guess! 😛
>
> https://drive.google.com/file/d/1DfZY4dLoCS5wJ1iTXK9bT644_vKga-4_/view?usp=drive_link
>
> Hope you leave it there for posterity, or upload it to YT or the likes.
>
> _Mark
>
> On 02.11.2023 15:42, vespaman wrote:
>> Mark,
>> So good to hear! I am glad I could be of help, but you are the hero.
>>
>> This new version actually highlighted a new issue in the chmt smoothie
>> port - the vacuum sensing is not sampled quickly enough, afaict after

>> eyeballing the code quickly, it is default to be sampled every /200ms
>> /so pick dwell time is always hit instead. (It makes sense, since this

>> is temperature sensors in the 3d printing world).
>>
>>  - Micael
>>
>> torsdag 2 november 2023 kl. 15:17:41 UTC+1 skrev ma...@makr.zone:
>>
>> Ouch! Bad mistake by me. 😭 So sorry!
>>

>> *@other users: I am sorry to say this affects all users. Please read.
>> *

>>
>> The culprit was now made visible by the new logging:
>>
>> 2023-11-02 13:16:25.007 SimulationModeMachine TRACE: BLOW-OFF
>> simulate actuation, sleep 5ms
>>
>> This sleep should actually only happen for simulated machines. It
>> was even 50ms before, and I now reduced it to 5ms which already
>> helps a lot, as you reported, Micael.
>>

>> The code doesn't disable the sleep when *not* in simulation mode

>> (a curly brackets nesting mistake). Fixed here:
>>
>> https://github.com/openpnp/openpnp/pull/1596
>>

>> All users, please upgrade, you will get 50ms faster /per
>> actuation/ in the newest *test* version (or the remaining 5ms

>> compared to yesterday's version).
>>
>> Thank you Micael for relentlessly insisting on this, and then
>> having the patience to follow it through, always ready to test one
>> more thing. I hope more users follow your shining example! 😎 🥇
>>
>> _Mark
>>
>>
>> On 02.11.2023 14:27, vespaman wrote:
>>> Mark!
>>>
>>> What did you do!!?!?! You must have found the cap that contained
>>> all of OpenPnP's bad spirits, and let them out! :-)
>>>
>>>
>>> New version has no delays, and everything is faster!
>>> (Some tweaks has been done on my machine since last checkpoint
>>> (the last pie chart message above), but this is still with
>>> limited articulation (have not had time to print needed parts
>>> yet), so most of this is due to new OpenPnP ;
>>>

>>> Screenshot_20231102_141700.pngScreenshot_20231102_141747.png

>>>
>>>
>>> Now the single nozzle drag+pick+place is down to 1675ms
>>> (previously 2344). I wouldn't be surprised if this is on par with
>>> stock fw+sw.
>>>
>>>
>>> Running test setup

>>> <https://drive.google.com/file/d/1DfZY4dLoCS5wJ1iTXK9bT644_vKga-4_/view?usp=drive_link>

>>> https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com?utm_medium=email&utm_source=footer>> <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/973fc3b2-8485-4835-88ee-780bf6fad3b1n%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/04083ebd-a95b-4170-add3-b7ef93d7c518n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/04083ebd-a95b-4170-add3-b7ef93d7c518n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/04083ebd-a95b-4170-add3-b7ef93d7c518n%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/59d56ca5-0699-41e2-be7f-45d88a97b54dn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/59d56ca5-0699-41e2-be7f-45d88a97b54dn%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/d7c538fb-6d9c-4aa8-8d6b-d95ca43faa55n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/d7c538fb-6d9c-4aa8-8d6b-d95ca43faa55n%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/8edb759e-e48c-4149-9e6b-1ee044cd3757%40makr.zone <https://groups.google.com/d/msgid/openpnp/8edb759e-e48c-4149-9e6b-1ee044cd3757%40makr.zone?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan,

No, I did not. But I tested now, and there's no obvious difference. The settle time fluctuates a lot, so it is hard to tell. (Between 64-200 normally). This is something to look more detailed into, I suppose. There's a lot of settings on the up camera that I have not touched. But I suspect the motion needs to be sorted first.

I also rerun the test job with free articulation and minimal move, and think it is now OK to have it limited, no major difference, so I suspect Y acceleration is now the limitation again. It is a bit back and forth. However, I think I will leave it as is (just update to the version also without the 5ms, which I have not yet done), for now.

I'd like to fix the vacuum sensing in fw first. I read it wrong yesterday, it is updated every 50ms, not every 200ms, which I first though. But it is still uselessly slow, so need to do something about it. Don't really want to burden the MCU with just upping the sample/poll/averaging frequency, and vacuum result also messes with the tx dma stream performance, since it is feeding results in two parts (one for each sensor), so I would like to deal with that at the same time.

 - Micael

[vespaman]

..just as I pressed send, I realized that I will probably want to go full articulation anyway, because I am using dual 502 nozzles for my 0402's, and this means that the move will be even shorter, and on the much faster X-axis, hence I'm sure the rotation will be the limiting factor in some situations.

  - Micael

[vespaman]

Hi Jan,

Following up on a old thread, since I had some notes of things that might be done within the FW..

måndag 28 augusti 2023 kl. 22:46:12 UTC+2 skrev Jan:

Then you might add [..] delay/wait until the dragpin is down and
automatically switch the pwm to a lower value.

Jan

While I did not think this was needed a year ago, I think it makes sense to do it in FW now, since it makes the FW dealing with stuff that are truly a hardware thing, and therefore less possible to burn the drag pin coil for new users setting up their machines, and, of course, we save 10 (20 in my case)ms on each drag. It is also easier to freely select a longer delay, since there will be no penalty at all, should this be desired.

So Now I have added this to my FW, (have yet to test it, since my machine is not available to me because of moving it to different location, but hope be able to test in a couple of days).

The way I did this, is to simply add two new config items - the delay in ms before reducing the PWM, and the secondary PWM value.

Now, as you may remember, 'M816 S100' is the activation followed by the delay and a new M816 with new/reduced PWM value.

What I did in firmware code, was to simply check for a M816 without the PWM argument, (i.e. 'M816' alone), and if there's no argument, I let the FW manage the drag pin itself, by the use of the above mentioned settings.

This way, a user may override the FW management should it be desired (e.g. for testing or whatever).

Is this a good idea, or do you (or anyone else for that matter!) think it is better to never accept the arguments from OpenPnP, in order to protect the coil from burning by accident?

 - Micael

 

[Jan]

Hi Micael!
Good to hear, that you're still interested in enhancing your machine!
That keeps us going!

On 21.07.2024 14:51, vespaman wrote:
>
> Hi Jan,
>
> Following up on a old thread, since I had some notes of things that
> might be done within the FW..
>
> måndag 28 augusti 2023 kl. 22:46:12 UTC+2 skrev Jan:
>
>
> Then you might add [..] delay/wait until the dragpin is down and
> automatically switch the pwm to a lower value.
>
> Jan
>
>
>
> While I did not think this was needed a year ago, I think it makes sense
> to do it in FW now, since it makes the FW dealing with stuff that are
> truly a hardware thing, and therefore less possible to burn the drag pin
> coil for new users setting up their machines, and, of course, we save 10
> (20 in my case)ms on each drag. It is also easier to freely select a
> longer delay, since there will be no penalty at all, should this be desired.
>

Please keep in mind, that you will still need a delay to make sure the
dragpin is in tape before the move starts. However, the benefit would be
that the dragpin can stay low @100% a little longer then required.
General speaking I still think, that waiting (M400) shall be reduced to
a minimum as it involves signalling OpenPnP to send more commands. That
is always prone to jitter, even though the jitter seems lower with Linux.
Therefor as there is no waiting required for the dragpin to go down,
I'm not entirely sure you modification will make a big difference
besides reducing the amount of data send to the controller and enforcing
a healthy state of the drag pin.

> So Now I have added this to my FW, (have yet to test it, since my
> machine is not available to me because of moving it to different
> location, but hope be able to test in a couple of days).
>
> The way I did this, is to simply add two new config items - the delay in
> ms before reducing the PWM, and the secondary PWM value.
> Now, as you may remember, 'M816 S100' is the activation followed by the
> delay and a new M816 with new/reduced PWM value.
> What I did in firmware code, was to simply check for a M816 without the
> PWM argument, (i.e. 'M816' alone), and if there's no argument, I let the
> FW manage the drag pin itself, by the use of the above mentioned settings.
> This way, a user may override the FW management should it be desired
> (e.g. for testing or whatever).
>

Sounds good! IIRC M816 (without S argument) would use the (configurable)
default value, which shall be 100%. I'm using M817 to release the dragpin.

> Is this a good idea, or do you (or anyone else for that matter!) think
> it is better to never accept the arguments from OpenPnP, in order to
> protect the coil from burning by accident?
>

It's an expert machine, so it shall probable follow the advice not to
impose anything. Therefore, I'd suggest to trigger on "M816" only.

Jan

[vespaman]

Hi Jan,

Thanks for your input!

Yes, there's not much time gain here, but I don't like "dummy waits", so at least we can get rid of some of that. And the actual setup is cleaner now, that there's anyways a special drag pin management in FW.

It is a shame that there's no "pin down" sensor, it would be something to add if I ever get to do a head board revamp, but for now we'll have to add a small static wait for the pin movement. It will not need to be as much as before, since it is super strong, so as soon as the tip is in the sprocket hole, drag can commence. Maybe I can do some tests on the bench, to see how long it typically takes for it to extend fully.

No, looking at the code, M816 without argument should send off to the coil, since it is used as default startup value (so it must not be set to 100 in config!). 

Therefore I can't use this, but this does not matter much anyway, since we know 100% is what we always want here.

Unfortunately, I can only do stuff that does not actually need access to the machine, otherwise I would try to finish up my nozzle changer, or some other mechanical stuff this summer.

Looking forward to test your new stuff though, once I get full access to a working machine again!

 - Micael