feeder QR scanning issue

[Shai]

Hi Mark,

It seems that either I am doing something wrong here or OpenPNP has an issue scanning rapid feeder QRs now. I fixed the virtual Z axis so that the head doesn't move up/down (sorry been a while since I've updated the test branch). The scan appears to never end. It keeps attempting to scan (I think) but the head stops moving (as it should, since it reached the end). 

As you can see from the video, there are two feeders mounted but neither address of the QR code gets populated in OpenPNP (no new feeder added).

See video here: https://youtu.be/vRYlR_RH1lQ

Log: https://pastebin.com/pGjF2zSV

Latest machine.xml (star machine) attached.

[mark maker]

Hi Shai

I had a look at the RapidFeeder code. There is a numerical instability in there.

If the distance from start to end is exactly a multiple of the increment, the loop will never end, because it lands exactly on the end point and can no longer create the next point along the line to the end point (as the line is zero length).

Workaround: Set the end to 430.1 and it should be OK. 

I've made a fix and will integrate it into the next bugfix roundup. Until then use the workaround.

_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/6574c583-3ea2-4350-9ff2-1fdf90b27ca6n%40googlegroups.com.

[Shai]

Thanks Mark! I just tested it with 430.1 and it populated all the feeders. Not sure why this feature stopped working since Jason wrote this and it worked a while ago. Let me know when the change has been pushed to test branch and I'll be happy to test it again.

[mark maker]

Hi Shai,

As I said it only happens when the distance is an exact multiple. I'm quite sure this exact case never worked!

To be perfectly correct: Since lengths and locations are internally stored as IEEE 754 double values, it might even be possible that internally, i.e. in binary representation, a distance is not an exact multiple, even if it appears that way in decimal representation. The loop was also driven in increments, i.e. each iteration amplified the representational artifact. So maybe with other distances, increments or start/end locations the bug might not have expressed itself previously, even when the distance appeared to be a multiple of the increment. But that was sheer luck.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2a30ff9a-2136-4dd1-b554-4e5efbb3dbf2n%40googlegroups.com.

[mark maker]

In a few minutes, a new testing version will be deployed.

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

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/73ad4fa2-42b1-f96a-1171-024a81fff6c6%40makr.zone.