RRP IR Probe randomly reads insanely large value

So,

I've been having a random issue with the RRP IR Probe on the O2.

Occasionally on the web control, I'll see the IR probe report a value in perhaps somewhere in the millions (well beyond the max of 1024), it only occurs for fractions of a second so it's very hard to catch and I suspect it sometimes happens when the web control isn't 'reading' (between pings, if that's the correct term here) from the duet. The rest of the time the readings seem normal.

The issue is that if an X home or Z home, or bed level probe are in progress the firmware thinks it's at the trigger point for the IR probe. If I move close to where triggering should occur and home, I can home without issue. But if I home too far away it'll have a problem.

Also, back when assembling the printer the IR loom had a couple of wires reversed and the probe was ran this way for a while before I could figure out why it always read 1024 (1024). I'd assumed that it survived the experience undamaged because I got reasonable numbers out of it after that..... but thought I'd mention it

I suspect there might be a loose wiring connection somewhere.... but wondering what you guys think.

Running

Firmware Version: 1.04e-dc42 (2015-04-09)
Web Interface Version: HTML: 1.05, JS: 1.05 ZPL's version right before tonights release of 1.06

Edited 1 time(s). Last edit at 04/16/2015 10:09PM by shadow651.

I started experiencing this same problem today as well. I didn't have a lot of time to play with it so I am also unsure as to the cause.
Firmware Version: 1.04c-dc42 (2015-04-02)
Web Interface Version: HTML: 1.05, JS: 1.05

That's a strange problem, one that I haven't seen. If the zprobe reading on the web interface is very high AND probing terminates before it should, then it sounds like a firmware issue. Does the problem always occur at the start of a Z home or Z probe, or can it occur at any time? If it is just occurring at the start, then one thing you can try is to look for all the M558 commands in the homex.g, homez.g and homeall.g files, and comment them out. Leave the M558 P2 command in config.g.

Explanation: RepRapPro's firmware switches the sensor into unmodulated mode when homing the X axis, because their firmware fork modulates the IR sensor too slowly to give a fast enough response when X homing. My fork modulates it much faster, so this is not necessary. I'm thinking that the code that switches the IR sensor mode may produce a glitch in the reading when the mode is switched.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

well, today it seems to be behaving normally......


I'll try to investigate it further if I start seeing this issue again, maybe it only happens after a lot of printing? But I did try restarting the printer when I first had the homing issue, odd

I've found a possible race condition in the code for switching probe type, which I believe I have now fixed. This, along with the M558 commands in RRP's homing files, might explain the high readings, if they only occur during homing.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Well, I've been using your provided home files, so there wasn't any M558 Commands

This seems to happen randomly, but not only when homing, the printer can be sitting preheating and I see this as well.

It seems to be a rare occurrence, but mainly towards the end of the day if I've been using the printer a lot.

Edited 1 time(s). Last edit at 04/20/2015 02:07PM by shadow651.

Try version 1.04f (just released). If that shows the same problem, let me know and I'll try connecting an RRP modulated sensor to my Ormerod to see if I can reproduce the problem.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Try version 1.04f (just released). If that shows the same problem, let me know and I'll try connecting an RRP modulated sensor to my Ormerod to see if I can reproduce the problem.

I'm still seeing it on 1.04f.

If trying to reproduce, I'd recommend trying to home X from X ~190, you'll see it truncate early.

I think I just spotted the problem. I'll build another binary tomorrow.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Try the 1.04g preview, available here [dl.dropboxusercontent.com].

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Try the 1.04g preview, available here [dl.dropboxusercontent.com].

Trying this today, thanks. Will repost if the issue reoccurs for me.

Quote
dc42
Try the 1.04g preview, available here [dl.dropboxusercontent.com].

I'll also try this out tonight when I get home. I'll let you know if I do or don't see it again

Quote
shadow651

Quote
dc42
Try the 1.04g preview, available here [dl.dropboxusercontent.com].

I'll also try this out tonight when I get home. I'll let you know if I do or don't see it again

This preview version seems to have fixed the problem, Thanks!

Edit: after a few hours printing still no issues. I've also noticed that noise on the z probe has been significantly reduced.

Edited 1 time(s). Last edit at 04/21/2015 12:38AM by shadow651.

I think that the wire is wrong,I have done it a few days ago. after I adjusted it. Now it is normal....