CHM-T36VA updates
1,465 views
Skip to first unread message
Jan
Feb 23, 2022, 12:31:05 PM2/23/22
to OpenPnP
Hi All!
As promised, today I've
- released my modifications to the smoothieware code for the CMH-T36VA
mainboard at https://github.com/janm012012/Smoothieware-CHMT,
- my ringlight design for the CHM-T36VA at
https://github.com/janm012012/Ringlight and
- updated the Wiki for the CHM-T36VA at
https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA with some notes.
If you feel there is anything missing, not helpful, imprecise or even
incorrect, please let me know and I'll be happy to fix it.
Jan
As promised, today I've
- released my modifications to the smoothieware code for the CMH-T36VA
mainboard at https://github.com/janm012012/Smoothieware-CHMT,
- my ringlight design for the CHM-T36VA at
https://github.com/janm012012/Ringlight and
- updated the Wiki for the CHM-T36VA at
https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA with some notes.
If you feel there is anything missing, not helpful, imprecise or even
incorrect, please let me know and I'll be happy to fix it.
Jan
mark maker
Feb 23, 2022, 1:21:03 PM2/23/22
to ope...@googlegroups.com
Many thanks, that's 👍👍👍 💯😃
Wayne Black
Feb 23, 2022, 2:05:22 PM2/23/22
to OpenPnP
Awesome Jan :)
Wayne Black
Feb 23, 2022, 7:48:42 PM2/23/22
to OpenPnP
Hey Jan,
Thanks for the add'l info. Can you share your latest openpnp machine.xml?
What I'm mostly after is the actuator/sensor drag pin setting to prevent XY motion in case of a stuck dragpin, but still allowing X motion (the drag) for the tape feed. Right now I have the axis interlock disabled but worried of a stuck dragpin machine crash.
Do you have this sorted in Openpnp?
Jan
Feb 24, 2022, 4:55:17 AM2/24/22
to ope...@googlegroups.com
Hi Wayne!
Good point, I will add that.
Yes, I do have setup a dragpin interlock (I've found the details in a
thread between Mark and Nelio some month back on this list). The basic
idea is, that the machine is not allowed to move while the dragpin is
commanded to retract and the read back has confirmed it's in the up
position. It does not prevent any other movements. However, I found it
quite helpful, because it prevents movements while the dragpin is stuck
in tape.
Please find a picture of my setup. In addition you need to wire the
dragpin read back in. I've done that by assigning the dragpin a
ACTUATOR_READ_COMMAND. I also added a small (100ms) delay to the
ACTUATOR_BOOLEAN_COMMAND false state to allow the dragpin to move up.
This was needed to avoid false alarms. Unfortunately OpenPnp does not
provide a way to help the dragpin from retracting if is stuck. I've
read, that he original Chinese software drives small cycles if that
case. Would be probably a good thing to add. However, with good setup I
did not have problem while running yet and while optimizing the
interlock helps...
I've stripped my machine.xml and put it into my smoothieware repository
at
https://github.com/janm012012/Smoothieware-CHMT/tree/chmt/machine.xml.
(I removed my feeder setup, camera calibration, backlash calibration and
reopened all fundamental subjects in Issues & Solutions).
Jan
On 24.02.2022 01:48, Wayne Black wrote:
> Hey Jan,
> Thanks for the add'l info. Can you share your latest openpnp machine.xml?
> What I'm mostly after is the actuator/sensor drag pin setting to prevent
> XY motion in case of a stuck dragpin, but still allowing X motion (the
> drag) for the tape feed. Right now I have the axis interlock disabled
> but worried of a stuck dragpin machine crash.
> Do you have this sorted in Openpnp?
> On Wednesday, February 23, 2022 at 11:05:22 AM UTC-8 Wayne Black wrote:
>
> Awesome Jan :)
>
> On Wednesday, February 23, 2022 at 10:21:03 AM UTC-8 ma...@makr.zone
> wrote:
>
> Many thanks, that's 👍👍👍 💯😃
>
> On 23.02.22 18:31, 'Jan' via OpenPnP wrote:
>> Hi All!
>> As promised, today I've
>> - released my modifications to the smoothieware code for the
>> CMH-T36VA mainboard at
>> https://github.com/janm012012/Smoothieware-CHMT
>> <https://github.com/janm012012/Smoothieware-CHMT>,
> 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/61c98006-14d9-47bc-b4c2-1a50fd78613bn%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/61c98006-14d9-47bc-b4c2-1a50fd78613bn%40googlegroups.com?utm_medium=email&utm_source=footer>.
Good point, I will add that.
Yes, I do have setup a dragpin interlock (I've found the details in a
thread between Mark and Nelio some month back on this list). The basic
idea is, that the machine is not allowed to move while the dragpin is
commanded to retract and the read back has confirmed it's in the up
position. It does not prevent any other movements. However, I found it
quite helpful, because it prevents movements while the dragpin is stuck
in tape.
Please find a picture of my setup. In addition you need to wire the
dragpin read back in. I've done that by assigning the dragpin a
ACTUATOR_READ_COMMAND. I also added a small (100ms) delay to the
ACTUATOR_BOOLEAN_COMMAND false state to allow the dragpin to move up.
This was needed to avoid false alarms. Unfortunately OpenPnp does not
provide a way to help the dragpin from retracting if is stuck. I've
read, that he original Chinese software drives small cycles if that
case. Would be probably a good thing to add. However, with good setup I
did not have problem while running yet and while optimizing the
interlock helps...
I've stripped my machine.xml and put it into my smoothieware repository
at
https://github.com/janm012012/Smoothieware-CHMT/tree/chmt/machine.xml.
(I removed my feeder setup, camera calibration, backlash calibration and
reopened all fundamental subjects in Issues & Solutions).
Jan
On 24.02.2022 01:48, Wayne Black wrote:
> Hey Jan,
> Thanks for the add'l info. Can you share your latest openpnp machine.xml?
> What I'm mostly after is the actuator/sensor drag pin setting to prevent
> XY motion in case of a stuck dragpin, but still allowing X motion (the
> drag) for the tape feed. Right now I have the axis interlock disabled
> but worried of a stuck dragpin machine crash.
> Do you have this sorted in Openpnp?
> On Wednesday, February 23, 2022 at 11:05:22 AM UTC-8 Wayne Black wrote:
>
> Awesome Jan :)
>
> On Wednesday, February 23, 2022 at 10:21:03 AM UTC-8 ma...@makr.zone
> wrote:
>
> Many thanks, that's 👍👍👍 💯😃
>
> On 23.02.22 18:31, 'Jan' via OpenPnP wrote:
>> Hi All!
>> As promised, today I've
>> - released my modifications to the smoothieware code for the
>> CMH-T36VA mainboard at
>> https://github.com/janm012012/Smoothieware-CHMT
>> - my ringlight design for the CHM-T36VA at
>> https://github.com/janm012012/Ringlight
>> <https://github.com/janm012012/Ringlight> and
>> - updated the Wiki for the CHM-T36VA at
>> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
>> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA>
>> with some notes.
>> If you feel there is anything missing, not helpful,
>> imprecise or even incorrect, please let me know and I'll be
>> happy to fix it.
>>
>> Jan
>>
> --
>> https://github.com/janm012012/Ringlight
>> <https://github.com/janm012012/Ringlight> and
>> - updated the Wiki for the CHM-T36VA at
>> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
>> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA>
>> with some notes.
>> If you feel there is anything missing, not helpful,
>> imprecise or even incorrect, please let me know and I'll be
>> happy to fix it.
>>
>> 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/61c98006-14d9-47bc-b4c2-1a50fd78613bn%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/61c98006-14d9-47bc-b4c2-1a50fd78613bn%40googlegroups.com?utm_medium=email&utm_source=footer>.
Wayne Black
Feb 24, 2022, 11:46:19 AM2/24/22
to OpenPnP
Excellent, Ill give it a try and let you know how it goes :)
vespaman
Feb 24, 2022, 4:24:00 PM2/24/22
to OpenPnP
Thanks Jan! Just in time for my conversion :)
Wayne Black
Feb 27, 2022, 11:16:07 PM2/27/22
to OpenPnP
Hey Jan,
As evidenced in the pic, I think I may have mis-understood;
" In addition you need to wire the dragpin read back in. I've done that by assigning the dragpin a ACTUATOR_READ_COMMAND. I also added a small (100ms) delay to the ACTUATOR_BOOLEAN_COMMAND false state to allow the dragpin to move up."
I thought you meant to check the IO state of the drag pin actuator, not the drag pin sensor. The thought being if the dragpin logic was actuated and the head was commanded to move, the move would be allowed. Conversely, if the drag pin was de activated but the drag pin sensor was triggered, head movement would not be allowed.
Just to confirm, by "wire the dragpin read back in" you mean the drag pin sensor correct?
Looking at your read and regex, I see your calling the limit switch states, but dont see the dragpin listed as an endstop in your config.
Ill look for the thread you cited above.
Jan
Feb 28, 2022, 3:53:51 AM2/28/22
to ope...@googlegroups.com
Oh Wayne, that looks really terrifying!
As I mentioned, I started using Nelios machine.xml I found on this list
and verified every bit, I thought would be relevant and that the overall
procedure works as expected:
- I have a dragpin actuator attached to the head.
- The dragpin actuator is of BOOLEAN type and its
ACTUATOR_BOOLEAN_COMMAND is
{True: M816 S100} ; DRAGPIN M816 down @100%
{True: G4 P10} ; wait a little bit until the pin is down
{True: M816 S10} ; switch to hold @10%
{False: M817} ; DRAGPIN M817 release
{False: G4 P100} ; wait a little bit until the pin is up (avoid false
interlock errors)
The M816 is the "input_on_command" property and M817 the
"input_off_command" of a "switch" in smoothieware. This switch is
configured as PWM so the S parameter specifies the duty cycle in
percent. The "G4 P100" in the False path is the delay I mentioned. Its
intention is to wait a little bit before the interlock check runs to
verify the pin is actually up.
- I'm using the same dragpin actuator for read back of the actual state.
The machine provides a separate interrupter for that.
- I've "M119" assigned as ACTUATOR_READ_COMMAND. This seems to be a
generic command that returns the state of all limit switches. It returns
for me:
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
- I've a lengthy ACTUATOR_READ_REGEX command:
^X_min:\d Y_min:\d Z_min:\d pins- \(X\)P\d.\d+:\d \(Y\)P\d.\d+:\d
\(Z\)P\d.\d+:\d \(Z\)P\d.\d+:(?<Value>\d)
It seems to return the value behind "P4.2:" as "Value".
- "4.2" is smoothies name for PE2, which is according the the reverse
engineering information "LZ Drag Pin Limit"
- PE2 is configured in my smoothieware as "gamma_max_endstop" using the
value "4.2!^". If I understand the syntax correctly, is specifies an
inverted input. "gamma_homing_direction" it set to "home_to_min". So the
state of "gamma_max_endstop" seems to be actually not used internally.
- If I press the "Read" button on the dragpin actuator the "Read Value"
is 1 if the dragpin is up and 0 if down.
- The "Axis Interlock" configuration is as on the screenshot I posted a
few days before: "Interlock Type" is "ConfirmMatchBeforeAxisMove",
"Confirmation Pattern" is "1", "Axis 1" is "X", "Axis 2" is "Y", "Axis
3" and "Axis 4" are unused and "Interlock Conditions" are set to my
dragpin actuator, "SwitchedOff" and "Speed %" to 0% and 100%.
I've verified that the entire setup works. If the dragpin is held down
and switched off, OpenPnp throws an exception, that the interlock fails.
I hope this helps...
Jan
On 28.02.2022 05:16, Wayne Black wrote:
> Hey Jan,
> that by assigning the dragpin a //ACTUATOR_READ_COMMAND. I also added a
> small (100ms) delay to the //ACTUATOR_BOOLEAN_COMMAND false state to
> allow the dragpin to move up./"
> <https://github.com/janm012012/Smoothieware-CHMT/tree/chmt/machine.xml>.
> <https://groups.google.com/d/msgid/openpnp/61c98006-14d9-47bc-b4c2-1a50fd78613bn%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/61c98006-14d9-47bc-b4c2-1a50fd78613bn%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> <https://groups.google.com/d/msgid/openpnp/5eaad83f-ac63-4c20-a974-4028236dede4n%40googlegroups.com?utm_medium=email&utm_source=footer>.
As I mentioned, I started using Nelios machine.xml I found on this list
and verified every bit, I thought would be relevant and that the overall
procedure works as expected:
- I have a dragpin actuator attached to the head.
- The dragpin actuator is of BOOLEAN type and its
ACTUATOR_BOOLEAN_COMMAND is
{True: M816 S100} ; DRAGPIN M816 down @100%
{True: G4 P10} ; wait a little bit until the pin is down
{True: M816 S10} ; switch to hold @10%
{False: M817} ; DRAGPIN M817 release
{False: G4 P100} ; wait a little bit until the pin is up (avoid false
interlock errors)
The M816 is the "input_on_command" property and M817 the
"input_off_command" of a "switch" in smoothieware. This switch is
configured as PWM so the S parameter specifies the duty cycle in
percent. The "G4 P100" in the False path is the delay I mentioned. Its
intention is to wait a little bit before the interlock check runs to
verify the pin is actually up.
- I'm using the same dragpin actuator for read back of the actual state.
The machine provides a separate interrupter for that.
- I've "M119" assigned as ACTUATOR_READ_COMMAND. This seems to be a
generic command that returns the state of all limit switches. It returns
for me:
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
- I've a lengthy ACTUATOR_READ_REGEX command:
^X_min:\d Y_min:\d Z_min:\d pins- \(X\)P\d.\d+:\d \(Y\)P\d.\d+:\d
\(Z\)P\d.\d+:\d \(Z\)P\d.\d+:(?<Value>\d)
It seems to return the value behind "P4.2:" as "Value".
- "4.2" is smoothies name for PE2, which is according the the reverse
engineering information "LZ Drag Pin Limit"
- PE2 is configured in my smoothieware as "gamma_max_endstop" using the
value "4.2!^". If I understand the syntax correctly, is specifies an
inverted input. "gamma_homing_direction" it set to "home_to_min". So the
state of "gamma_max_endstop" seems to be actually not used internally.
- If I press the "Read" button on the dragpin actuator the "Read Value"
is 1 if the dragpin is up and 0 if down.
- The "Axis Interlock" configuration is as on the screenshot I posted a
few days before: "Interlock Type" is "ConfirmMatchBeforeAxisMove",
"Confirmation Pattern" is "1", "Axis 1" is "X", "Axis 2" is "Y", "Axis
3" and "Axis 4" are unused and "Interlock Conditions" are set to my
dragpin actuator, "SwitchedOff" and "Speed %" to 0% and 100%.
I've verified that the entire setup works. If the dragpin is held down
and switched off, OpenPnp throws an exception, that the interlock fails.
I hope this helps...
Jan
On 28.02.2022 05:16, Wayne Black wrote:
> Hey Jan,
> As evidenced in the pic, I think I may have mis-understood;
> "/ In addition you need to wire the //dragpin read back in. I've done
> that by assigning the dragpin a //ACTUATOR_READ_COMMAND. I also added a
> small (100ms) delay to the //ACTUATOR_BOOLEAN_COMMAND false state to
> allow the dragpin to move up./"
> 20220227_191412.jpg
>
> I thought you meant to check the IO state of the drag pin actuator, not
> the drag pin sensor. The thought being if the dragpin logic was actuated
> and the head was commanded to move, the move would be allowed.
> Conversely, if the drag pin was de activated but the drag pin sensor was
> triggered, head movement would not be allowed.
>
> Just to confirm, by "/wire the //dragpin read back in/" you mean the
>
> I thought you meant to check the IO state of the drag pin actuator, not
> the drag pin sensor. The thought being if the dragpin logic was actuated
> and the head was commanded to move, the move would be allowed.
> Conversely, if the drag pin was de activated but the drag pin sensor was
> triggered, head movement would not be allowed.
>
> <https://groups.google.com/d/msgid/openpnp/61c98006-14d9-47bc-b4c2-1a50fd78613bn%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/5eaad83f-ac63-4c20-a974-4028236dede4n%40googlegroups.com
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/5eaad83f-ac63-4c20-a974-4028236dede4n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Wayne Black
Feb 28, 2022, 10:27:19 AM2/28/22
to OpenPnP
Hey Jan,
Wanted to give you quick feedback that I rec'd your response. Yes, a quick review and this is very helpful, thanks again Jan.
Later today Ill review more thoroughly and step through the smoothie config and openpnp setup to match this to RRF3.
Re the crash. I was empirically playing we the interlock settings and testing movement in what I thought was a "safe range" when I accidentally hit the park button...
Wayne Black
Mar 1, 2022, 12:23:56 PM3/1/22
to OpenPnP
Hey Jan just got the coil changed, will let you know how it goes. FYI heres a pic of the X limit, 'LZ' limit and drag pin board. You need to remove the pcb if you dont want to cut and butt splice in a new selenoid. It not hard, but it pretty uncomfortable accessing the 6 screws required for removal.
Jan
Mar 5, 2022, 2:03:22 PM3/5/22
to ope...@googlegroups.com
Thanks Wayne, for the picture!
Do you see any chance to increase the clearance at the dragpin? I've
verified my dragpin operation again and found, that the pin/its mounting
is a little bit lower then required to safely pull the tape. If there is
space, increasing the clearnace would give me more room to place my
customers favourit 5.5mm tall connectors...
Jan
On 01.03.2022 18:23, Wayne Black wrote:
> Hey Jan just got the coil changed, will let you know how it goes. FYI
> heres a pic of the X limit, 'LZ' limit and drag pin board. You need to
> remove the pcb if you dont want to cut and butt splice in a new
> selenoid. It not hard, but it pretty uncomfortable accessing the 6
> screws required for removal.
> <https://groups.google.com/d/msgid/openpnp/5eaad83f-ac63-4c20-a974-4028236dede4n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/5eaad83f-ac63-4c20-a974-4028236dede4n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> <https://groups.google.com/d/msgid/openpnp/1531b519-1490-4c6c-aee8-a77074972723n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Do you see any chance to increase the clearance at the dragpin? I've
verified my dragpin operation again and found, that the pin/its mounting
is a little bit lower then required to safely pull the tape. If there is
space, increasing the clearnace would give me more room to place my
customers favourit 5.5mm tall connectors...
Jan
On 01.03.2022 18:23, Wayne Black wrote:
> Hey Jan just got the coil changed, will let you know how it goes. FYI
> heres a pic of the X limit, 'LZ' limit and drag pin board. You need to
> remove the pcb if you dont want to cut and butt splice in a new
> selenoid. It not hard, but it pretty uncomfortable accessing the 6
> screws required for removal.
> <https://groups.google.com/d/msgid/openpnp/5eaad83f-ac63-4c20-a974-4028236dede4n%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/1531b519-1490-4c6c-aee8-a77074972723n%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/1531b519-1490-4c6c-aee8-a77074972723n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Jan
Mar 5, 2022, 2:06:52 PM3/5/22
to ope...@googlegroups.com
Cool! Who do you operate the peeler? I can't see the delay where just
the peeler is moving, that I have...
On 02.03.2022 06:37, Wayne Black wrote:
> Hey Jan,
> <https://groups.google.com/d/msgid/openpnp/5eaad83f-ac63-4c20-a974-4028236dede4n%40googlegroups.com>
>
> >
> <https://groups.google.com/d/msgid/openpnp/5eaad83f-ac63-4c20-a974-4028236dede4n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/5eaad83f-ac63-4c20-a974-4028236dede4n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> <https://groups.google.com/d/msgid/openpnp/a87a1280-ea8f-44d8-9582-2c5fcf204ef1n%40googlegroups.com?utm_medium=email&utm_source=footer>.
the peeler is moving, that I have...
On 02.03.2022 06:37, Wayne Black wrote:
> Hey Jan,
> I got it all working correctly now. I had to invert the 'LZ' switch. Now
> the head will move w the drag pin down when actuated, but not move when
> the drag pin is down and NOT actuated. A quick vid is attached.
>
>
> On Tuesday, March 1, 2022 at 9:23:56 AM UTC-8 Wayne Black wrote:
>
> Hey Jan just got the coil changed, will let you know how it goes.
> FYI heres a pic of the X limit, 'LZ' limit and drag pin board. You
> need to remove the pcb if you dont want to cut and butt splice in a
> new selenoid. It not hard, but it pretty uncomfortable accessing the
> 6 screws required for removal.
> the head will move w the drag pin down when actuated, but not move when
> the drag pin is down and NOT actuated. A quick vid is attached.
>
>
> On Tuesday, March 1, 2022 at 9:23:56 AM UTC-8 Wayne Black wrote:
>
> Hey Jan just got the coil changed, will let you know how it goes.
> FYI heres a pic of the X limit, 'LZ' limit and drag pin board. You
> need to remove the pcb if you dont want to cut and butt splice in a
> new selenoid. It not hard, but it pretty uncomfortable accessing the
> 6 screws required for removal.
>
> >
> <https://groups.google.com/d/msgid/openpnp/5eaad83f-ac63-4c20-a974-4028236dede4n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/5eaad83f-ac63-4c20-a974-4028236dede4n%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/a87a1280-ea8f-44d8-9582-2c5fcf204ef1n%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/a87a1280-ea8f-44d8-9582-2c5fcf204ef1n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Wayne Black
Mar 5, 2022, 4:37:31 PM3/5/22
to OpenPnP
Hay Jan,
If you're asking if the dragpin can be moved up slightly for more Z clearance, the quick answer is no. The reason I say that is that after I had severely bent the crashed solenoid's frame I figured I would have to do a lot of adjusting when mounting the new solenoid to maintain perpendicularity to the LZ limit and tape holes. Then a lot of recalibrating the pin offset. In the end everything went back very easily and aligned without a fuss because the screw/hole mounting for the pin is pretty tight. Even the pin to camera offset was barely changed. All this means attempting to offset the pin physically from its original position would very minor at best and probably not enough for what you want to do.
I have clearance issues too. Of all the searching on the web about this I haven't seen any good solutions. The only solution I can figure is raising the Y rails. I dont have the numbers in front of me, but I think the Y could be raised 3mm and nozzle/pin have full reach of the feeders and PCB tray. I'm Thinking of doing this as I have a USB connector and inductor that I have to manually place.
I also bought this guy with essentially double the Z travel. It's pretty sweet in that it has individual rotation and Z limits, but the best thing is that there is Zero cam slop between the two nozzles. I figured Id build a new X carriage to mount it, but after comparing my 36VA to my 48VB, they both have different X carriages/rails. Im not pulling the 48 out of the box until the 36 is dialed in and will use the better nozzle system for the 48.
Ian Arkver
Mar 5, 2022, 5:59:13 PM3/5/22
to OpenPnP
That's the China SMT head assembly I bought too (not for a CHMT though). It is quite nice - so far anyway.
When I started this project I modelled my design on the CHMT to a degree (no drag pin though) and now I too have low clearance under the Y rails and would ideally raise them a bit.
Wayne Black
Mar 5, 2022, 6:10:30 PM3/5/22
to OpenPnP
Hi Ian,
Can you show a pic of the head to carriage mount?Jan
Mar 6, 2022, 3:59:41 AM3/6/22
to ope...@googlegroups.com
Hi Wayne!
On 05.03.2022 22:37, Wayne Black wrote:
> Hay Jan,
> If you're asking if the dragpin can be moved up slightly for more Z
> clearance, the quick answer is no. The reason I say that is that after I
> had severely bent the crashed solenoid's frame I figured I would have to
> do a lot of adjusting when mounting the new solenoid to maintain
> perpendicularity to the LZ limit and tape holes. Then a lot of
> recalibrating the pin offset. In the end everything went back very
> easily and aligned without a fuss because the screw/hole mounting for
> the pin is pretty tight. Even the pin to camera offset was barely
> changed. All this means attempting to offset the pin physically from its
> original position would very minor at best and probably not enough for
> what you want to do.
>
I've used the suggested method for position measurement of head
mountables: put a fine layer of putty on an old PCB, make a mark using
the dragpin and then moved the camera with the DRO set to relative.
Switching between camera and tool then gave a good indication, how
precise the dragpin location is.
What about the structure the dragpin is mounted on? It looks like some
black aluminum. For me, this structure seems to be even lower then the
dragpin magnet itself. Do you know if this structure can be removed
safely for modification?
> I have clearance issues too. Of all the searching on the web about this
> I haven't seen any good solutions. The only solution I can figure is
> raising the Y rails. I dont have the numbers in front of me, but I think
> the Y could be raised 3mm and nozzle/pin have full reach of the feeders
> and PCB tray. I'm Thinking of doing this as I have a USB connector and
> inductor that I have to manually place.
>
As we've discussed with Paul a few weeks before, the dragpin is one
limit and the nozzle tip upper position a second. I like his Paul's idea
to lower the PCB to place larger parts. Guess it should be quite easy to
put some spaces on the machine bed and reuse the registration system.
The cam has a length of 17.5m. With about 45° max tilt angle, the max.
Z travel is about 12mm. That's about 3mm more then my default Z heights
for 1.6mm PCB of -8.8mm.
> I also bought this guy
> <https://www.aliexpress.com/item/32807025833.html?spm=a2g0o.detail.0.0.70529dadW8hwBW&gps-id=pcDetailBottomMoreThisSeller&scm=1007.13339.274029.0&scm_id=1007.13339.274029.0&scm-url=1007.13339.274029.0&pvid=84ab9e2d-33aa-45b7-a20c-bddbd92e60af&_t=gps-id:pcDetailBottomMoreThisSeller,scm-url:1007.13339.274029.0,pvid:84ab9e2d-33aa-45b7-a20c-bddbd92e60af,tpp_buckets:668%232846%238115%232000&pdp_ext_f=%257B%2522sku_id%2522%253A%252266664677644%2522%252C%2522sceneId%2522%253A%25223339%2522%257D&pdp_pi=-1%253B263.8%253B-1%253B-1%2540salePrice%253BUSD%253Brecommend-recommend>
nozzle tip holders yet: I don't see yet how they can be used with
automatic nozzle changers. Do you have any idea?
Concerning the cam tilt: is my understanding correct, that you're
talking about the tilt after homing which leaves the right nozzle
slightly lower then the left? I solved that by applying an offset on the
Z-axis after homing (using G92). I tried to rotate the rubber wheels to
feel the balance point.
Jan
> <https://groups.google.com/d/msgid/openpnp/a87a1280-ea8f-44d8-9582-2c5fcf204ef1n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/a87a1280-ea8f-44d8-9582-2c5fcf204ef1n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> <https://groups.google.com/d/msgid/openpnp/909bdff8-e6f0-45f4-9f0b-fa83356bc3bcn%40googlegroups.com?utm_medium=email&utm_source=footer>.
On 05.03.2022 22:37, Wayne Black wrote:
> Hay Jan,
> If you're asking if the dragpin can be moved up slightly for more Z
> clearance, the quick answer is no. The reason I say that is that after I
> had severely bent the crashed solenoid's frame I figured I would have to
> do a lot of adjusting when mounting the new solenoid to maintain
> perpendicularity to the LZ limit and tape holes. Then a lot of
> recalibrating the pin offset. In the end everything went back very
> easily and aligned without a fuss because the screw/hole mounting for
> the pin is pretty tight. Even the pin to camera offset was barely
> changed. All this means attempting to offset the pin physically from its
> original position would very minor at best and probably not enough for
> what you want to do.
>
mountables: put a fine layer of putty on an old PCB, make a mark using
the dragpin and then moved the camera with the DRO set to relative.
Switching between camera and tool then gave a good indication, how
precise the dragpin location is.
What about the structure the dragpin is mounted on? It looks like some
black aluminum. For me, this structure seems to be even lower then the
dragpin magnet itself. Do you know if this structure can be removed
safely for modification?
> I have clearance issues too. Of all the searching on the web about this
> I haven't seen any good solutions. The only solution I can figure is
> raising the Y rails. I dont have the numbers in front of me, but I think
> the Y could be raised 3mm and nozzle/pin have full reach of the feeders
> and PCB tray. I'm Thinking of doing this as I have a USB connector and
> inductor that I have to manually place.
>
limit and the nozzle tip upper position a second. I like his Paul's idea
to lower the PCB to place larger parts. Guess it should be quite easy to
put some spaces on the machine bed and reuse the registration system.
The cam has a length of 17.5m. With about 45° max tilt angle, the max.
Z travel is about 12mm. That's about 3mm more then my default Z heights
for 1.6mm PCB of -8.8mm.
> I also bought this guy
> with essentially double the Z travel. It's pretty sweet in that it has
> individual rotation and Z limits, but the best thing is that there is
> Zero cam slop between the two nozzles. I figured Id build a new X
> carriage to mount it, but after comparing my 36VA to my 48VB, they both
> have different X carriages/rails. Im not pulling the 48 out of the box
> until the 36 is dialed in and will use the better nozzle system for the 48.
>
Looks cool! What cam length do they use? However, I don't like the
> individual rotation and Z limits, but the best thing is that there is
> Zero cam slop between the two nozzles. I figured Id build a new X
> carriage to mount it, but after comparing my 36VA to my 48VB, they both
> have different X carriages/rails. Im not pulling the 48 out of the box
> until the 36 is dialed in and will use the better nozzle system for the 48.
>
nozzle tip holders yet: I don't see yet how they can be used with
automatic nozzle changers. Do you have any idea?
Concerning the cam tilt: is my understanding correct, that you're
talking about the tilt after homing which leaves the right nozzle
slightly lower then the left? I solved that by applying an offset on the
Z-axis after homing (using G92). I tried to rotate the rubber wheels to
feel the balance point.
Jan
> <https://groups.google.com/d/msgid/openpnp/a87a1280-ea8f-44d8-9582-2c5fcf204ef1n%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/909bdff8-e6f0-45f4-9f0b-fa83356bc3bcn%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/909bdff8-e6f0-45f4-9f0b-fa83356bc3bcn%40googlegroups.com?utm_medium=email&utm_source=footer>.
Ian Arkver
Mar 6, 2022, 4:13:45 AM3/6/22
to OpenPnP
Hi Wayne,
I don't have a great photo handy. This is the best I could find - it's an early one (July 2020). As I said the design was sort of inspired by looking at YT videos of the CHMT (and others), it's not just a clone.
The main part of the mount was a 3D printed block which holds the lower bearing and the camera, has the head assembly bolted to one side and a plate with the upper bearing on the other side. There are slopes to ease printing and remove bridging.
The FC assembly shows it most clearly I think. The bolted thing in the middle of the block is the belt tensioner.
All the best,
Ian
Ian
Ian Arkver
Mar 6, 2022, 5:04:04 AM3/6/22
to ope...@googlegroups.com
from. I guess I measured it at some point. A quick check shows it's
probably right.
These holders are indeed a problem with a toolchanger. They're very
tight. It might be possible to change the rubber/plastic ring and reduce
the side force, but there's no way the carriage springs will pull the
nozzle out themselves.
> Concerning the cam tilt: is my understanding correct, that you're
> talking about the tilt after homing which leaves the right nozzle
> slightly lower then the left? I solved that by applying an offset on the
> Z-axis after homing (using G92). I tried to rotate the rubber wheels to
> feel the balance point.
opto-interrupter then sets the zero position to half way between the two
readings. Seems to work, but I've not done enough placements to know
whether it's accurate or I just got lucky.
Also the springs will pull the carriages up to the end stop tube/bolt in
the middle when the motor is off. So long as you've tweaked it so there
really is no cam gap then that's also a natural zero point. When I first
got the head there was a slight gap but I adjusted the endstop up a
fraction (with a file, iirc) to remove it.
Regards,
Ian
Jan
Mar 6, 2022, 2:12:38 PM3/6/22
to ope...@googlegroups.com
Hi Ian!
On 06.03.2022 11:03, Ian Arkver wrote:
[...]
for the China SMT head Wayne linked?
> These holders are indeed a problem with a toolchanger. They're very
> tight. It might be possible to change the rubber/plastic ring and reduce
> the side force, but there's no way the carriage springs will pull the
> nozzle out themselves.
>
The Betz head seems to use a holder with a spring to lock the nozzle
tip. I guess this locking can be easily pushed way then trying to change
the nozzle tip.
However, the holder on the 36VA stock head seems to be fixed to the
rotation stepper. At least I have not found a way to dismount them. (If
anyone does, please tell me.) Anyhow, due to the small cam radius, there
is not much space to play with...
>> Concerning the cam tilt: is my understanding correct, that you're
>> talking about the tilt after homing which leaves the right nozzle
>> slightly lower then the left? I solved that by applying an offset on
>> the Z-axis after homing (using G92). I tried to rotate the rubber
>> wheels to feel the balance point.
>
> My controller FW moves each carriage down until it clears the zero
> opto-interrupter then sets the zero position to half way between the two
> readings. Seems to work, but I've not done enough placements to know
> whether it's accurate or I just got lucky.
>
Thats need! What controller do you use? I'm using a smoothieware port
and have not found such an option.
Its exactely the problem, that the homing only goes into one
directions. Without the offset, my right nozzle was lower by about 2mm
with respect to the left.
> Also the springs will pull the carriages up to the end stop tube/bolt in
> the middle when the motor is off. So long as you've tweaked it so there
> really is no cam gap then that's also a natural zero point. When I first
> got the head there was a slight gap but I adjusted the endstop up a
> fraction (with a file, iirc) to remove it.
>
I thought about removeing some of this material. Would allow the nozzle
to go a little higher and still keep the old mechanics.
Jan
On 06.03.2022 11:03, Ian Arkver wrote:
[...]
> I've cam radius in OpenPnP set to 22.55mm. Not sure where that came
> from. I guess I measured it at some point. A quick check shows it's
> probably right.
>
The 17.5mm is the cam radius of my CHM-T36VA stock head. The 22.5mm is
> from. I guess I measured it at some point. A quick check shows it's
> probably right.
>
for the China SMT head Wayne linked?
> These holders are indeed a problem with a toolchanger. They're very
> tight. It might be possible to change the rubber/plastic ring and reduce
> the side force, but there's no way the carriage springs will pull the
> nozzle out themselves.
>
tip. I guess this locking can be easily pushed way then trying to change
the nozzle tip.
However, the holder on the 36VA stock head seems to be fixed to the
rotation stepper. At least I have not found a way to dismount them. (If
anyone does, please tell me.) Anyhow, due to the small cam radius, there
is not much space to play with...
>> Concerning the cam tilt: is my understanding correct, that you're
>> talking about the tilt after homing which leaves the right nozzle
>> slightly lower then the left? I solved that by applying an offset on
>> the Z-axis after homing (using G92). I tried to rotate the rubber
>> wheels to feel the balance point.
>
> My controller FW moves each carriage down until it clears the zero
> opto-interrupter then sets the zero position to half way between the two
> readings. Seems to work, but I've not done enough placements to know
> whether it's accurate or I just got lucky.
>
and have not found such an option.
Its exactely the problem, that the homing only goes into one
directions. Without the offset, my right nozzle was lower by about 2mm
with respect to the left.
> Also the springs will pull the carriages up to the end stop tube/bolt in
> the middle when the motor is off. So long as you've tweaked it so there
> really is no cam gap then that's also a natural zero point. When I first
> got the head there was a slight gap but I adjusted the endstop up a
> fraction (with a file, iirc) to remove it.
>
to go a little higher and still keep the old mechanics.
Jan
Jan
Mar 6, 2022, 2:17:13 PM3/6/22
to ope...@googlegroups.com
Hi Wayne!
On 05.03.2022 22:37, Wayne Black wrote:
[...]
On 05.03.2022 22:37, Wayne Black wrote:
> I have clearance issues too. Of all the searching on the web about this
> I haven't seen any good solutions. The only solution I can figure is
> raising the Y rails. I dont have the numbers in front of me, but I think
> the Y could be raised 3mm and nozzle/pin have full reach of the feeders
> and PCB tray. I'm Thinking of doing this as I have a USB connector and
> inductor that I have to manually place.
IIRC the easiest way to get just the nozzles up is probably to lift the
> I haven't seen any good solutions. The only solution I can figure is
> raising the Y rails. I dont have the numbers in front of me, but I think
> the Y could be raised 3mm and nozzle/pin have full reach of the feeders
> and PCB tray. I'm Thinking of doing this as I have a USB connector and
> inductor that I have to manually place.
rotation stepper. So as long as your clearance problem is not the
dragpin, this should be a 5min job plus recallibration...
Jan
Ian Arkver
Mar 6, 2022, 2:32:24 PM3/6/22
to ope...@googlegroups.com
Hi Jan!
On 06/03/2022 19:12, 'Jan' via OpenPnP wrote:
> Hi Ian!
>
> On 06.03.2022 11:03, Ian Arkver wrote:
> [...]
>> I've cam radius in OpenPnP set to 22.55mm. Not sure where that came
>> from. I guess I measured it at some point. A quick check shows it's
>> probably right.
>>
> The 17.5mm is the cam radius of my CHM-T36VA stock head. The 22.5mm is
> for the China SMT head Wayne linked?
Yes, I think so. It looks the same as mine and mine was from China SMT.
>> These holders are indeed a problem with a toolchanger. They're very
>> tight. It might be possible to change the rubber/plastic ring and
>> reduce the side force, but there's no way the carriage springs will
>> pull the nozzle out themselves.
>>
> The Betz head seems to use a holder with a spring to lock the nozzle
> tip. I guess this locking can be easily pushed way then trying to change
> the nozzle tip.
> However, the holder on the 36VA stock head seems to be fixed to the
> rotation stepper. At least I have not found a way to dismount them. (If
> anyone does, please tell me.) Anyhow, due to the small cam radius, there
> is not much space to play with...
The spring in the Betz holder is apparently quite strong. I don't have
them, but Duncan was discussing these on Discord recently. I'm not sure
if Peter's holders and the stock China SMT ones have the same diameter
stepper shaft.
Can't comment on the 36VA itself.
>>> Concerning the cam tilt: is my understanding correct, that
>>> you're talking about the tilt after homing which leaves the right
>>> nozzle slightly lower then the left? I solved that by applying an
>>> offset on the Z-axis after homing (using G92). I tried to rotate the
>>> rubber wheels to feel the balance point.
>>
>> My controller FW moves each carriage down until it clears the zero
>> opto-interrupter then sets the zero position to half way between the
>> two readings. Seems to work, but I've not done enough placements to
>> know whether it's accurate or I just got lucky.
>>
> Thats need! What controller do you use? I'm using a smoothieware port
> and have not found such an option.
> Its exactely the problem, that the homing only goes into one
> directions. Without the offset, my right nozzle was lower by about 2mm
> with respect to the left.
Ah, it's my own FW, written in C++ and running as a Linux process which
talks over SPI to an FPGA. The FPGA has the stepper S-curve ramp
generators and they handle the "move to zero"/"move out of zero"
coordination at the HW level.
Having said all that, I'm sure you could add it to Smoothieware if
suitably motivated. It's open source, right?
>> Also the springs will pull the carriages up to the end stop tube/bolt
>> in the middle when the motor is off. So long as you've tweaked it so
>> there really is no cam gap then that's also a natural zero point. When
>> I first got the head there was a slight gap but I adjusted the endstop
>> up a fraction (with a file, iirc) to remove it.
>>
> I thought about removeing some of this material. Would allow the nozzle
> to go a little higher and still keep the old mechanics.
On the China SMT head the endstop leaves the cam horizontal (well, to
within about 0.5mm). There wasn't much to adjust. Taking more off the
endstop wouldn't help since the cam itself would then keep the carriages
down instead. Maybe it's different on the CHMT head.
Regards,
Ian
>
> Jan
>
On 06/03/2022 19:12, 'Jan' via OpenPnP wrote:
> Hi Ian!
>
> On 06.03.2022 11:03, Ian Arkver wrote:
> [...]
>> I've cam radius in OpenPnP set to 22.55mm. Not sure where that came
>> from. I guess I measured it at some point. A quick check shows it's
>> probably right.
>>
> The 17.5mm is the cam radius of my CHM-T36VA stock head. The 22.5mm is
> for the China SMT head Wayne linked?
>> These holders are indeed a problem with a toolchanger. They're very
>> tight. It might be possible to change the rubber/plastic ring and
>> reduce the side force, but there's no way the carriage springs will
>> pull the nozzle out themselves.
>>
> The Betz head seems to use a holder with a spring to lock the nozzle
> tip. I guess this locking can be easily pushed way then trying to change
> the nozzle tip.
> However, the holder on the 36VA stock head seems to be fixed to the
> rotation stepper. At least I have not found a way to dismount them. (If
> anyone does, please tell me.) Anyhow, due to the small cam radius, there
> is not much space to play with...
them, but Duncan was discussing these on Discord recently. I'm not sure
if Peter's holders and the stock China SMT ones have the same diameter
stepper shaft.
Can't comment on the 36VA itself.
>>> Concerning the cam tilt: is my understanding correct, that
>>> you're talking about the tilt after homing which leaves the right
>>> nozzle slightly lower then the left? I solved that by applying an
>>> offset on the Z-axis after homing (using G92). I tried to rotate the
>>> rubber wheels to feel the balance point.
>>
>> My controller FW moves each carriage down until it clears the zero
>> opto-interrupter then sets the zero position to half way between the
>> two readings. Seems to work, but I've not done enough placements to
>> know whether it's accurate or I just got lucky.
>>
> Thats need! What controller do you use? I'm using a smoothieware port
> and have not found such an option.
> Its exactely the problem, that the homing only goes into one
> directions. Without the offset, my right nozzle was lower by about 2mm
> with respect to the left.
talks over SPI to an FPGA. The FPGA has the stepper S-curve ramp
generators and they handle the "move to zero"/"move out of zero"
coordination at the HW level.
Having said all that, I'm sure you could add it to Smoothieware if
suitably motivated. It's open source, right?
>> Also the springs will pull the carriages up to the end stop tube/bolt
>> in the middle when the motor is off. So long as you've tweaked it so
>> there really is no cam gap then that's also a natural zero point. When
>> I first got the head there was a slight gap but I adjusted the endstop
>> up a fraction (with a file, iirc) to remove it.
>>
> I thought about removeing some of this material. Would allow the nozzle
> to go a little higher and still keep the old mechanics.
within about 0.5mm). There wasn't much to adjust. Taking more off the
endstop wouldn't help since the cam itself would then keep the carriages
down instead. Maybe it's different on the CHMT head.
Regards,
Ian
>
> Jan
>
Jan
Mar 7, 2022, 5:24:47 AM3/7/22
to ope...@googlegroups.com
On 06.03.2022 20:32, Ian Arkver wrote:
[...]
bad...
I was wondering whether one could unload the nozzle using some kind of
ramp with the nozzle moved to its lower limit. Moving side wise with the
ramp going down, the nozzle tip might be removed. To load the nozzle tip
the head would have to touch the nozzle, move it side wise up the ramp
and then attache it by moving the nozzle down. I'm not sure if the force
the z-axis can generate will be strong enough for the stock holder to
push the nozzle in.
[...]
critical timing. Combines both worlds using simple inexpensive hardware
and makes software development (except the FPGA) very simple...
SPI sounds like Lattice. A few years before I designed a product where
this type of FPGAs are loaded at runtime and then controlled using the
same SPI link. Easy to update the image and very reliable...
Have you published the details of your controller somewhere?
> Having said all that, I'm sure you could add it to Smoothieware if
> suitably motivated. It's open source, right?
>
Yes, would be possible. However, I don't feel so comfortable with the
code yet and - as you said - suitable motivation is missing if you can
just apply an offset...
>>> Also the springs will pull the carriages up to the end stop tube/bolt
>>> in the middle when the motor is off. So long as you've tweaked it so
>>> there really is no cam gap then that's also a natural zero point.
>>> When I first got the head there was a slight gap but I adjusted the
>>> endstop up a fraction (with a file, iirc) to remove it.
>>>
>> I thought about removeing some of this material. Would allow the
>> nozzle to go a little higher and still keep the old mechanics.
>
> On the China SMT head the endstop leaves the cam horizontal (well, to
> within about 0.5mm). There wasn't much to adjust. Taking more off the
> endstop wouldn't help since the cam itself would then keep the carriages
> down instead. Maybe it's different on the CHMT head.
>
The head is well made and the original code centers both nozzles.
However, I've read, that they home the nozzle after each pick. That's
required, because they just drive down to some fixed z position. So it's
likely, that they home as you do, using both sides.
Btw: do you know if the cam is sold separately somewhere? If I could
replace my 17.5mm one with a lets say 22.5mm, I'd gain an other 4mm in z
travel without replacing the entire head...
Jan
[...]
>> The Betz head seems to use a holder with a spring to lock the nozzle
>> tip. I guess this locking can be easily pushed way then trying to
>> change the nozzle tip.
>> However, the holder on the 36VA stock head seems to be fixed to
>> the rotation stepper. At least I have not found a way to dismount
>> them. (If anyone does, please tell me.) Anyhow, due to the small cam
>> radius, there is not much space to play with...
>
> The spring in the Betz holder is apparently quite strong. I don't have
> them, but Duncan was discussing these on Discord recently. I'm not sure
> if Peter's holders and the stock China SMT ones have the same diameter
> stepper shaft.
>
That's good to know! So this is likely no option for cam style heads, to
>> tip. I guess this locking can be easily pushed way then trying to
>> change the nozzle tip.
>> However, the holder on the 36VA stock head seems to be fixed to
>> the rotation stepper. At least I have not found a way to dismount
>> them. (If anyone does, please tell me.) Anyhow, due to the small cam
>> radius, there is not much space to play with...
>
> The spring in the Betz holder is apparently quite strong. I don't have
> them, but Duncan was discussing these on Discord recently. I'm not sure
> if Peter's holders and the stock China SMT ones have the same diameter
> stepper shaft.
>
bad...
I was wondering whether one could unload the nozzle using some kind of
ramp with the nozzle moved to its lower limit. Moving side wise with the
ramp going down, the nozzle tip might be removed. To load the nozzle tip
the head would have to touch the nozzle, move it side wise up the ramp
and then attache it by moving the nozzle down. I'm not sure if the force
the z-axis can generate will be strong enough for the stock holder to
push the nozzle in.
[...]
> Ah, it's my own FW, written in C++ and running as a Linux process which
> talks over SPI to an FPGA. The FPGA has the stepper S-curve ramp
> generators and they handle the "move to zero"/"move out of zero"
> coordination at the HW level.
>
That sounds really cool! Let the pc do the math and the FPGA the
> talks over SPI to an FPGA. The FPGA has the stepper S-curve ramp
> generators and they handle the "move to zero"/"move out of zero"
> coordination at the HW level.
>
critical timing. Combines both worlds using simple inexpensive hardware
and makes software development (except the FPGA) very simple...
SPI sounds like Lattice. A few years before I designed a product where
this type of FPGAs are loaded at runtime and then controlled using the
same SPI link. Easy to update the image and very reliable...
Have you published the details of your controller somewhere?
> Having said all that, I'm sure you could add it to Smoothieware if
> suitably motivated. It's open source, right?
>
code yet and - as you said - suitable motivation is missing if you can
just apply an offset...
>>> Also the springs will pull the carriages up to the end stop tube/bolt
>>> in the middle when the motor is off. So long as you've tweaked it so
>>> there really is no cam gap then that's also a natural zero point.
>>> When I first got the head there was a slight gap but I adjusted the
>>> endstop up a fraction (with a file, iirc) to remove it.
>>>
>> I thought about removeing some of this material. Would allow the
>> nozzle to go a little higher and still keep the old mechanics.
>
> On the China SMT head the endstop leaves the cam horizontal (well, to
> within about 0.5mm). There wasn't much to adjust. Taking more off the
> endstop wouldn't help since the cam itself would then keep the carriages
> down instead. Maybe it's different on the CHMT head.
>
However, I've read, that they home the nozzle after each pick. That's
required, because they just drive down to some fixed z position. So it's
likely, that they home as you do, using both sides.
Btw: do you know if the cam is sold separately somewhere? If I could
replace my 17.5mm one with a lets say 22.5mm, I'd gain an other 4mm in z
travel without replacing the entire head...
Jan
Ian Arkver
Mar 7, 2022, 5:46:24 AM3/7/22
to ope...@googlegroups.com
Hi Jan
On 07/03/2022 10:24, 'Jan' via OpenPnP wrote:
> On 06.03.2022 20:32, Ian Arkver wrote:
> [...]
>>> The Betz head seems to use a holder with a spring to lock the nozzle
>>> tip. I guess this locking can be easily pushed way then trying to
>>> change the nozzle tip.
>>> However, the holder on the 36VA stock head seems to be fixed to
>>> the rotation stepper. At least I have not found a way to dismount
>>> them. (If anyone does, please tell me.) Anyhow, due to the small cam
>>> radius, there is not much space to play with...
>>
>> The spring in the Betz holder is apparently quite strong. I don't have
>> them, but Duncan was discussing these on Discord recently. I'm not
>> sure if Peter's holders and the stock China SMT ones have the same
>> diameter stepper shaft.
>>
> That's good to know! So this is likely no option for cam style heads, to
> bad...
> I was wondering whether one could unload the nozzle using some kind
> of ramp with the nozzle moved to its lower limit. Moving side wise with
> the ramp going down, the nozzle tip might be removed. To load the nozzle
> tip the head would have to touch the nozzle, move it side wise up the
> ramp and then attache it by moving the nozzle down. I'm not sure if the
> force the z-axis can generate will be strong enough for the stock holder
> to push the nozzle in.
This has been discussed many times before, including on Discord again
recently. :-)
There are some designs around for such ramped holders. There's also
concern that the side forces will knock off nozzle alignment.
I haven't seen a completed solution though, as I mentioned, Duncan was
working on one.
Also, yeah, getting the nozzle off is only half the problem. Loading the
new one is the other half and I haven't tried it to see if the Z stepper
is strong enough.
> [...]
>> Ah, it's my own FW, written in C++ and running as a Linux process
>> which talks over SPI to an FPGA. The FPGA has the stepper S-curve ramp
>> generators and they handle the "move to zero"/"move out of zero"
>> coordination at the HW level.
>>
> That sounds really cool! Let the pc do the math and the FPGA the
> critical timing. Combines both worlds using simple inexpensive hardware
> and makes software development (except the FPGA) very simple...
> SPI sounds like Lattice. A few years before I designed a product
> where this type of FPGAs are loaded at runtime and then controlled using
> the same SPI link. Easy to update the image and very reliable...
> Have you published the details of your controller somewhere?
I haven't published it since I didn't think it would be of much interest
to others, but maybe I should. It's very specific to my setup but still
might be useful. I'll think about it.
I used an Altera (Intel) CycloneV, but that was more because I was
already familiar with them. There's nothing to tie you to any particular
FPGA family.
The board I chose is no longer available. The replacement has a bigger
FPGA and more RAM (which I don't use at all):
https://www.aliexpress.com/item/1005001782703399.html
This is complete overkill of course. Utilisation of that would be less
than 10% probably.
>> Having said all that, I'm sure you could add it to Smoothieware if
>> suitably motivated. It's open source, right?
>>
> Yes, would be possible. However, I don't feel so comfortable with the
> code yet and - as you said - suitable motivation is missing if you can
> just apply an offset...
>
>>>> Also the springs will pull the carriages up to the end stop
>>>> tube/bolt in the middle when the motor is off. So long as you've
>>>> tweaked it so there really is no cam gap then that's also a natural
>>>> zero point. When I first got the head there was a slight gap but I
>>>> adjusted the endstop up a fraction (with a file, iirc) to remove it.
>>>>
>>> I thought about removeing some of this material. Would allow the
>>> nozzle to go a little higher and still keep the old mechanics.
>>
>> On the China SMT head the endstop leaves the cam horizontal (well, to
>> within about 0.5mm). There wasn't much to adjust. Taking more off the
>> endstop wouldn't help since the cam itself would then keep the
>> carriages down instead. Maybe it's different on the CHMT head.
>>
> The head is well made and the original code centers both nozzles.
> However, I've read, that they home the nozzle after each pick. That's
> required, because they just drive down to some fixed z position. So it's
> likely, that they home as you do, using both sides.
> Btw: do you know if the cam is sold separately somewhere? If I
> could replace my 17.5mm one with a lets say 22.5mm, I'd gain an other
> 4mm in z travel without replacing the entire head...
I haven't seen just the cam, but I have in the past seen various other
bits (eg. a kit with the metalwork and the linear rails). Have a look in
China SMT's AliExp store.
All the best,
Ian
> Jan
>
On 07/03/2022 10:24, 'Jan' via OpenPnP wrote:
> On 06.03.2022 20:32, Ian Arkver wrote:
> [...]
>>> The Betz head seems to use a holder with a spring to lock the nozzle
>>> tip. I guess this locking can be easily pushed way then trying to
>>> change the nozzle tip.
>>> However, the holder on the 36VA stock head seems to be fixed to
>>> the rotation stepper. At least I have not found a way to dismount
>>> them. (If anyone does, please tell me.) Anyhow, due to the small cam
>>> radius, there is not much space to play with...
>>
>> The spring in the Betz holder is apparently quite strong. I don't have
>> them, but Duncan was discussing these on Discord recently. I'm not
>> sure if Peter's holders and the stock China SMT ones have the same
>> diameter stepper shaft.
>>
> That's good to know! So this is likely no option for cam style heads, to
> bad...
> I was wondering whether one could unload the nozzle using some kind
> of ramp with the nozzle moved to its lower limit. Moving side wise with
> the ramp going down, the nozzle tip might be removed. To load the nozzle
> tip the head would have to touch the nozzle, move it side wise up the
> ramp and then attache it by moving the nozzle down. I'm not sure if the
> force the z-axis can generate will be strong enough for the stock holder
> to push the nozzle in.
recently. :-)
There are some designs around for such ramped holders. There's also
concern that the side forces will knock off nozzle alignment.
I haven't seen a completed solution though, as I mentioned, Duncan was
working on one.
Also, yeah, getting the nozzle off is only half the problem. Loading the
new one is the other half and I haven't tried it to see if the Z stepper
is strong enough.
> [...]
>> Ah, it's my own FW, written in C++ and running as a Linux process
>> which talks over SPI to an FPGA. The FPGA has the stepper S-curve ramp
>> generators and they handle the "move to zero"/"move out of zero"
>> coordination at the HW level.
>>
> That sounds really cool! Let the pc do the math and the FPGA the
> critical timing. Combines both worlds using simple inexpensive hardware
> and makes software development (except the FPGA) very simple...
> SPI sounds like Lattice. A few years before I designed a product
> where this type of FPGAs are loaded at runtime and then controlled using
> the same SPI link. Easy to update the image and very reliable...
> Have you published the details of your controller somewhere?
to others, but maybe I should. It's very specific to my setup but still
might be useful. I'll think about it.
I used an Altera (Intel) CycloneV, but that was more because I was
already familiar with them. There's nothing to tie you to any particular
FPGA family.
The board I chose is no longer available. The replacement has a bigger
FPGA and more RAM (which I don't use at all):
https://www.aliexpress.com/item/1005001782703399.html
This is complete overkill of course. Utilisation of that would be less
than 10% probably.
>> Having said all that, I'm sure you could add it to Smoothieware if
>> suitably motivated. It's open source, right?
>>
> Yes, would be possible. However, I don't feel so comfortable with the
> code yet and - as you said - suitable motivation is missing if you can
> just apply an offset...
>
>>>> Also the springs will pull the carriages up to the end stop
>>>> tube/bolt in the middle when the motor is off. So long as you've
>>>> tweaked it so there really is no cam gap then that's also a natural
>>>> zero point. When I first got the head there was a slight gap but I
>>>> adjusted the endstop up a fraction (with a file, iirc) to remove it.
>>>>
>>> I thought about removeing some of this material. Would allow the
>>> nozzle to go a little higher and still keep the old mechanics.
>>
>> On the China SMT head the endstop leaves the cam horizontal (well, to
>> within about 0.5mm). There wasn't much to adjust. Taking more off the
>> endstop wouldn't help since the cam itself would then keep the
>> carriages down instead. Maybe it's different on the CHMT head.
>>
> The head is well made and the original code centers both nozzles.
> However, I've read, that they home the nozzle after each pick. That's
> required, because they just drive down to some fixed z position. So it's
> likely, that they home as you do, using both sides.
> Btw: do you know if the cam is sold separately somewhere? If I
> could replace my 17.5mm one with a lets say 22.5mm, I'd gain an other
> 4mm in z travel without replacing the entire head...
bits (eg. a kit with the metalwork and the linear rails). Have a look in
China SMT's AliExp store.
All the best,
Ian
> Jan
>
Jan
Mar 7, 2022, 4:17:19 PM3/7/22
to ope...@googlegroups.com
Hi Ian!
On 07.03.2022 11:46, Ian Arkver wrote:
[...]
rid of all this 3d-printer optimized boards with all the compromises
that involves and focuses on the main features needed for a pnp. If I'd
be a professional pnp designer, I'd go for your concept.
If you'd design a board with stepper drivers and ios, I'm sure many
people will be interested. At least I'd try to make it a product (lower
or comparable hardware costs with much better features)...
Jan
On 07.03.2022 11:46, Ian Arkver wrote:
[...]
>> [...]
>>> Ah, it's my own FW, written in C++ and running as a Linux process
>>> which talks over SPI to an FPGA. The FPGA has the stepper S-curve
>>> ramp generators and they handle the "move to zero"/"move out of zero"
>>> coordination at the HW level.
>>>
>> That sounds really cool! Let the pc do the math and the FPGA the
>> critical timing. Combines both worlds using simple inexpensive
>> hardware and makes software development (except the FPGA) very simple...
>> SPI sounds like Lattice. A few years before I designed a product
>> where this type of FPGAs are loaded at runtime and then controlled
>> using the same SPI link. Easy to update the image and very reliable...
>> Have you published the details of your controller somewhere?
>
> I haven't published it since I didn't think it would be of much interest
> to others, but maybe I should. It's very specific to my setup but still
> might be useful. I'll think about it.
>
> I used an Altera (Intel) CycloneV, but that was more because I was
> already familiar with them. There's nothing to tie you to any particular
> FPGA family.
>
> The board I chose is no longer available. The replacement has a bigger
> FPGA and more RAM (which I don't use at all):
> https://www.aliexpress.com/item/1005001782703399.html
>
> This is complete overkill of course. Utilisation of that would be less
> than 10% probably.
>
Your concept is the coolest and most advanced I've ever seen. It gets
>>> Ah, it's my own FW, written in C++ and running as a Linux process
>>> which talks over SPI to an FPGA. The FPGA has the stepper S-curve
>>> ramp generators and they handle the "move to zero"/"move out of zero"
>>> coordination at the HW level.
>>>
>> That sounds really cool! Let the pc do the math and the FPGA the
>> critical timing. Combines both worlds using simple inexpensive
>> hardware and makes software development (except the FPGA) very simple...
>> SPI sounds like Lattice. A few years before I designed a product
>> where this type of FPGAs are loaded at runtime and then controlled
>> using the same SPI link. Easy to update the image and very reliable...
>> Have you published the details of your controller somewhere?
>
> I haven't published it since I didn't think it would be of much interest
> to others, but maybe I should. It's very specific to my setup but still
> might be useful. I'll think about it.
>
> I used an Altera (Intel) CycloneV, but that was more because I was
> already familiar with them. There's nothing to tie you to any particular
> FPGA family.
>
> The board I chose is no longer available. The replacement has a bigger
> FPGA and more RAM (which I don't use at all):
> https://www.aliexpress.com/item/1005001782703399.html
>
> This is complete overkill of course. Utilisation of that would be less
> than 10% probably.
>
rid of all this 3d-printer optimized boards with all the compromises
that involves and focuses on the main features needed for a pnp. If I'd
be a professional pnp designer, I'd go for your concept.
If you'd design a board with stepper drivers and ios, I'm sure many
people will be interested. At least I'd try to make it a product (lower
or comparable hardware costs with much better features)...
Jan
Ian Arkver
Mar 7, 2022, 4:44:56 PM3/7/22
to ope...@googlegroups.com
I picked the FPGA route because I didn't know what all I needed and this
was a way to allow adding more later. For example I added BMP280
pressure sensors to the machine later, so dropped in a couple of I2C
masters to the FPGA and some control registers to drive them. (I could
have just used the i2c bus on the Nano, but that would have been more
wiring, needed an i2c mux, needed another interface in the software,
etc. etc.)
I've been designing with FPGAs since XC4000 days, and CPLDs and SPLDs
before that so this kind of thing is fairly familiar to me.
By the way, I'm certainly not the first one to drop in an FPGA. Smoothie
V2 Pro has been on the books for a while. I dunno what stage that
project's at. There are probably others too.
Anyway, we've strayed rather off-topic for this thread. Apologies.
Mark M
Mar 10, 2022, 11:50:51 AM3/10/22
to OpenPnP
Jan,
I have just joined the group and this is my first post here. So if I sound like a newbie then......
I have spent over a week researching OpenPnP as it relates to the Charmhigh models. I have a CHM-T48VB. Hardware-wise happy with it but the stock software/firmware is pretty weak. Thus the reason I am looking at this OpenPnP.
I have followed the guides, ordered the upgrade parts, etc, which haven't arrived yet. I want to familiarize myself with the tool as much as possible. Watched many Youtube videos , etc.
I have played around and followed the tutorials wit the virtual machine and very impressed with OpenPnP.
So now I start the migration. You posted a CHM-T36VA machine.xml file per the link above. Rename and place in the correct path and I get this error when I start OpenPnP.
Maybe I need real hardware to start OpenPnP when I get to this point? I thought I could at least load and look at the machine setup tab without turning on the power button on OpenPnP?
Seems like I am really missing something.
Most of the pages say they are outdated. Trying to figure out how to get the ball rolling here and the machine configuration is a huge step. Trying to leverage off some of the experts. Not sure at the hardware level of the internal differences between the 36VA and the 48VB other than it has more feeders and the touchscreen, which appears to go away with the OpenPnP upgrade, which is no problem. Can I use the smoothie 36VA version on the 48VB controller board without bricking it?
How can I use a machine.xml file to load on a desktop machine not connected to hardware?
Can someone push me in the right direction?
Thanks!!!
Mark
On Wednesday, February 23, 2022 at 11:31:05 AM UTC-6 Jan wrote:
Hi All!
As promised, today I've
- released my modifications to the smoothieware code for the CMH-T36VA
mainboard at https://github.com/janm012012/Smoothieware-CHMT,
- my ringlight design for the CHM-T36VA at
- updated the Wiki for the CHM-T36VA at
https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA with some notes.
Jan
Mar 10, 2022, 1:10:49 PM3/10/22
to ope...@googlegroups.com
Hi Mark!
Welcome on board! Just to be warned, the original Chinese software is
faster, but with OpenPnp you're free to configure and change everything
you can't otherwise...
The machine.xml I posted was for the testing version of OpenPnp. It
contains a few optimizations in Issues & Solutions, especially targeted
to the CHM-T machines and a lot of other cool new features.
"safe-z-park" sounds like one of them... I'd suggest to upgrade to the
testing version. Alternatively you could remove the offending attribute
and retry.
Jan
On 10.03.2022 17:30, Mark M wrote:
> Jan,
>
> I have just joined the group and this is my first post here. So if I
> sound like a newbie then......
>
> I have spent over a week researching OpenPnP as it relates to the
> Charmhigh models. I have a CHM-T48VB. Hardware-wise happy with it but
> the stock software/firmware is pretty weak. Thus the reason I am looking
> at this OpenPnP.
>
> I have followed the guides, ordered the upgrade parts, etc, which
> haven't arrived yet. I want to familiarize myself with the tool as much
> as possible. Watched many Youtube videos , etc.
>
> I have played around and followed the tutorials wit the virtual machine
> and very impressed with OpenPnP.
>
> So now I start the migration. You posted a CHM-T36VA machine.xml file
> per the link above. Rename and place in the correct path and I get this
> error when I start OpenPnP.
> <https://groups.google.com/d/msgid/openpnp/c4a80969-208e-4337-96f3-0fe69e166cddn%40googlegroups.com?utm_medium=email&utm_source=footer>.
Welcome on board! Just to be warned, the original Chinese software is
faster, but with OpenPnp you're free to configure and change everything
you can't otherwise...
The machine.xml I posted was for the testing version of OpenPnp. It
contains a few optimizations in Issues & Solutions, especially targeted
to the CHM-T machines and a lot of other cool new features.
"safe-z-park" sounds like one of them... I'd suggest to upgrade to the
testing version. Alternatively you could remove the offending attribute
and retry.
Jan
On 10.03.2022 17:30, Mark M wrote:
> Jan,
>
> I have just joined the group and this is my first post here. So if I
> sound like a newbie then......
>
> I have spent over a week researching OpenPnP as it relates to the
> Charmhigh models. I have a CHM-T48VB. Hardware-wise happy with it but
> the stock software/firmware is pretty weak. Thus the reason I am looking
> at this OpenPnP.
>
> I have followed the guides, ordered the upgrade parts, etc, which
> haven't arrived yet. I want to familiarize myself with the tool as much
> as possible. Watched many Youtube videos , etc.
>
> I have played around and followed the tutorials wit the virtual machine
> and very impressed with OpenPnP.
>
> So now I start the migration. You posted a CHM-T36VA machine.xml file
> per the link above. Rename and place in the correct path and I get this
> error when I start OpenPnP.
> OpenPnP_Error.jpg
>
> Maybe I need real hardware to start OpenPnP when I get to this point? I
> thought I could at least load and look at the machine setup tab without
> turning on the power button on OpenPnP?
>
> Seems like I am really missing something.
>
> Most of the pages say they are outdated. Trying to figure out how to get
> the ball rolling here and the machine configuration is a huge step.
> Trying to leverage off some of the experts. Not sure at the hardware
> level of the internal differences between the 36VA and the 48VB other
> than it has more feeders and the touchscreen, which appears to go away
> with the OpenPnP upgrade, which is no problem. Can I use the smoothie
> 36VA version on the 48VB controller board without bricking it?
>
> How can I use a machine.xml file to load on a desktop machine not
> connected to hardware?
>
> Can someone push me in the right direction?
>
> Thanks!!!
>
> Mark
>
>
> On Wednesday, February 23, 2022 at 11:31:05 AM UTC-6 Jan wrote:
>
> Hi All!
> As promised, today I've
> - released my modifications to the smoothieware code for the CMH-T36VA
> mainboard at https://github.com/janm012012/Smoothieware-CHMT
> <https://github.com/janm012012/Smoothieware-CHMT>,
>
> Maybe I need real hardware to start OpenPnP when I get to this point? I
> thought I could at least load and look at the machine setup tab without
> turning on the power button on OpenPnP?
>
> Seems like I am really missing something.
>
> Most of the pages say they are outdated. Trying to figure out how to get
> the ball rolling here and the machine configuration is a huge step.
> Trying to leverage off some of the experts. Not sure at the hardware
> level of the internal differences between the 36VA and the 48VB other
> than it has more feeders and the touchscreen, which appears to go away
> with the OpenPnP upgrade, which is no problem. Can I use the smoothie
> 36VA version on the 48VB controller board without bricking it?
>
> How can I use a machine.xml file to load on a desktop machine not
> connected to hardware?
>
> Can someone push me in the right direction?
>
> Thanks!!!
>
> Mark
>
>
> On Wednesday, February 23, 2022 at 11:31:05 AM UTC-6 Jan wrote:
>
> Hi All!
> As promised, today I've
> - released my modifications to the smoothieware code for the CMH-T36VA
> mainboard at https://github.com/janm012012/Smoothieware-CHMT
> - my ringlight design for the CHM-T36VA at
> https://github.com/janm012012/Ringlight
> <https://github.com/janm012012/Ringlight> and
> - updated the Wiki for the CHM-T36VA at
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA> with
> some notes.
> If you feel there is anything missing, not helpful, imprecise or even
> incorrect, please let me know and I'll be happy to fix it.
>
> Jan
>
> https://github.com/janm012012/Ringlight
> <https://github.com/janm012012/Ringlight> and
> - updated the Wiki for the CHM-T36VA at
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA> with
> some notes.
> If you feel there is anything missing, not helpful, imprecise or even
> incorrect, please let me know and I'll be happy to fix it.
>
> 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/c4a80969-208e-4337-96f3-0fe69e166cddn%40googlegroups.com
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/c4a80969-208e-4337-96f3-0fe69e166cddn%40googlegroups.com?utm_medium=email&utm_source=footer>.
Mark M
Mar 10, 2022, 2:46:34 PM3/10/22
to OpenPnP
Jan,
Thanks for the welcome!
I went and looked for a testing version and was not able to find a compiled version.
Mostly a hardware guy, can dabble in software but looked at the tool chain and uffda! :)
Is there a nightly build that is available for download?
I tried removing the attributes out of the .XML file, made it to line 572 after many removes. Line 572 is the line after all the removes, but there appears there is a lot of changes to the calibration, background hues and such going on. Too many deletes.
So is the only way to be on the testing version is to compile the source to your target?
Thank you for your time.
Regards,
Mark
Jan
Mar 10, 2022, 4:30:23 PM3/10/22
to ope...@googlegroups.com
Hi Mark!
Yes, automatic background removal is an other new feature...
Please find precompiled versions of the test branch at
https://openpnp.org/test-downloads/
Jan
> <https://groups.google.com/d/msgid/openpnp/c4a80969-208e-4337-96f3-0fe69e166cddn%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/c4a80969-208e-4337-96f3-0fe69e166cddn%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> <https://groups.google.com/d/msgid/openpnp/5811b0f7-9ab7-46f3-b4c1-221428f7c4c9n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Yes, automatic background removal is an other new feature...
Please find precompiled versions of the test branch at
https://openpnp.org/test-downloads/
Jan
> <https://groups.google.com/d/msgid/openpnp/c4a80969-208e-4337-96f3-0fe69e166cddn%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/5811b0f7-9ab7-46f3-b4c1-221428f7c4c9n%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/5811b0f7-9ab7-46f3-b4c1-221428f7c4c9n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Mark M
Mar 11, 2022, 11:00:09 AM3/11/22
to OpenPnP
Jan,
Well OpenPnp is perfectly happy now with the machine.xml file that was downloaded from your
You are in a conversation in the group Desktop Pick and Place group, subject : OpenPnP on 48Vb Upgrade (Need some help)
You made reference to https://github.com/janm012012/Smoothieware-CHMT page and the enhancements etc on the drag pin PWM and some very helpful instructions on what files to use.
My question, as being new to all of this:
1. Since this was a thread question on the 48VB, you made reference to using your machine CHM-T36VA.xml file. At this level of configuration are the machines the same and can use the same file?
2. If I understand correctly, you have a 36VA?
3. Do the 36VA and 46VB have the same number of axis? I know there are more feeders and a touchscreen. I have built over 100 boards already on the Charmhigh platform.
4. In you above machine.xml file, Machine Setup, Cameras, there is only an uplooking camera listed. The 36VA and the 48VB both have up and down cameras, plus upgrade swaps out the stock Charmhigh cameras to USB models. I was expecting to see two cameras listed here?
Thanks again for the help, I want to start migrating my old charmhigh .dpv over to OpenPnP and setting up the feeders as I used an excel spreadsheet to track the machine's configuration and all of the part settings come from Peachtree which is my accounting software used to build assemblies and manage the inventory. All width, pitch, datasheet info was stored for each inventory part and can export to excel. Charmhigh didn't save this for the jobs, just the one currently in use but appears that OpenPnP has a wider scope on tracking the feeders and how the job relates to the population of the feeders. Very nice!
You made reference in my welcome post that OpenPnP is slower than the Charmhigh. Not concerned with speed but accuracy. With that said it can't be super slow and have read posts on a recommended host of being at least an i5 with 8GBs of RAM etc and the speed of the machine is very good then. The specs on the 48VB list it faster CPH faster than the 36VA
One last observation, while reading the upgrade path instructions, one version says to use the STLINK-V3SET programmer, another the Seeger. The Seeger is pretty expensive, so I bought the STLINK-V3SET and is inbound from CN now. In another thread of messages, a person said they couldn't flash using the STLINK-V3SET and had to use the Seeger for the first time, after that the STLINK-V3SET worked just fine.
Is this a common problem that you are aware of?
Regards,
Mark
Jan
Mar 11, 2022, 6:19:46 PM3/11/22
to ope...@googlegroups.com
Hi Mark!
I'll put my comments between the lines.
On 11.03.2022 17:00, Mark M wrote:
[...]
speak for that. To my understanding, the 36 and 48 share the same
controller board with minor differences in the communication interface.
The 36 has RS232 populated and the 48 shall have RS485. Configuration
wise the two differ in the x and y limits (the 48 is larger) and the
right peeler, which is not present on the 36. If you take my
machine.xml, you'll have to add the second peeler and adjust the xy
limits. Everything else should be the same.
> 2. If I understand correctly, you have a 36VA?
Yes, that's correct.
> 3. Do the 36VA and 46VB have the same number of axis? I know there are
> more feeders and a touchscreen. I have built over 100 boards already on
> the Charmhigh platform.
No, the 36 has 5 axis + one peeler = 6, while the 48 has 5 + two peeler
= 7.
> 4. In you above machine.xml file, Machine Setup, Cameras, there is only
> an uplooking camera listed. The 36VA and the 48VB both have up and down
> cameras, plus upgrade swaps out the stock Charmhigh cameras to USB
> models. I was expecting to see two cameras listed here?
>
Please have a look at the head. The down-looking camera is mounted on
the head and hence listed as a head mounted device.
> Thanks again for the help, I want to start migrating my old charmhigh
> .dpv over to OpenPnP and setting up the feeders as I used an excel
> spreadsheet to track the machine's configuration and all of the part
> settings come from Peachtree which is my accounting software used to
> build assemblies and manage the inventory. All width, pitch, datasheet
> info was stored for each inventory part and can export to excel.
> Charmhigh didn't save this for the jobs, just the one currently in use
> but appears that OpenPnP has a wider scope on tracking the feeders and
> how the job relates to the population of the feeders. Very nice!
>
Indeed. Feeders are separated from jobs and jobs just check if at least
one feeder loaded with the required part is available. You can have as
many feeders as you like at different or same locations...
> You made reference in my welcome post that OpenPnP is slower than the
> Charmhigh. Not concerned with speed but accuracy. With that said it
> can't be super slow and have read posts on a recommended host of being
> at least an i5 with 8GBs of RAM etc and the speed of the machine is very
> good then. The specs on the 48VB list it faster CPH faster than the 36VA
>
The main difference is, that the Chinese software sends chunks of moves
to the controller so that the controller can work until the software
needs to do something like a vision correction. And the Chinese use very
little of this events... With proper tuning and some optimizations
OpenPnp can do the same.
> One last observation, while reading the upgrade path instructions, one
> version says to use the STLINK-V3SET programmer, another the Seeger. The
> Seeger is pretty expensive, so I bought the STLINK-V3SET and is inbound
> from CN now. In another thread of messages, a person said they couldn't
> flash using the STLINK-V3SET and had to use the Seeger for the first
> time, after that the STLINK-V3SET worked just fine.
>
> Is this a common problem that you are aware of?
I don't know the STLINK, however the requirements are simple: unlock an
STM32F407 and program a .hex file using SWD. Any universal programmer
like the Segger should do that. I suppose the STLINK is a less expensive
version limited to ST MCUs. Probably one that's directly mounted on eval
or discovery boards. I doubt is insufficient.
Jan
> <https://groups.google.com/d/msgid/openpnp/5811b0f7-9ab7-46f3-b4c1-221428f7c4c9n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/5811b0f7-9ab7-46f3-b4c1-221428f7c4c9n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> <https://groups.google.com/d/msgid/openpnp/6e14821b-9b46-49bc-a779-8ba5a9a54f0en%40googlegroups.com?utm_medium=email&utm_source=footer>.
I'll put my comments between the lines.
On 11.03.2022 17:00, Mark M wrote:
[...]
> My question, as being new to all of this:
> 1. Since this was a thread question on the 48VB, you made reference to
> using your machine CHM-T36VA.xml
> <https://github.com/janm012012/Smoothieware-CHMT/blob/chmt/machine.xml/machine%20CHM-T36VA.xml> file.
> 1. Since this was a thread question on the 48VB, you made reference to
> using your machine CHM-T36VA.xml
> At this level of configuration are the machines the same and can use the
> same file?
The stuff I published is what I'm using on my machine. Hence I can only
> same file?
speak for that. To my understanding, the 36 and 48 share the same
controller board with minor differences in the communication interface.
The 36 has RS232 populated and the 48 shall have RS485. Configuration
wise the two differ in the x and y limits (the 48 is larger) and the
right peeler, which is not present on the 36. If you take my
machine.xml, you'll have to add the second peeler and adjust the xy
limits. Everything else should be the same.
> 2. If I understand correctly, you have a 36VA?
> 3. Do the 36VA and 46VB have the same number of axis? I know there are
> more feeders and a touchscreen. I have built over 100 boards already on
> the Charmhigh platform.
= 7.
> 4. In you above machine.xml file, Machine Setup, Cameras, there is only
> an uplooking camera listed. The 36VA and the 48VB both have up and down
> cameras, plus upgrade swaps out the stock Charmhigh cameras to USB
> models. I was expecting to see two cameras listed here?
>
the head and hence listed as a head mounted device.
> Thanks again for the help, I want to start migrating my old charmhigh
> .dpv over to OpenPnP and setting up the feeders as I used an excel
> spreadsheet to track the machine's configuration and all of the part
> settings come from Peachtree which is my accounting software used to
> build assemblies and manage the inventory. All width, pitch, datasheet
> info was stored for each inventory part and can export to excel.
> Charmhigh didn't save this for the jobs, just the one currently in use
> but appears that OpenPnP has a wider scope on tracking the feeders and
> how the job relates to the population of the feeders. Very nice!
>
one feeder loaded with the required part is available. You can have as
many feeders as you like at different or same locations...
> You made reference in my welcome post that OpenPnP is slower than the
> Charmhigh. Not concerned with speed but accuracy. With that said it
> can't be super slow and have read posts on a recommended host of being
> at least an i5 with 8GBs of RAM etc and the speed of the machine is very
> good then. The specs on the 48VB list it faster CPH faster than the 36VA
>
to the controller so that the controller can work until the software
needs to do something like a vision correction. And the Chinese use very
little of this events... With proper tuning and some optimizations
OpenPnp can do the same.
> One last observation, while reading the upgrade path instructions, one
> version says to use the STLINK-V3SET programmer, another the Seeger. The
> Seeger is pretty expensive, so I bought the STLINK-V3SET and is inbound
> from CN now. In another thread of messages, a person said they couldn't
> flash using the STLINK-V3SET and had to use the Seeger for the first
> time, after that the STLINK-V3SET worked just fine.
>
> Is this a common problem that you are aware of?
STM32F407 and program a .hex file using SWD. Any universal programmer
like the Segger should do that. I suppose the STLINK is a less expensive
version limited to ST MCUs. Probably one that's directly mounted on eval
or discovery boards. I doubt is insufficient.
Jan
> <https://groups.google.com/d/msgid/openpnp/5811b0f7-9ab7-46f3-b4c1-221428f7c4c9n%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/6e14821b-9b46-49bc-a779-8ba5a9a54f0en%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/6e14821b-9b46-49bc-a779-8ba5a9a54f0en%40googlegroups.com?utm_medium=email&utm_source=footer>.
Wayne Black
Mar 11, 2022, 11:36:06 PM3/11/22
to OpenPnP
Hi Mark,
I'll add to Jan's response. I have 48 and 36. The 48 is still in the crate and 36 is in use and converted to Openpnp. The machines are very similar but there are some nuances between the two. As mentioned by Jan;
1, The 48 uses an on board computer/display board that is the motion planner that communicates to the main controller main board via RS485. The 36 uses RS232 to communicate to a secondary PC that uses CHMT or Openpnp as the motion planner. In order for the 48 to use Openpnp you will need to use either RS232 or RS485 to bypass the 48 computer/display board and connect to a secondary PC.
2, I have both 36 and 48
3, As Jan says both 36 and 48 head is a 5 axis machine with an addl motor for 'peeling' feeder tape on the 36 and an addl two motors on the 48 for the peelers.
4, As Jan says both 36 and 48 have up and down cameras, the down camera is associated with the head within the machine.xml file.
One thing missing from Jan's response is that the soft limits of the different machines are different. The 48 has a larger table and needs access the right side feeder bank. You may need to empirically work through the soft limits of the X axis at least to use the right hand feeder bay.
Re the STLINK-V3SET flashing issue. I believe you may be referring to my post. I was unable to successfully flash my board using the STLINK-V3SET. I downloaded all the correct utilities and updated the driver and still couldn't get the STLINK-V3SET to flash. I was able to flash the board easily using the segger. After the segger flash, STLINK-V3SET had no problem reading and confirming the flash. After flashing, figuring out the secondary PC connection via 485 or 232 should be your first business. Everything else is just tweaking. Be mindful not burn out the dragpin during testing. I believe it is a 5v tolerant device that is controlled by a 24V source.
Lastly, this is a very long mod, or at least it has been in my case. I started the conversion in Dec and I'm still working on it...
Mark M
Mar 12, 2022, 8:57:50 AM3/12/22
to OpenPnP
Jan,
Thank you for all of the information.
Will research/explore adding the other table size and the peeler in the correct machine setup.
Quick look the peeler must be named something else in the Axes configuration.
I found the discard location coordinates, but not the overall size.
Will refer to the setup instructions in the manual.
Started my first job/board, have the data imported from .csv working so far. So baby steps! :)
Regards,
Mark
Mark M
Mar 12, 2022, 10:17:03 AM3/12/22
to OpenPnP
Wayne,
Thanks for the additional information, can never have too much on a project like this! :)
Are you part of the black box group? Bought many adapters over the years from them!
In the previous post to Jan I didn't have the application large enough on the screen and didn't see the soft limits in the axes setup. See them now.
I have read so much on this topic forget exactly where but sounds like it was your thread. I will find out if the STLINK works, specs indicate that it works on the STM32 line.
I will follow your tips on the process below. ATE Hardware Test Engineer so understand 232/422/485 to the hilt. I tend to be over-prepared and sometimes it is just better to jump into it!
I have several hundred boards to build and the second one in line is all 0402 with three tiny ICs, TSSOP, SOT23-5 opamp and a SOIC-14 all fits in a 16 pin socket(.1" spaced)part, 56 of them on one panel.
All the upgrade parts are one their way but won't get here for another 14-20 days guessing. Gives me more time to start using the OpenPnP tool and porting over the .dpvs to .job.boards, etc.
So far impressed with OpenPnP, Charmhigh's tools were buggy on such a simple interface. Was going to write my own but then the issues just kept snowballing to the point I researched and found this platform. I like the Charmhigh hardware so far. Pretty sure I won't look back once I have the upgrade in place.
Appreciate all the insight from the group. Priceless!
Regards,
Mark
Wayne Black
Mar 12, 2022, 11:57:41 AM3/12/22
to OpenPnP
Mark
I think you are a referring to a different company. My company specializes in navigation systems for BMW motorcycles.
Re the peelers, they are not set as 'Axis' but rather as 'Actuators'. As such there is no motion planning for them, just simple bool commands to advance a predetermined amount. This is the really cool thing about Openpnp, you can abstract hardware any which way you want...
Mark M
Mar 13, 2022, 11:15:00 AM3/13/22
to OpenPnP
Wayne,
I did go to your site, cool hardware for the bike!
Peelers, I am running Jan's latest machine.xml release from the link at the top of this thread. He has a 36VA so I would expect at least one peeler. I have looked but am new to OpenPnP.
Attached is the screenshot of the actuators.
Regards
Wayne Black
Mar 13, 2022, 12:00:16 PM3/13/22
to OpenPnP
Thanks. We must be doing something right as BMW copied our design...
I have a copy of one of Jans machine files loaded. Here you can see the Jan has the 'Peeler' is associated to the head. I don't think this is mandatory. I'm not sure if I do the same or just have the peeler working under machine actuators. It should work either way.
Mark M
Mar 13, 2022, 12:34:02 PM3/13/22
to OpenPnP
Thanks for the .pic, I hate to keep asking questions after you explain something but to me this makes little sense to me ATM. So trying to understand.
Jan has a 36VA, one peeler, and above lists two peelers, Peeler and Peeler12????
Also Jan's update indicates that
- The drag pin will burn if operated for more then a few seconds at 100%. Using a PWM signal it can be switched to ~10% holding current after an initial push and then keeps cool over longer periods. This has been integrated into the example machine.xml and the linked firmware.
Looking at the drag pin settings how can one confirm the above statement?
Mark M
Mar 13, 2022, 12:50:35 PM3/13/22
to OpenPnP
Started to make a job and imported parts no problem, configured the feeders etc. Everything in a green / ready status.
I have looked in the setup and manual and can't see how the relationship is from the nozzle tip to the part / feeder?
Charmhigh it was just whatever you had on both heads. OpenPnP seems to have a bit more smarts behind it, can switch nozzle tips detect part sizes, which is disabled ATM.
So is there a nozzle tip association with a setup feeder?
How do you know the correct nozzle tip is for the said placed part?
I thought I would get to a point of less questions..... sorry to be a PIA......
Wayne Black
Mar 13, 2022, 12:57:57 PM3/13/22
to OpenPnP
You can declare as many actuators as you want, but Openpnp will only utilize a single actuator selected for the given purpose. Jan may be using 'Peeler' for a feeder if the part pitch is 4mm or 'Peeler12' if the feeder part pitch is 12mm. This illustrates how you can use a single piece of hardware with more than one actuator...
Wayne Black
Mar 13, 2022, 1:05:16 PM3/13/22
to OpenPnP
You need to define those things
Wayne Black
Mar 13, 2022, 1:59:14 PM3/13/22
to OpenPnP
Re the Dragpin.
1st You declare actuator via the machine setup tree.
2nd You define actuator function via the GCode Driver
Mark M
Mar 13, 2022, 8:13:22 PM3/13/22
to OpenPnP
Wow, great information!
Do you know if the OpenPnP configuration checks to see if the drag pin actually releases and returns to the retracted position?
Original Charmhigh firmware during a build. The tape in the drag feeder bound up. The dragpin pulled hard on the paper tape to the point the dragpin did not retract after the solenoid current was released. This caused an alarm and the machine stopped. The head would not move till the pin was retracted from the tape. I was surprised that it did this, but makes total sense way that interlock should be present.
Is OpenPnP checking that input ?
Mark M
Mar 13, 2022, 8:28:29 PM3/13/22
to OpenPnP
Uffda.... :) Manual indicates that packages are not used that much, so there is little information on this.
What does 'Compatible?' mean when it is checked?
With only one nozzle listed hard to tell. I have Juki 502-506, two full sets.
Guessing that the machine setup, heads, ReferenceHead H1, ContactProbeNozzle N1 and N2 would have the Compatible? checked on all nozzle tips listed. Meaning they fit on the head/nozzle?
In the packages section, only the nozzle tips that will fit / work on the part should then have compatible? property checked. Correct?
Loaded? property, if no nozzle tips are checked and the Tool Changer is not enabled then no placements will occur.
If a single nozzle tips or two are loaded on the dual nozzle head then the parts will be attempted to be picked up from the feeders. Correct?
Then if for instance...a too small of nozzle tip is loaded, for instance, a Juki 504(0805 tip) and you try to pick up a TQFP, it will try but will fail.
Does OpenPnP check the vacuum to detect if the part was actually picked up like the Charmhigh firmware did if enabled?
Thanks again!
Wayne Black
Mar 13, 2022, 9:18:04 PM3/13/22
to OpenPnP
Yes its baked into Jan's machine xml if you're going to run smoothie on the original chmt board. What you can see here is that in addition to activating and de activating an actuator, you can also read its state. In the case of the CHMT dragpin state there is a limit switch and this is read to see if the pin is in the correct position. Basic logic being if the dragpin is actuated and the limit is sensed down that the head is allowed to move. Conversely if the dragpin is de activated and the limit is sensed down head movement is prohibited.
Jan
Mar 14, 2022, 6:18:21 AM3/14/22
to ope...@googlegroups.com
Hi Mark!
Wayne is right, I've declared multiple peelers with different gcode
to peel off different amounts of tape. The magic is in the gcode, that's
assigned at driver level.
Remember I said, that there is room for improvements: the peeler is
an actuator which means its operated at its own, while in reality it's
an axis, that shall be operated in parallel with the drag move...
(IIRC I had to tighten the peeler for the 12mm pitch parts quite a
lot, likely because after moving the tape by 12mm the cover is pinched
on the holder. If drag move and peeling would be in parallel, that's no
issue.)
Jan
On 13.03.2022 17:57, Wayne Black wrote:
> You can declare as many actuators as you want, but Openpnp will only
> utilize a single actuator selected for the given purpose. Jan may be
> using 'Peeler' for a feeder if the part pitch is 4mm or 'Peeler12' if
> the feeder part pitch is 12mm. This illustrates how you can use a single
> piece of hardware with more than one actuator...
>
> On Sunday, March 13, 2022 at 9:34:02 AM UTC-7 mark.m...@gmail.com wrote:
>
> Thanks for the .pic, I hate to keep asking questions after you
> explain something but to me this makes little sense to me ATM. So
> trying to understand.
>
> Jan has a 36VA, one peeler, and above lists two peelers, Peeler and
> Peeler12????
>
> Also Jan's update indicates that
>
> * The drag pin will burn if operated for more then a few seconds
> <https://groups.google.com/d/msgid/openpnp/6e14821b-9b46-49bc-a779-8ba5a9a54f0en%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/6e14821b-9b46-49bc-a779-8ba5a9a54f0en%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> <https://groups.google.com/d/msgid/openpnp/998ea078-cddd-47f1-aef1-a8c239e79b77n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Wayne is right, I've declared multiple peelers with different gcode
to peel off different amounts of tape. The magic is in the gcode, that's
assigned at driver level.
Remember I said, that there is room for improvements: the peeler is
an actuator which means its operated at its own, while in reality it's
an axis, that shall be operated in parallel with the drag move...
(IIRC I had to tighten the peeler for the 12mm pitch parts quite a
lot, likely because after moving the tape by 12mm the cover is pinched
on the holder. If drag move and peeling would be in parallel, that's no
issue.)
Jan
On 13.03.2022 17:57, Wayne Black wrote:
> You can declare as many actuators as you want, but Openpnp will only
> utilize a single actuator selected for the given purpose. Jan may be
> using 'Peeler' for a feeder if the part pitch is 4mm or 'Peeler12' if
> the feeder part pitch is 12mm. This illustrates how you can use a single
> piece of hardware with more than one actuator...
>
> On Sunday, March 13, 2022 at 9:34:02 AM UTC-7 mark.m...@gmail.com wrote:
>
> Thanks for the .pic, I hate to keep asking questions after you
> explain something but to me this makes little sense to me ATM. So
> trying to understand.
>
> Jan has a 36VA, one peeler, and above lists two peelers, Peeler and
> Peeler12????
>
> Also Jan's update indicates that
>
> at 100%. Using a PWM signal it can be switched to ~10% holding
> current after an initial push and then keeps cool over longer
> periods. This has been integrated into the example machine.xml
> and the linked firmware.
>
> Looking at the drag pin settings how can one confirm the above
> statement?
> current after an initial push and then keeps cool over longer
> periods. This has been integrated into the example machine.xml
> and the linked firmware.
>
> Looking at the drag pin settings how can one confirm the above
> statement?
> OpenPnP_DragPin.jpg
>
> On Sunday, March 13, 2022 at 11:00:16 AM UTC-5
> black...@blackboxembedded.com wrote:
>
> Thanks. We must be doing something right as BMW copied our design...
>
> I have a copy of one of Jans machine files loaded. Here you can
> see the Jan has the 'Peeler' is associated to the head. I don't
> think this is mandatory. I'm not sure if I do the same or just
> have the peeler working under machine actuators. It should work
> either way.
>
> On Sunday, March 13, 2022 at 11:00:16 AM UTC-5
> black...@blackboxembedded.com wrote:
>
> Thanks. We must be doing something right as BMW copied our design...
>
> I have a copy of one of Jans machine files loaded. Here you can
> see the Jan has the 'Peeler' is associated to the head. I don't
> think this is mandatory. I'm not sure if I do the same or just
> have the peeler working under machine actuators. It should work
> either way.
> peeler1.png
> On Sunday, March 13, 2022 at 8:15:00 AM UTC-7
> mark.m...@gmail.com wrote:
>
> Wayne,
>
> I did go to your site, cool hardware for the bike!
>
> Peelers, I am running Jan's latest machine.xml release from
> the link at the top of this thread. He has a 36VA so I would
> expect at least one peeler. I have looked but am new to OpenPnP.
>
> Attached is the screenshot of the actuators.
> On Sunday, March 13, 2022 at 8:15:00 AM UTC-7
> mark.m...@gmail.com wrote:
>
> Wayne,
>
> I did go to your site, cool hardware for the bike!
>
> Peelers, I am running Jan's latest machine.xml release from
> the link at the top of this thread. He has a 36VA so I would
> expect at least one peeler. I have looked but am new to OpenPnP.
>
> Attached is the screenshot of the actuators.
> <https://groups.google.com/d/msgid/openpnp/6e14821b-9b46-49bc-a779-8ba5a9a54f0en%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/998ea078-cddd-47f1-aef1-a8c239e79b77n%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/998ea078-cddd-47f1-aef1-a8c239e79b77n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Wayne Black
Mar 14, 2022, 12:53:59 PM3/14/22
to OpenPnP
Hi Jan,
I think I missed responding to your Q about my 'Peeler' running concurrently with the drag move. I didnt do anything differently than you other than disable all actuator movement coordination. This doesn't work well. I have found that the the actual 'peeled' distance is inconsistant. The only way to get consistant peeling is to enable movement coordination.
One thing you posted above about actuator vs axis. Would it be possible to make a peeler an individual axis and allow for concurrent movement of 'peeling' and 'dragging' simultaneously?
Jan
Mar 14, 2022, 2:56:53 PM3/14/22
to ope...@googlegroups.com
Hi Wayne!
Many thanks for your answer. Yes, I think its not a good idea to run
the peeler without coordination as the tape has to be collected *while*
or *after* the drag move and *before* the pick.
I've discussed a few weeks before with _Mark that it would be ideal to
make the peeler an other axis and operate it in parallel with the drag
move. He agreed and had already ideas how that could be easily
integrated. However, he warned, that this might be not a good first
PR... In the mean while I found out, that I can/missed to configure the
acceleration for the peeler. It was always running with the last value
set via M204, which is about 1/10 of the max allowed value. So I added a
M204 to the peelers G-Code and how it works much faster. However, do to
the separate drag and peel operation, I have some trouble with 12mm
pitch tape.
Jan
> <https://groups.google.com/d/msgid/openpnp/998ea078-cddd-47f1-aef1-a8c239e79b77n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/998ea078-cddd-47f1-aef1-a8c239e79b77n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> <https://groups.google.com/d/msgid/openpnp/bcf3a2c8-dfd8-451f-8555-f46fee23b286n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Many thanks for your answer. Yes, I think its not a good idea to run
the peeler without coordination as the tape has to be collected *while*
or *after* the drag move and *before* the pick.
I've discussed a few weeks before with _Mark that it would be ideal to
make the peeler an other axis and operate it in parallel with the drag
move. He agreed and had already ideas how that could be easily
integrated. However, he warned, that this might be not a good first
PR... In the mean while I found out, that I can/missed to configure the
acceleration for the peeler. It was always running with the last value
set via M204, which is about 1/10 of the max allowed value. So I added a
M204 to the peelers G-Code and how it works much faster. However, do to
the separate drag and peel operation, I have some trouble with 12mm
pitch tape.
Jan
> <https://groups.google.com/d/msgid/openpnp/998ea078-cddd-47f1-aef1-a8c239e79b77n%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/bcf3a2c8-dfd8-451f-8555-f46fee23b286n%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/bcf3a2c8-dfd8-451f-8555-f46fee23b286n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Wayne Black
Mar 14, 2022, 3:25:52 PM3/14/22
to OpenPnP
Aha, more good insights Jan! I too running G0 command wo checking/setting feed rate before hand. I notice actuating the peeler via actuate command is much faster than the peeler being actuated via a pick command... Ill need to address that when I get back to the machine.
mark maker
Mar 15, 2022, 4:48:29 AM3/15/22
to ope...@googlegroups.com
> I've discussed a few weeks before with _Mark that it would be ideal to make the peeler an other axis and operate it in parallel with the drag move. He agreed and had already ideas how that could be easily integrated.
I still have this on the radar and will implement it as soon as possible.
_Mark
dani
Mar 17, 2022, 8:38:21 PM3/17/22
to OpenPnP
Hello,
I am new around here but not new with openpnp: I have built my own machine with dragfeeder and reprogrammed locally ReferenceDragFeeder to do what is discussed here. That is, I've been running for a month or so with an axis configured peeler that removes the tape simultaneously with the dragpin movement. I haven't posted anything as it doesn't meet anywhere near the requirements to post for developers and is too "homemade" a code made for my purposes. I have seen mark as a code contributor and I am certain you will do much better. Still, if it can be of any use to you, I can attach my "progress".
One thing I can humbly contribute something useful in the community is in the use of a driver for the solenoid that prevents it from burning out if it is inadvertently active longer than necessary as I have read someone has had happen to them. Anyway, if anyone is interested I will be happy to upload it wherever you tell me.
I am new around here but not new with openpnp: I have built my own machine with dragfeeder and reprogrammed locally ReferenceDragFeeder to do what is discussed here. That is, I've been running for a month or so with an axis configured peeler that removes the tape simultaneously with the dragpin movement. I haven't posted anything as it doesn't meet anywhere near the requirements to post for developers and is too "homemade" a code made for my purposes. I have seen mark as a code contributor and I am certain you will do much better. Still, if it can be of any use to you, I can attach my "progress".
One thing I can humbly contribute something useful in the community is in the use of a driver for the solenoid that prevents it from burning out if it is inadvertently active longer than necessary as I have read someone has had happen to them. Anyway, if anyone is interested I will be happy to upload it wherever you tell me.
vespaman
Jul 3, 2022, 10:50:58 AM7/3/22
to OpenPnP
Hi Jan,
After a few month of no time to work with my Charmhigh conversion, I now finally have.. So I added your ring light, since my new camera really needed good light, but I have yet connected it properly..
Did you just solder the two light wire(s) onto the mainboard, or do you know what kind of crimp connector to use for the missing OT2 connector pin?
And:- (I know, probably a bit lazy, I should be able to figure this out, but faster to ask!) the other wire (not the OT2 one), where did you connect that (on the head or on the mainboard), and should it be connected to GND or 24V?
For now I am running constant 24V on the ring light and it makes huge difference compared to how it was without.
Thanks,
Micael
onsdag 23 februari 2022 kl. 18:31:05 UTC+1 skrev Jan:
Hi All!
As promised, today I've
- released my modifications to the smoothieware code for the CMH-T36VA
mainboard at https://github.com/janm012012/Smoothieware-CHMT,
- my ringlight design for the CHM-T36VA at
- updated the Wiki for the CHM-T36VA at
https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA with some notes.
Jan
Jul 4, 2022, 5:32:13 AM7/4/22
to ope...@googlegroups.com
Hi Micael!
Its the same here: I've a bunch of PCBs and parts here to populate, but
just no time...
IIRC I've soldered wires to D7, which is the flyback diode for OT2. The
OT* outputs are low-side (N-Channel) feds, hence you've to get power
from somewhere else. I've used the two spare wires, one to provide 24V
for the camera light and the seconds for PWM control via OT2. Both
signals are at D7.
Jan
On 03.07.2022 16:50, vespaman wrote:
> Hi Jan,
> After a few month of no time to work with my Charmhigh conversion, I now
> finally have.. So I added your ring light, since my new camera really
> needed good light, but I have yet connected it properly..
> Did you just solder the two light wire(s) onto the mainboard, or do you
> know what kind of crimp connector to use for the missing OT2 connector pin?
> And:- (I know, probably a bit lazy, I should be able to figure this out,
> but faster to ask!) the other wire (not the OT2 one), where did you
> connect that (on the head or on the mainboard), and should it be
> connected to GND or 24V?
>
> For now I am running constant 24V on the ring light and it makes huge
> difference compared to how it was without.
>
> Thanks,
> Micael
>
> onsdag 23 februari 2022 kl. 18:31:05 UTC+1 skrev Jan:
>
> Hi All!
> As promised, today I've
> - released my modifications to the smoothieware code for the CMH-T36VA
> mainboard at https://github.com/janm012012/Smoothieware-CHMT
> <https://github.com/janm012012/Smoothieware-CHMT>,
> <https://groups.google.com/d/msgid/openpnp/71929645-7264-49b1-a433-162a8ef5a404n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Its the same here: I've a bunch of PCBs and parts here to populate, but
just no time...
IIRC I've soldered wires to D7, which is the flyback diode for OT2. The
OT* outputs are low-side (N-Channel) feds, hence you've to get power
from somewhere else. I've used the two spare wires, one to provide 24V
for the camera light and the seconds for PWM control via OT2. Both
signals are at D7.
Jan
On 03.07.2022 16:50, vespaman wrote:
> Hi Jan,
> After a few month of no time to work with my Charmhigh conversion, I now
> finally have.. So I added your ring light, since my new camera really
> needed good light, but I have yet connected it properly..
> Did you just solder the two light wire(s) onto the mainboard, or do you
> know what kind of crimp connector to use for the missing OT2 connector pin?
> And:- (I know, probably a bit lazy, I should be able to figure this out,
> but faster to ask!) the other wire (not the OT2 one), where did you
> connect that (on the head or on the mainboard), and should it be
> connected to GND or 24V?
>
> For now I am running constant 24V on the ring light and it makes huge
> difference compared to how it was without.
>
> Thanks,
> Micael
>
> onsdag 23 februari 2022 kl. 18:31:05 UTC+1 skrev Jan:
>
> Hi All!
> As promised, today I've
> - released my modifications to the smoothieware code for the CMH-T36VA
> mainboard at https://github.com/janm012012/Smoothieware-CHMT
> - my ringlight design for the CHM-T36VA at
> https://github.com/janm012012/Ringlight
> <https://github.com/janm012012/Ringlight> and
> - updated the Wiki for the CHM-T36VA at
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA> with
> some notes.
> If you feel there is anything missing, not helpful, imprecise or even
> incorrect, please let me know and I'll be happy to fix it.
>
> Jan
>
> https://github.com/janm012012/Ringlight
> <https://github.com/janm012012/Ringlight> and
> - updated the Wiki for the CHM-T36VA at
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA> with
> some notes.
> If you feel there is anything missing, not helpful, imprecise or even
> incorrect, please let me know and I'll be happy to fix it.
>
> 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/71929645-7264-49b1-a433-162a8ef5a404n%40googlegroups.com
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/71929645-7264-49b1-a433-162a8ef5a404n%40googlegroups.com?utm_medium=email&utm_source=footer>.
vespaman
Jul 7, 2022, 9:18:50 AM7/7/22
to OpenPnP
Jan, thanks.
That worked just fine, I have light! :)
If someone else are to do this mod, and like me, don't have the correct crimp connector, here's how I did;
I took a 3 pole JST type connector removed the mid pin, and soldered it directly onto D7, and crimped a new connector on the wires. This way, the soldering iron will not be needed if/when the board are to be removed the next time.
Thorsten.R
Jul 11, 2022, 1:51:15 AM7/11/22
to OpenPnP
Hello Jan,
I have now also used your firmware, so it runs almost straight away, compared to mattthebaker's . However, it is always referred to this :(
Great !
I still have the upper mini camera removed and through this https://www.amazon.de/gp/product/B07PGFJFND/ref=ppx_yo_dt_b_asin_title_o09_s00?ie=UTF8&psc=1
replaced.
Now if OpenPNP gets a proper GUI :)
Thorsten
I have now also used your firmware, so it runs almost straight away, compared to mattthebaker's . However, it is always referred to this :(
Great !
However, the Worklight as PWM is not so nice, as there are stripes on the cam.
With the new cam it is not noticeable.
That was better as a digital pin.
I still have the upper mini camera removed and through this https://www.amazon.de/gp/product/B07PGFJFND/ref=ppx_yo_dt_b_asin_title_o09_s00?ie=UTF8&psc=1
replaced.
This is much brighter due to the Sony IMX323 sensor and not so noisy.
Mounted in PETG and the 2nd one printed with SLA.
Now if OpenPNP gets a proper GUI :)
Thorsten
Jan schrieb am Mittwoch, 23. Februar 2022 um 18:31:05 UTC+1:
Hi All!
As promised, today I've
- released my modifications to the smoothieware code for the CMH-T36VA
mainboard at https://github.com/janm012012/Smoothieware-CHMT,
- my ringlight design for the CHM-T36VA at
- updated the Wiki for the CHM-T36VA at
https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA with some notes.
Jarosław Karwik
Jul 11, 2022, 1:58:07 AM7/11/22
to OpenPnP
Hi,
Question about your camera - is the attachment stiff enough ? I think I have exactly same camera and I was not sure how to make mechanics for it.
Did you just screw it the housing ? I wanted something more permanent ( like in original solution) to avoid recalibration in case I have to open the head access.
Wayne Black
Jul 11, 2022, 2:09:43 AM7/11/22
to ope...@googlegroups.com
I have my camara similarly mounted but the camera housing is aluminum and rock solid. One thing to note if you do mount the camera to the head shield is that it won't be perpendicular. Youll have to really tune the offset settings...
--
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/42777fcc-c0a5-4e14-9411-2da91ba0cc35n%40googlegroups.com.
vespaman
Jul 11, 2022, 2:15:59 AM7/11/22
to OpenPnP
Hi Thorsten,
While I haven't tried it but with the work light, will not setting PWM to 100 make the flicker go away?
(I have no issues with this, therefore i haven't tried changing)
Micael
Jan
Jul 11, 2022, 2:38:54 AM7/11/22
to ope...@googlegroups.com
Hi Thorsten!
Great to hear that my modifications to the firmware work well for you
too! I think it would be a good idea if you could use your experience to
update the Wiki.
Concerning the worklight: the pin (PF4) seems not to be hardware-pwm
capable (it's at least configured for software pwm), hence it's period
is rather long and unstable. As general recommendation I'd suggest to
make the camera light as bright as possible and configure the cameras
exposer time as short as possible. That should give you low image noise
and fast camera response and it does not matter much if the worklight is
on or off. However, you might suffer from reflections at the drag feeder
cover (if you're - as I would recommend - use the
ReferencePushPullFeeder). Coloring the cover in black might help (I'll
try that next) and masking the cover (using MaskRectangle) definitely works.
Jan
On 09.07.2022 21:29, 'Thorsten.R' via OpenPnP wrote:
> Hello Jan,
> I have now also used your firmware, so it runs almost straight away,
> compared to mattthebaker's . However, it is always referred to this :(
>
> Great !
>
> However, the Worklight as PWM is not so nice, as there are stripes on
> the cam.
> With the new cam it is not noticeable.
> That was better as a digital pin.
>
> I still have the upper mini camera removed and through this
> https://www.amazon.de/gp/product/B07PGFJFND/ref=ppx_yo_dt_b_asin_title_o09_s00?ie=UTF8&psc=1
> replaced.
> This is much brighter due to the Sony IMX323 sensor and not so noisy.
>
> Mounted in PETG and the 2nd one printed with SLA.
>
> Now if OpenPNP gets a proper GUI :)
>
>
> Thorsten
>
> <https://groups.google.com/d/msgid/openpnp/5a6f7dea-5da1-4e20-9786-c8855b45b936n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Great to hear that my modifications to the firmware work well for you
too! I think it would be a good idea if you could use your experience to
update the Wiki.
Concerning the worklight: the pin (PF4) seems not to be hardware-pwm
capable (it's at least configured for software pwm), hence it's period
is rather long and unstable. As general recommendation I'd suggest to
make the camera light as bright as possible and configure the cameras
exposer time as short as possible. That should give you low image noise
and fast camera response and it does not matter much if the worklight is
on or off. However, you might suffer from reflections at the drag feeder
cover (if you're - as I would recommend - use the
ReferencePushPullFeeder). Coloring the cover in black might help (I'll
try that next) and masking the cover (using MaskRectangle) definitely works.
Jan
On 09.07.2022 21:29, 'Thorsten.R' via OpenPnP wrote:
> Hello Jan,
> I have now also used your firmware, so it runs almost straight away,
> compared to mattthebaker's . However, it is always referred to this :(
>
> Great !
>
> However, the Worklight as PWM is not so nice, as there are stripes on
> the cam.
> With the new cam it is not noticeable.
> That was better as a digital pin.
>
> I still have the upper mini camera removed and through this
> https://www.amazon.de/gp/product/B07PGFJFND/ref=ppx_yo_dt_b_asin_title_o09_s00?ie=UTF8&psc=1
> replaced.
> This is much brighter due to the Sony IMX323 sensor and not so noisy.
>
> Mounted in PETG and the 2nd one printed with SLA.
>
> Now if OpenPNP gets a proper GUI :)
>
>
> Thorsten
>
> IMG_0842.JPG
>
> Jan schrieb am Mittwoch, 23. Februar 2022 um 18:31:05 UTC+1:
>
> Hi All!
> As promised, today I've
> - released my modifications to the smoothieware code for the CMH-T36VA
> mainboard at https://github.com/janm012012/Smoothieware-CHMT
> <https://github.com/janm012012/Smoothieware-CHMT>,
>
> Jan schrieb am Mittwoch, 23. Februar 2022 um 18:31:05 UTC+1:
>
> Hi All!
> As promised, today I've
> - released my modifications to the smoothieware code for the CMH-T36VA
> mainboard at https://github.com/janm012012/Smoothieware-CHMT
> - my ringlight design for the CHM-T36VA at
> https://github.com/janm012012/Ringlight
> <https://github.com/janm012012/Ringlight> and
> - updated the Wiki for the CHM-T36VA at
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA> with
> some notes.
> If you feel there is anything missing, not helpful, imprecise or even
> incorrect, please let me know and I'll be happy to fix it.
>
> Jan
>
> https://github.com/janm012012/Ringlight
> <https://github.com/janm012012/Ringlight> and
> - updated the Wiki for the CHM-T36VA at
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA> with
> some notes.
> If you feel there is anything missing, not helpful, imprecise or even
> incorrect, please let me know and I'll be happy to fix it.
>
> 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>.
> 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/5a6f7dea-5da1-4e20-9786-c8855b45b936n%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/5a6f7dea-5da1-4e20-9786-c8855b45b936n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Jan
Jul 11, 2022, 2:47:48 AM7/11/22
to ope...@googlegroups.com
Hi Jarosław!
I'm using the camera that Erich is recommending at
https://mcuoneclipse.com/2020/05/03/retrofitting-a-charmhigh-chm-t36va-machine-with-openpnp/
which fits nicely into the original housing. The camera mounting in the
tube uses some grub crews so that it can be well secured and adjusted.
In addition the mounting holes between the camera holder and the head
are a little larger then needed so that the holder can be slightly
tilted. According to advanced camera calibration my camera is mounted
with an error of 0.2° in X and 0.8° in Y.
The original camera holder is mounted directly to the head. Hence you
can open the head (remove the blue cover) without removing the camera.
Jan
On 11.07.2022 07:58, Jarosław Karwik wrote:
> Hi,
>
> Question about your camera - is the attachment stiff enough ? I think I
> have exactly same camera and I was not sure how to make mechanics for it.
>
> Did you just screw it the housing ? I wanted something more permanent (
> like in original solution) to avoid recalibration in case I have to open
> the head access.
>
>
>
>
> poniedziałek, 11 lipca 2022 o 08:51:15 UTC+3 Thorsten.R napisał(a):
>
> Hello Jan,
> I have now also used your firmware, so it runs almost straight away,
> compared to mattthebaker's . However, it is always referred to this :(
>
> Great !
>
> However, the Worklight as PWM is not so nice, as there are stripes
> on the cam.
> With the new cam it is not noticeable.
> That was better as a digital pin.
>
> I still have the upper mini camera removed and through this
> https://www.amazon.de/gp/product/B07PGFJFND/ref=ppx_yo_dt_b_asin_title_o09_s00?ie=UTF8&psc=1
> <https://www.amazon.de/gp/product/B07PGFJFND/ref=ppx_yo_dt_b_asin_title_o09_s00?ie=UTF8&psc=1>
> replaced.
> This is much brighter due to the Sony IMX323 sensor and not so noisy.
>
> Mounted in PETG and the 2nd one printed with SLA.
>
> Now if OpenPNP gets a proper GUI :)
>
>
> Thorsten
>
> <https://groups.google.com/d/msgid/openpnp/42777fcc-c0a5-4e14-9411-2da91ba0cc35n%40googlegroups.com?utm_medium=email&utm_source=footer>.
I'm using the camera that Erich is recommending at
https://mcuoneclipse.com/2020/05/03/retrofitting-a-charmhigh-chm-t36va-machine-with-openpnp/
which fits nicely into the original housing. The camera mounting in the
tube uses some grub crews so that it can be well secured and adjusted.
In addition the mounting holes between the camera holder and the head
are a little larger then needed so that the holder can be slightly
tilted. According to advanced camera calibration my camera is mounted
with an error of 0.2° in X and 0.8° in Y.
The original camera holder is mounted directly to the head. Hence you
can open the head (remove the blue cover) without removing the camera.
Jan
On 11.07.2022 07:58, Jarosław Karwik wrote:
> Hi,
>
> Question about your camera - is the attachment stiff enough ? I think I
> have exactly same camera and I was not sure how to make mechanics for it.
>
> Did you just screw it the housing ? I wanted something more permanent (
> like in original solution) to avoid recalibration in case I have to open
> the head access.
>
>
>
>
> poniedziałek, 11 lipca 2022 o 08:51:15 UTC+3 Thorsten.R napisał(a):
>
> Hello Jan,
> I have now also used your firmware, so it runs almost straight away,
> compared to mattthebaker's . However, it is always referred to this :(
>
> Great !
>
> However, the Worklight as PWM is not so nice, as there are stripes
> on the cam.
> With the new cam it is not noticeable.
> That was better as a digital pin.
>
> I still have the upper mini camera removed and through this
> https://www.amazon.de/gp/product/B07PGFJFND/ref=ppx_yo_dt_b_asin_title_o09_s00?ie=UTF8&psc=1
> <https://www.amazon.de/gp/product/B07PGFJFND/ref=ppx_yo_dt_b_asin_title_o09_s00?ie=UTF8&psc=1>
> replaced.
> This is much brighter due to the Sony IMX323 sensor and not so noisy.
>
> Mounted in PETG and the 2nd one printed with SLA.
>
> Now if OpenPNP gets a proper GUI :)
>
>
> Thorsten
>
> IMG_0842.JPG
>
> Jan schrieb am Mittwoch, 23. Februar 2022 um 18:31:05 UTC+1:
>
> Hi All!
> As promised, today I've
> - released my modifications to the smoothieware code for the
> CMH-T36VA
>
> mainboard at https://github.com/janm012012/Smoothieware-CHMT
> <https://github.com/janm012012/Smoothieware-CHMT>,
>
> Jan schrieb am Mittwoch, 23. Februar 2022 um 18:31:05 UTC+1:
>
> Hi All!
> As promised, today I've
> - released my modifications to the smoothieware code for the
> CMH-T36VA
>
> mainboard at https://github.com/janm012012/Smoothieware-CHMT
>
> - my ringlight design for the CHM-T36VA at
>
> https://github.com/janm012012/Ringlight
> <https://github.com/janm012012/Ringlight> and
>
> - updated the Wiki for the CHM-T36VA at
>
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA>
> with some notes.
>
> If you feel there is anything missing, not helpful, imprecise or
> even
> incorrect, please let me know and I'll be happy to fix it.
>
> Jan
>
> - my ringlight design for the CHM-T36VA at
>
> https://github.com/janm012012/Ringlight
> <https://github.com/janm012012/Ringlight> and
>
> - updated the Wiki for the CHM-T36VA at
>
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA>
> with some notes.
>
> If you feel there is anything missing, not helpful, imprecise or
> even
> incorrect, please let me know and I'll be happy to fix it.
>
> 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/42777fcc-c0a5-4e14-9411-2da91ba0cc35n%40googlegroups.com
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/42777fcc-c0a5-4e14-9411-2da91ba0cc35n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Jarosław Karwik
Jul 11, 2022, 2:54:16 AM7/11/22
to OpenPnP
Hi,
I know that better fitting camera can be bought, just this one was leftover from other project and for free :-)
My plan was to make aluminium attachment, but if printed part would work then I would go for that.
However as it was pointed out, it may be hard to get alignment, so most likely I will make aluminium adapter to fit original assembly.
BTW:
Next in plans is to get running my replacement for the controller - I should get PCBs today :-)
Thorsten.R
Jul 11, 2022, 7:28:22 AM7/11/22
to OpenPnP
Hi Jan,
with 100% it is almost gone with the old camera.
The ELP does not interfere with this.
I think the digital pin was better, as in the recommended firmware. However, this FW made many problems.
3 x driven to stop :(
Yours is there wsendlich rounder from the start. :)
with 100% it is almost gone with the old camera.
The ELP does not interfere with this.
I think the digital pin was better, as in the recommended firmware. However, this FW made many problems.
3 x driven to stop :(
Yours is there wsendlich rounder from the start. :)
Thorsten.R
Jul 11, 2022, 7:29:29 AM7/11/22
to OpenPnP
Hi,
Unfortunately, I have not found anyone who mills me that in aluminum.
vespaman
Jul 11, 2022, 7:31:39 AM7/11/22
to OpenPnP
Maybe I should not put this question in this thread, but it has kind of turned into a everything CHMT thread, so.. :)
I have now no more issues to solve, hopefully everything is calibrated at least into an operational point.
I have now no more issues to solve, hopefully everything is calibrated at least into an operational point.
So, I started to look into feeders. I understand that the pushpull feeder is the most flexible one, so I started with that, trying to add the first left feeder on my 48VB.
To be honest, I don't really know what I am doing, so I also tried the drag feeder when pushpull feeder did not make sense to me. But also that does not work, and I felt that the pushpull feeder had better UI, so I went back to that.
I have entered pick/hole1/hole2 locations by manually jog.
If I "press Auto-Setup with Camera at Pick Location", I get the sprocket hole error.
If I press "Preview Vision Features", Absolutely nothing happens at all.
If I press any of the four buttons the tab dialog (outside this pic) (pick/feed/move/move), I get the No line of sprocker error.
Now, I never run my 48 with the China FW, so maybe I am not even at the correct pick location(?) I just viewed some youtube videos, where it looked like this was the pick location..
What did I do wrong?
Micael
Thorsten.R
Jul 11, 2022, 7:40:08 AM7/11/22
to OpenPnP
Hi,
The new holder made of resin with 30% Monocure Flex 100 is extremely stable. The flex addition only serves to make it less brittle.
Whereas the PETG holder has not shifted so far.
I have not fixed the holder to the head cover, the hole is only for safety.
Whereas the PETG holder has not shifted so far.
I have not fixed the holder to the head cover, the hole is only for safety.
But especially on the feeder side you can see more, the brightness of the camera even has to be turned down a bit.
black...@blackboxembedded.com schrieb am Montag, 11. Juli 2022 um 08:09:43 UTC+2:
Thorsten.R
Jul 11, 2022, 7:44:11 AM7/11/22
to OpenPnP
I covered the UpLed ring with a ring of diffuser foil, so there are hardly any reflections on the nozzle.
https://www.amazon.de/gp/product/B08PTD35D1/ref=ppx_yo_dt_b_asin_title_o07_s00?ie=UTF8&psc=1
https://www.amazon.de/gp/product/B08PTD35D1/ref=ppx_yo_dt_b_asin_title_o07_s00?ie=UTF8&psc=1
Thorsten.R
Jul 11, 2022, 8:33:16 AM7/11/22
to OpenPnP
Hi Jan,
what are the reasons to use the ReferencePushPullFeeder ? Tried but did not understand :)
Maybe you could write something more about this.
The drag feeder works perfectly here, if you know that you have to set 4.2mm for a feed of 4mm and a pullback of 0.2mm. And one has measured the offset for the DragPin well then the set works, per camera Top.
Very rarely there is a hanger with the black plastic tapes.
what are the reasons to use the ReferencePushPullFeeder ? Tried but did not understand :)
Maybe you could write something more about this.
The drag feeder works perfectly here, if you know that you have to set 4.2mm for a feed of 4mm and a pullback of 0.2mm. And one has measured the offset for the DragPin well then the set works, per camera Top.
Very rarely there is a hanger with the black plastic tapes.
Jan
Jul 13, 2022, 4:43:10 AM7/13/22
to ope...@googlegroups.com
Hi Thorsten!
Its just a personal preference if you go for ReferenceDragFeeder or
ReferencePushPullFeeder. Here my list of pros and cons:
ReferenceDragFeeder:
- easier to setup (only need to specify 3 coordinates, pick and 2x drag)
- less configuration options to deal with
- no vision for drag location
- might require different actuators for the peel move depending on the
part pitch
ReferencePushPullFeeder:
- plenty of configuration options, mostly not used on CHM-T
- supports parallel operation of drag and peel move (requires a recent
version of OpenPnp)
- supports vision correction of Y locations only (requires a recent
version of OpenPnp) (might require special pipeline tuning to handle
reflections)
- supports auto-setup using vision (pick location only) (might require
special pipeline tuning to handle reflections)
- supports cloning
- requires 6 coordinates to be setup (pick, 2x hole close to pick
location, 3x drag move)
- backoff has to be calculated manually as part of the inner drag move
location
Jan
> <https://groups.google.com/d/msgid/openpnp/5a6f7dea-5da1-4e20-9786-c8855b45b936n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/5a6f7dea-5da1-4e20-9786-c8855b45b936n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> <https://groups.google.com/d/msgid/openpnp/b219e710-7a4d-4a02-8d7b-9201f6d98472n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Its just a personal preference if you go for ReferenceDragFeeder or
ReferencePushPullFeeder. Here my list of pros and cons:
ReferenceDragFeeder:
- easier to setup (only need to specify 3 coordinates, pick and 2x drag)
- less configuration options to deal with
- no vision for drag location
- might require different actuators for the peel move depending on the
part pitch
ReferencePushPullFeeder:
- plenty of configuration options, mostly not used on CHM-T
- supports parallel operation of drag and peel move (requires a recent
version of OpenPnp)
- supports vision correction of Y locations only (requires a recent
version of OpenPnp) (might require special pipeline tuning to handle
reflections)
- supports auto-setup using vision (pick location only) (might require
special pipeline tuning to handle reflections)
- supports cloning
- requires 6 coordinates to be setup (pick, 2x hole close to pick
location, 3x drag move)
- backoff has to be calculated manually as part of the inner drag move
location
Jan
> <https://groups.google.com/d/msgid/openpnp/5a6f7dea-5da1-4e20-9786-c8855b45b936n%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/b219e710-7a4d-4a02-8d7b-9201f6d98472n%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/b219e710-7a4d-4a02-8d7b-9201f6d98472n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Thorsten.R
Jul 13, 2022, 8:04:57 AM7/13/22
to OpenPnP
Hello Jan,
thank you for the explanation.
Since I have almost only 805 components, top vision is relatively uninteresting, I think. Bottom vision is sufficient here.
"- supports parallel operation of drag and peel move"
This is of course very interesting :)
Where I find your FW eh not soooo slow, compared to the original FW, there we mostly 75% machine speed.
Since some of the GUI is more disturbing. How do you call that in english "Work flow"?
The Blue Move and Red Ref, button right next to each other have already cost me nerves and that the Singe Move button is a debug step :(
I had read somewhere that you wanted to do something against the drag pin hang ?
That never happened with the original software.
Should not there be a slight "circling" introduced when the drag pin hangs ?
That would be the icing on the cake :)
Thorsten
thank you for the explanation.
Since I have almost only 805 components, top vision is relatively uninteresting, I think. Bottom vision is sufficient here.
"- supports parallel operation of drag and peel move"
Where I find your FW eh not soooo slow, compared to the original FW, there we mostly 75% machine speed.
Since some of the GUI is more disturbing. How do you call that in english "Work flow"?
The Blue Move and Red Ref, button right next to each other have already cost me nerves and that the Singe Move button is a debug step :(
I had read somewhere that you wanted to do something against the drag pin hang ?
That never happened with the original software.
Should not there be a slight "circling" introduced when the drag pin hangs ?
That would be the icing on the cake :)
I have unfortunately 0 idea of GCode :(
Otherwise, things are running tip-top.
Thorsten
mark maker
Jul 13, 2022, 9:14:14 AM7/13/22
to ope...@googlegroups.com
Hi Jan,
could you please post some screenshots of the finished
ReferencePushPullFeeder setup?
Or even add it to a new Wiki page, perhaps linked from these pages:
https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder
> backoff has to be calculated manually as part of the
inner drag move location
Could you elaborate, please?
_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/13cbb74c-7ffd-46a1-819a-126b90747b1dn%40googlegroups.com.
vespaman
Jul 13, 2022, 11:23:44 AM7/13/22
to OpenPnP
Some screenshots would be super useful! I am kind of stuck, just because there are so many options.. :)
Some feed-back already from a stuck user;
It would be very useful to have one of these Blue "I" link buttons to goto the wiki page describing this feature in this dialog. (I did not find that wiki page a couple of days ago, when I was trying to get my head around this!).
I think I understand now, that the "Preview vision features" only works if the vision system has picked up the sprocket holes? If possible to do - it would be great to get some kind of message when pressing this button, so one could know what to expect, if the sprocket holes are not detected.
I also assume the undetected sprocket holes makes the "Discard Parts" button also do nothing (apart from the count goes up, but nothing else).
And, editing pipeline, I though that was only for the OCR (since it is located in the OCR box (even if it is called vision)) - but Jan's response above makes me think it is also for the sprocket holes(?).
Especially perhaps also the "Push-Pull Motion" tab - why is there no correlation here from the first tab? Should not the pick location and the drag feeder be used as an input to start and stop? Now when I write this, I understand why, (because drag pin is a maybe mostly a CHMT thing?!). In this case; if/once the feed actuator is set to DRAGPIN, could maybe calculated values be populated from the drag pin offsets? (Or maybe that is too much work for a small proportion of users)
Or probably I am misunderstanding the hole Push-Pull Motion tab and you should disregard this! :)
Sorry for all this newbie feedback, take it for what it is worth!
mark maker
Jul 13, 2022, 12:29:59 PM7/13/22
to ope...@googlegroups.com
> It would be very useful to have one of these Blue "I"
link buttons to goto the wiki page describing this feature in
this dialog.
Could in deed make sense. Will keep this in mind. Am more generic
solution should be found (many Wizards have Wiki pages, or
sections).
> think I understand now, that the "Preview vision features" only works if the vision system has picked up the sprocket holes? If possible to do - it would be great to get some kind of message when pressing this button, so one could know what to expect, if the sprocket holes are not detected.
Yes, it seems that way. Good point! I fixed it. Please test in the testing version.
> I also assume the undetected sprocket holes makes the "Discard Parts" button also do nothing (apart from the count goes up, but nothing else).
This is a misunderstanding. I added a description in the Wiki:
The Discard Parts function voids any remaining parts that were produced by prior feed actuations. This can be the case in 2mm pitch tapes (0201 or 0402 parts), where one feed produces two parts, and/or if you used a Multiplier greater than one. These parts might have fallen out of the tape in the meantime, or you don't want them picked for some reason. Discarding will just disregard these parts and prompt a new feed actuation on the next feed. If parts are still physically in their pockets, they will be transported away with the spent tape.
https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder#tape-settings
> And, editing pipeline, I though that was only for the OCR (since it is located in the OCR box (even if it is called vision)) - but Jan's response above makes me think it is also for the sprocket holes(?).
For efficiency the pipeline was very carefully designed to cover
all the vision operations in one fell swoop. Unlike in other
pipelines, the results are obtained from two stages.
> Especially perhaps also the "Push-Pull Motion" tab - why
is there no correlation here from the first tab? Should not the
pick location and the drag feeder be used as an input to start
and stop?
Not sure I understand the specific question. Some general explanations:
The locations on the first and second tab are correlated in
that the first tab gives the reference for the second. The two
sprocket holes define the position and rotation
of the feeder. All the other locations are then handled as relative
to this reference. If you later move around the feeder, or if
you clone another feeder from it, it will automatically translate
and rotate everything to the target location and
rotation.
That's how it supports one-click-setup from the second feeder. So yes, it is hard work with these locations, but it is usually only needed once!
https://youtu.be/5QcJ2ziIJ14?t=295
Other than defining/using the reference, the two tabs are
completely free from each other. The ReferencePushPullFeeder can
be used for any mechanical motion. Dragging is just one
popular option among many, like lever feeders, push-pull feeders
or any other contraption OpenPnP users will come up with.
Even if the ReferencePushPullFeeder would know that this is a
drag feeder, it wouldn't know where to position the drag pin.
Which of the two sprocket holes? Maybe it drags several holes away
from those two it detected using vision? And even if it knew the
right hole, it would not know the drag pin diameter and how much
to go back from the hole edge. It is just simpler to let the user
position the drag pin right in real life, and then capture that
location.
> Sorry for all this newbie feedback, take it for what it is worth!
Keep asking. 😉
Maybe open a new discussion thread, because this has become a
specific sub-topic.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/948e0fb5-b744-4102-8b60-d175796bf036n%40googlegroups.com.
Thorsten.R
Jul 13, 2022, 2:41:23 PM7/13/22
to OpenPnP
Hi Mark,
that a good explanation plus video about the ReferencePushPullFeeder .
Thorsten
that a good explanation plus video about the ReferencePushPullFeeder .
Thorsten
Jan
Jul 13, 2022, 4:31:14 PM7/13/22
to ope...@googlegroups.com
Hi Thorsten!
On 13.07.2022 14:04, 'Thorsten.R' via OpenPnP wrote:
[...]
make the configuration then nothing bad shall happen.
Yes, the work flow is different compared to the Chinese software.
However, according to the videos I've see, it more like other software.
So it might be rather the Chinese who did it different. Anyhow, as Mark
said, OpenPnp is open source and any contribution is welcome.
> I had read somewhere that you wanted to do something against the drag
> pin hang ?
> That never happened with the original software.
>
> Should not there be a slight "circling" introduced when the drag pin hangs ?
>
Yes, I've read that somewhere too. No, I never intended to implement
such a workaround. With proper setup (good coordinates) it's - mostly -
not needed and if it is, the interlock feature will prevent you from
breaking the pin. (I once had a tape where either the tape was jittering
in the feeder or where the holes where jittering with respect to the
edge. There I had to retune the y locations of the final drag move every
few meters) With vision correction in the ReferencePushPullFeeder this
is hopefully not needed anymore.
> That would be the icing on the cake :)
>
> I have unfortunately 0 idea of GCode :(
>
I'm not sure if this can be implemented just with some GCode. You'd have
to drive something like a spiral and stop once the dragpin released
signal gets asserted. This is probably something that could be best done
in the controller.
Jan
> <https://groups.google.com/d/msgid/openpnp/b219e710-7a4d-4a02-8d7b-9201f6d98472n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/b219e710-7a4d-4a02-8d7b-9201f6d98472n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> <https://groups.google.com/d/msgid/openpnp/13cbb74c-7ffd-46a1-819a-126b90747b1dn%40googlegroups.com?utm_medium=email&utm_source=footer>.
On 13.07.2022 14:04, 'Thorsten.R' via OpenPnP wrote:
[...]
> Since some of the GUI is more disturbing. How do you call that in
> english "Work flow"?
> The Blue Move and Red Ref, button right next to each other have already
> cost me nerves and that the Singe Move button is a debug step :(
>
Don't worry, you'll get more familiar when you use it. Just carefully
> english "Work flow"?
> The Blue Move and Red Ref, button right next to each other have already
> cost me nerves and that the Singe Move button is a debug step :(
>
make the configuration then nothing bad shall happen.
Yes, the work flow is different compared to the Chinese software.
However, according to the videos I've see, it more like other software.
So it might be rather the Chinese who did it different. Anyhow, as Mark
said, OpenPnp is open source and any contribution is welcome.
> I had read somewhere that you wanted to do something against the drag
> pin hang ?
> That never happened with the original software.
>
> Should not there be a slight "circling" introduced when the drag pin hangs ?
>
such a workaround. With proper setup (good coordinates) it's - mostly -
not needed and if it is, the interlock feature will prevent you from
breaking the pin. (I once had a tape where either the tape was jittering
in the feeder or where the holes where jittering with respect to the
edge. There I had to retune the y locations of the final drag move every
few meters) With vision correction in the ReferencePushPullFeeder this
is hopefully not needed anymore.
> That would be the icing on the cake :)
>
> I have unfortunately 0 idea of GCode :(
>
to drive something like a spiral and stop once the dragpin released
signal gets asserted. This is probably something that could be best done
in the controller.
Jan
> <https://groups.google.com/d/msgid/openpnp/b219e710-7a4d-4a02-8d7b-9201f6d98472n%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/13cbb74c-7ffd-46a1-819a-126b90747b1dn%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/13cbb74c-7ffd-46a1-819a-126b90747b1dn%40googlegroups.com?utm_medium=email&utm_source=footer>.
Thorsten.R
Jul 13, 2022, 4:45:09 PM7/13/22
to OpenPnP
Jan schrieb am Mittwoch, 13. Juli 2022 um 22:31:14 UTC+2:
Hi Thorsten!
On 13.07.2022 14:04, 'Thorsten.R' via OpenPnP wrote:
[...]
> Since some of the GUI is more disturbing. How do you call that in
> english "Work flow"?
> The Blue Move and Red Ref, button right next to each other have already
> cost me nerves and that the Singe Move button is a debug step :(
>
Don't worry, you'll get more familiar when you use it. Just carefully
make the configuration then nothing bad shall happen.
Yes, the work flow is different compared to the Chinese software.
However, according to the videos I've see, it more like other software.
So it might be rather the Chinese who did it different. Anyhow, as Mark
said, OpenPnp is open source and any contribution is welcome.
True you get used to everything :)
> I had read somewhere that you wanted to do something against the drag
> pin hang ?
> That never happened with the original software.
>
> Should not there be a slight "circling" introduced when the drag pin hangs ?
>
Yes, I've read that somewhere too. No, I never intended to implement
such a workaround. With proper setup (good coordinates) it's - mostly -
not needed and if it is, the interlock feature will prevent you from
breaking the pin. (I once had a tape where either the tape was jittering
in the feeder or where the holes where jittering with respect to the
edge. There I had to retune the y locations of the final drag move every
few meters) With vision correction in the ReferencePushPullFeeder this
is hopefully not needed anymore.
Then it was someone else but it would be nice.
It also happens only with the thin plastic tapes.
Sometimes after 50 feeds then again after 500 feeds.
This just never happened in the original FW.
Will immediately load the new test version and try further.
It also happens only with the thin plastic tapes.
Sometimes after 50 feeds then again after 500 feeds.
This just never happened in the original FW.
Will immediately load the new test version and try further.
Mark has again presented beautiful things. :)
> That would be the icing on the cake :)
>
> I have unfortunately 0 idea of GCode :(
>
I'm not sure if this can be implemented just with some GCode. You'd have
to drive something like a spiral and stop once the dragpin released
signal gets asserted. This is probably something that could be best done
in the controller.
It is certainly easier there ?
Jan
Jul 13, 2022, 4:45:56 PM7/13/22
to ope...@googlegroups.com
Hi Mark!
On 13.07.2022 15:14, mark maker wrote:
> Hi Jan,
>
> could you please post some screenshots of the finished
> ReferencePushPullFeeder setup?
>
> Or even add it to a new Wiki page, perhaps linked from these pages:
>
> https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder
>
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
>
Yes, I will. Probably next week (vacation is getting closer and a large
job has to be done before...) I guess especially the combined drag and
peel move setup shall be well documented for others to copy. I'll try that.
> /> backoff has to be calculated manually as part of the inner drag move
> //location /
>
> Could you elaborate, please?
> I'd love to! The goal of the drag move is to leave the tape where it
started, just shifted by part pitch. The drag pin's diameter is smaller
then the hole diameter. So there is some play when the drap pin is
lowered into the hole. To compensate for this play, the drag move is a
little longer then the part pitch (about 0.2..0.4mm depending on the
type of tape and the speed of the drag move). Finally the drag pin has
to be moved backwards a little bit (~0.25mm) until it can safely be
lifted off the hole using its spring. The extra distance of the drag
move is what I called "backoff" because - iirc - its the name used on
the GUI of the ReferenceDragFeeeder.
When I setup a feeder, I copy the hole positions to the drag move
positions (Side note: it would be perfect, if a special copy/past could
be used to copy X and Y at once), increment the start coordinate by some
holes (the drag pin uses different holes then the vision is looking at)
and then calculate the actual move by adding the part pitch and backoff
distance. Luckily the feeder X locations (direction of tape) are
forgiving. You can round them to ~0.1mm or even 1mm which greatly
simplifies the calculations required.
Jan
>> <https://groups.google.com/d/msgid/openpnp/13cbb74c-7ffd-46a1-819a-126b90747b1dn%40googlegroups.com?utm_medium=email&utm_source=footer>.
> <https://groups.google.com/d/msgid/openpnp/569f868f-aa65-8cfa-b211-2dbd2805e366%40makr.zone?utm_medium=email&utm_source=footer>.
On 13.07.2022 15:14, mark maker wrote:
> Hi Jan,
>
> could you please post some screenshots of the finished
> ReferencePushPullFeeder setup?
>
> Or even add it to a new Wiki page, perhaps linked from these pages:
>
> https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder
>
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
>
job has to be done before...) I guess especially the combined drag and
peel move setup shall be well documented for others to copy. I'll try that.
> /> backoff has to be calculated manually as part of the inner drag move
> //location /
>
> Could you elaborate, please?
> I'd love to! The goal of the drag move is to leave the tape where it
started, just shifted by part pitch. The drag pin's diameter is smaller
then the hole diameter. So there is some play when the drap pin is
lowered into the hole. To compensate for this play, the drag move is a
little longer then the part pitch (about 0.2..0.4mm depending on the
type of tape and the speed of the drag move). Finally the drag pin has
to be moved backwards a little bit (~0.25mm) until it can safely be
lifted off the hole using its spring. The extra distance of the drag
move is what I called "backoff" because - iirc - its the name used on
the GUI of the ReferenceDragFeeeder.
When I setup a feeder, I copy the hole positions to the drag move
positions (Side note: it would be perfect, if a special copy/past could
be used to copy X and Y at once), increment the start coordinate by some
holes (the drag pin uses different holes then the vision is looking at)
and then calculate the actual move by adding the part pitch and backoff
distance. Luckily the feeder X locations (direction of tape) are
forgiving. You can round them to ~0.1mm or even 1mm which greatly
simplifies the calculations required.
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/569f868f-aa65-8cfa-b211-2dbd2805e366%40makr.zone
> --
> 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/569f868f-aa65-8cfa-b211-2dbd2805e366%40makr.zone?utm_medium=email&utm_source=footer>.
Jan
Jul 14, 2022, 12:01:52 AM7/14/22
to ope...@googlegroups.com
Hi Micael!
Here are some preliminary screenshots from my setup of Feeder 1:
- I've disabled vision corrections (setup was done before Mark added the
ability to fix the Y coordinates) To use it, I'll configure "Calibration
Trigger" to UntilConfident or OnEachTapeFeed and disable "Vision
Calibrate?" for X. Then one probably has to tune the pipeline to handle
the reflections from shiny cover of the feeder and holes being detected
left of the cover (at least with my fov). (I'd not be surprised if
vision correction works, but feeders run better without it...)
- There may be a setup error for the rotation: today I'd try to run with
rotation of end location set to 0. The peel-move is only needed on the
main drag move, which happens while going from Start to Mid 3.
("Additive" suggests that there shall be nothing added between Mid 3 and
End anymore)
- You might have to tune the backoff distance (the difference between
Mid 3 and End X Location) for the drag pin to safely release. (I need
0.2..0.4mm depending on tape and drag speed)
- Please note, that the holes used for dragging are 3 holes (12mm) right
of the first visible hole. I'd recommend not to use the holes close to
the pick location because a) the space is limited to 4 or maybe 8mm drag
moves, b) the floor is not deep enough so that the need hits the ground
and c) the machine would run slower because it would have to move farther.
- I'm using reduced precision in the MOVE_TO_COMMAND to fasten the
transfer speed on the serial link. Be aware that when you drive super
slow, this could result in zero speed being send to the controller which
in turn would result in a timeout error.
- I don't remember how the peeler axis is linked to the feeder. It seems
there is no dedicated selection for the axis to use. So this setup might
probably not work on the 48VB's second side.
Jan
> <https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder>
>
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA>
>
> /> backoff has to be calculated manually as part of the inner drag
> move //location /
>> <https://groups.google.com/d/msgid/openpnp/b219e710-7a4d-4a02-8d7b-9201f6d98472n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/948e0fb5-b744-4102-8b60-d175796bf036n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Here are some preliminary screenshots from my setup of Feeder 1:
- I've disabled vision corrections (setup was done before Mark added the
ability to fix the Y coordinates) To use it, I'll configure "Calibration
Trigger" to UntilConfident or OnEachTapeFeed and disable "Vision
Calibrate?" for X. Then one probably has to tune the pipeline to handle
the reflections from shiny cover of the feeder and holes being detected
left of the cover (at least with my fov). (I'd not be surprised if
vision correction works, but feeders run better without it...)
- There may be a setup error for the rotation: today I'd try to run with
rotation of end location set to 0. The peel-move is only needed on the
main drag move, which happens while going from Start to Mid 3.
("Additive" suggests that there shall be nothing added between Mid 3 and
End anymore)
- You might have to tune the backoff distance (the difference between
Mid 3 and End X Location) for the drag pin to safely release. (I need
0.2..0.4mm depending on tape and drag speed)
- Please note, that the holes used for dragging are 3 holes (12mm) right
of the first visible hole. I'd recommend not to use the holes close to
the pick location because a) the space is limited to 4 or maybe 8mm drag
moves, b) the floor is not deep enough so that the need hits the ground
and c) the machine would run slower because it would have to move farther.
- I'm using reduced precision in the MOVE_TO_COMMAND to fasten the
transfer speed on the serial link. Be aware that when you drive super
slow, this could result in zero speed being send to the controller which
in turn would result in a timeout error.
- I don't remember how the peeler axis is linked to the feeder. It seems
there is no dedicated selection for the axis to use. So this setup might
probably not work on the 48VB's second side.
Jan
>
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA>
>
> /> backoff has to be calculated manually as part of the inner drag
> move //location /
>> <https://groups.google.com/d/msgid/openpnp/b219e710-7a4d-4a02-8d7b-9201f6d98472n%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/13cbb74c-7ffd-46a1-819a-126b90747b1dn%40googlegroups.com
>> <https://groups.google.com/d/msgid/openpnp/13cbb74c-7ffd-46a1-819a-126b90747b1dn%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/13cbb74c-7ffd-46a1-819a-126b90747b1dn%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/openpnp/948e0fb5-b744-4102-8b60-d175796bf036n%40googlegroups.com
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/948e0fb5-b744-4102-8b60-d175796bf036n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Jan
Jul 14, 2022, 12:06:46 AM7/14/22
to ope...@googlegroups.com
Hi Mark!
On 13.07.2022 17:23, vespaman wrote:
minor glitch on the Motion tabs GUI. If the window space gets narrow,
the scroll bar appears to early, suggesting that the GUI requires some
blank space right of the capture buttons.
Jan
On 13.07.2022 17:23, vespaman wrote:
> Some screenshots would be super useful! I am kind of stuck, just because
> there are so many options.. :)
>
While taking the preliminary screenshots I noticed, that there is a
> there are so many options.. :)
>
minor glitch on the Motion tabs GUI. If the window space gets narrow,
the scroll bar appears to early, suggesting that the GUI requires some
blank space right of the capture buttons.
Jan
mark maker
Jul 14, 2022, 2:00:05 AM7/14/22
to ope...@googlegroups.com
Hi Jan,
thanks!
I'm taking the occasion to profess that trying to instruct other
people effectively, is very, very difficult. I struggle with it
every mail I write here, every snippet of text in the Wiki, and
in a foreign language. It takes a lot of effort and time,
and yes, there is a learning curve, and still I know, I fail at
times. I just wanted to express this here, in the sense that there
is no shame in not getting it right immediately.
I'm very grateful for your help, and I can really use it, so please take the following positively 😁, just as some well-intended constructive criticism. 😇
> I've disabled vision corrections (setup was done before Mark added the ability to fix the Y coordinates) To use it, I'll configure "Calibration Trigger" to UntilConfident or OnEachTapeFeed and disable "Vision Calibrate?" for X.
This should really be shown on the screenshot. It is even more confusing for newcomers to have the explanation not match the screenshot. Take your time! If vacation comes first, so be it.
> Then one probably has to tune the pipeline to handle the reflections from shiny cover of the feeder and holes being detected left of the cover (at least with my fov). (I'd not be surprised if vision correction works, but feeders run better without it...)
It should not be needed. Have you already tried using the Circular Symmetry pipeline?
https://github.com/openpnp/openpnp/wiki/DetectCircularSymmetry#referencepushpullfeeder
> - There may be a setup error for the rotation: today I'd try to run with rotation of end location set to 0. The peel-move is only needed on the main drag move, which happens while going from Start to Mid 3. ("Additive" suggests that there shall be nothing added between Mid 3 and End anymore)
Again, it is better to figure this out, before increasing the
confusion even more. Imagine the big question marks popping up
above the other users' heads.
>- I'm using reduced precision in the MOVE_TO_COMMAND to fasten the transfer speed on the serial link. Be aware that when you drive super slow, this could result in zero speed being send to the controller which in turn would result in a timeout error.
This should only affect your particular G-code setup
(and we should do something against it). It is a different topic
and should not be mixed in here.
> - I don't remember how the peeler axis is linked to the feeder. It seems there is no dedicated selection for the axis to use. So this setup might probably not work on the 48VB's second side.
It is explained here:
https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder#coordinated-peeling
you have to create two Actuators and assign the corresponding axis there. In fact that is a problem for easy feeder cloning EAST ↔ WEST. I'll think about that.
> The goal of the drag move is to leave the tape where it started, just shifted by part pitch. The drag pin's diameter is smaller then the hole diameter. So there is some play when the drap pin is lowered into the hole. ...
I understand all that, and how hard it probably was to figure out the best configuration. But once you get it right, isn't it the same for all feeders? Can't you make the play good enough for all of them? Does feeder cloning work for you, or not?
Remember: The push-pull feeder is taking a vision calibration after the feed/drag, so it will look how far precisely the tape was transported, any difference between tapes (how much they give against the drag pin etc.) is compensated. After we introduced the "Vision Calibrate?" axis switches (thank you for that idea), this should really nail it. Does it not?
_Mark
Jan
Jul 14, 2022, 4:05:37 AM7/14/22
to ope...@googlegroups.com
Hi Mark!
You're right, I missed to publish my drag pin configuration. Please
find it attached.
Just for reference: the setup I posted is fully working with my
firmware (peeler has to be configured as axis). It's just not taking
advantage of the new vision features because they where not available
back when I configured the feeders. I'll reconfigured my feeders with
vision and then report and publish the new configuration.
Jan
On 14.07.2022 08:00, mark maker wrote:
> Hi Jan,
>
> thanks!
>
> I'm taking the occasion to profess that trying to instruct other people
> effectively, is very, very difficult. I struggle with it every mail I
> write here, every snippet of text in the Wiki, /and in a foreign
> language/. It takes a lot of effort and time, and yes, there is a
>
> This should really be shown on the screenshot. It is even /more
> /confusing for newcomers to have the explanation not match the
> screenshot. Take your time! If vacation comes first, /so be it./
>
> /> Then one probably has to tune the pipeline to handle the reflections
>
> This should only affect /your /particular G-code setup (and we should do
> *the feed/drag, so it will look how far precisely the tape was
> https://groups.google.com/d/msgid/openpnp/7773340d-aa44-692e-3e1f-90626ee26c73%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/7773340d-aa44-692e-3e1f-90626ee26c73%40makr.zone?utm_medium=email&utm_source=footer>.
You're right, I missed to publish my drag pin configuration. Please
find it attached.
Just for reference: the setup I posted is fully working with my
firmware (peeler has to be configured as axis). It's just not taking
advantage of the new vision features because they where not available
back when I configured the feeders. I'll reconfigured my feeders with
vision and then report and publish the new configuration.
Jan
On 14.07.2022 08:00, mark maker wrote:
> Hi Jan,
>
> thanks!
>
> I'm taking the occasion to profess that trying to instruct other people
> effectively, is very, very difficult. I struggle with it every mail I
> language/. It takes a lot of effort and time, and yes, there is a
> learning curve, and still I know, I fail at times. I just wanted to
> express this here, in the sense that there is no shame in not getting it
> right immediately.
>
> I'm very grateful for your help, *and I can really use it,* so please
> express this here, in the sense that there is no shame in not getting it
> right immediately.
>
> take the following positively 😁, just as some well-intended
> constructive criticism. 😇
>
> /> I've disabled vision corrections (setup was done before Mark added
> constructive criticism. 😇
>
> the ability to fix the Y coordinates) To use it, I'll configure
> "Calibration Trigger" to UntilConfident or OnEachTapeFeed and disable
> "Vision Calibrate?" for X./
> "Calibration Trigger" to UntilConfident or OnEachTapeFeed and disable
>
> This should really be shown on the screenshot. It is even /more
> /confusing for newcomers to have the explanation not match the
> screenshot. Take your time! If vacation comes first, /so be it./
>
> /> Then one probably has to tune the pipeline to handle the reflections
> from shiny cover of the feeder and holes being detected left of the
> cover (at least with my fov). (I'd not be surprised if vision correction
> works, but feeders run better without it...) /
> cover (at least with my fov). (I'd not be surprised if vision correction
>
> It should not be needed. Have you already tried using the Circular
> Symmetry pipeline?
>
> https://github.com/openpnp/openpnp/wiki/DetectCircularSymmetry#referencepushpullfeeder
>
> /> - There may be a setup error for the rotation: today I'd try to run
> It should not be needed. Have you already tried using the Circular
> Symmetry pipeline?
>
> https://github.com/openpnp/openpnp/wiki/DetectCircularSymmetry#referencepushpullfeeder
>
> with rotation of end location set to 0. The peel-move is only needed on
> the main drag move, which happens while going from Start to Mid 3.
> ("Additive" suggests that there shall be nothing added between Mid 3 and
> End anymore) /
> the main drag move, which happens while going from Start to Mid 3.
> ("Additive" suggests that there shall be nothing added between Mid 3 and
>
> Again, it is better to figure this out, before increasing the confusion
> even more. Imagine the big question marks popping up above the other
> users' heads.
>
> />- I'm using reduced precision in the MOVE_TO_COMMAND to fasten the
> Again, it is better to figure this out, before increasing the confusion
> even more. Imagine the big question marks popping up above the other
> users' heads.
>
> transfer speed on the serial link. Be aware that when you drive super
> slow, this could result in zero speed being send to the controller which
> in turn would result in a timeout error. /
> slow, this could result in zero speed being send to the controller which
>
> This should only affect /your /particular G-code setup (and we should do
> something against it). It is a different topic and should not be mixed
> in here.
>
> /> //- I don't remember how the peeler axis is linked to the feeder. It
> in here.
>
> seems there is no dedicated selection for the axis to use. So this setup
> might probably not work on the 48VB's second side. /
>
> It is explained here:
>
> https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder#coordinated-peeling
>
> you have to create *two *Actuators and assign the corresponding axis
> It is explained here:
>
> https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder#coordinated-peeling
>
> there. In fact that is a problem for easy feeder cloning EAST ↔ WEST.
> I'll think about that.
>
> /> //The goal of the drag move is to leave the tape where it //started,
> I'll think about that.
>
> just shifted by part pitch. The drag pin's diameter is smaller then the
> hole diameter. So there is some play when the drap pin is lowered into
> the hole. .../
> hole diameter. So there is some play when the drap pin is lowered into
>
> I understand all that, and how hard it probably was to figure out the
> best configuration. But once you get it right, isn't it the same for all
> feeders? Can't you make the play good enough for all of them? Does
> feeder cloning work for you, or not?
>
> Remember: The push-pull feeder is taking a vision calibration *after
> I understand all that, and how hard it probably was to figure out the
> best configuration. But once you get it right, isn't it the same for all
> feeders? Can't you make the play good enough for all of them? Does
> feeder cloning work for you, or not?
>
> *the feed/drag, so it will look how far precisely the tape was
> <https://groups.google.com/d/msgid/openpnp/7773340d-aa44-692e-3e1f-90626ee26c73%40makr.zone?utm_medium=email&utm_source=footer>.
vespaman
Jul 14, 2022, 4:09:48 AM7/14/22
to OpenPnP
Hi Jan,
I'm sorry that I am so slow, and I understand you are too busy to respond right now, but I think I need to get the basics right..
- Please note, that the holes used for dragging are 3 holes (12mm) right
of the first visible hole. I'd recommend not to use the holes close to
the pick location because a) the space is limited to 4 or maybe 8mm drag
moves, b) the floor is not deep enough so that the need hits the ground
and c) the machine would run slower because it would have to move farther.
Oookay. Now I think I understand something..
The Hole 1 location and the Hole 2 location are not at all related to the actual feed location?
That would explain a lot. Something like this;
- I don't remember how the peeler axis is linked to the feeder. It seems
there is no dedicated selection for the axis to use. So this setup might
probably not work on the 48VB's second side.
That's fine, once I get close the the right hand side feeders, and I am still as clueless as I am now, I will probably ask again. ;-)
- Micael
Jan
Jul 14, 2022, 4:21:15 AM7/14/22
to ope...@googlegroups.com
Hi Micael!
On 13.07.2022 17:23, vespaman wrote:
[...]
initially to Marks all 3d printed feeder
(https://makr.zone/tag/feeder/). We're just reusing it for our drag
feeders to take advantage of the vision correction (of the Y coordinate
only), the ability to make the peel move in parallel with the drag move
and the ability to clone them. I consider this a major advantage over
the ReferenceDragFeeder, which we could also use and which is a little
bit easier to setup. However, setup has to be done once, reliable and
fast operation about 100 times.
I'd encourage you to try both so you can find out which one suites you
better. (IIRC I mentioned in the Wiki, that one shall create multiple
bootlean peeler actuators with different GCode, one for each part pitch
that needs to be peeled, for efficient peeling when using the
ReferenceDragFeeder.)
Jan
> onsdag 13 juli 2022 kl. 15:14:14 UTC+2 skrev ma...@makr.zone:
>
> Hi Jan,
>
> could you please post some screenshots of the finished
> ReferencePushPullFeeder setup?
>
> Or even add it to a new Wiki page, perhaps linked from these pages:
>
> https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder
> move //location /
>> <https://groups.google.com/d/msgid/openpnp/b219e710-7a4d-4a02-8d7b-9201f6d98472n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/948e0fb5-b744-4102-8b60-d175796bf036n%40googlegroups.com?utm_medium=email&utm_source=footer>.
On 13.07.2022 17:23, vespaman wrote:
> Especially perhaps also the "Push-Pull Motion" tab - why is there no
> correlation here from the first tab? Should not the pick location and
> the drag feeder be used as an input to start and stop? Now when I write
> this, I understand why, (because drag pin is a maybe mostly a CHMT
> thing?!). In this case; if/once the feed actuator is set to DRAGPIN,
> could maybe calculated values be populated from the drag pin offsets?
> (Or maybe that is too much work for a small proportion of users)
> Or probably I am misunderstanding the hole Push-Pull Motion tab and you
> should disregard this! :)
>
The ReferencePushPullFeeder is a multi-purpose feeder which was tuned
> correlation here from the first tab? Should not the pick location and
> the drag feeder be used as an input to start and stop? Now when I write
> this, I understand why, (because drag pin is a maybe mostly a CHMT
> thing?!). In this case; if/once the feed actuator is set to DRAGPIN,
> could maybe calculated values be populated from the drag pin offsets?
> (Or maybe that is too much work for a small proportion of users)
> Or probably I am misunderstanding the hole Push-Pull Motion tab and you
> should disregard this! :)
>
initially to Marks all 3d printed feeder
(https://makr.zone/tag/feeder/). We're just reusing it for our drag
feeders to take advantage of the vision correction (of the Y coordinate
only), the ability to make the peel move in parallel with the drag move
and the ability to clone them. I consider this a major advantage over
the ReferenceDragFeeder, which we could also use and which is a little
bit easier to setup. However, setup has to be done once, reliable and
fast operation about 100 times.
I'd encourage you to try both so you can find out which one suites you
better. (IIRC I mentioned in the Wiki, that one shall create multiple
bootlean peeler actuators with different GCode, one for each part pitch
that needs to be peeled, for efficient peeling when using the
ReferenceDragFeeder.)
Jan
> onsdag 13 juli 2022 kl. 15:14:14 UTC+2 skrev ma...@makr.zone:
>
> Hi Jan,
>
> could you please post some screenshots of the finished
> ReferencePushPullFeeder setup?
>
> Or even add it to a new Wiki page, perhaps linked from these pages:
>
> https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder
> <https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder>
>
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA>
>
> /> backoff has to be calculated manually as part of the inner drag
>
> https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA
> <https://github.com/openpnp/openpnp/wiki/CharmHigh-CHMT36VA>
>
> move //location /
>> <https://groups.google.com/d/msgid/openpnp/b219e710-7a4d-4a02-8d7b-9201f6d98472n%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/13cbb74c-7ffd-46a1-819a-126b90747b1dn%40googlegroups.com
>> <https://groups.google.com/d/msgid/openpnp/13cbb74c-7ffd-46a1-819a-126b90747b1dn%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/13cbb74c-7ffd-46a1-819a-126b90747b1dn%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/openpnp/948e0fb5-b744-4102-8b60-d175796bf036n%40googlegroups.com
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/openpnp/948e0fb5-b744-4102-8b60-d175796bf036n%40googlegroups.com?utm_medium=email&utm_source=footer>.
mark maker
Jul 14, 2022, 4:34:35 AM7/14/22
to ope...@googlegroups.com
Nice image!
If it is correct, it should go to the Wiki 😎
--
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/66d6f471-679f-4b3d-83bd-e5c7950c9efcn%40googlegroups.com.
vespaman
Jul 14, 2022, 4:38:53 AM7/14/22
to OpenPnP
Hi again Jan,
Yes, I understand that the history of referencePushPullFeeder, but I also see that there's a lot of enhancements with this code in many ways.
I used your machine.xml, where there are two examples of peeler actuators (one called '12' IIRC) which is a great start!
Maybe I should test the referenceDragpinFeeder a bit again, just to get the hang of it.
I really would love to do my first pick and place, even of one component.. :)
> />- I'm using reduced precision in the MOVE_TO_COMMAND to fasten the
> transfer speed on the serial link. Be aware that when you drive super
> slow, this could result in zero speed being send to the controller which
> in turn would result in a timeout error. / > slow, this could result in zero speed being send to the controller which
Since I am running my CHMT at around 1mbit serial speed, the above might not be necessary for me?
Cheers,
Micael
Jan
Jul 14, 2022, 4:58:22 AM7/14/22
to ope...@googlegroups.com
On 14.07.2022 10:38, vespaman wrote:
[...]
"C"-axis for the peeler already in. Everything else is just playing
around trying to optimize things. (The default serial link has no
hardware flow control and therefore requires "Confirmation Flow
Control?" to be enabled. This generates some extra task switches and
synchronization requirements in the GCode-Driver. To minimize the time
required to send a command, I reduced the precision to the physical
limit of the motor/controller, e.g. my X axis is configured with a
resolution of 1/32mm hence sending coordinates better then 10e-2 does
not result in any advantage. For a typical 100mm position I'm now
sending 6 characters using %.2f instead of 8 using the default %.4f,
which is a relevant gain in speed for a 115.2kbaud serial link, I think.)
Jan
[...]
>> />- I'm using reduced precision in the MOVE_TO_COMMAND to fasten the
>> transfer speed on the serial link. Be aware that when you drive super
>> slow, this could result in zero speed being send to the controller which
>> in turn would result in a timeout error. /
>
> Since I am running my CHMT at around 1mbit serial speed, the above might
> not be necessary for me?
>
The machine runs fine with the I&S suggested default. It even has the
>> transfer speed on the serial link. Be aware that when you drive super
>> slow, this could result in zero speed being send to the controller which
>> in turn would result in a timeout error. /
>
> Since I am running my CHMT at around 1mbit serial speed, the above might
> not be necessary for me?
>
"C"-axis for the peeler already in. Everything else is just playing
around trying to optimize things. (The default serial link has no
hardware flow control and therefore requires "Confirmation Flow
Control?" to be enabled. This generates some extra task switches and
synchronization requirements in the GCode-Driver. To minimize the time
required to send a command, I reduced the precision to the physical
limit of the motor/controller, e.g. my X axis is configured with a
resolution of 1/32mm hence sending coordinates better then 10e-2 does
not result in any advantage. For a typical 100mm position I'm now
sending 6 characters using %.2f instead of 8 using the default %.4f,
which is a relevant gain in speed for a 115.2kbaud serial link, I think.)
Jan
vespaman
Jul 14, 2022, 5:03:17 AM7/14/22
to OpenPnP
Mark,
I fear it is not correct. But maybe this one is! :) Hope Jan can set me straight once again!
mark maker
Jul 14, 2022, 5:10:14 AM7/14/22
to ope...@googlegroups.com
> For a typical 100mm position I'm now sending 6 characters
using %.2f instead of 8 using the default %.4f, which is a
relevant gain in speed for a 115.2kbaud serial link, I think.)
Jan, have you actually measured a difference? Aren't the required hand-shakes absolutely dominant?
_Mark
Jan
Jul 14, 2022, 5:21:07 AM7/14/22
to ope...@googlegroups.com
On 14.07.2022 10:09, vespaman wrote:
> Hi Jan,
>
> I'm sorry that I am so slow, and I understand you are too busy to
> respond right now, but I think I need to get the basics right..
>
> - Please note, that the holes used for dragging are 3 holes (12mm)
> right
> of the first visible hole. I'd recommend not to use the holes close to
> the pick location because a) the space is limited to 4 or maybe 8mm
> drag
> moves, b) the floor is not deep enough so that the need hits the ground
> and c) the machine would run slower because it would have to move
> farther.
>
>
> Oookay. Now I think I understand something..
> The Hole 1 location and the Hole 2 location are not at all related to
> the actual feed location?
> That would explain a lot. Something like this;
>
> PickFeed.jpg
> Hi Jan,
>
> I'm sorry that I am so slow, and I understand you are too busy to
> respond right now, but I think I need to get the basics right..
>
> - Please note, that the holes used for dragging are 3 holes (12mm)
> right
> of the first visible hole. I'd recommend not to use the holes close to
> the pick location because a) the space is limited to 4 or maybe 8mm
> drag
> moves, b) the floor is not deep enough so that the need hits the ground
> and c) the machine would run slower because it would have to move
> farther.
>
>
> Oookay. Now I think I understand something..
> The Hole 1 location and the Hole 2 location are not at all related to
> the actual feed location?
> That would explain a lot. Something like this;
>
>
I agree with Mark, this should definite be part of the wiki.
I suggest to use the hole you marked as "Drag Hole" as the drag move
start location. Using the "Hole 1" is possible (I've done that) but not
recommended: you a) get "acoustic feedback" that your setup is good when
the needle hits the bottom, b) the dimensions of the feeder cover are
not precise on my machine which made the drag pin hit the cover on the
left and/or upper side on some feeders, where it got stuck (failed to
release) and c) the space is limited to 4mm drag moves. At "Drag Hole"
you have 8mm for 8mm feeders and 12mm for larger feeders.
> - I don't remember how the peeler axis is linked to the feeder. It seems
>
> there is no dedicated selection for the axis to use. So this setup
> might
> probably not work on the 48VB's second side.
>
>
> That's fine, once I get close the the right hand side feeders, and I am
> still as clueless as I am now, I will probably ask again. ;-)
think, your right hand side should work immediately as the two peelers
seem to share the same motor driver (according to a recent post in the
PnP group, which now seems to be not available anymore). If they don't,
you'd probably need to update the firmware so you can access the right
hand side peeler as addition (D?) axis. Then I'd clone the dragpin and
assign it the new peeler axis. Now you have two drag pin actuators,
accessing physically the one drag pin with just different rotation axis.
(Don't forget to update the MOVE_TO_COMMAND and
SET_GLOBAL_OFFSETS_COMMAND for the new axis letter.)
Jan
Jan
Jul 14, 2022, 5:37:26 AM7/14/22
to ope...@googlegroups.com
Hi Mark!
On 14.07.2022 11:10, mark maker wrote:
> /> For a typical 100mm position I'm now sending 6 characters using %.2f
>
> Jan, have you actually /measured /a difference? Aren't the required
> hand-shakes absolutely dominant?
>
No, I did not yet measured the overall timing. I have it on the list,
because I'd like to add hardware handshake (just the "Receive Buffer Is
Full" wire from controller to PC) to let the communication run
asynchronously. However, I need a reproducible sequence to test with,
which I current don't have.
Jan
> Am 14.07.2022 um 10:58 schrieb 'Jan' via OpenPnP:
>> For a typical 100mm position I'm now sending 6 characters using %.2f
>> instead of 8 using the default %.4f, which is a relevant gain in speed
>> for a 115.2kbaud serial link, I think.)
>
> <https://groups.google.com/d/msgid/openpnp/d3016c30-b99f-a94d-9343-aa04141fa54d%40makr.zone?utm_medium=email&utm_source=footer>.
On 14.07.2022 11:10, mark maker wrote:
> /> For a typical 100mm position I'm now sending 6 characters using %.2f
> instead of 8 using the default %.4f, which is a relevant gain in speed
> for a 115.2kbaud serial link, I think.) /
>
> Jan, have you actually /measured /a difference? Aren't the required
> hand-shakes absolutely dominant?
>
No, I did not yet measured the overall timing. I have it on the list,
because I'd like to add hardware handshake (just the "Receive Buffer Is
Full" wire from controller to PC) to let the communication run
asynchronously. However, I need a reproducible sequence to test with,
which I current don't have.
Jan
> Am 14.07.2022 um 10:58 schrieb 'Jan' via OpenPnP:
>> For a typical 100mm position I'm now sending 6 characters using %.2f
>> instead of 8 using the default %.4f, which is a relevant gain in speed
>> for a 115.2kbaud serial link, I think.)
>
> --
> 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/d3016c30-b99f-a94d-9343-aa04141fa54d%40makr.zone
> 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/d3016c30-b99f-a94d-9343-aa04141fa54d%40makr.zone?utm_medium=email&utm_source=footer>.
Jan
Jul 14, 2022, 5:41:36 AM7/14/22
to ope...@googlegroups.com
On 14.07.2022 11:03, vespaman wrote:
> Mark,
>
> I fear it is not correct. But maybe this one is! :) Hope Jan can set me
> straight once again!
>
The first (other) version is correct. The pick location is in the middle
of the two holes. This is difficult for 2mm pitch parts, but obvious for
all other pitches.
Jan
> torsdag 14 juli 2022 kl. 10:34:35 UTC+2 skrev ma...@makr.zone:
>
> Nice image!
>
> If it is correct, it should go to the Wiki 😎
>
> Am 14.07.2022 um 10:09 schrieb vespaman:
>> Hi Jan,
>>
>> I'm sorry that I am so slow, and I understand you are too busy to
>> respond right now, but I think I need to get the basics right..
>>
>> - Please note, that the holes used for dragging are 3 holes
>> (12mm) right
>> of the first visible hole. I'd recommend not to use the holes
>> close to
>> the pick location because a) the space is limited to 4 or
>> maybe 8mm drag
>> moves, b) the floor is not deep enough so that the need hits
>> the ground
>> and c) the machine would run slower because it would have to
>> move farther.
>>
>>
>> Oookay. Now I think I understand something..
>> The Hole 1 location and the Hole 2 location are not at all related
>> to the actual feed location?
>> That would explain a lot. Something like this;
>>
>> PickFeed.jpg
>>
>>
>>
>>
>>
>>
>> - I don't remember how the peeler axis is linked to the feeder.
>> It seems
>>
>> there is no dedicated selection for the axis to use. So this
>> setup might
>> probably not work on the 48VB's second side.
>>
>>
>> That's fine, once I get close the the right hand side feeders, and
>> I am still as clueless as I am now, I will probably ask again. ;-)
>> - Micael
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "OpenPnP" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to openpnp+u...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/openpnp/66d6f471-679f-4b3d-83bd-e5c7950c9efcn%40googlegroups.com
>> <https://groups.google.com/d/msgid/openpnp/66d6f471-679f-4b3d-83bd-e5c7950c9efcn%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>
>>
>>
>>
>>
>>
>> - I don't remember how the peeler axis is linked to the feeder.
>> It seems
>>
>> there is no dedicated selection for the axis to use. So this
>> setup might
>> probably not work on the 48VB's second side.
>>
>>
>> That's fine, once I get close the the right hand side feeders, and
>> I am still as clueless as I am now, I will probably ask again. ;-)
>> - Micael
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "OpenPnP" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to openpnp+u...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/openpnp/66d6f471-679f-4b3d-83bd-e5c7950c9efcn%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/openpnp/d79048b5-5445-421e-b012-e98c98efccebn%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/d79048b5-5445-421e-b012-e98c98efccebn%40googlegroups.com?utm_medium=email&utm_source=footer>.
mark maker
Jul 14, 2022, 6:00:00 AM7/14/22
to ope...@googlegroups.com
Yes, solving it properly/electronically is king!
mark maker
Jul 14, 2022, 6:09:51 AM7/14/22
to ope...@googlegroups.com
> The pick location is in the middle of the two holes. This is difficult for 2mm pitch parts, but obvious for all other pitches.
Are you sure? I programmed it to be the closer one,
specifically because that is easier / always the same for the
user:
https://youtu.be/5QcJ2ziIJ14?t=12
The multiple pick locations will then be numbered visually:
https://youtu.be/5QcJ2ziIJ14?t=300
_Mark
Jan
Jul 14, 2022, 6:22:43 AM7/14/22
to ope...@googlegroups.com
I'm sorry, I was wrong, Mark is right. According to my screenshot I
posted earlier, I've configured the location with the same X-coordinate
as the left hole as pick location.
This is in agreement with Marks intention and in sync with the simple
rule "the pick location is the one closed to the feeder/wheel".
So, Micael, please use your second image for the Wiki.
Jan
On 14.07.2022 12:09, mark maker wrote:
> /> //The pick location is in the middle of the two holes. This is
> difficult for 2mm pitch parts, but obvious for all other pitches. /
>
> Are you sure? I programmed it to be the /closer /one, specifically
> https://groups.google.com/d/msgid/openpnp/befd3d51-593c-21dc-2b4c-4f9b369fe07b%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/befd3d51-593c-21dc-2b4c-4f9b369fe07b%40makr.zone?utm_medium=email&utm_source=footer>.
posted earlier, I've configured the location with the same X-coordinate
as the left hole as pick location.
This is in agreement with Marks intention and in sync with the simple
rule "the pick location is the one closed to the feeder/wheel".
So, Micael, please use your second image for the Wiki.
Jan
On 14.07.2022 12:09, mark maker wrote:
> /> //The pick location is in the middle of the two holes. This is
> difficult for 2mm pitch parts, but obvious for all other pitches. /
>
> Are you sure? I programmed it to be the /closer /one, specifically
> because that is easier / always the same for the user:
>
> https://youtu.be/5QcJ2ziIJ14?t=12
>
> The multiple pick locations will then be numbered visually:
>
>
> https://youtu.be/5QcJ2ziIJ14?t=12
>
> The multiple pick locations will then be numbered visually:
>
> <https://groups.google.com/d/msgid/openpnp/befd3d51-593c-21dc-2b4c-4f9b369fe07b%40makr.zone?utm_medium=email&utm_source=footer>.
vespaman
Jul 14, 2022, 6:31:35 AM7/14/22
to OpenPnP
No, I did not yet measured the overall timing. I have it on the list,
because I'd like to add hardware handshake (just the "Receive Buffer Is
Full" wire from controller to PC) to let the communication run
asynchronously. However, I need a reproducible sequence to test with,
which I current don't have.
Jan, if you want to test HW handshake & higher bitrate, you can just merge in my HW RTS/CTS code.
With it, you can select to use only CTS or only RTS, or none (as it is today), by simply configuring a pin for the respective function.
i.e. if you configure cts pin, it will use it, if you don't configure either rts or cts, no HW handshake will take place.
But, obviously, without hardware modifications, my code will in the end be useless. :)
I have based it on Chris code, and locally, I have merged most of your changes as well (if not all), but I haven't checked in those.
mark maker
Jul 14, 2022, 6:35:51 AM7/14/22
to ope...@googlegroups.com
vespaman,
does this mean that you have made these hardware modifications?
If yes, any details (photos) on these?
_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/86f98955-8332-4799-a356-e535314aa9f5n%40googlegroups.com.
vespaman
Jul 14, 2022, 6:43:55 AM7/14/22
to OpenPnP
Yes, I did them months ago, as detailed on the github page. I think I also wrote about hem in desktop pick and place forum. (but maybe also removed, since posting there was hopeless for me vs. google) :)
I have yet to do DMA, but I want to get my machine up before contiuning FW work... :)
mark maker
Jul 14, 2022, 6:48:37 AM7/14/22
to ope...@googlegroups.com
> as detailed on the github page
Sorry, where exactly?
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/422388ca-f1ad-49df-a9e2-14236709a17dn%40googlegroups.com.
vespaman
Jul 14, 2022, 6:53:59 AM7/14/22
to OpenPnP
torsdag 14 juli 2022 kl. 12:48:37 UTC+2 skrev ma...@makr.zone:
> as detailed on the github page
Sorry, where exactly?
The readme.md
It is loading more messages.
0 new messages