Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Losing Zero
#1
Bug 
Very curious...

I've set up 3 iGaging scales with an Arduino and a tablet running Yuriy's TouchDRO app.  Works great, except back EMF when I shut the motor off randomly sends Zero to some place in Albuquerque, and it stays there.  I just don't get that.

Okay, I understand back EMF, but these iGaging scales are reporting absolute position, not sending pulses.  If I understand things correctly, the sensors just read the bar to get position.  The Arduino just reads the location from the sensor and ships it out the serial port (I'm using bluetooth serial).  If it gets scrambled for a reading or 2, it should just come back to where it was after the nuclear EMP has passed.  I've looked at the Arduino code and I don't see any history-based manipulation... just in and out.  The stock iGaging heads don't have any issue.  It's just the TouchDRO app.

I can set a point in TouchDRO, and it shows where that point is.  Sometimes, when I turn off the motor, the zero jumps... and the above coordinates of that point also shift.  Why?  All I can think of is that the numbers coming in the serial port are not sanitized by TouchDRO and that they are so far off it is somehow trashing the code.

Is this a bug?

I think I ended up having to invert most of the scale output within the TouchDRO app, which might be generating some big negative numbers if things go wrong.  Next shop day, I'll try removing that check. 

I've already tried sanitizing the Arduino output to make sure the long integers don't go into negative territory by mistake.  That didn't make a difference.  I may get real numbers as reported by the scale and limit all the way down to that.  (next shop day, actually)

I've just added a serial bluetooth monitor to the tablet and will try that next time... anything I should look for?  Anything else I can try?

I had originally planned on making my own DRO head using the Arduino, but Yuriy's app is really nice and it would save me a lot of work... if I can get it working.

David...

P.S.  Yes, I have done some basic shielding, ferrite chokes on the cables etc., though obviously not enough.  But, being absolute reading, so long as the Arduino isn't crashing it should make no permanent difference.  I don't really care if the numbers flick about whist turning off the motor, as I'm rather preoccupied at that point.  But, losing Zero... that's annoying.  It's surprising how fast I became dependent on a DRO Shy
Reply
#2
(09-08-2016, 05:04 AM)fixerdave Wrote: Very curious...

I've set up 3 iGaging scales with an Arduino and a tablet running Yuriy's TouchDRO app.  Works great, except back EMF when I shut the motor off randomly sends Zero to some place in Albuquerque, and it stays there.  I just don't get that.

Okay, I understand back EMF, but these iGaging scales are reporting absolute position, not sending pulses.  If I understand things correctly, the sensors just read the bar to get position.  The Arduino just reads the location from the sensor and ships it out the serial port (I'm using bluetooth serial).  If it gets scrambled for a reading or 2, it should just come back to where it was after the nuclear EMP has passed.  I've looked at the Arduino code and I don't see any history-based manipulation... just in and out.  The stock iGaging heads don't have any issue.  It's just the TouchDRO app.

I can set a point in TouchDRO, and it shows where that point is.  Sometimes, when I turn off the motor, the zero jumps... and the above coordinates of that point also shift.  Why?  All I can think of is that the numbers coming in the serial port are not sanitized by TouchDRO and that they are so far off it is somehow trashing the code.

Is this a bug?

I think I ended up having to invert most of the scale output within the TouchDRO app, which might be generating some big negative numbers if things go wrong.  Next shop day, I'll try removing that check. 

I've already tried sanitizing the Arduino output to make sure the long integers don't go into negative territory by mistake.  That didn't make a difference.  I may get real numbers as reported by the scale and limit all the way down to that.  (next shop day, actually)

I've just added a serial bluetooth monitor to the tablet and will try that next time... anything I should look for?  Anything else I can try?

I had originally planned on making my own DRO head using the Arduino, but Yuriy's app is really nice and it would save me a lot of work... if I can get it working.

David...

P.S.  Yes, I have done some basic shielding, ferrite chokes on the cables etc., though obviously not enough.  But, being absolute reading, so long as the Arduino isn't crashing it should make no permanent difference.  I don't really care if the numbers flick about whist turning off the motor, as I'm rather preoccupied at that point.  But, losing Zero... that's annoying.  It's surprising how fast I became dependent on a DRO Shy

David,
When you shut off the motor the scale cable probably picks up enough noise sot he power supply voltage is reversed momentarily, which resets the scale. You can't fix that in the software, and ferrite beads on the cables won't do anything either.
Try grounding things as good as you can and try to eliminate ground loops in the setup.

Regards
Yuriy
Reply
#3
Dave - I guess you're seeing the same issue I was:

https://youtu.be/UoJWShlXaug

I had grounded everything, and it still did it. After reading the info here:

http://bettec.info/dro/

I added 1uf caps to the power lines at the reader heads, and ensured that the inner shielding of the usb lead was only connected to the usb shield at the interface end, not the reader. This seemed to do the trick.
Reply
#4
(09-08-2016, 03:54 PM)Yuriy Wrote: David,
When you shut off the motor the scale cable probably picks up enough noise sot he power supply voltage is reversed momentarily, which resets the scale. You can't fix that in the software, and ferrite beads on the cables won't do anything either.
Try grounding things as good as you can and try to eliminate ground loops in the setup.

Regards
Yuriy

(09-13-2016, 02:43 PM)GreatOldOne Wrote: Dave - I guess you're seeing the same issue I was:
...
I added 1uf caps to the power lines at the reader heads, and ensured that the inner shielding of the usb lead was only connected to the usb shield at the interface end, not the reader. This seemed to do the trick.

Sorry for the delay in responding... I'm getting limited shop-days right now and wanted to verify a few things.

Yes, I understand that I can do a lot more for noise suppression.  However, because the scales are absolute-reading, I don't think I have to.  I can set a relative zero in TouchDRO, unplug the Arduino (which unpowers the iGaging sensors), wait for 5 minutes, plug everything back in, reconnect bluetooth, and TouchDRO will still hold the same relative zero.  I can even replace the Arduino with another one and still keep zero.  The sensor reads its absolute position from the scale, the Arduino reads that number, and then it sends it via bluetooth to the tablet.  It's just a number.  It doesn't change unless the scales move in the sensors.

I can solder in decoupling caps if I have to, but I'll admit I'm a lazy programmer type...  

I tried running a bluetooth serial terminal on the last shop-day but it turned out to be less than useful.  It didn't log a long enough period of information, and then it tossed what little logging it had.  I'll try again with a better app next day.  I did notice (though I'll admit to only being somewhat confident of this) that the numbers coming from the Arduino were the same before and after an "event."  The numbers just go squirrelly for a little bit.  Exactly how squirrelly, I don't know, but they do go back to where they were.  Thus, there's no reason TouchDRO should retain a permanent change of location, but it does.

Again, I'll try to get better data the next time I'm in my shop.  Specifically, I want to get the numbers over the entire range of movement, on all 3 axis.  I'd also like to get a sample of squirrel data to know exactly why things are going south.

David...
Reply
#5
Well, it turns out I was wrong (but you probably already knew that).

My initial tests showed that I get exactly the same number out before and after a decent power cycle and, from that, I had assumed the scales were absolute-reading.  However, the bluetooth logs show that when the sensors are hit with an EMF event, they sometimes permanently change.  Three times, I saw the y-axis switch from its current reading to "506."  No idea why 506 was the number to be, or if it's always that number, but that new number survived a power-cycle too.

Then, I got to thinking about the other thread here on sensor power consumption, and the measurements I made for that.  I guess the decoupling caps I wired into the Arduino circuit can power the sensors for a long time.

I was wrong and made wrong assumptions because of it.  Sorry for spreading the confusion around.

Sigh... looks like I have to do it the hard way.  I've pulled the scale sensors off and will solder on the decoupling caps.  See where it goes from there...

David...

P.S.  I'm still thinking I might be able to code around it... if I can detect the event, and remember the number it should be, then I just have to figure out the difference and do a little +/- on the output.  Yeah, I'm that lazy.
Reply
#6
(09-16-2016, 06:40 AM)fixerdave Wrote: Well, it turns out I was wrong (but you probably already knew that).

My initial tests showed that I get exactly the same number out before and after a decent power cycle and, from that, I had assumed the scales were absolute-reading.  However, the bluetooth logs show that when the sensors are hit with an EMF event, they sometimes permanently change.  Three times, I saw the y-axis switch from its current reading to "506."  No idea why 506 was the number to be, or if it's always that number, but that new number survived a power-cycle too.

Then, I got to thinking about the other thread here on sensor power consumption, and the measurements I made for that.  I guess the decoupling caps I wired into the Arduino circuit can power the sensors for a long time.

I was wrong and made wrong assumptions because of it.  Sorry for spreading the confusion around.

Sigh... looks like I have to do it the hard way.  I've pulled the scale sensors off and will solder on the decoupling caps.  See where it goes from there...

David...

P.S.  I'm still thinking I might be able to code around it... if I can detect the event, and remember the number it should be, then I just have to figure out the difference and do a little +/- on the output.  Yeah, I'm that lazy.
Hi Folks,
If you have problems with changing readouts (arduino) place a toroid 4C65 in the power line (9 or 12V line) and your problems are gone.

Greetings Jacques
Reply
#7
Jacques
Electronic newbie here. Could you post a pic of this installation?

Thanks
Dennis
Reply
#8
(12-15-2016, 11:26 PM)Clubmaster00 Wrote: Jacques
Electronic newbie here. Could you post a pic of this installation?

Thanks
Dennis

here is a good write up on how they fixed this issue (http://bettec.info/dro/).  I ran into this same problem and by grounding the board and adding the caps to the read head it fixed all my problems.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)