disable move to safe z

[cncmachineguy]

Is it possible to disable this feature? I have been looking and searching the group, but have not found an answer.

[Jason von Nieda]

No, not in general. It's hardcoded as part of most of the moves. What are you trying to accomplish?

Jason

On Tue, Nov 20, 2018 at 9:20 PM cncmachineguy <bert.s...@gmail.com> wrote:

Is it possible to disable this feature? I have been looking and searching the group, but have not found an answer.

--
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 post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c401e471-4b3c-4cfd-a35c-f148c07c18f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bert shivaan]

I have 6 nozzles. all pnumatic driven down and up. the "Z" is actually a common stop for all six. so, if you want to pick 6 parts, 1 on each nozzle, you

-move to the first nozzle pick point

-lower Z (remember this is a moving mechinacal stop)

-fire valve sequence which puts nozzle down, turn on vac, raise nozzle.

-wait for z stop to raise up

-move 15mm for next nozzle pick

-wait for z to move back to where it was for last nozzle

-repeat process for remaining nozzles.

As you can see, I am spending a fair amount of time needlessly moving a stop up and down.

Hoping I could hit a check box somewhere to turn that feature off.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jzcvontUU6ej%2BrxWhg%2B_GP6W27mH_JbJ8yuGN1BDaWa4A%40mail.gmail.com.

[Jason von Nieda]

So the Z stop sets the lower limit of how far a nozzle will go down, and then the nozzle is pushed down to the stop individually? And your preference would be that if you are picking 6 parts you set the Z stop once, fire each nozzle in turn, then finally raise the Z stop?

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNx_dcjehQfuygpFWJYcSvgVBhfGAo1KH933ttTCMu7WmA%40mail.gmail.com.

[bert shivaan]

yes that is how it works.

My preference would be for the Z to move to the next needed height, ie maybe placing a tall cap so height is higher than for a 402 LED.

Y do have sensors to detect when nozzle is up or down (lower sensor is attached to stop). I have not connected them yet, but if I have issues I will.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jxOzWwVNqoU%2BWK0yJz9dEYtmnj9yUURDB-r6VH_17i7Eg%40mail.gmail.com.

[bert shivaan]

not Y, I

Also I do not expect code changes based on my needs, just wondering if it was already there.

[Jason von Nieda]

No, afraid not. It would be a pretty small change in the driver to implement this, but it would not be universal, so I'd suggest just making the change in your local copy. Another option would be to put a layer between OpenPnP and your controller and basically just have it ignore G0 Z0

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNzgjcRexjXj68-j83feirYvVBq%3DUzHAN9FczDvfsmdMqw%40mail.gmail.com.

[bert shivaan]

to make the change in my local copy, I would need to build oPNP after I make the change? If so this might be above my pat grade right now.

BUT, as you say maybe I can hack GRBL a little more and ignore any Z0 moves.Need to think on this idea - do I ever need to move to Z0 I wonder? Sounds like something to sleep on a few nights.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jyJSKYOpgK%3DMqX%3DLt98Qr-pmuuopBU7u%3DnGO%2BjGOxPe_A%40mail.gmail.com.

[Marek T.]

I have probably similiar setup as your one.
I have an actuator added to the code which is responsible for nozzle up/down. And the mechanism synchronising this actuator with system Z management. Condition is to set this actuator true (down) if system Z is lowering nozzle below -2, and set it false (up) if Z is going above +2. So using system Z-heights and system Z management (including arrows) I can control my individual Z pneumatic nozzles.

If it sounds good for your setup I can help you with this.

[bert shivaan]

Hi Marek,

Yes I think we do have similar setups.

Right now mine works fine, I am just looking to save a lot of Z moving. I Must move the End stop down to control how far my nozzle(s) move down. But then I raise the nozzles without moving Z up. There is no need for me to raise the Z if the next nozzle move will be at the same or even just close Z position.

Does this make sense? I will try and get a close up video of this in action, nut not sure when I will do that. Maybe not for another day or 3.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8bdef6c3-e38e-4bed-8113-418e5595129e%40googlegroups.com.

[Marek T.]

Sorry, only now have red your description more insightfully.

So you must lower Z-endstop, lower nozzle, raise nozzle, raise Z-endstop. And you want to eliminate last endstop raising in some situations.

How do you move the endstop? Do you have the control on its specific Z position or it is only max-up or max-down?

Do you raise/lower the nozzle using system Z management or "manually" with commands within PICK(PLACE)_COMMAND?

[Marek T.]

forget last line of the post before. Forgotten to cancel it...

[Bert Lewis]

You are correct in how it works except I have no need to raise the stop unless I need the z position to be higher. Operation is m-codes through the pick and place commands. 

The end stop is very precise controlled z axis. It is stepper driven fine pitch screw. 

As you can assume, with air cylinder the nozzle extends until it hits something. The something in this case is the end stop. 

Bert Lewis

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ceb5acb7-3418-4c33-95f0-052a84d25156%40googlegroups.com.

[Marek T.]

So your endstop is just adjusted stopper/limitter for pneumatic nozzle.

So you can control your endstop using system Z-control rotating and raise/lower the nozzle using commands in PICK/PLACE_COMMANDS.

Is this so slow that you want to limit the number of endstop up/downs?

[bert shivaan]

I think that did not work, maybe this will?

https://www.youtube.com/watch?v=FODfIeHQYJE

On Wed, Nov 21, 2018 at 6:53 PM bert shivaan <bert.s...@gmail.com> wrote:

here is a video (maybe). I see maybe it only does this when picking parts.

The video is pretending to pick 6 parts, then place them.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0154d46f-f168-4ecf-9e38-3c54e81ede5a%40googlegroups.com.

[Marek T.]

Is it some slow motion? :-).

Looks like you have fast nozzles with slow endstop :-)

[bert shivaan]

Well I may be able to speed the Z up some, but still it will be slower than the air cylinders.

Also I have HUGE delays in between firing the valves (.25 sec and 1 sec) This is just me testing things. I like to go slower at first to be sure what is happening.

But clearly you see when a nozzle retracts (in the first part of the video) then the z moves up, machine moves over, z moves down. Seems like there is no need to wait on the up and down part.

But it looks like when it is "placing" them, Z does not move up and down. So maybe this is not a big deal at all.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2e0eec1c-03cb-48b1-959d-aeb07adec1ec%40googlegroups.com.

[Marek T.]

The question is: do you really need to move this endstop at all? Nozzles have some 4mm spring loading. It is enough in 90% of placements.

Technically it's nice feature but usually useless in my oppinion. I have constant stopper, and do the parts from 0402 to 3mm without problems.

But if you look into the code of the ReferencePnpJobProcessor there is section doFeedAndPick and next find

            // Retract
            nozzle.moveToSafeZ();

if you comment this you probably will get what you want. And the same in doPlace section.

Note, I'm electronic but not programmist. I want to tell that I'm not sure if I'm right but it should be ok :-).

If you want I can compile the jar for you to you could test it. But later you will have to play on your own with compilations of the future versions.

What is this delay 0.25-1sec that sounds like horror?? I fight and cry with delays like 50ms :-)

Give more details about it.

[bert shivaan]

My nozzles do not have anywhere near that much travel. Maybe 1mm or so. In any rate the difference from 0402 and SOT23 would be too much. So sadly I think I will need it at some point.

If you want to do the code test I am happy to try it. I will eventually learn to compile my own, but that is not on my priorty list just yet.

The delays are me testing, so for instance here is my pick commands:

M701.0 - up valve off

g4p.25   -some delay because things in real life are slow

M721.1 - down valve

g4p.25

M731.1 - vac on for nozzle 1

g4p1.0  - longer delay, mostly so I can see the delay is working

M721.0 - down valve off

g4p.25 -

M701.1 - up valve on

So the delays are there because I will need them or everything will fight itself. They are too long right now because I need to see them before making them right.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d8928a60-a27e-4453-8aed-7b080f10bcb7%40googlegroups.com.

[Marek T.]

So they are not the problem but for your debug...

I will send you some file later.

[bert shivaan]

take your time, I am in no hurry right now. I have much to do still to start building a board.And the point of this for me is to build a board. I ordered the PCB's and all the parts when my other machine terminally failed. So the focus is to build the board I have in hand, then I can worry about going faster.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cc1bb40c-e525-492a-941b-cb33f6ba74d3%40googlegroups.com.

[Marek T.]

Yes it's like I've understood :-). I will do this at occasion when play with some another changes for me.

[SMdude]

You probably would be better off not raising the stopper at all. It really only needs to adjust a little bit for each pick and place to adjust the stop height to the thickness of the new part about to be picked/placed. If safe Z could be assigned to a switch(put all your nozzle sensors in series, Normally Closed with all nozzles up) of some sort to notify when the nozzle really has retracted before the next move, this would be much better for you, and better than running with a nozzle still down.. :(

Have a look and play with the code, just see if you can get it to compile and run to begin with. Follow the Wiki ;)

Use github search to find/narrow down which file you want to modify.

Mick

[Marek T.]

Hi Bert

I have mailed you the link to jar we talked. Check it if it's good for you.

Only retracts while pick and placement commented, nothing more.

It's newest git version that Jason has put there. If you use some Openpnp older than nov.17 you must have opencv-3.4.2-1 downloaded to library or just install newest version and exchange the jar with "mine".

W dniu czwartek, 22 listopada 2018 21:38:43 UTC+1 użytkownik cncmachineguy napisał:

[bert shivaan]

Thanks Marak, I will test it tomorrow morning (11/29)

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d2e34ccb-6c01-40bb-846a-5b6f3d8728e3%40googlegroups.com.

[bert shivaan]

Good Morning (for me anyway) Marak,

I have tried your jar, but oPNP will not start. it says :

"

There was a problem loading the configuration. The reason was:

Error while reading machine.xml (org/opencv/core/Keypoint)

Please check your configuration files and try again.

"

I updated before trying yours and everything worked. If I go back to the original it all works. Haven't tried anything else as I rather have the advice of folks that know first. I do not know what I am checking for.

[Marek T.]

Have you installed developed or stable version? I used developed and it starts normally. Have you tried without machine.xml ?

[bert shivaan]

I assume I used stable version, steps taken by me:

1) help->check for updates

2) update found -> install

3) run updated to be sure all is good - it is

4) rename openpnp-gui-0.0.1.....

5) paste in your supplied openpnp-gui-0.0.1....

6) try to start oPNP - fail with posted message

7) revert oopenpnp.gui files to original

8) start oPNP - worked

9) posted problem here.

:)

I will try without machine .XML file now

Tried with fresh configuration (as suggested by error message) still did not work.

Attached is the log created when trying to start.

Maybe I have the wrong version of Java installed?

On Thu, Nov 29, 2018 at 8:52 AM Marek T. <marek.tw...@gmail.com> wrote:

Have you installed developed or stable version? I used developed and it starts normally. Have you tried without machine.xml ?

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0ca78c30-6523-498b-adbe-be3dc7dab9e6%40googlegroups.com.

[Marek T.]

You have java in installed package, in folder jre.
Try install develope version into another disk location. There was an update of openpcv and possible that Jason haven't add it yet into the stable version. Check whether you have opencv 3.4.2-1 in lib folder, if it's not there this jar will not work. I guess you don't have it and then you need develope version to install.

[bert shivaan]

I believe that must be it. I will try to install the dev version later today or in the morning, WAY TOO much work to do at work today :(

Thank you for your help so far, I am sure this will work out when I get my part caught up with you :)

On Thu, Nov 29, 2018 at 9:34 AM Marek T. <marek.tw...@gmail.com> wrote:

You have java in installed package, in folder jre.
Try install develope version into another disk location. There was an update of openpcv and possible that Jason haven't add it yet into the stable version. Check whether you have opencv 3.4.2-1 in lib folder, if it's not there this jar will not work. I guess you don't have it and then you need develope version to install.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/32b8a39b-8110-4625-b56c-3ba3b156fdd2%40googlegroups.com.

[bert shivaan]

Well no love today either.

Downloaded and installed the dev version, replaced the .jar and now a new issue. Seems maybe to have something to do with not being able to create a key in the registry maybe.

At any rate I will keep working at it to see if I can get it to open.

[Marek T.]

Does original jar work for you properly? If it does the modified one must work the same. The change is so very small and no possible to be a reason of any issue to stop running.
In fact in my personal version it is also blocked the same as for you, plus many many other changes much more suspected - and it all works properly.

[bert shivaan]

Yes it does. Is it possible I still have the wrong "version" of oPNP?

I am using this one :

http://openpnp.org/downloads/  Latest (New Features, New Bugs) 64 bit winblows

On Fri, Nov 30, 2018 at 8:53 AM Marek T. <marek.tw...@gmail.com> wrote:

Does original jar work for you properly? If it does the modified one must work the same. The change is so very small and no possible to be a reason of any issue to stop running.
In fact in my personal version it is also blocked the same as for you, plus many many other changes much more suspected - and it all works properly.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/81c6678c-134f-4898-b76d-56cd83ad82f9%40googlegroups.com.

[Marek T.]

Yes it should be this one.

https://s3-us-west-2.amazonaws.com/openpnp/OpenPnP-windows-x64-develop.exe

So when you replace originally installed jar with mine it does not work at all for you?

What in fact does this mean " and now a new issue" ?

[bert shivaan]

I get this message.

It is a new issue because at first the error said

" Error while reading machine.xml (org/opencv/core/Keypoint)"

It gives me this even if I delete the entire .openpnp folder as suggested by the error message

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b1d7e7a4-3db0-4dae-920c-64ef860568db%40googlegroups.com.

[bert shivaan]

It just occured to me to ask, I should be replacing the file found at :

program files\openpnp

correct?

The file names are the same so I didn't look elsewhere for it

[Marek T.]

Yes it's this location.

I don't understand why you have an effect like that. As said there is nothing modified in practice, difference to original is that it's my compilation.

Actual Openpnp opencv uses core instead of features2d.

-import org.opencv.features2d.KeyPoint;
+import org.opencv.core.KeyPoint;

So your message - at least I understand it this way - is telling that see something related to feature2d in machine while expects to use core.

But the same should be in case of your original installed jar and sholuld be gone when you delete old machine.xml

However I didn't need to remove old machine and both jars - original and mine works with it properly on my two machines.

Sorry Bert, I'm too short to know this :-(. As said I'm not software engineer and it must be I made maybe something wrong while the compilation???

Maybe Jason may help to explain it?

[Jason von Nieda]

Marek, it sounds like your version is probably building against OpenCV 2, not 3. In 3 several classes and packages changed. KeyPoint is now in org.opencv.core.KeyPoint. If Bert downloaded the latest develop version, he should have opencv-3.4.2-1 so the jar you are sending him will need to use that library to work properly.

I will once again reiterate that it's a bad idea to send jars around. If Bert needs custom code, he should install the development environment and build OpenPnP himself. It's really not hard. Certainly no more difficult than building and running a pick and place machine :) Then you can send a simple patch or show the code change. This way he doesn't lose access to the changes when OpenPnP updates or you change your jar.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a6734fcb-db22-4c84-b540-6461dae4b4d3%40googlegroups.com.

[bert shivaan]

Marek, no worries, it is really just a wish list thing for me.

Jason, I agree I should figure out how to compile my own if I want/need custom code.

Certainly no more difficult than building and running a pick and place machine :)

I must disagree here, For some it is. Others like me have a hard time keeping all my build enviroments seperate from each other. One time I spent a few weeks trying to debug some simple code, only to find out when something unrelated updated (like VS2008 to VS2010 or something) it broke my MPLABX enviroment.

BUT, I will sort this out maybe (compiling from source), really it depends if you move over to C++/Qt. If you do that I may not be so inclined to get my Java in order. :)

Thank you both again for the help and support so freely given!!

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jyEmGWrtgzT7j4Ek5J6Q%3DuAMe0PKzB7Qv3ommSebppYLw%40mail.gmail.com.

[Marek T.]

Jason, you are right about jar sharing for sure but at occasion maybe I can find that doing something wrong. Could be good to have this under control.

The code change is euphemism in this case, there are only two lines commented and this is told few posts above. I don't hide anything, only intended to give little help Bert to test it and warned for later he should install maven.

So the question is:

I'm compiling last version downloaded from git. It's develop with merged PR#766. Using the pom that's in packet (if, it's important for this case). Is this possible that I build the jar using OpenCV 2, not 3?

If I remove opencv3.4.2-1.jar from the lib I get message "error while reading machine.xml (nu/pattern/Opencv)" - so a bit different than Bert gets.

[Jason von Nieda]

Hi Bert,

When I say "no more difficult" I mean specifically OpenPnP. I've put a lot of work into making it very, very easy to build a custom version specifically for this reason. To get up and running you basically just need:

* JDK >= 1.8

* Maven (pretty much any version)

* Git (optional, pretty much any version)

Basically, if you can open a command line and do:

`javac -version` and get >= 1.8

`mvn -version` and get basically anything that isn't "command not found"

`git` and get anything

Then you can build and run OpenPnP.

From there it's as simple as:

git clone https://github.com/openpnp/openpnp.git (or download zip from https://github.com/openpnp/openpnp/archive/develop.zip)

cd openpnp

mvn package -DskipTests=true

openpnp.bat

Maven will download everything else it needs and will not mess with global dependencies. Everything will be self contained in the OpenPnP directory.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNzhq%2B98W0uZ31dDxFfgTTk3a9G5ja_kbWRtn9FTU%2BTMKw%40mail.gmail.com.

[Jason von Nieda]

Hi Marek,

I'm not suggesting you are hiding anything. Just trying to suggest a process that will ultimately be easier for everyone involved.

Based on what you said above, it should be compiling against 3.4.2-1, yes. It's possible that Bert has an old KeyPoint reference in machine.xml, but I don't think those are saved so it seems unlikely. Probably best to start with a fresh machine.xml, or search machine.xml for references to KeyPoint which may need to be updated.

Jason

[bert shivaan]

Jason I will get this sorted as far as building my own copy. Thank you for the very Verbose instructions (I love those, never any questions :))

As for the issue I am having with Marek jar file, I have deleted .openpnp folder located in user\.

My understanding is that should take care of the machine.xml chances of being wrong?

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jyBKTuEPFG_LDPtfrReSx6JYL5pX9mVyL-_AKWkxr7rfw%40mail.gmail.com.

[Marek T.]

Hi Jason,

I know you don't like to see jars published here so I prefer to be sure you don't think I'm hiding anything :-) :-) :-). No matter.

You are trying to suggest to Bert very well and I can confirm that jar bulding may perform a monkey after short training ;). It's not possible to tell the same about digging in the code...

I just checked that i.e have "import org.opencv.core.KeyPoint;" in ReferenceNozzleTip.java dated 28.11.2018, not "org.opencv.features2d.KeyPoint;"

So I think it's proper version downloaded, correct?

Strange that Bert says has the same error message when remove machine and tries with fresh configuration, isn't it?

[bert shivaan]

LOL Marek, 

THIS right here is prolly the biggest reason not to pass jars around. it's all good when just between the 2 people helping each other, but the moment there is an issue (like we have now) then Jason gets asked to jump in.

Now He will likely help cuz he seems like a nice helpful guy as you are and lots of other folks here are. BUT we may be creating a problem he doesn't need to solve (if I just compile my own I assume it would work).

Now there is an educational side to it that makes you and myself want to understand the problem, but for him it really is just noise maybe.

Having said that, Jason do you know what is wrong?

-Bert

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/dea1e4d3-d56e-4cd2-a935-832a6ee543b3%40googlegroups.com.

[Marek T.]

Yes it may be noise and not worth to loose a time on it.

But many times I had situation when small thing was a "tip of the iceberg" (not sure if it's sentece used in English) and helped to solve some bigger issues...

Finaly, when you deleted .openpnp from users did it help to run my jar??

[Jason von Nieda]

Sorry, I don't know offhand. Here is how I'd proceed:

1. Get Marek's jar in place.

2. Delete the entire $HOME/.openpnp director and go confirm it's gone.

3. Start Marek's jar. If it fails, that's okay, record the error.

4. Go check if $HOME/.openpnp now exists. If so, look at the machine.xml inside and try to find the line that matches the error. Report back with this.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNyOyZ%2ByWejR3qAiutdMwHUpYv8BZX0BreLFrnY62Vo%2BQw%40mail.gmail.com.

[bert shivaan]

there is no machine.xml created in the new directory, there is however a log file. I have attached it. This is the only thing in the directory.

I am making the assumption that $HOME is the same as $USER for me.

so I delete .openpnp dir located in the user\bert folder

try to run with Marek jar,

a new .openpnp folder is created with a log folder inside of that.

in the log folder is the attached file.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jxHng%3DcOB7s9M1v5r1fNY8ot%3DwbpajZtHQz%2Bv0PtSOhwg%40mail.gmail.com.

[Marek T.]

It's showing feature2d, no idea where from??
And no idea where reads it if you don't have machine.xml at all.

[bert shivaan]

Ok, After another full unstall and reinstall, it will open and run - BUT it seems like it is the same. Z still moves to 0 on pick.

On Fri, Nov 30, 2018 at 1:28 PM Marek T. <marek.tw...@gmail.com> wrote:

It's showing feature2d, no idea where from??
And no idea where reads it if you don't have machine.xml at all.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/164c75c0-bc66-4976-a5b4-f02fbe473505%40googlegroups.com.

[Jason von Nieda]

Marek,

Sounds like you may have modified the built in resources that create the machine.xml. This would be included in the jar you built, and will get installed when Bert runs it. You can check in src/main/resources/config/machine.xml.

Here are the defaults: https://github.com/openpnp/openpnp/tree/develop/src/main/resources/config

Jason

On Fri, Nov 30, 2018 at 12:28 PM Marek T. <marek.tw...@gmail.com> wrote:

It's showing feature2d, no idea where from??
And no idea where reads it if you don't have machine.xml at all.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/164c75c0-bc66-4976-a5b4-f02fbe473505%40googlegroups.com.

[Marek T.]

No, I never maven operate on downloaded directory but keep it aside as quick copy untouched, for any case if screw something.

I have checked it now and machine used for jar building is the same as my clear copy.

I have also compared them with the default you're linking and it is 141138KB size but the file on git is 8412KB.

So they are quite different at least. I'm not sure which part of config is important about this "issue".

Bert I will look later onto it. Try clone the git.

[bert shivaan]

This weekend I will compile my own build and test it on my virtual machine at home (Mega without an actual machine)

I can look at the log to see if the "safe Z move" has been disabled.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/af471400-0f8e-4367-942a-2a9a09c4a2a4%40googlegroups.com.

[Marek T.]

As Jason said It's hard to disable everywhere. I have disabled Retract after the pick procedure is finished. But after this begins another nozzle picking and I'm not sure it may be that movableutils changing xy position is also moving z to zero together. I'm AFK now.
You can find it in src/.../machine/ReferencePnpJobProcessor java in doFeedAndPick part of code.

[bert shivaan]

Well this is a little off topic, but it is MY topic so anyway:

Jason or any others, here are the errors from my first build attempt.

Is something pointing to JRE that should be pointing to JDK? (I am guessing here)

On Fri, Nov 30, 2018 at 3:47 PM Marek T. <marek.tw...@gmail.com> wrote:

As Jason said It's hard to disable everywhere. I have disabled Retract after the pick procedure is finished. But after this begins another nozzle picking and I'm not sure it may be that movableutils changing xy position is also moving z to zero together. I'm AFK now.
You can find it in src/.../machine/ReferencePnpJobProcessor java in doFeedAndPick part of code.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c53b8d65-c00f-49c9-bfc3-fe07818cfc94%40googlegroups.com.

[Marek T.]

Did you use test skip?
mvn -Dmaven.test.skip=true package

[bert shivaan]

I followed this:

git clone https://github.com/openpnp/openpnp.git (or download zip from https://github.com/openpnp/openpnp/archive/develop.zip)

cd openpnp

mvn package -DskipTests=true

openpnp.bat

I will try as you have listed

......

and I am back. Same error :(

On Sat, Dec 1, 2018 at 9:35 AM Marek T. <marek.tw...@gmail.com> wrote:

Did you use test skip?
mvn -Dmaven.test.skip=true package

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/70d69444-a6fa-429a-b28b-e8b9c185c8d3%40googlegroups.com.

[bert shivaan]

well my work will be cut out for me I think. A quick search in all src  files located in the fresh git pull shows 55 hits in 20 files. Now maybe they all don't do something, but thats plenty for me to keep busy with while I learn.

I am hoping to find the spot (if it exists) where it actually generates the command to serial and disable it there. That way I wouldn't need to change it every where. My gut feeling is it won't work this way or Jason would prolly have pointed it out already.

And of course I will need to sort out building openpnp from source.

[Marek T.]

Probably both commands do exactly the same.
Normally you should get green text "build success". Understand you don't get it. This openpnp.bat is not needed on build moment. Enough to use maven command being in openpnp directory. Later you can run jar that you'll find in openpnp/target directory.

[bert shivaan]

So now to expose my total lack of programming knowledge:

When I see this:

 head.moveToSafeZ();

and this:

nozzle.moveToSafeZ();

it makes me think there is some method defined somewhere called moveToSafeZ()

If this is true really I need to just alter the method then when it is called it will do what I want?

[bert shivaan]

Yes I am assuming bold red BUILD FAILURE means I have failed to build, therefore nothing to run. :(

[Marek T.]

Do you get it building originally downloaded archive or something modified?

[bert shivaan]

I have not modified anything just yet.

I am trying to just build original.

I think something is wrong in my %path%, but really want someone to tell me this instead of me following something I find online.

On Sat, Dec 1, 2018 at 10:34 AM Marek T. <marek.tw...@gmail.com> wrote:

Do you get it building originally downloaded archive or something modified?

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a5f43998-b66b-439c-bcc3-300fba7c7446%40googlegroups.com.

[Jason von Nieda]

Hi Bert,

Yes, JAVA_HOME is pointing to the JRE, rather than the JDK. It needs to point to the JDK. When I'm on a machine where I am doing development I usually set this globally since the JDK also includes the JRE, but you can also set it locally during build.

Something like `set JAVA_HOME C:\Program Files\Java....wherever you installed the JDK` should get you going.

So, like this:

1. `set JAVA_HOME C:\Program Files\Java...`

2. mvn package -DskipTests=true

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNy-ZfqQRLFPMnTKxi%3D5U24LYvesaWSw31USJf5GFGUuNw%40mail.gmail.com.

[Marek T.]

There is online detailed description how to set global pointing jdk. I thought you have followed it...

[Marek T.]

Hi Jason,
-DskipTests ==> compiles the tests, but skips running them
-Dmaven.test.skip.exec=true ==> the tests get compiled, but not executed.
-Dmaven.test.skip=true ==> doesn't compile or execute the tests.

Is it some serious mistake using last command (what I always do)?

[Jason von Nieda]

I prefer to compile them as a quick check just to make sure nothing breaks as I code. Doesn’t add much time. So, either way is fine.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/032fce32-465c-44b9-942f-7b80ec52b8bd%40googlegroups.com.

[Marek T.]

Thx

[bert shivaan]

WELL AWESOME (for me) stuff!!!!!!

It builds and runs using openpnp.bat

when I put all my .openpnp folder contents in it even has my machine specific stuff in there :)

Thank you Marek and Jason for getting me this far.

Now to Jason or anyone else that knows, did you see my post a few back about the .moveToSafeZ() ?

Is this a method somewhere that maybe I can change the method and not have to address all 55 occurrences in 20 files?

On Sat, Dec 1, 2018 at 11:29 AM Marek T. <marek.tw...@gmail.com> wrote:

Thx

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b8041dfa-8940-42f8-b4dc-fbca9d965f18%40googlegroups.com.

[Jason von Nieda]

Hi Bert,

Good idea. You can just comment out the relevant code in the moveToSafeZ methods in ReferenceCamera, ReferenceActuator, ReferenceNozzle. ReferencePasteDispenser and ReferenceHead.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNxDNPcThPXUVAUBJVRt4VoCex6HtpTRv28xQpzpkZfmuw%40mail.gmail.com.

[Marek T.]

Jason small explanation pls. MoveToSaveZ is the only mechanism bringing nozzle to zero position or it's also made in some situations with the method driving xy motion? Sorry if I maybe use improper things' naming but I hope you know what I mean.

[Brynn Rogers]

It seems like having multiple methods:

 head.moveToSafeZ();

nozzle.moveToSafeZ();

 ReferenceCamera, ReferenceActuator, ReferenceNozzle. ReferencePasteDispenser and ReferenceHead. 

is silly and redundant - shouldn't each of those methods call the one true moveToSafeZ() so  Bert can just make a change in one spot?

Or am I missing something?  

Brynn

[Marek T.]

It's not clear if Bert need to kill every safeZ that exists in the system, maybe only very few. This what you tell kills them all.
Bert, you must knew this but maybe not. It's usable to put debug descriptions near the safeZ callings that you want to eliminate, first - before commenting them. Then you'll find in the log which one is really harmful for you.

[Jason von Nieda]

It's just sort of an artifact of when this feature was introduced. They could certainly be combined.

Jason

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/80725cc0-242e-4de5-b3d3-955e7bf1121c%40googlegroups.com.

[bert shivaan]

Yes Marek, I too look for stuff by adding comments to see if I am in the right place.

I have no need for any of the safe Z stuff on my machine, So it would be fine if I could kill all of it. BUT, I am happy also if I only get rid of the stuff that affects me. So if the paste dispenser moves to safe z everytime I use it, thats fine because I don't have one.

Brynn, I was hoping to be able to turn off just one method somewhere, but likely that is not the case.

On Sat, Dec 1, 2018 at 2:46 PM Marek T. <marek.tw...@gmail.com> wrote:

It's not clear if Bert need to kill every safeZ that exists in the system, maybe only very few. This what you tell kills them all.
Bert, you must knew this but maybe not. It's usable to put debug descriptions near the safeZ callings that you want to eliminate, first - before commenting them. Then you'll find in the log which one is really harmful for you.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0082136b-3e15-4d32-8feb-113934ea4613%40googlegroups.com.

[bert shivaan]

Jason seems like I am the first and likely only user needing/wanting to get rid of this. Maybe on oPNP v2 it becomes a selectable option - or not.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jzVgA%2Bpa23UXNGoe%3D%2BdhJ_B-_SegZuK6JBxWMFT3yYiOQ%40mail.gmail.com.

[bert shivaan]

Seems like I have this sorted out for me?

Just in case anyone is interested, with my test job of pick up 6 parts (1 per nozzle) from the same feeder, then place them all .2 inches apart
.

using un-modified code, this takes 51 seconds to complete the job according to the bottom left corner.

removing all the move to safe Z runs the same board in 32 seconds. so saving 20 seconds on this simple test - AMAZING!!

Now do I replace the far file in my "production" setup of just run the compilied version?

[Marek T.]

Put your jar in place where original one lays on the moment.

[bert shivaan]

OK I will do that.

Just tested at home (fresh iinstall) and replacing the jar file works perfect!!

In fact, running the same job on new install took 61.1 seconds, swapped jar and the time went to 38.8 seconds.

I'll take that!!!

On Sun, Dec 2, 2018 at 12:05 PM Marek T. <marek.tw...@gmail.com> wrote:

Put your jar in place where original one lays on the moment.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a51e34db-c290-4488-b577-030093194753%40googlegroups.com.

[Marek T.]

Remember in this case new jar may not work if replaced into some old installed package. It may use some libraries missing in old package. So only jar replacement is not enough in every cases, depend on changes range.
In this specific case I guess you have installed stable release on this second computer and it's still using old opencv probably. New jar is develop and using new opencv 342-1. So it won't work and you need to do there a full new install.

[Marek T.]

If I turn off allign vision get cph near 4000. With vision it drops much below 2000.
In my case openpnp without vision is the same fast as before retrofitting. Vision is narrow throat in openpnp.

[Jason von Nieda]

It would be interesting to see some comparisons to the old before retrofit. Do you have any videos? We might be able to understand where the slowness is.

The actual vision ops in OpenPnP are really quite fast - usually on the order of a few milliseconds if you aren't saving debug images. But maybe the old machine used a flash to take the picture and did not require a settle time? Or maybe it had a global shutter and didn't even stop over the camera at all?

I'm very interested to know where these bottlenecks are. I can't fix them without knowing what the problem is. So if you can find areas that are slow and file issues then we can make them fast :)

Jason

On Sun, Dec 2, 2018 at 11:54 AM Marek T. <marek.tw...@gmail.com> wrote:

If I turn off allign vision get cph near 4000. With vision it drops much below 2000.
In my case openpnp without vision is the same fast as before retrofitting. Vision is narrow throat in openpnp.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6ab4617a-5144-4deb-a5fd-fa812a0189b7%40googlegroups.com.

[Marek T.]

The problem is just the settle time. If I turn it off (set 0) get blurry picture. To get always good pictures I must do in my machine the settle time like 140ms.

Trully it's value from old experiments and maybe today could be shorter but not less than 100ms.

So we send the head to the camera, settle time, picture, correction, settle time, picture, go_to_placement. Is it the complete allign sequence or I'm wrong about this second settle time?

If this second settle time exists it could be removed or be separately parametrized. It's because any xyz moves while correction are so small and short-timed than it seems no sense to loose another hundred milisecunds again.

Another problem which I may understood wrong as many times when we talk about the vision. When we need a picture we do something like "deliver mi a picture", isn't it? If it is the question is - how it is related to the camera set fps and fps really available in Openpnp, otherwords: how long do we need to wait for the picture. Is this not any "connected", if we'd have real 30-60fps available it wouldn't help anyway?

[Jason von Nieda]

On Sun, Dec 2, 2018 at 1:09 PM Marek T. <marek.tw...@gmail.com> wrote:

The problem is just the settle time. If I turn it off (set 0) get blurry picture. To get always good pictures I must do in my machine the settle time like 140ms.

Trully it's value from old experiments and maybe today could be shorter but not less than 100ms.

So we send the head to the camera, settle time, picture, correction, settle time, picture, go_to_placement. Is it the complete allign sequence or I'm wrong about this second settle time?

If this second settle time exists it could be removed or be separately parametrized. It's because any xyz moves while correction are so small and short-timed than it seems no sense to loose another hundred milisecunds again.

That's correct, if you are using pre-rotate. I didn't write that code, and I don't really understand why the second check is needed. No other PnP does this, as far as I know. It may be that it's intended to correct any final small error. There are comments in the code to that effect. Cri S wrote that code and never fully explained how or why it worked. More information here: https://github.com/openpnp/openpnp/pull/590#issuecomment-403222572

If you want to experiment, try commenting the lines around 120-131 in ReferenceBottomVision. You'll have to set it up so the offsets are calculated with the previous angle, but it should be pretty easy.

Another problem which I may understood wrong as many times when we talk about the vision. When we need a picture we do something like "deliver mi a picture", isn't it? If it is the question is - how it is related to the camera set fps and fps really available in Openpnp, otherwords: how long do we need to wait for the picture. Is this not any "connected", if we'd have real 30-60fps available it wouldn't help anyway?

No, FPS is unrelated to vision operations. When any vision code needs an image it calls Camera.capture() which grabs a fresh image from the camera and returns it immediately. This is why I always tell people to use low FPS. FPS is only related to what you see on screen, and high FPS just uses more CPU with no benefit.

Jason

 

W dniu niedziela, 2 grudnia 2018 19:05:04 UTC+1 użytkownik Jason von Nieda napisał:

It would be interesting to see some comparisons to the old before retrofit. Do you have any videos? We might be able to understand where the slowness is.

The actual vision ops in OpenPnP are really quite fast - usually on the order of a few milliseconds if you aren't saving debug images. But maybe the old machine used a flash to take the picture and did not require a settle time? Or maybe it had a global shutter and didn't even stop over the camera at all?

I'm very interested to know where these bottlenecks are. I can't fix them without knowing what the problem is. So if you can find areas that are slow and file issues then we can make them fast :)

Jason

On Sun, Dec 2, 2018 at 11:54 AM Marek T. <marek.tw...@gmail.com> wrote:

If I turn off allign vision get cph near 4000. With vision it drops much below 2000.
In my case openpnp without vision is the same fast as before retrofitting. Vision is narrow throat in openpnp.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6ab4617a-5144-4deb-a5fd-fa812a0189b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5a0e2514-e0d0-4fcc-a559-a33e10fa96c3%40googlegroups.com.

[Marek T.]

Having "Juki" no possible to work without the prerotate until nozzle auto-calibration is ready.

Ok, I will look into the code and try find what eat most of the time and what can comment without penalty. Maybe last shot is used just to get final picture showing well alligned part?

If camera has set low fps, let it be 2fps i.e. to explain what I mean. It means camera living with its own life delivers images to the output in every 500ms. At some 0ms, 500ms, 1000ms etc.

If we call Camera.capture() being at 100ms on time axis then we really get image immediately or we need to wait 400ms until image is ready at 500ms?

Or if we call capture at 400ms - do we get image immediately or after 100ms?

Sorry for primitive explanation, English barrier to explain it more elegant...

[bert shivaan]

OK my $.02 about vision. In my very limited experience, we want real time video for set up type things and frame grabbing for production.

My commercial machine had hybrid I think. The down looking camera seemed to be realtime but the up looking were frame grab only. and the frame grab was on the fly with flash/strobe fired by the motion system.

Is there any way in the future to implement strobe type?

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ee16c172-b648-4ab9-8be8-83a9220a0983%40googlegroups.com.

[Marek T.]

You can now turn on light before camera capturing and off after it.
I'm not sure if it flashes at exactly proper moment, I mean that maybe camera should control flashing.

[bert shivaan]

the way the strobe system should work is at the exact moment the nozzle is centered over the camera it should strobe and grab the frame.

I don't think the camera knows when the nozzle is over top of it so cant do it strickly on the fly without the help of the motion system.

Maybe something could be done through the motion controller

, but not sure how that would happen either.

What does the setteling time do? I mean what are we waiting for when we wait? Is it a camera thing or maybe time for the machine to stop shaking?

On Sun, Dec 2, 2018 at 4:34 PM Marek T. <marek.tw...@gmail.com> wrote:

You can now turn on light before camera capturing and off after it.
I'm not sure if it flashes at exactly proper moment, I mean that maybe camera should control flashing.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3e0f158c-399b-463d-a1a2-1f494764c480%40googlegroups.com.

[Marek T.]

Time to be sure the nozzle achieved the stable position over camera and can take no blurry snapshot.
This what you say I meant moreless, moment of flash and image grabbing should be both made in synchronized moment.

[Jason von Nieda]

Settle time is a combination of several things:

* waiting for the machine to stop moving, flexing, etc.
* wait for lights to be on and stable.
* wait for camera to adjust any auto settings like exposure and white balance.

Ways to speed it up:

* Use a global shutter camera, strong flash, and fast shutter speed. Then you can take a picture and it will “freeze” the motion.
* Make sure machine stops fast (high acceleration) and does not bounce around (high mass)
* turn off auto settings on camera - especially exposure.
* leave lights on instead of triggering on capture

As far as triggering, it’s my understanding that this is usually done by the motion controller. Only the motion controller knows the exact instant when the nozzle is over the camera, so it can fire the trigger signal as the nozzle passes by. High end motion controllers have this output and high end camera systems have the input, which will both fire the strobe and capture the image.

Anyone with this kind of hardware is welcome to ask me to help make it work with OpenPnP. I’d be happy to help!

Jason

On Sun, Dec 2, 2018 at 3:56 PM Marek T. <marek.tw...@gmail.com> wrote:

Time to be sure the nozzle achieved the stable position over camera and can take no blurry snapshot.
This what you say I meant moreless, moment of flash and image grabbing should be both made in synchronized moment.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/34891afa-1b04-4c28-bdf5-e9dd09f0faf1%40googlegroups.com.

[bert shivaan]

LOL, so my $10 mega running GRBL and $30 USB "microscope" may not be up to the task you say?

I could imagine motion control software being altered to provide the output but not sure how to fire the camera. I am assuming there is not really an input to say "take picture"

Also did you see MArek question about fps? Do we wait for the camera to send out a new pic or do we tell it we want one?

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jw4SfgUKbEkBFLgh8ic-p71o7Gy5keY7n-iRcN9GZNPtQ%40mail.gmail.com.

[Jason von Nieda]

Cameras with external triggers can be found used pretty cheap on eBay and such.

FPS: answered his email earlier, check previous messages. FPS not related to capture speed.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNyHvRAt7sE3bbv2rjp-BMc7pFLdSiB0i70ycwqo3JFB8Q%40mail.gmail.com.

[Marek T.]

You have not understood my question.
Camera is connected to anything or not is delivering images in programmed time distances (fps). Do you want me to tell that you can get the image from camera whenever you want without waiting for the moment when she deliver an image in agree with her time distanced, asynchronic?

[Jason von Nieda]

Hi Marek,

There are three "FPS" settings involved.

1. The physical camera has a "max" FPS that is set when you set the format. This is the max FPS the camera can deliver for a specific resolution and image format. I *think* (not 100% sure) that if you ask the camera for images faster than this then you just get the last image until it has processed a new one.

2. The OpenPnP "Camera" has an FPS setting. This is basically the speed at which the camera thread will ask the physical camera for a new image and then dispatch it to the rest of OpenPnP.

3. The Camera View - the actual GUI widget that shows the camera - has an FPS setting that is the one I described before. This is used to slow down #2 when more than one camera is showing.

When a vision operation wants an image it skips #2 and #3. It asks the camera for an image directly. So, there is the possibility that when you ask for an image from the camera you might get the last one it processed, but you don't have to wait for whatever the setting is in #2 or #3.

So, let's say you set the format of the camera to 1280x720, 30 FPS, MJPEG. This means that the camera will have a new frame ready every 33.3ms. So, if you ask for two images faster than 33.3ms you might actually get the same image, I think. I'm not 100% sure on this. It may be that it is platform dependent, or even camera dependent. Niels might know better than me.

In general, though, I don't think it's an actual problem because no one is asking for two images faster than the max FPS of the camera for vision operations.

Does that answer your question?

Jason

On Sun, Dec 2, 2018 at 5:06 PM Marek T. <marek.tw...@gmail.com> wrote:

You have not understood my question.
Camera is connected to anything or not is delivering images in programmed time distances (fps). Do you want me to tell that you can get the image from camera whenever you want without waiting for the moment when she deliver an image in agree with her time distanced, asynchronic?

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9ed0db64-95aa-44db-9552-33a0ebf2a756%40googlegroups.com.

[Bernd Walter]

That can't be entirely true.

I'm doing a TCP stream.
raspivid is asked to do a specific FPS, which is 10 FPS in my case.
The camera system produces an MJPEG stream with 10 FPS, as long as the stream
flows.
The camera takes a picture every 100ms and it is processed by the GPU to do
the MJPEG encoding, so there is some buffereing there too, even before it hits
the TCP network buffers.
Same as the TCP buffers goes for the USB buffer, although they are likely
smaller.
There is always some kind of buffering involved somewhere along the line.

When 2 can't take the 10 FPS all the time then the data from the camera will
buffer up somewhere on the way and when the vision wants a picture it will
not get a fresh image from the camera, it will gets the oldest picture from
the buffer.
If 2 stalled for some reason, then the "fresh" picture can be as old as the
stall.

Also with just 10FPS it takes 100ms for each picture, plus some buffered
along the path you wait at least 100ms for each buffered picture to expect,
plus at average 50ms for the next to be taken.
At least one buffered image has to be expected.
And if your camera does autotuning, then you might have to wait several
pictures for the camera to settle after movement.
That said - camera in automode is a showsstopper anyway.

All in all I think you do the best possible, but for the understanding you
always have to consider that there is something in front of OpenPnP.

There are some interesting OpenSource FPGA camera boards I've seen in
development, which would allow for tight control over the camera.
Greg Davill did some work on this, as well as others.
All in all very interesting work they do.

> On Sun, Dec 2, 2018 at 5:06 PM Marek T. <marek.tw...@gmail.com> wrote:
>
> > You have not understood my question.
> > Camera is connected to anything or not is delivering images in programmed
> > time distances (fps). Do you want me to tell that you can get the image
> > from camera whenever you want without waiting for the moment when she
> > deliver an image in agree with her time distanced, asynchronic?

--

B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

[Jason von Nieda]

Hi Bernd,

To be clear, I am only referring to USB cameras using the openpnp-capture library, since that is the most common setup and is also the only one I know in depth. I don't believe there is any such USB buffering or stacking of images. There is not a stream of images coming from the camera - we request one be "grabbed" and then "read". The image that is returned during the "read" operation is the one that was "grabbed". This is easy to prove - simply connect to a camera, grab a frame, move the camera, wait 1 second and then grab another frame. The new frame will show where the camera is now, not where the camera was one second ago. If what you were describing were correct (for USB) then we'd have to read every image that was captured during the 1 second before we get the correct image. That is not the case.

Again, this only applies to USB and openpnp-capture.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/20181203033804.GA31166%40cicely7.cicely.de.

[Bernd Walter]

On Sun, Dec 02, 2018 at 09:52:06PM -0600, Jason von Nieda wrote:
> Hi Bernd,
>
> To be clear, I am only referring to USB cameras using the openpnp-capture
> library, since that is the most common setup and is also the only one I
> know in depth. I don't believe there is any such USB buffering or stacking
> of images. There is not a stream of images coming from the camera - we
> request one be "grabbed" and then "read". The image that is returned during
> the "read" operation is the one that was "grabbed". This is easy to prove -
> simply connect to a camera, grab a frame, move the camera, wait 1 second
> and then grab another frame. The new frame will show where the camera is
> now, not where the camera was one second ago. If what you were describing
> were correct (for USB) then we'd have to read every image that was captured
> during the 1 second before we get the correct image. That is not the case.

Ok - I thought it is actually a stream from the USB cameras as well.
So bassicly you request single pictures.

> Again, this only applies to USB and openpnp-capture.

Well, it works reasonable well in my setup.
Finding out how to get the raspi camera into fixed exposure and white balance
was the most tricky part.
You just can't configure a stable pipeline with autosetup.

This is what I do on the raspberies:
raspivid -t 0 -n -w 800 -h 600 -v -e -ss 400 -awb off -awbg 1.4,1.8 -ev 1 -ex off -ag 16.0 -dg 1.0 -ih -fps 10 -cd MJPEG -o - | nc -k -l 8081 -O 32768
raspivid -t 0 -n -w 800 -h 600 -v -e -ss 800 -awb off -awbg 1.6,2 -ev 1 -ex off -ag 16.0 -dg 1.0 -ih -fps 10 -cd MJPEG -o - | nc -k -l 8081 -O 32768
The cameras have a slightly different setup because of light conditions.
800x600 is not a native resolution, but I've used it and was too lazy
to change until I do a planed major mechanical modification on the machine.
There may be some leftover parameter, which are useless.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jyJ5uzpcMpr-MVLvMuX5tgXaXMxGp45%3DpCRHiCqGuEL%2Bg%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.

[Marek T.]

Thx Jason, if it is true it works this way - it is clear now :-).

[Mark]

Hi everyone

 

> I am only referring to USB cameras  … There is not a stream of images coming from the camera

 

I think there is streaming in USB since USB 1.1:

https://en.wikipedia.org/wiki/USB_video_device_class#Revision_history

 

Latency does seem to happen in various buffer and processing stages:

“Each stage works independently of the others, and while one frame is being processed by the image scaler, the next is being captured by the video decoder.”

http://www.us-tech.com/RelId/1490472/ISvars/default/Understanding_Video_Latency.htm

 

Still, the FPS do contribute to the overall latency, the higher the FPS, the smaller the overall latency the shorter you can set the settling time. This is most evident with large FPS differences, like between my ELP camera 6 FPS 1980x1080 YUV2 format vs. the 60 FPS 1280x720 MJPG format. The former (not surprisingly) requires a much higher settling time. I tried.

 

And BTW the Windows port of openpnp-capture does not implement custom FPS setting…

https://github.com/openpnp/openpnp-capture/blob/1b2153d4b8550120c5e58a30eb85e4f3a5529a73/win/platformstream.cpp#L508

…nor does the mac port

https://github.com/openpnp/openpnp-capture/blob/1b2153d4b8550120c5e58a30eb85e4f3a5529a73/mac/platformstream.mm#L302

…only the Linux port does

https://github.com/openpnp/openpnp-capture/blob/1b2153d4b8550120c5e58a30eb85e4f3a5529a73/linux/platformstream.cpp#L584

 

If I understand correctly, this means the FPS setting in OpenPNP has no effect on Mac / Windows. The Camera will always send a stream with the full FPS as advertised in the Format drop down. These resolution + FPS + compression setting are each optimized to fill up the USB 2.0 streaming bandwidth which nowadays seems to be the bottleneck (the camera could probably do better but is limited by USB).

https://github.com/openpnp/openpnp/wiki/OpenPnpCaptureCamera#multiple-cameras

 

 

> If what you were describing were correct (for USB) then we'd have to read every image that was captured during the 1 second before we get the correct image.

 

I think this is exactly what is happening behind the scenes. Images are processed in the background, but just never picked up by OpenPNP. Windows for instance is implemented as Sample Grabber here…

https://github.com/openpnp/openpnp-capture/blob/1b2153d4b8550120c5e58a30eb85e4f3a5529a73/win/platformstream.cpp#L352

that calls back for each sample in the stream here…

https://github.com/openpnp/openpnp-capture/blob/1b2153d4b8550120c5e58a30eb85e4f3a5529a73/win/platformstream.cpp#L79

that copies the sample over into the “stream” which seems to simply keep the last image in a buffer…

https://github.com/openpnp/openpnp-capture/blob/1b2153d4b8550120c5e58a30eb85e4f3a5529a73/common/stream.cpp#L59

which is then picked up when needed. All the samples (at full FPS) are processed through all the decompression/color space filters etc. and the buffer image is just overwritten again and again.

 

Those two last point – not implementing custom FPS and handling the full stream – are also the reason…

 

a) why one USB Root Hub can still only manage one camera even with MJPEG compression (as tested under Windows) and

b) why we might have the high CPU usage issue as described here: https://github.com/openpnp/openpnp/issues/687

 

I don’t know if there is a way to only capture single frames instead and if it will actually be faster in the end(!). USB Webcams are clearly optimized for streaming, so maybe this is still the best option. This also eliminates the latency that would be present when commanding the camera to capture the frame. Having high FPS is good for low latency (as explained above). However it should be possible to discard unused frames without so much CPU load (sadly I don’t know how to achieve that, maybe go for the newer Media Foundation/Source Reader API?).

 

> Only the motion controller knows the exact instant when the nozzle is over the camera, so it can fire the trigger signal as the nozzle passes by. High end motion controllers have this output and high end camera systems have the input, which will both fire the strobe and capture the image.
Anyone with this kind of hardware is welcome to ask me to help make it work with OpenPnP. I’d be happy to help!

Having the camera on fixed exposure (not auto) then switching on the light via G-code immediately after an M400 (motion queue empty) could be used as a very fast controller synced signal into the video stream: the first image that bubbles out of the stream with brightness above a certain threshold is the one. All latencies are then automatically properly accounted for. No need to have a conservative settle time that has to cover the worst case of all possible streaming latencies plus the worst case frame rate alignment. No need for configuration at all.

 

The brightness detector should of course look at the earliest band of scanlines of the sensor (usually the top band of the image. Put a little white object into the “peripheral vision” there, mounted on the camera&light. The brightness detection would then focus on that spot (a few pixels) and even be done by openpnp-capture for the least overhead. Perhaps the capture call from OpenPNP could simply be blocked until such a bright frame bubbles up (with timeout of course).

 

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jyJ5uzpcMpr-MVLvMuX5tgXaXMxGp45%3DpCRHiCqGuEL%2Bg%40mail.gmail.com.

[Jason von Nieda]

Hi Mark,

The "physical FPS" I am referring to is part of the "format". The formats are enumerated by the camera and one is chosen. The custom FPS field you are referring to as not implemented was added to provide a way to reduce the frame rate from the max, instead of just using the max.

I'm not claiming that there isn't latency - of course data takes time to move through the various systems - but there is no piling up of frames when OpenPnP isn't keeping up with reading them. When OpenPnP calls Camera.capture() for a vision operation the image it will get will be the last one processed by the camera.

In case it's been lost in the thread, the claim I was refuting was:

When 2 can't take the 10 FPS all the time then the data from the camera will
buffer up somewhere on the way and when the vision wants a picture it will
not get a fresh image from the camera, it will gets the oldest picture from
the buffer.
If 2 stalled for some reason, then the "fresh" picture can be as old as the
stall.

Again, this is *very easy* to test and prove if you want to see it yourself. openpnp-capture has a simple interface that you can write a test program for in about 10 minutes. Capture an image, write it to disk, sleep for 10 seconds and during those 10 seconds change what is in view of the camera. Capture an image, write it to disk. Look at the two images.

I'm not talking about a theoretical system - I'm talking about what happens in OpenPnP today.

a) why one USB Root Hub can still only manage one camera even with MJPEG compression (as tested under Windows) and

I am honestly just so tired of reading this incorrect claim. I invite you to *test* it yourself. Hook up two ELP (or other well behaved) cameras and actually try it, as I did, repeatedly. As Neils did *while developing the library* you are quoting. It works correctly on all three operating systems. This was the entire reason we undertook the months long development effort and is the reason we released it when it was *tested* and finished.

If you are unable to get two cameras working on a single hub please file a bug report with details on the cameras, operating system, and USB tree. We will attempt to reproduce and fix it.

Jason