CHMT PushPullFeeder coordinated Peeling

[Wayne Black]

First many thanks to Mark, Micael and Jan...

After struggling several days trying to get Marks PushPullFeeder with coordinated peeling to work on my CHMT 36, I finally got it working. It wasn't until reading and rereading and Micaels Case study Thread I started discovering details within the thread I had missed in the PushPullFeeder doc. Special thanks Jan! The info is there in the doc, but not as explicit as my brain requires. In case it may help anyone else, this is how I did it;

- This assumes you already have a baseline CHMT set up for Openpnp with appropriate Dragpin setup. You will need to also ensure your GCode driver is updated for the newly formed Axis below. I'm omitting my Gcode setup as Im using RRF3.5.3 and not the typical Smoothie. If anyone sees anything wrong or misleading please let me/us know!

-Create a new ReferenceControllerAxis, name should include "PEEL", like LPEEL for the left CHMT peeler motor;

-Create a new head ReferenceActuator, name should include "FEED", like LFEED to correlate to the LPEEL axis;

-Set FEED actuator profile to leverage the Dragpin

-Create a PushPullFeeder and set the Push-Pull Motion

Now experiment with pushing, Dragpin and Peeling interactions. Spend hours of fun combing thru the log to find what you missed if it doesn't work as expected :)

One initial issue that I finally figured out was random M204 timeouts. In the end it turned out my A/C1 axis MOVE_TO_COMMAND was set .3f vs .4f for the balance of axii. Setting A to %.4f  as the rest resolved the issue. I point this out as it illustrates the nature of coordinated axis peeling vs the uncoordinated simple actuation peeling. The Gcode driver must be accurate. Now that I have it working, it feeds are much nicer, Thanks Mark!

[mark maker]

Hi Wayne

thanks for the feed-back.

Am I right to assume that this is only necessary because you need two peeler axes, but only one drag pin actuators?

Then yes, this makes sense. Are you willing to add this to the Wiki? Pretty please 😎

Design Question: 

If I understand the system of the CHMT feeders correctly, then the peeling axis pulls on each tape of a side, i.e., all but one feeders' cover foil drums just slip on the rod, right? How bad would it be to just always rotate both peeling axes? I'm also asking, because the PushPullFeeders cloning system is currently not smart enough to distinguish east and west feeders, and assign the right actuator... it would simplify setup much. 😇

_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 visit https://groups.google.com/d/msgid/openpnp/ce38cf19-c160-4221-a509-19e8e7e8cbb0n%40googlegroups.com.

[Jan]

Hi Wayne!
Many thanks for sharing your finding! Please update the Wiki.
Yes, the current documentation silently makes the assumption that the
controller supports the peeler as separate axis/axes and that the
MOVE_TO_COMMAND, SET_GLOBAL_OFFSET_COMMAND and POSITION_REPORT_REGEX are
updated to control this axis/axes. For the reference firmware on the
original control board that's enforced by I&S.
IIRC the profile actuator is only needed to support operating the
peelers on a 48VB separately. On the 36VA - with just a single peeler
axis - that is not needed (and works as documented). Details about the
profile actuator are not yet in the Wiki.
Operating the left and right peeler on a 48VB in parallel might require
other modifications: the reference firmware operates them as separate
axes. So the peeling axis assigned to the drag pin has to create g-code
that moves them both. Maybe modifying the MOVE_TO_COMMAND like "(C:C%.1f
D%.1f)" might work, but I've not tested that. If you're running a
different controller, the configuration might be changed to operate both
motors using a single axis.
The issue you reported concerning the %.4f modification is likely
hiding a different problem: if the peeler is commanded to move by 4mm,
it shall not matter whether OpenPnP send "4.0000" or "4.000" to the
controller. I suggest to check the generated G-Code and verify the
operation externally (or via the GCode console).

Jan

On 05.11.2024 02:32, Wayne Black wrote:

> First many thanks to Mark, Micael and Jan...
>
> After struggling several days trying to get Marks PushPullFeeder

> <https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder> with

> coordinated peeling to work on my CHMT 36, I finally got it working. It
> wasn't until reading and rereading and Micaels Case study Thread

> <https://groups.google.com/u/1/g/openpnp/c/JUCRTa6pKbQ/m/2qbB42eBAgAJ> I

> started discovering details within the thread I had missed in the
> PushPullFeeder doc. Special thanks Jan! The info is there in the doc,
> but not as explicit as my brain requires. In case it may help anyone
> else, this is how I did it;
>
> - This assumes you already have a baseline CHMT set up for Openpnp with
> appropriate Dragpin setup. You will need to also ensure your GCode
> driver is updated for the newly formed Axis below. I'm omitting my Gcode
> setup as Im using RRF3.5.3 and not the typical Smoothie. If anyone sees
> anything wrong or misleading please let me/us know!
>
> -Create a new ReferenceControllerAxis, name should include "PEEL", like
> LPEEL for the left CHMT peeler motor;

> ReferenceControllerAxis.png
>
> -Create a new head ReferenceActuator, name should include "FEED", like
> LFEED to correlate to the LPEEL axis;

> ReferenceControllerAxis.png
>
> -Set FEED actuator profile to leverage the Dragpin

> ReferenceControllerAxis.png
>
> -Create a PushPullFeeder and set the Push-Pull Motion

> ReferenceControllerAxis.png
>
> Now experiment with pushing, Dragpin and Peeling interactions. Spend
> hours of fun combing thru the log to find what you missed if it
> doesn't work as expected :)
>
> One initial issue that I finally figured out was random M204 timeouts.
> In the end it turned out my A/C1 axis MOVE_TO_COMMAND was set .3f vs .4f
> for the balance of axii. Setting A to %.4f  as the rest resolved the
> issue. I point this out as it illustrates the nature of coordinated axis
> peeling vs the uncoordinated simple actuation peeling. The Gcode driver
> must be accurate. Now that I have it working, it feeds are much nicer,
> Thanks 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

> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion visit

> https://groups.google.com/d/msgid/openpnp/ce38cf19-c160-4221-a509-19e8e7e8cbb0n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/ce38cf19-c160-4221-a509-19e8e7e8cbb0n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[mark maker]

Oh, I oversaw the issue with  %.3f vs %.4f

First, these decimal representation formats are derived automatically from your axis Resolution / Steps per Unit:

https://github.com/openpnp/openpnp/wiki/Machine-Axes#controller-settings

For feed-rate and acceleration (e.g. your M204) they are calculated with taking the Minimum Speed on the Motion Planner into account. The tool-tip gives you the rationale:

When you are running the machine at lower speed than indicated here, the decimal will become too coarse very quickly. Note that the Speed factor in the PushPullFeeder Push-Pull Motion might be very low. And this factor is even multiplied with the Speed % you set in the Machine Controls, so it might be ultra-snail in combo.

When you lower the Minimum Speed it will automatically add more digits in the M204 G-code command. Go to Issues & Solutions and press the Find Issues & Solutions button for the suggestions to appear.

The goal here is to make sure the I&S suggestions are good. There should be no need to hand-adjust this. So please help me find the facts, thanks.😎

I'm not excluding this is a bug. Please report back what you have for speed factors etc.

_Mark

[vespaman]

Hi Mark,

>>How bad would it be to just always rotate both peeling axes?

While this shouldn't be a problem when your machine is setup and all feeders dialed in correctly, I'd suggest better leave it as is. There's enough issues with these kind of drag feeders, adding another potential problem does not appeal to me. This would also add extra noise and vibration. The cloning, if used, is done only during setup.

 -  Micael

[vespaman]

And since we are on the subject of reference push pull feeders (rppf hereon)...

I might be alone with this, but very often, when I edit a rppf, which I do often, when changing reels etc, the values of 'Rotation' fields are messed up when I edit/change the coordinates of the 5 locations. Most of the time, they are just reset to zero, but earlier (maybe someone has done stuff in this code, or I have been lucky lately?) they have also been to e.g. -178 or something like that. Also the Feed Actuator has been changed (also not lately). When the -178 happens - not fun. You get spaghetti with the used tape protector all over your machine, since the peeler runs backward unwinding every single spool! After the second time this happened, I now always double check the three rotation fields &  Feed actuator I use so every time I edit any field of rppf, I always switch to the second tab before closing the feeder edit view (by selecting another feeder or any other pane).

The zeroing, I know for sure is happening when editing/changing the location fields, the 'Feed actuator' and the negative values, could also be from when editing the first tab. I'm not sure what caused this, and hopefully this has been fixed.

Now, when I decided to test, before writing this, of course I could not get any issues, and while doing real work, I never have time to look into this.

The zeroing out happens super often, so I guess I only have to learn what I do to end up with this.

 - Micael

[Wayne Black]

To add to my original post, I tried and failed many times to get the dragon to actuate in concert w XYC motion. I got very frustrated and built Micael's machine.xml from the Case Study thread and it finally worked. It was there I realised I was attempting to use the PEEL as the Feed Actuator within the rppf instead of the FEED. 

@Mark 

Am I right to assume that this is only necessary because you need two peeler axes, but only one drag pin actuators?

No, I have CHMT 36 which is a single 'west' peeler and a single drag pin. CHMT 48 has two peelers and a single drag pin. Micaels machine is CHMT 48 and why my setup follows suit. 

If I understand the system of the CHMT feeders correctly, then the peeling axis pulls on each tape of a side, i.e., all but one feeders' cover foil drums just slip on the rod, right? How bad would it be to just always rotate both peeling axes? I'm also asking, because the PushPullFeeders cloning system is currently not smart enough to distinguish east and west feeders, and assign the right actuator... it would simplify setup much.

Correct, just one 'foil drum' rotates to pull the slack cover of a 'fed' tape. Its a simple friction/clutch system. I dont think there would be an issue rotating both peelers on machines that have east/west feeders. 

@Jan!

Yes, the current documentation silently makes the assumption that the controller supports the peeler as separate axis/axes and that the MOVE_TO_COMMAND, SET_GLOBAL_OFFSET_COMMAND and POSITION_REPORT_REGEX are updated to control this axis/axes. For the reference firmware on the original control board that's enforced by I&S.

Yes, I&S probably would have avoided the differing precision in my gcode. I am terrible at using I&S and mostly do things manually without having I&S double check me. I need to get better

A question I have about my settings above. Should the dragpin offset be set on the dragpin actuator itself or on the FEED actuator? I'm thinking offsets should be on the drag pin itself.

Re random M204 timeouts. Mark is correct that I was running the machine slowly around 25% so I could watch dragpin actuation and XC motion. When I looked at the log.; 

timeout waiting for response to M204 S600 G1 X17.484 Y197.3690  A0.431   F5969 ; move to target

The timeouts only occured when A axis motion was involved and changing the precision solved the issue, no more timeouts.

Re Wiki, I just got this running. I need to put the machine back together and do a run then Ill add to the wiki once Ive confirmed no more issues. 

Other little notes: my CHMT is far from factory form. I'm running full Duet CAN on all axii except for C and my dragpin is pneumatic not electromechanical.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/236d5be4-9e5e-4aa4-9853-2f5d97363690n%40googlegroups.com.

--

Wayne Black

Owner

Black Box Embedded, LLC

black...@blackboxembedded.com

1.831.682.4964

[vespaman]

Hi Wayne,

>Should the dragpin offset be set on the dragpin actuator itself or on the FEED actuator? I'm thinking offsets should be on the drag pin itself.

You need to put them on the feed actuators, but it is good to also put it on the drag pin, so I do them all. As a side note, if the drag pin assy' is a bit worn, you may end up with slightly different settings on left/right side. But I guess you have your improved pneumatic drag pin, so yours should be fine.

 -  Micael

[mark maker]

Doesn't sound good. 🙁

Should definitely not happen. One thing that could screw this up, is the capturing button. It likely treats the rotation field as any other rotation field (like for a nozzle rotation), which of course has nothing to do with it. We should probably unwire it. I think this is possible.

Another source could be the geometric transformation that happens when the feeder is rotated, i.e. when you clone or rededicate from east to west or back. Rotating for the other side sounds like 180°, which with some inaccuracies in the sprocket hole line, could well be ±178°. It should not actually include the rotation in the transformation, but there could be a bug.

If you're fiddling around with settings on individual feeders you should enable the Use this one as template? checkbox on each feeder. So each becomes independent.

Also note that Auto-Setup, and some of the part auto assignment OCR functions, also do the cloning implicitly.

The actuator I don't understand. In earlier versions ist was bound by name, and when you change the name of the actuator, the binding was gone. But this should now be tracked and fixed before saving the configuration.

_Mark

To view this discussion visit https://groups.google.com/d/msgid/openpnp/236d5be4-9e5e-4aa4-9853-2f5d97363690n%40googlegroups.com.

[mark maker]

> @Mark
> Am I right to assume that this is only necessary because you need two peeler axes, but only one drag pin actuators?
> No, I have CHMT 36 which is a single 'west' peeler and a single drag pin.

Huh, but then why don't you just actuate and move the same one actuator?

_Mark

To view this discussion visit https://groups.google.com/d/msgid/openpnp/CABUTZN8LKoyWeQn9%2Bj5nss2h7NoB9k_SG8rbRvdGRbCUS1hdAA%40mail.gmail.com.

[Wayne Black]

@Mark

Huh, but then why don't you just actuate and move the same one actuator?

Is that possible and if so how? I couldn't find any other way to make the dragpin work in concert with the XC movement. What I have above works on my CHMT 36 and apparently works on the CHMT 48 as well. I'll be back at the machine tomorrow and will look into this further.

I think you may know this, but in case you dont. Seemingly minor crashes or incorrect movements with the dragpin on the CHMT machines are catastrophic leading to a destroyed dragpin assembly at minimum. The CHMT dragpin assembly is difficult to replace and replacements are not widely available. Given the pain of changing/replacing these pins, which Ive done multiple times after converting to Openpnp, I'm not that big on "trying and seeing what happens".

Again many thanks Mark

To view this discussion visit https://groups.google.com/d/msgid/openpnp/f10106ed-e72e-4039-b0ba-fd858b074cfb%40makr.zone.

[mark maker]

Yes that is possible. The actuator has both an "actuating" soul, and a "motion" soul. You can use both independently.

But the profile actuator is also fine, and it is arguably cleaner to separate them like that.

I just wanted to point out, that at least for machines with one spool axis, the Wiki is correctly documented. I would still appreciate if somebody documented the profile actuator in the Wiki as an alternative.

Regarding breaking things on the CHMT. I guess it would need a sensor on the pin, sensing when retracted successfully. Then OpenPnP can be used to define an interlock to prevent X/Y motion when not sensed retracted:

https://github.com/openpnp/openpnp/wiki/Axis-Interlock-Actuator#safety-confirmation-sensor-on-a-drag-pin

_Mark

To view this discussion visit https://groups.google.com/d/msgid/openpnp/CABUTZN-pcgBrvVktm-dH6N_Vck4Nma9AbgCP6Y6tA6XLSCK%2BZg%40mail.gmail.com.

[Jan]

Hi Wayne!

On 06.11.2024 01:39, Wayne Black wrote:
> @Mark

> /Huh, but then why don't you just actuate and move the same *one* actuator?/

> Is that possible and if so how? I couldn't find any other way to make
> the dragpin work in concert with the XC movement. What I have above
> works on my CHMT 36 and apparently works on the CHMT 48 as well. I'll be
> back at the machine tomorrow and will look into this further.
>

The basic steps are as follows (I'll repeat all for completeness):

1. configure the controller to operate the peeler as axis and remember
it's axis letter.

2. add a new axis for the peeler in OpenPnP and assign it the axis
letter the controller expects to move it.

3. update the MOVE_TO_COMMAND, SET_GLOBAL_OFFSET_COMMAND and
POSITION_REPORT_REGEX to reflect the new peeler axis by it's axis letter.

4. Make sure an actuator driving the drag pin is present (on the head).

5. Go to the drag pin actuator and assign the new peeler axis as it's
rotation axis. (this provides the linkage between dragging and peeling)

6. On the ReferencePushPullFeeder's Push-Pull Motion tab select the drag
pin actuator as Feed Actuator and configure the required peeling motion
in the Rotation column. Selecting Additive will make the peeling motion
relative and generate a reset to 0 of the peeler axis before and after
each feed.

In case of a 48VB with two peelers the setup can be slightly extended to
operate both peelers independently:

1-4. as before

5. create one profile actuators per peeler axes and link all to the drag
pin actuator as described earlier in this thread.

6. for each profile actuator configure the coordinate system using the
same data as the drag pin. (IIRC when using this profile actuator it's
axis and offset configuration is used and data on the drag pin is
ignored. The linkage profile -> drag pin only enables/disables the drag pin)

7. for each profile actuator assign the rotation axis to the respective
peeler axis. This provides the linkage between dragging and peeling.

8. On the ReferenecePushPullFeeders Push-Pull Motion tab select one of
the profile actuator as Feed Actuator.

In both scenarios the drag pin interlock feature shall remain at the
drag pin actuator.

> I think you may know this, but in case you dont. Seemingly minor crashes
> or incorrect movements with the dragpin on the CHMT machines are
> catastrophic leading to a destroyed dragpin assembly at minimum. The
> CHMT dragpin assembly is difficult to replace and replacements are not
> widely available. Given the pain of changing/replacing these pins, which
> Ive done multiple times after converting to Openpnp, I'm not that big on
> "trying and seeing what happens".
>

IIRC there is no solution for that yet: one can jog around regardless of
the drag pin state. The drag pin interlock only helps to not move before
the drag pin is confirmed to be in its up position, which is only
triggered (in the recommended configuration) when the drag pin is
switched off.

Jan

> On Tue, Nov 5, 2024 at 10:31 AM 'mark maker' via OpenPnP

> <ope...@googlegroups.com <mailto:ope...@googlegroups.com>> wrote:
>
> __
> > @Mark
> /> Am I right to assume that this is only necessary because you need
> *two* peeler axes, but only *one* drag pin actuators?
> /> No, I have CHMT 36 which is a single 'west' peeler and a single
> drag pin.
>
> Huh, but then why don't you just actuate and move the same *one*

> actuator?
>
> _Mark
>
> On 05.11.2024 17:04, Wayne Black wrote:
>> To add to my original post, I tried and failed many times to get
>> the dragon to actuate in concert w XYC motion. I got very
>> frustrated and built Micael's machine.xml from the Case Study
>> thread and it finally worked. It was there I realised I was
>> attempting to use the PEEL as the Feed Actuator within the rppf
>> instead of the FEED.
>>
>> @Mark

>> /Am I right to assume that this is only necessary because you need
>> *two* peeler axes, but only *one* drag pin actuators?
>> /

>> No, I have CHMT 36 which is a single 'west' peeler and a single
>> drag pin. CHMT 48 has two peelers and a single drag pin.

>> Micaels machine is CHMT 48 and why my setup follows suit. /
>> /
>> /
>> /
>> /If I understand the system of the CHMT feeders correctly, then
>> the peeling axis pulls on each tape of a side, i.e.,* all but
>> one* feeders' cover foil drums just slip on the rod, right? How

>> bad would it be to just always rotate both peeling axes? I'm also
>> asking, because the PushPullFeeders cloning system is currently
>> not smart enough to distinguish east and west feeders, and assign

>> the right actuator... it would simplify setup much./

>> Correct, just one 'foil drum' rotates to pull the slack cover of a
>> 'fed' tape. Its a simple friction/clutch system. I dont think
>> there would be an issue rotating both peelers on machines
>> that have east/west feeders.

>> /
>> /
>> @Jan!
>> /Yes, the current documentation silently makes the assumption that

>> the controller supports the peeler as separate axis/axes and that
>> the MOVE_TO_COMMAND, SET_GLOBAL_OFFSET_COMMAND and
>> POSITION_REPORT_REGEX are updated to control this axis/axes. For
>> the reference firmware on the original control board that's

>> enforced by I&S./

>> Yes, I&S probably would have avoided the differing precision in my
>> gcode. I am terrible at using I&S and mostly do things manually
>> without having I&S double check me. I need to get better

>> /
>> /

>> A question I have about my settings above. Should the dragpin
>> offset be set on the dragpin actuator itself or on the FEED
>> actuator? I'm thinking offsets should be on the drag pin itself.
>>
>> Re random M204 timeouts. Mark is correct that I was running the
>> machine slowly around 25% so I could watch dragpin actuation and

>> XC motion. When I looked at the log.;//
>> /timeout waiting for response to M204 S600 G1 X17.484 Y197.3690
>> A0.431   F5969 ; move to target/

>> ma...@makr.zone <mailto:ma...@makr.zone>:

>>
>> Hi Wayne
>>
>> thanks for the feed-back.
>>
>> Am I right to assume that this is only necessary

>> because you need *two* peeler axes, but only *one*

>> drag pin actuators?
>>
>> Then yes, this makes sense. Are you willing to add
>> this to the Wiki? Pretty please 😎
>>
>> Design Question:
>>
>> If I understand the system of the CHMT feeders
>> correctly, then the peeling axis pulls on each tape of

>> a side, i.e.,*all but one* feeders' cover foil drums

>> just slip on the rod, right? How bad would it be to
>> just always rotate both peeling axes? I'm also asking,
>> because the PushPullFeeders cloning system is
>> currently not smart enough to distinguish east and
>> west feeders, and assign the right actuator... it
>> would simplify setup much. 😇
>>
>> _Mark
>>
>>
>> On 05.11.2024 02:32, Wayne Black wrote:
>>> First many thanks to Mark, Micael and Jan...
>>>
>>> After struggling several days trying to get Marks
>>> PushPullFeeder

>>> <https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder> with coordinated peeling to work on my CHMT 36, I finally got it working. It wasn't until reading and rereading and Micaels Case study Thread <https://groups.google.com/u/1/g/openpnp/c/JUCRTa6pKbQ/m/2qbB42eBAgAJ> I started discovering details within the thread I had missed in the PushPullFeeder doc. Special thanks Jan! The info is there in the doc, but not as explicit as my brain requires. In case it may help anyone else, this is how I did it;

>>>
>>> - This assumes you already have a baseline CHMT set
>>> up for Openpnp with appropriate Dragpin setup. You
>>> will need to also ensure your GCode driver is updated
>>> for the newly formed Axis below. I'm omitting my
>>> Gcode setup as Im using RRF3.5.3 and not the typical
>>> Smoothie. If anyone sees anything wrong or misleading
>>> please let me/us know!
>>>
>>> -Create a new ReferenceControllerAxis, name should
>>> include "PEEL", like LPEEL for the left CHMT peeler
>>> motor;

>>> ReferenceControllerAxis.png
>>>
>>> -Create a new head ReferenceActuator, name should
>>> include "FEED", like LFEED to correlate to the
>>> LPEEL axis;

>>> ReferenceControllerAxis.png
>>>
>>> -Set FEED actuator profile to leverage the Dragpin

>>> ReferenceControllerAxis.png
>>>
>>> -Create a PushPullFeeder and set the Push-Pull Motion

>>> ReferenceControllerAxis.png
>>>
>>> Now experiment with pushing, Dragpin and Peeling
>>> interactions. Spend hours of fun combing thru the log
>>> to find what you missed if it doesn't work as expected :)
>>>
>>> One initial issue that I finally figured out was
>>> random M204 timeouts. In the end it turned out my
>>> A/C1 axis MOVE_TO_COMMAND was set .3f vs .4f for the
>>> balance of axii. Setting A to %.4f  as the rest
>>> resolved the issue. I point this out as it
>>> illustrates the nature of coordinated axis peeling vs
>>> the uncoordinated simple actuation peeling. The Gcode
>>> driver must be accurate. Now that I have it working,
>>> it feeds are much nicer, Thanks 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 visit

>>> https://groups.google.com/d/msgid/openpnp/ce38cf19-c160-4221-a509-19e8e7e8cbb0n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/ce38cf19-c160-4221-a509-19e8e7e8cbb0n%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 visit

>> https://groups.google.com/d/msgid/openpnp/236d5be4-9e5e-4aa4-9853-2f5d97363690n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/236d5be4-9e5e-4aa4-9853-2f5d97363690n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>>
>>
>>
>> --
>> Wayne Black
>> Owner
>> Black Box Embedded, LLC
>> black...@blackboxembedded.com

>> <mailto:black...@blackboxembedded.com>
>> 1.831.682.4964

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

>> https://groups.google.com/d/msgid/openpnp/CABUTZN8LKoyWeQn9%2Bj5nss2h7NoB9k_SG8rbRvdGRbCUS1hdAA%40mail.gmail.com <https://groups.google.com/d/msgid/openpnp/CABUTZN8LKoyWeQn9%2Bj5nss2h7NoB9k_SG8rbRvdGRbCUS1hdAA%40mail.gmail.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 visit

> https://groups.google.com/d/msgid/openpnp/f10106ed-e72e-4039-b0ba-fd858b074cfb%40makr.zone <https://groups.google.com/d/msgid/openpnp/f10106ed-e72e-4039-b0ba-fd858b074cfb%40makr.zone?utm_medium=email&utm_source=footer>.

>
>
>
> --
> Wayne Black
> Owner
> Black Box Embedded, LLC

> black...@blackboxembedded.com <mailto:black...@blackboxembedded.com>
> 1.831.682.4964

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

> https://groups.google.com/d/msgid/openpnp/CABUTZN-pcgBrvVktm-dH6N_Vck4Nma9AbgCP6Y6tA6XLSCK%2BZg%40mail.gmail.com <https://groups.google.com/d/msgid/openpnp/CABUTZN-pcgBrvVktm-dH6N_Vck4Nma9AbgCP6Y6tA6XLSCK%2BZg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Mark,

One thing that could screw this up, is the capturing button. It likely treats the rotation field as any other rotation field (like for a nozzle rotation), which of course has nothing to do with it. We should probably unwire it. I think this is possible.

Another source could be the geometric transformation that happens when the feeder is rotated, i.e. when you clone or rededicate from east to west or back. Rotating for the other side sounds like 180°, which with some inaccuracies in the sprocket hole line, could well be ±178°. It should not actually include the rotation in the transformation, but there could be a bug.

Aha, I did not consider rotation, so for me, the -178.something looked like a "random number happening twice". :-)

 

If you're fiddling around with settings on individual feeders you should enable the Use this one as template? checkbox on each feeder. So each becomes independent.

OK, I have no feeders with "Use this one as a template" selected, will this not be the same end result?

 

 - Micael

[mark maker]

Im not sure (no time to look) but I think it will still select a template based on "similarity" alone. As far as I remember the "template" switch is mostly a tie-breaker between similar feeders. I would agree that this is not what you might expect, and we should change it (if in fact it works like that).

_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 visit https://groups.google.com/d/msgid/openpnp/1a4b3882-df7f-4415-993e-75464194ed78n%40googlegroups.com.

[Wayne Black]

Hey Jan!

I can confirm what you have here works for the CHMT 36, but item #5 also needs to have the X axis set as well (all axes involved). Otherwise the drag pin simply pulses during actual X drag movement. I feel silly just discovering this as it makes complete sense that the coordinated actuation will only activate with referenced axes. I've put a bracketed note in your #5 below

1. configure the controller to operate the peeler as axis and remember
it's axis letter.

2. add a new axis for the peeler in OpenPnP and assign it the axis
letter the controller expects to move it.

3. update the MOVE_TO_COMMAND, SET_GLOBAL_OFFSET_COMMAND and
POSITION_REPORT_REGEX to reflect the new peeler axis by it's axis letter.

4. Make sure an actuator driving the drag pin is present (on the head).

5. Go to the drag pin actuator and assign the new peeler axis as it's
rotation axis. (this provides the linkage between dragging and peeling)

[Assign all axes involved with the coordinated movement]

6. On the ReferencePushPullFeeder's Push-Pull Motion tab select the drag
pin actuator as Feed Actuator and configure the required peeling motion
in the Rotation column. Selecting Additive will make the peeling motion
relative and generate a reset to 0 of the peeler axis before and after
each feed.

Thanks Guys