Trouble Connecting OpenPNP with TinyG

[John Lettang]

Hi All,

I wanted to see if I could start messing around with openPNP software a bit. I got my Liteplacer to work just fine on the liteplacer software but I wanted to see about some other opportunities with openpnp.

I am having some issues trying to set it all up, and I am not even able to get my Tinyg to be recognized by the software.

I am done with the initial set up and have my Gcode driver set to detect firmware automatically. I have double checked a couple times as well but I am using the right COM for tinyg.

The only other weird thing is that it looks like I somehow ended up with two Gcode drivers which doesn't quite make sense to me.

Also, I was mainly following the tutorial from this website: 

Openpnp with LitePlacer Pick and Place – Inductive-Kickback.com

Any help is appreciated!

[mark maker]

Hi John

you should update to the latest testing version ...

https://openpnp.org/test-downloads/

... then let yourself be guided by Issues & Solutions.

https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions

It should help you setup a Liteplacer mostly automatically. You should delete the second driver, though.

It will also guide you through many new auto-calibration steps, many have report that it has improved their machine precision a lot.

https://youtu.be/md68n_J7uto

(This video is a bit dated, there are now even more calibrations, and the ones shown have been improved)

> Also, I was mainly following the tutorial from this website: Openpnp with LitePlacer Pick and Place – Inductive-Kickback.com

From what I've just quickly seen, there's cool stuff in these scripts, but unfortunately on a rather outdated version of OpenPnP. That's a bit of a problem with scripting, you tend to be stuck on a version, because if the underlying software model changes, it breaks your scripts, with no prior warning, i.e. you'll only get the error at runtime.

There are some things that he shows with helper scripts, that were great at the time, but may no longer be needed at all.

One feature is part auto-height sensing with auto focus. If you enable it, you don't even need to set up part heights any more, they will be measured on first use.

Another new feature: on a Liteplacer you can enable Contact Probing, so feeder Z need only be set very roughly by hand or script (+/-2mm). The precise feeder height is then automatically probed on the first use. But for that, you need a feeder design, that allows contact probing, i.e. the tape bottom must be suspended on a sturdy surface, so the nozzle tip can press against it (the Liteplacer probe is not very gentle). If the tapes are only suspended on their sides, it will bounce like a trampoline and eject all parts.

Some of these features are shown here:

https://youtu.be/9uFxV1-vnXw

https://makr.zone/openpnp-nozzle-tip-changer-vision-z-calibration-part-height-sensing/653/

https://github.com/openpnp/openpnp/wiki/Contact-Probing-Nozzle

There are many more new features that make it easier, less work, more precise.

Most of all we have improved the Vision Settings system, so you don't need to copy all the settings across individual parts, but can manage them centrally in a handful of settings.

If you are interested in having less work and more importantly less mistakes in setting up feeders, look at those that can clone settings around and OCR/barcode/QR-code support to recognize the loaded part. This is especially useful for off-machine feeder preparation and mountable/storable feeders.

See here how you can get a one click per feeder setup with the PushPullFeeder:

https://youtu.be/5QcJ2ziIJ14?t=295

This is shown for the All-3D-printed feeder here, but it'll work with any form of mechanical drag/lever/push-pull or electrical feeder.

https://makr.zone/new-all-3d-printed-tapereel-feeder/399/

OCR/barcode has now also been added to the BlindsFeeder (though that part is not yet in the video):

https://youtu.be/dGde59Iv6eY

https://makr.zone/new-openpnp-blindsfeeder/353/

_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/e1f9b8b6-89ec-4110-92c2-7b05ab36b269n%40googlegroups.com.

[John Lettang]

Hi Mark,

So going through the tutorial you set out for me, I am getting stuck fairly early on. I believe that openpnp and tinyG are connected but it looks like it isn't recognizing tinyG still. I am on the test build of openpnp and everything but still had this issue. I also went ahead and reinstalled everything which fixed the double driver issue from before.

I was wondering if the version or something could be the issue with the tinyG not being recognized. I found this blog post giving a tutorial and adding more commands for better compatibility with openpnp but it of course takes flashing to the tinyG. Is this recommended by the community to do and will openpnp recognize tinyG if I do this?

Thanks for the advice,

John

[mark maker]

Hi John

Issues & Solutions should tell you, if it does not recognize the firmware (missing M115 command or unknown response). Then it should point you to the Wiki. If not, try enabling the Include dismissed? switch.

The (lower) blue [ i ] button on that issue should lead you here:

https://github.com/openpnp/openpnp/wiki/Motion-Controller-Firmwares

Does it not do that? Please report, so I can fix bugs if present.

For TinyG you need to read this:

https://github.com/openpnp/openpnp/wiki/Motion-Controller-Firmwares#tinyg

So yes, you need to flash a new firmware version if you haven't yet. Stock TinyG does not support OpenPnP well and you're missing out on better speed control:

https://youtu.be/6SBDApObbz0

It is all linked in the Wiki, which leads you to my blog, where I explain the extra TinyG commands, and how you can flash it.

Be sure to follow the guide carefully, so you can reconstruct your settings after the flashing. Unfortunately, some TinyG EEPROM settings tend to get lost.

https://makr.zone/tinyg-new-g-code-commands-for-openpnp-use/577/

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/32885fef-9497-43b0-b7e2-76c95827f55dn%40googlegroups.com.

[John Lettang]

Thank you, Mark.

I found that the error message did not point me to the wiki and was just the firmware read error I found before. Even with checking the "Include Dismissed?" Box. The Blue [i] in the lower right hand corner did lead me to the right page though.

Going into the driver terminal I wasn't getting much luck either as the $fv and $fb commands didn't return anything. However the $$ command did return all of the current settings. I will continue with trying to flash the board and see if that helps at all.

-John

[mark maker]

if I'm not mistaken, the $$ lists the $fv and $fb as well, so you have all the information. Just make sure to copy and save the information for later.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7266907c-df83-4382-a325-da0308a13d79n%40googlegroups.com.

[John Lettang]

Hi Mark,

The flash worked great and I am getting the ball rolling with issues and solutions.

I am having no issues jogging and everything is going the right direction now that I inverted the z-axis. However, whenever I choose to home the pnp it is overshooting the limit switches by a good bit. Is there a way to effect the speed and acceleration but only for homing? Or perhaps you have another way on correcting this. Apologies if this is on the wiki but I am not able to find it anywhere.

Also, this isn't a major problem but whenever I hit the reset switch I have to restart openpnp to establish communication again. Is there another way to do this? Perhaps I am missing something.

Best,

John

[tonyl...@gmail.com]

John,

> Is there a way to effect the speed and acceleration but only for homing?

OpenPnP doesn't control the homing speeds or accelerations - they are controlled by these TinyG settings instead (you need to set these on your X, Y and Z axes)
$xjh   Jerk Homing - Jerk used during homing operations. (found on axes XYZA only)
$xsv   Search velocity = Homing speed during search phase (drive to switch) (XYZA only)
$xlv    Latch velocity - Homing speed during latch phase (drive off switch) (XYZA only)

>Also, this isn't a major problem but whenever I hit the reset switch I have to restart openpnp to establish communication again. Is there another way to do this? Perhaps I am missing something.

Try adding \u0018 as the first command sent in your DISABLE_COMMAND - that should reset the TinyG every time you click the disable button (it adds a few seconds to disabling though).  Be sure Backslash Escaped Characters is enabled on the Driver Settings tab.

Tony

[Jim Young]

Which axis are the limit switches overshooting? 

Converting from the LitePlacer software to OpenPnP requires two changes for the Z axis:

Physically swapping the Z limit switch inputs on the TinyG

Reversing the Z polarity in the TinyG firmware (actually correcting how the LitePlacer had it wrong). GCode   $3po=1

Also check that the meaning of the limit switch are correct in firmware:

[xsn] x switch min                3 [0=off,1=homing,2=limit,3=limit+homing]
[xsx] x switch max                2 [0=off,1=homing,2=limit,3=limit+homing]

[ysn] y switch min                3 [0=off,1=homing,2=limit,3=limit+homing]
[ysx] y switch max                2 [0=off,1=homing,2=limit,3=limit+homing]

[zsn] z switch min                0 [0=off,1=homing,2=limit,3=limit+homing]
[zsx] z switch max                3 [0=off,1=homing,2=limit,3=limit+homing]

Don't get discouraged. I have a LitePlacer and TinyG too and it is working fine.

[John Lettang]

Hi Tony and Infinite,

Luckily I have already inverted the z-axis in lightplacer and I used a DPDT switch to be able to switch between openpnp and liteplacer z-limit switch layouts.

Thank you for posting the commands for how to change those values, I really appreciate it. I have been able to tune the homing process a bit and also I had a couple of my switches off for some reason so I was able to fix that too.

My next hurdle looks like I somehow messed up the jogging for the z and c (or a) axes. I can jog fine for the x and y but the other two just stopped for some reason when I was putting in commands and settings. I have been looking for about an hour on what I missed and I will keep looking later as well. Either way I will post a list of my settings below in case something looks off and might be the issue.

Also Tony, both my DISABLE_COMMAND and my ENABLE_COMMAND are currently blank. What should they look like instead? I am only on the Kinematics step of "issues and Solutions" so I don't know if that is something that is set up later.

Thanks again, all,

John

[John Lettang]

Apologies, here are my current settings in case that is useful:

[mark maker]

> My next hurdle looks like I somehow messed up the jogging for the z and c (or a) axes. I can jog fine for the x and y but the other two just stopped for some reason when I was putting in commands and settings. I have been looking for about an hour on what I missed and I will keep looking later as well. Either way I will post a list of my settings below in case something looks off and might be the issue.

See here:

https://github.com/openpnp/openpnp/wiki/FAQ#my-nozzle-is-not-turning-or-going-updown-when-i-jog-c-or-z

This seems to be a very common misunderstanding for new users. If anybody has an idea how to make this more intuitive, please speak up. 😁

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8311609a-df5d-4f68-9f52-860f8d423e30n%40googlegroups.com.

[John Lettang]

Hi Mark,

ah...that is quite a silly mistake. Apologies. I couldn't tell you a good way to make it more intuitive unfortunately. Maybe doing something along the lines of selecting through a submenu the head/nozzle you want as opposed to just seeing the list but that's all I could think of.

Anyways, I have a different issue that is still confusing me a bit and it is simply that my C axis is moving at a snails pace. I have messed with all of the speed settings as much as I could and there are some settings that make it move slower but it is still stuck at that very slow pace.

Also, I currently using a black mark on a white surface for a homing mark, is there an easy way to invert the current homing visual algorithm or should I just make a new mark with a white dot and black background?

Best,

John

[Jan]

Couldn't one disable the buttons if a tool is selected, that has a
virtual axis? And/or add a tool-tip or overlay that informs the user.
Also a message box with a "don't show this again" check box could pop up...

Jan

On 22.06.2022 21:29, mark maker wrote:
[...]

>>> the Wiki. If not, try enabling the *Include
>>> dismissed?* switch.
>>>
>>> The (lower) blue *[ i ]* button on that issue

>>>> <https://makr.zone/tinyg-new-g-code-commands-for-openpnp-use/577/>

>>>> blog post giving a tutorial and adding more
>>>> commands for better compatibility with openpnp
>>>> but it of course takes flashing to the tinyG. Is
>>>> this recommended by the community to do and will
>>>> openpnp recognize tinyG if I do this?
>>>>
>>>> Thanks for the advice,
>>>>
>>>> John
>>>>
>>>> On Friday, June 17, 2022 at 10:43:09 AM UTC-6
>>>> ma...@makr.zone wrote:
>>>>
>>>> Hi John
>>>>
>>>> you should update to the latest testing
>>>> version ...
>>>>
>>>> https://openpnp.org/test-downloads/
>>>>

>>>> ... then let yourself be guided by *Issues &
>>>> Solutions*.

>>>>
>>>> https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions
>>>>
>>>>
>>>> It should help you setup a Liteplacer mostly
>>>> automatically. You should delete the second
>>>> driver, though.
>>>>
>>>> It will also guide you through many new
>>>> auto-calibration steps, many have report
>>>> that it has improved their machine precision
>>>> a lot.
>>>>
>>>> https://youtu.be/md68n_J7uto
>>>>
>>>> (This video is a bit dated, there are now
>>>> even more calibrations, and the ones shown
>>>> have been improved)
>>>>

>>>> /> Also, I was mainly following the tutorial
>>>> from this website: //Openpnp with LitePlacer
>>>> Pick and Place – Inductive-Kickback.com
>>>> <https://inductive-kickback.com/2020/09/openpnp-with-liteplacer-pick-and-place/>/

>>>>
>>>> From what I've just quickly seen, there's
>>>> cool stuff in these scripts, but

>>>> unfortunately on a /rather/ outdated version

>>>> of OpenPnP. That's a bit of a problem with
>>>> scripting, you tend to be stuck on a
>>>> version, because if the underlying software
>>>> model changes, it breaks your scripts, with
>>>> no prior warning, i.e. you'll only get the
>>>> error at runtime.
>>>>

>>>> There are /some /things that he shows with

>>>> See here how you can get a *one click per
>>>> feeder setup* with the PushPullFeeder:

>>>>
>>>> https://youtu.be/5QcJ2ziIJ14?t=295
>>>>
>>>> This is shown for the All-3D-printed feeder

>>>> here, but it'll work with /any/ form of

>>>> mechanical drag/lever/push-pull or
>>>> electrical feeder.
>>>>

>>>> https://makr.zone/new-all-3d-printed-tapereel-feeder/399/
>>>>
>>>> OCR/barcode has now also been added to the
>>>> BlindsFeeder (though that part is not yet in
>>>> the video):
>>>>

>>>> BlindsFeeder with OCR
>>>>
>>>> https://youtu.be/dGde59Iv6eY
>>>>
>>>> https://makr.zone/new-openpnp-blindsfeeder/353/
>>>>

>>>> _Mark
>>>>
>>>>
>>>> On 16.06.22 22:41, John Lettang wrote:
>>>>> Hi All,
>>>>>
>>>>> I wanted to see if I could start messing
>>>>> around with openPNP software a bit. I got
>>>>> my Liteplacer to work just fine on the
>>>>> liteplacer software but I wanted to see
>>>>> about some other opportunities with openpnp.
>>>>>
>>>>> I am having some issues trying to set it
>>>>> all up, and I am not even able to get my
>>>>> Tinyg to be recognized by the software.
>>>>>
>>>>> I am done with the initial set up and have
>>>>> my Gcode driver set to detect firmware
>>>>> automatically. I have double checked a
>>>>> couple times as well but I am using the
>>>>> right COM for tinyg.
>>>>>
>>>>> The only other weird thing is that it looks
>>>>> like I somehow ended up with two Gcode
>>>>> drivers which doesn't quite make sense to me.
>>>>>
>>>>> Also, I was mainly following the tutorial
>>>>> from this website:
>>>>> Openpnp with LitePlacer Pick and Place –
>>>>> Inductive-Kickback.com

>>>>> <https://inductive-kickback.com/2020/09/openpnp-with-liteplacer-pick-and-place/>

>>>>>
>>>>>
>>>>> Any help is appreciated!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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/e1f9b8b6-89ec-4110-92c2-7b05ab36b269n%40googlegroups.com

>>>>> <https://groups.google.com/d/msgid/openpnp/e1f9b8b6-89ec-4110-92c2-7b05ab36b269n%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/32885fef-9497-43b0-b7e2-76c95827f55dn%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/openpnp/32885fef-9497-43b0-b7e2-76c95827f55dn%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/7266907c-df83-4382-a325-da0308a13d79n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/openpnp/7266907c-df83-4382-a325-da0308a13d79n%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/8311609a-df5d-4f68-9f52-860f8d423e30n%40googlegroups.com
>> <https://groups.google.com/d/msgid/openpnp/8311609a-df5d-4f68-9f52-860f8d423e30n%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/600566f2-c4ca-1d92-7420-c9f21d59c127%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/600566f2-c4ca-1d92-7420-c9f21d59c127%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

Hi John,

> my C axis is moving at a snails pace

Are you sure you handled all the Issues & Solutions suggestions? Have you set all the axis limits?

https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits

Also Issues & Solutions should have told you to remove (set to 0) the driver limit, so that only the axes are limited.  This is especially important for the rotation axis (a machine can usually be faster in degrees than in millimeters).

Also Issues & Solutions should have told you to set the right Motions Control Type for TinyG  (SimpleSCurve):

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#motion-control-type

> Also, I currently using a black mark on a white surface for a homing mark

Again, are you sure you used the Issues & Solutions suggestion to set up Visual Homing? Have you set the Feature Diameter right?

https://github.com/openpnp/openpnp/wiki/Visual-Homing#mounting-a-fiducial

If you want to re-visit, just set the Visual Homing method on the Head to None. Then press Find Issues & Solutions again.

https://github.com/openpnp/openpnp/wiki/Visual-Homing#method-for-new-machines

If this is setup is correct, the color should be of no concern. The new algorithm is agnostic to inside/outside color, all that counts is a contrast between the two and that it must be circular:

https://github.com/openpnp/openpnp/wiki/DetectCircularSymmetry

If in doubt, send the machine.xml

https://github.com/openpnp/openpnp/wiki/FAQ#where-are-configuration-and-log-files-located

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bb358263-f29d-4aef-a9a2-376ed56ceb30n%40googlegroups.com.

[mark maker]

> Couldn't one disable the buttons if a tool is selected, that has a virtual axis?

No, the virtual axes must be movable.

But we could probably draw the Z and C letter in a different color to indicate they are virtual... 🤔

_Mark

[tonyl...@gmail.com]

> This seems to be a very common misunderstanding for new users. If anybody has an idea how to make this more intuitive, please speak up.

Perhaps the buttons on the Jog panel should have a different look if they are going to move a virtual axis verses a real axis - maybe a red border for real axes and a green dashed (for color blind folks) border for virtual axes.   They can't just be disabled as the operator still needs to be able to jog the virtual axes.  Tool tips that change depending on what tool is selected would be good as well, but they are not obvious enough IMHO (as the operator has to hover over the button before they become visible) to be the only differentiator.

Tony 

[Jim Young]

If your rotation is moving slowly you might try checking the adjustment of the potentiometer for the A axis on the TinyG. If the stepper is not getting enough current then it will move slowly. The pot shouldn't have more than a 1/4 turn as it is easy to burnout the rotation stepper with over-current. If you find the pot is already adjusted correctly then you might have a stepper motor that is bad or going out.

[Jan]

Hi Mark! Hi Tony!
I would say that just changing the drawing style of Z/C letters and/or
the buttons alone will results in more questions why the drawing style
changes. I'd suggest to popup and message, that explains that the user
is going to operate a virtual axis and that he shall not expect any
physical effect from that. This box could/should be equipped with the
usual "don't show this again" check box.
Alternatively I would suggest to add a global switch that toggles
between expert and user mode behavior: here it might be ok for users to
disable the buttons if they would operate a virtual axis, while for
experts they stay active. (I personally never had the need to operate a
virtual axis. If I need the camera somewhere, its Z axis is usually
already setup by the relevant bring-the-camera-there operation)
Some weeks before, we had discussions about the step function within
jobs. The OP asked for a way to only stop on events that are relevant
for the user while you experts explained, that all intermediate events
are relevant for developers. There such a switch could join both needs.

Jan

On 22.06.2022 23:47, mark maker wrote:
> /> //Couldn't one disable the buttons if a tool is selected, that has a
> virtual axis?/

>
> No, the virtual axes must be movable.
>

> But we could probably draw the *Z *and *C* letter in a different color

> to indicate they are virtual... 🤔
>

> https://groups.google.com/d/msgid/openpnp/36ffb3e5-76c2-bb53-4f6e-c6281a98a1b5%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/36ffb3e5-76c2-bb53-4f6e-c6281a98a1b5%40makr.zone?utm_medium=email&utm_source=footer>.

[John Lettang]

Hi Mark,

I managed to get the rotation axis stuff working again. I don't quite know what was happening but I reset from a previous machine.xml and it ended up working fine.

>Also Issues & Solutions should have told you to remove (set to 0) the driver limit, so that only the axes are limited.  This is especially important for the rotation axis (a machine can usually be faster in degrees than in millimeters).

Strangely enough though I don't think this was ever a prompt for me. However there are so many setting that I may have just accepted the suggestion and forgotten about it.

Also, apologies, I thought I was stuck on the homing function but it turns out it was the camera calibration. I have tried my original black dot and a 12 pixel and 42 pixel white dot. After registering the fiducial with the auto measure it "swipes" twice and then says "subject not found." I assume this may be because my paper isn't matte enough and is too reflective, and in that case what would be a good way to fix that? Or what else could be the problem here?

Perhaps there is a threshold function or somethin I could use in order to make the dot more clear? Any advice is greatly appreciated.

-John

[mark maker]

Hi John,

when you say "dot" you do mean a printed circular feature, right? It has to be exactly circular, high color contrast and sharp edges are a bonus. Just a dot from a pen won't do!

> this may be because my paper isn't matte enough and is too reflective

Yes, this could be a cause. Also make sure you have a good light diffuser, otherwise even quite matte paper might reflect some pinprick highlights that break up the circular shape.

You cut out anything from your household: I'm looking at the mess on my desk now, and I see at least three good candidates from packaging, a booklet cover, etc.

If you have old PCBs you can cut out a fiducial.

> Perhaps there is a threshold function or somethin I could use in order to make the dot more clear?

No, the algorithm is self-tuning, as it compares the image to itself, that's the beauty of that detection method:

https://github.com/openpnp/openpnp/wiki/DetectCircularSymmetry

But that's also the reason it has to be truly circular. It is robust against imperfections along the contour, but the overall contour as such, must be circular, it must not be oval or whatever.

For example: these imperfections from a hole-punch confetti are fine, as the overall contour is still very circular:

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f8f42958-c617-475b-963f-4b29940fe8a0n%40googlegroups.com.

[John Lettang]

Hi Mark,

I tried a couple things, both cutting out the mark and putting it on an old PCB and also just the piece of paper. The image doesn't seem to have too much reflection but I don't know. I also can't find the setting for turning the corsshairs on for the camera for some reason.

I can also try to record a video as well of my multiple attempts with different fiducials if that will help.

But yeah, don't worry, I am not just using a dot from a pen. And i have a pretty good diffuser on my lights.

One other thing, my light bottom and light top are just always on when the pick and place are on. Should I just dismiss the suggestion for adding boolean commands or is there a specific setting for saying they are always on?

Best,

John

[John Lettang]

Once again, I forgot to attach the actually important information, apologies. (I don't know how to copy/paste into google groups but if there is a way, please let me know.)

[tonyl...@gmail.com]

>  I also can't find the setting for turning the corsshairs on for the camera for some reason.

Move the mouse pointer into the camera view and use the right mouse button to open a pop-up menu with lots of selections.  The mouse scroll wheel also can be used for zooming.

Tony

[mark maker]

> I can also try to record a video as well of my multiple attempts with different fiducials if that will help.

As the behaviors is rather unexpected, yes that would probably help.

> I also can't find the setting for turning the corsshairs on for the camera for some reason.

Context menu (right mouse button) on the camera view.

> One other thing, my light bottom and light top are just always on

You can enable the "After Capture" "OFF" checkbox here:

https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration%3A-Camera-Lighting#assign-the-camera-light-actuator

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/79438cce-7e60-4498-9911-88a1b8b8d858n%40googlegroups.com.

[John Lettang]

Here are two videos, one with the pdf printed out onto a full sheet of paper and elevated by being placed on some PCBs and another larger fiducial that is glued onto a copper plate. I also put a piece of paper over the second one because there are some fiducials on it that could mess up the algorithm.

Also, the 3D printer next to me makes quite a bit of noise in the background and I don't say anything in the video so feel free to mute it.

Here is a link to a drive folder that has the two videos on it: https://drive.google.com/drive/folders/17Zc49g7GDW4Hl_Ia5g_5uP2IVcvwVqm3?usp=sharing

Thanks again,

John

[tonyl...@gmail.com]

Hey John,

Have you verified that when you jog your machine that it moves by the correct amount?  I was just reviewing your TinyG settings and assuming you're using the stock LitePlacer motors, belts and gearing, these settings look wrong:

[1sa] m1 step angle 1.800 deg                      <-- should be 0.9 deg

[1tr] m1 travel per revolution 1.2500 mm    <-- should be 40.0000 mm

[2sa] m2 step angle 1.800 deg                      <-- should be 0.9 deg

[2tr] m2 travel per revolution 1.2500 mm    <-- should be 40.0000 mm

[3sa] m3 step angle 1.800 deg                       <-- this one is ok

[3tr] m3 travel per revolution 1.2500 mm     <-- should be 8.0000 mm

[4sa] m4 step angle 1.800 deg                            <-- should be 0.9 deg

[4tr] m4 travel per revolution 360.0000 mm     <-- should be 160.0000 mm

Tony

[mark maker]

That image looks very good. Are you sure you set the diameter right?

Another thing to check is camera settling:

https://github.com/openpnp/openpnp/wiki/Camera-Settling

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e76833bc-8434-4245-a166-8658f638869an%40googlegroups.com.

[John Lettang]

Hi Tony and Mark,

Tony that ended up being my issue and after going back to kinematics for a bit to redo all of that it looks like the calibration function works now. Only issue now is that my A axis is still way off and is overshooting by quite a bit. Perhaps it is in mm instead of deg? Where can I find a setting to change that?

If that isn't it, then maybe it is something with my settings for steps to that motor. So I will send my updated configuration file.

-John

[tonyl...@gmail.com]

Did you change to these settings:

[4sa] m4 step angle 1.800 deg                            <-- should be 0.9 deg

[4tr] m4 travel per revolution 360.0000 mm     <-- should be 160.0000 mm (this is not a typo)

[mark maker]

> [4tr] m4 travel per revolution 360.0000 mm     <-- should be 160.0000 mm (this is not a typo)

I case anybody is wondering: 160 instead of 360 is due to gear reduction on the Liteplacer (GT2-16 pulley drives GT2-36 pulley):

https://liteplacer.com/the-machine/assembly-instructions/pnp-head-step-9-place-z-low-limit-switch/

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cffbc844-f593-4cb2-8244-652ed779edcen%40googlegroups.com.

[tonyl...@gmail.com]

Oh, I think this TinyG setting is also incorrect:

[aam] a axis mode 3 [radius]      <-- should be 1 [standard]

Tony

[John Lettang]

Apologies, I thought I hit reply all saying that this was the solution but it looks like I did not. Either way fixing the a axis mode fixed that issue.

Essentially, I run into an M400 timeout error whenever I am trying to calibrate the axis. This specifically happens the first time the nozzle goes to the upper soft limit of the x axis. I went into the machine.xml file and made the timeout go from 5000ms to 10000ms. No luck though.

I have gone through this forum post and this one. And did some reading but no luck. Could someone point me in the right direction?

Now I tried scouring the site for a bit a found a couple of forum posts but the advice there didn't quite help either.

Thanks again,

John

[tonyl...@gmail.com]

Try going to the Driver Settings tab and bumping up your Command Timeout to something like 40000ms - some of the long slow moves during the calibration sequence can take quite a while to complete.

[Litterio Andrea Guainella]

Hi John,

I have had this problem too indeed I think all tinyg owners have had this problem. I solved it as Tony said. 

I have increased the connection timeout. I am attaching my configuration.

LAG

[mark maker]

> I went into the machine.xml file

No need for that, Just go to Machine Setup / Drivers / your Driver and set the timeouts in the Driver Settings tab.   

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7009fe3b-ff21-4f4e-8184-90df9fb2cca4n%40googlegroups.com.

[Clemens Koller]

Hello, John!

I came late to this discussion, but in case you still have issues with broken
communication:

You don't want to feed TinyG with a continous stream of configuration commands $xxx, since
it needs time to process and store it and it starts to chokes when the communication buffer
overflows. This is possibly leading to your problem!
This seems to be a bug (or undesired behaviour) in TinyG how settings are saved to
internal flash (or so).

I strongly recommend to do the full TinyG configuration only once before OpenPnP and keep
it configured that way. Flow Control stuff doesn't seem to work properly in that case. :-(
I do that with a script which pauses 0.1s in between each $xxx command.


Regards,

Clemens

On 6/16/22 22:41, John Lettang wrote:
> Hi All,
>
> I wanted to see if I could start messing around with openPNP software a bit. I got my Liteplacer to work just fine on the liteplacer software but I wanted to see about some other opportunities with openpnp.
>
> I am having some issues trying to set it all up, and I am not even able to get my Tinyg to be recognized by the software.
>
> I am done with the initial set up and have my Gcode driver set to detect firmware automatically. I have double checked a couple times as well but I am using the right COM for tinyg.
>
> The only other weird thing is that it looks like I somehow ended up with two Gcode drivers which doesn't quite make sense to me.
>
> Also, I was mainly following the tutorial from this website:
> Openpnp with LitePlacer Pick and Place – Inductive-Kickback.com <https://inductive-kickback.com/2020/09/openpnp-with-liteplacer-pick-and-place/>
>
> <https://inductive-kickback.com/2020/09/openpnp-with-liteplacer-pick-and-place/>Any help is appreciated!
>
>
>
>
> --
> 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/e1f9b8b6-89ec-4110-92c2-7b05ab36b269n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/e1f9b8b6-89ec-4110-92c2-7b05ab36b269n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[mark maker]

Hi everybody,

I'm not really sure if this is the issue for the OP.

But just to exclude what Clemens said, once and for all, I added a tiny extension to the GcodeDrivers and GcodeAsyncDriver.

There is now a $-Command Wait Time [ms] that pauses sending for that many milliseconds after each command starting with a $-sign.

I took the 50ms default from the Liteplacer Software source code.

You can see how the commands are staggered by 50ms:

This will now be added to any $-commands, regardless of whether they write to the EEPROM or not. But I guess that's no problem in practice, you can still send 20 commands a second.

See also:
https://github.com/openpnp/openpnp/pull/1433

Download as testing Version:
https://openpnp.org/test-downloads/

Please help with testing on real TinyG controllers that have $-commands in the CONNECT_COMMAND. 😎

Note: if some TinyG users feel adventurous, they can also test if TinyG works without Confirmation Flow Control, i.e.  in truly asynchronous mode with the GcodeAsyncDriver. This is assuming it was only the $-commands that actually made that impossible so far. It would make operation slightly faster and make the TinyG a "first-class" controller. 😁

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#advanced-settings

_Mark

[John Lettang]

Hi Mark,

My issue was indeed just making the command timeout longer. I have to make it 20s long for it to not timeout on x axis calibration. That is a cool update to add though judging by the problem that Clemens outlined.

Now for what should be quite a simple problem, but I cannot find a good resource on turning the vacuum valve on and off. I am just not able to find a good example or list of M code that would work with TinyG. I am sure I am missing something but I can't figure it out based on searching through the google groups and the wiki.

Thanks again,

John

[mark maker]

I leave that to the many TinyG users.

_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/828d5dc8-88ce-4d18-bc2e-c46d02787d51n%40googlegroups.com.

[Clemens Koller]

Hello, John!

On 6/29/22 19:05, John Lettang wrote:
> My issue was indeed just making the command timeout longer. I have to make it 20s long for it to not timeout on x axis calibration. That is a cool update to add though judging by the problem that Clemens outlined.

The $-Command Wait Time are in the ms range and according to what I understood for TinyG's internal house-keeping
sufficient. (50 ms..100ms ... should be fine.)

If you are running into some longer / several second timeouts to get some moves or actions (G-Codes, M-Codes)
completed, that's a different thing. I don't know the current status how OpenPnP handles these timeouts.
Will it timeout and move on (silently ignore) the command, or will it actively throw up a message box
or log that the timeout x was hit because command y didn't return z whereas we expected u?

(I haven't had time to work much with OpenPnP lately, as I had to temporarily re-use my Liteplacer for some other
CNC micromachining.)

Regards,

Clemens

On 6/29/22 19:05, John Lettang wrote:
> Hi Mark,
>
> My issue was indeed just making the command timeout longer. I have to make it 20s long for it to not timeout on x axis calibration. That is a cool update to add though judging by the problem that Clemens outlined.
>

> Now for what should be quite a simple problem, but I cannot find a good resource on turning the vacuum valve on and off. I am just not able to find a good example or list of M code that would work with TinyG. I am sure I am missing something but I can't figure it out based on searching through the google groups and the wiki <https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration%3A-Vacuum-Setup>.

>
> Thanks again,
>
> John
>
> On Wednesday, June 29, 2022 at 8:43:36 AM UTC-6 ma...@makr.zone wrote:
>
> Hi everybody,
>
> I'm not really sure if this is the issue for the OP.
>

> But just to exclude what Clemens said, /once and for all/, I added a tiny extension to the GcodeDrivers and GcodeAsyncDriver.
>
> There is now a *$-Command Wait Time [ms]* that pauses sending for that many milliseconds after each command starting with a $-sign.

>
> I took the 50ms default from the Liteplacer Software source code.
>

> You can see how the commands are staggered by 50ms:
>

> This will now be added to any $-commands, regardless of whether they write to the EEPROM or not. But I guess that's no problem in practice, you can still send 20 commands a second.
>
> See also:

> https://github.com/openpnp/openpnp/pull/1433 <https://github.com/openpnp/openpnp/pull/1433>
>
> Download as testing Version:
> https://openpnp.org/test-downloads/ <https://openpnp.org/test-downloads/>
>
> *Please help with testing on real TinyG controllers that have $-commands in the CONNECT_COMMAND. 😎*
>
> *
> *
>
> Note: if some TinyG users feel adventurous, they can also test if TinyG works /without/ *Confirmation Flow Control*, i.e.  in truly /asynchronous/ mode with the GcodeAsyncDriver. This is assuming it was *only *the*$-commands* that actually made that impossible so far. It would make operation slightly faster and make the TinyG a "first-class" controller. 😁
>
> https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#advanced-settings <https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#advanced-settings>

>>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e1f9b8b6-89ec-4110-92c2-7b05ab36b269n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/e1f9b8b6-89ec-4110-92c2-7b05ab36b269n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/e1f9b8b6-89ec-4110-92c2-7b05ab36b269n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/e1f9b8b6-89ec-4110-92c2-7b05ab36b269n%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/828d5dc8-88ce-4d18-bc2e-c46d02787d51n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/828d5dc8-88ce-4d18-bc2e-c46d02787d51n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Litterio Andrea Guainella]

Hi John,

if you too are lazy like me you can use the actuators present in the default configuration of openpnp (or modify them to your liking).

The following configuration works for me.

I also added disable command configuration so when you click power off in openpnp disable motor and actuators

LAG

[John Lettang]

Hi LAG,

Yeah lazy and/or unable to find the correct technical information on the internet... Either way, thank you so much! Those configurations worked great for me.

-John

[tonyl...@gmail.com]

Mark,

I tried out your latest change and it appears to work fine with my configuration although I didn't run any actual jobs with it.  I compared running a board fiducial check (with 4 fiducials) with Confirm Flow Control both enabled and disabled.  Both appeared to work fine.  I ran it 4 times with each setting, and it averaged 13.301 seconds with it enabled and about 12.609 seconds with it disabled - so about 5% faster - that may just be a statistical fluke though since a lot of the time is camera settling.  I also looked at the queue reports coming from the TinyG and the worst case I saw was that its command buffer contained 6 commands out of a possible 32.  I then setup an actuator to stream 130 gcode moves all in a row to see if the serial flow control would hold-off more commands once the queue becomes full and it appeared to do just that - once the queue gets down to 3 or 4 available slots, the serial flow control throttles the flow.  I tested both XonXoff and RtsCts and both appeared to work just fine - interestingly, turning serial flow control completely off also seems to work just fine - I'm not sure why.

Tony

[mark maker]

Tony,

thanks a lot for testing. Sounds good!

The serial flow control behavior (your second test) is a bit of a mystery, though.  I think for the moment I keep the Issues & Solutions recommendation for Confirmation Flow Control in place for TinyG. Power users can then override that setting if they like, and perhaps we'll sort the serial flow control mystery out in the future.

Thanks again.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c8765c6a-99cc-431e-93a6-e7777b517920n%40googlegroups.com.

[John Lettang]

If I should start a new thread on this google group let me know, I don't quite know what the etiquette is now that my questions differ quite a bit from my original question.

Nonetheless, I am having some issues with advanced calibration that I thought were interesting. I reran it a few times and have run into some different results. I am just more or less confused by what it looks like and if perhaps this means that something else is off in my system and that is what is making advanced calibration so wonky.

The only way I can really describe it is that after calibration it makes it look like I am looking through a fish's eye.

-John

[John Lettang]

Upon further investigation, my pixel measurements also seem off. As the camera algorithm isn't able to detect any holes at the moment. I manually redid the pixel measurement but that didn't help much either. Here is the pixel measurements after calibration. And a few other photos showing some errors I am getting. I would not be surprised if all these are related but I went through all of calibration twice and still have the same errors. Any help is much appreciated.

John


Pipeline:

<cv-pipeline>
   <stages>
      <cv-stage class="org.openpnp.vision.pipeline.stages.ImageCapture" name="original" enabled="true" default-light="true" settle-first="true" count="1"/>
      <cv-stage class="org.openpnp.vision.pipeline.stages.BlurMedian" name="cleanup-original" enabled="true" kernel-size="5"/>
      <cv-stage class="org.openpnp.vision.pipeline.stages.ConvertColor" name="gray" enabled="true" conversion="Bgr2Gray"/>
      <cv-stage class="org.openpnp.vision.pipeline.stages.DetectEdgesCanny" name="find-edges" enabled="true" threshold-1="5.0" threshold-2="15.0"/>
      <cv-stage class="org.openpnp.vision.pipeline.stages.BlurGaussian" name="predetect-1" enabled="true" kernel-size="5" property-name="BlurGaussian"/>
      <cv-stage class="org.openpnp.vision.pipeline.stages.BlurMedian" name="predetect-2" enabled="false" kernel-size="7"/>
      <cv-stage class="org.openpnp.vision.pipeline.stages.DetectFixedCirclesHough" name="results" enabled="true" dp="1.0" param-1="25.0" param-2="20.0"/>
      <cv-stage class="org.openpnp.vision.pipeline.stages.ImageRecall" name="recalled" enabled="true" image-stage-name="original"/>
      <cv-stage class="org.openpnp.vision.pipeline.stages.DrawCircles" name="display" enabled="true" circles-stage-name="results" thickness="1">
         <color r="0" g="0" b="0" a="255"/>
      </cv-stage>
   </stages>
</cv-pipeline>

[mark maker]

It would really be better to open a new thread. 😉

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/75ad9645-81c9-4231-961d-878c9e6859acn%40googlegroups.com.

[John Lettang]

I will go ahead and reask the question on a new thread. Thanks Mark!