Placement orientation incorrect with Bottom Vision (only nozzle1)

[Simon Hölldobler]

Hey,

I try to equip my first board with openpnp, this also works if I switch off the botton vision.

When I use the botton vision, the orientation of the component that is placed by nozzle 1 is wrong by about 20 °, nozzle two works perfectly with bottom vision and places the parts correctly.

What is also noticeable is that nozzle 1 turns several times on the way from the feeder to the camera, nozzle 2 doesn't do that.

If I switch off the botton vision, the component is also correctly positioned by nozzle 1.

i compared the settings of nozzle 1 and 2 in openpnp and also in the config of the smoothieboard and they look identical to me.

I've also attached a video that shows the rotation of nozzle 1 (left).

hope someone can give me a tip, what is the cause of the problem.

[tony...@att.net]

Please post your machine.xml file, your log file (use Trace level), and debug images from bottom vision.

Tony 

[Simon Hölldobler]

Hello Tony,

attached the requested files.

Thanks

Simon

[tony...@att.net]

Something strange is going on here:

2021-02-14 18:44:34.886 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M204S188.32G1Y96.39A0X151.39F11571.83 

2021-02-14 18:44:34.886 GcodeAsyncDriver DEBUG: serial://COM3 commandQueue.offer(M114 ; get position, -1)... 

2021-02-14 18:44:34.887 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok 

2021-02-14 18:44:34.887 GcodeDriver TRACE: [serial://COM3] confirmed M204S188.32G1Y96.39A0X151.39F11571.83 

2021-02-14 18:44:34.888 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M204S50G1Z-0.4F268.33 

2021-02-14 18:44:34.889 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok 

2021-02-14 18:44:34.889 GcodeDriver TRACE: [serial://COM3] confirmed M204S50G1Z-0.4F268.33 

2021-02-14 18:44:34.890 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M400 

2021-02-14 18:44:39.270 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok 

2021-02-14 18:44:39.270 GcodeDriver TRACE: [serial://COM3] confirmed M400 

2021-02-14 18:44:39.271 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M114 

2021-02-14 18:44:39.273 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok C: X:151.3900 Y:96.3900 Z:-0.4000 A:337.2263 B:-0.6763 

2021-02-14 18:44:39.273 GcodeDriver TRACE: Position report: ok C: X:151.3900 Y:96.3900 Z:-0.4000 A:337.2263 B:-0.6763 

2021-02-14 18:44:39.273 GcodeDriver TRACE: GcodeDriver got lastReportedLocation (y:96.390000, z:-0.400000, rotationN1:337.226300, x:151.390000, rotationN2:-0.676300) 

2021-02-14 18:44:39.274 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete. 

2021-02-14 18:44:39.274 AbstractMotionPlanner DEBUG: Reported location changes current location from (y:96.390000, z:-0.400000, rotationN1:0.000000, x:151.390000, rotationN2:-0.676341) to (y:96.390000, z:-0.400000, rotationN1:337.226300, x:151.390000, rotationN2:-0.676300) 

At 18:44:34.886 the controller was told to move the A axis to 0 degrees and at 18:44:39.270 it responded saying the move was complete.  But at 18:44:39.273 it reports that the A axis is at 337.2263 degrees which is about a 23 degree difference.  So the question is, why did the controller send the A axis to 337.2263 degrees rather than 0 degrees?  Do you have motor drivers that can sense missed steps (like some Trinamic drivers)?  If so, perhaps your N1 motor is missing steps?

Tony

[Simon Hölldobler]

Hi Tony,

you are right i use the TMC2208 driver, i change the driver to a new one and remove the jumper for the UART Line but with the same result.

when I'm on the parts page and click "pick the selected part ...." after that i click on "Text Alignment"

Nozzle 1 then rotates a few times on the way to the bottom cam.

When I do the same with nozzle two, it stands still on the way to the camera and doesn't turn.

What can i do?

Thanks

Simon

[ma...@makr.zone]

Hi Simon

Is this a custom firmware build where you merged TMC2208 support in? The last PR was not merged, right?

And does it in deed have closed loop?

_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/19d6e957-9eaf-47f7-814b-52a92747cd39n%40googlegroups.com.

[Simon Hölldobler]

Hi Mark,

no i use the standard firmware, i know Smoothieware and this driver was not the best choice.....

for now is working with all axes, only the nozzle 1 (E1) have this problem :-(

the stepper/driver have no closed loop, i use standard NEM17 stepper without a feedback to the driver.

Simon

[Simon Hölldobler]

What I also cannot explain to myself is why is the component placed correctly when I switch off the botton vision?

if the botton vision for the component is switched off, both nozzles only turn the correct 90 °

[ma...@makr.zone]

Hi Simon

Assuming you are Simon24j:

Are you sure that issue is really, really solved?

https://github.com/openpnp/openpnp/issues/1120#issuecomment-774674476

Can you post the config.txt again?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/89202f71-58bb-47dd-86c4-dc99e69b3f7bn%40googlegroups.com.

[ma...@makr.zone]

Found it!

Smoothieware seems to use a numeric parser that reacts to C radix prefixes. 0x or 0X are Hexadecimal prefixes.

https://en.wikipedia.org/wiki/Hexadecimal

So A0X151.39 is interpreted as A 151.39 hex which is exactly the A 337.2263 decimal we get back from M114!  

So I suggest you move your X axis to the top using the black arrow buttons. This way it will never come after a zero.

Then regenerate the MOVE_TO_COMMAND using Issues & Solutions.

Or you can switch off G-code compression on the Driver.

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

Ultimately I will need to fix the Smoothieware firmware. This is clearly illegal behavior in the context of NIST RS274NGC Interpreter - Version 3, section 3.3.2.1.

https://www.nist.gov/publications/nist-rs274ngc-interpreter-version-3

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5a218d3f-ecae-d9d8-c6a6-a0d05addec9d%40makr.zone.

[ma...@makr.zone]

Yep, Smoothieware uses strtof()

A valid floating point number for strtof using the "C" locale is formed by an optional sign character (+ or -), followed by one of:

• A sequence of digits, optionally containing a decimal-point character (.), optionally followed by an exponent part (an e or E character followed by an optional sign and a sequence of digits).
• A 0x or 0X prefix, then a sequence of hexadecimal digits (as in isxdigit) optionally containing a period which separates the whole and fractional number parts. Optionally followed by a power of 2 exponent (a p or P character followed by an optional sign and a sequence of hexadecimal digits).
• ...
  

https://www.cplusplus.com/reference/cstdlib/strtof/

https://github.com/Smoothieware/Smoothieware/blob/18ee2483ab327ae1b9f9c99f88cf8ee8b85f3a92/src/modules/communication/utils/Gcode.cpp#L81-L97

This is obviously not OK for G-code.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d04d0050-9675-aa16-a720-bcbef05dfd00%40makr.zone.

[ma...@makr.zone]

Hi everybody

I made a new firmware version (5-axis and 6-axis) for Smoothieware that fixes the problem described in this thread.

I don't think it is super urgent for you to update, as the bug won't happen if you have the X axis as the first axis in the machine setup and if you have no E axis (you shouldn't anyway).

More details in the section "G-code Command Decimals":

https://makr.zone/smoothieware-new-firmware-for-pnp/500/

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/81e0d212-0353-6bc8-7b97-30feb28e45b0%40makr.zone.

[Simon Hölldobler]

Hi Mark,

i tested you new firmware yesterday and the orientation problem is solved.

Thank you so much, your support is really excellent.

Yes I'm simon24j

Simon