PC based DRO?

Home Model Engine Machinist Forum

Help Support Home Model Engine Machinist Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Well, I haven't investigated this too deeply yet so options are still open. I did put Model B Pi on my wishlist for inexpensive Christmas giving in case wife or any of the kids is looking for something for me.

Is there source code out there for what's been done so far in terms of reading/displaying? I know I would have to figure out how to compile and what includes I would need, etc.

Also, being a newb in terms of DRO, is there a primer/FAQ on the types of slides and pros/cons, etc.? The iGauge slides are glass you say?

Thanks for all the help from everyone who has contributed to this thread.

Paul

Paul,
All of my source code is available (linked from the site) but it won't help you much. The display is Adnroid-specific and is written in Java. Reading iGaging scales is brain-dead easy compared to any other scales and is as simple as looping 21 times while toggling the clock and reading the data line on the low edge. The other scales are MUCH more difficult. I've gotten a semi-working prototype but it's horribly unstable. I'm working a newer version that uses a more powerful MCU and will post the details once it's 'stable'.

There is no good primer on reading the scales. Take a look at these posts:

Harbor Freight Caliper Data Format
Mixed Linear Scale DRO with MSP430 Launchpad
Reading Grizzly iGaging DRO Scales with Arduino

This might give you a bit of "food for thought".
Glass scales are a completely different animal. They add another level of complexity because unlike the caliper-like scales, it's 100% to keep track of position. If you miss clicks with iGaging scales, 1/25th of a second later you can re-read the position. With glass scales, if you miss a pulse, your position will be off from that point on. At 20000 pulses per inch. At one inch per second you have a a bit over microsecond to process each scale's input and get ready for the next one.

Regards
Yuriy
 
This might give you a bit of "food for thought".
Glass scales are a completely different animal. They add another level of complexity because unlike the caliper-like scales, it's 100% to keep track of position. If you miss clicks with iGaging scales, 1/25th of a second later you can re-read the position. With glass scales, if you miss a pulse, your position will be off from that point on. At 20000 pulses per inch. At one inch per second you have a a bit over microsecond to process each scale's input and get ready for the next one.

Regards
Yuriy

For quadrature encoded scales or encoders you might want to consider the use of interface chips to reduce the CPU burden. Yeah this adds an additional expenses and makes for a more difficult board layout. Or go with a CPU chip with a more advanced counter timer facility. Here are some links if you aren't familiar with the hardware out there:

http://www.usdigital.com/products/interfaces/ics/LFLS7083
http://www.usdigital.com/products/interfaces/ics/LFLS7183-S
http://www.avagotech.com/pages/en/m...cts/integrated_circuits/decoder_ic/hctl-2022/
http://www.avagotech.com/pages/en/m.../integrated_circuits/decoder_ic/hctl-2032-sc/
http://www.ichaus.de/keyword/i/o ics
http://www.boondog.com/tutorials/mouse/hctl2000.pdf

There are actually many more varying in complexity and cost. Also don't forget that the likes of Texas Instruments and Micro Chip PIC which have many embedded ICs with built in quadrature decoders. Knowing that these sorts of hardware solutions add costs, below you will find some links to different solutions to solve the quadrature interface issue.

http://www.engr.mun.ca/~nick/eng5951/Optical Encoder.ppt
http://www.rocketnumbernine.com/2010/03/06/decoding-a-rotary-encoder
http://www.robotshop.com/ca/pdf/rbsum05-wheel-encoder-spec.pdf. (Nicely drawn truth table here with this your most efficient code can be realized)
http://forums.parallax.com/showthre...-pasm-code-for-a-gray-code-quadrature-encoder
http://web.eecs.umich.edu/~jfr/embeddedctrls/files/Lab2_W09.pdf
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=62118. (Long thread from one frustrated implementer)
http://makeatronics.blogspot.com/2013/02/efficiently-reading-quadrature-with.html
http://www.circuitsathome.com/mcu/reading-rotary-encoder-on-arduino/

Those might help. There is actually a better site out there someplace that describes the use of the truth tale described in item 3 above. I can't find that site so maybe these will help. In any event getting a CPU to read one quadrature input reliably is a job in and of itself, o do three or more is a bit of a reliability stretch if you ask me. Even the use of simple chips that convert the signals to count & direction or to up and down signals greatly simplify things

One option of course is chips with hardware support for quadrature signals. This can be had either with specialized hardware or enhanced counter modules. If you really want to do an all software solution consider a Parallax Propeller chip.

Best of luck.
 
Can iGage slides be shortened? My mill (U.S. Burke Millrite) y feed is about 9 inches. I only see 6 and 12 inch slides...too short or too long. I don't see a measurement for the over all length but I'm worried the 12 inches might not even fit; might hang out too far in front to be safe.

Similarly the table x feed is around 20 inches but the slides are 24 inches although I think the slide would fit within the table size simply leaving some unused slide at each end.

Paul
 
Can iGage slides be shortened? My mill (U.S. Burke Millrite) y feed is about 9 inches. I only see 6 and 12 inch slides...too short or too long. I don't see a measurement for the over all length but I'm worried the 12 inches might not even fit; might hang out too far in front to be safe.

Similarly the table x feed is around 20 inches but the slides are 24 inches although I think the slide would fit within the table size simply leaving some unused slide at each end.

Paul

Yes, quite easily. I cut mine on the mill, but beware of the fiberglass PCB (the black strip on top) that will dull an end mill in a hurry.

Thank you
Yuriy
 
Paul,
The problem with ARM micro controllers is the added complexity. Since I intended the project to be community-friendly I had to be mindful of the technical skill level of the "target audience". Arduino software is relatively easy to set up and use compared to GNU tool chain with Eclipse etc., With that said, I had to switch to ARM for the "mixed scale" version because MSP430 was simply not fast/flexible enough to read glass scales.
I haven't had time to play with Raspberry PI that much (have one sitting in my MCU box) but I imagine that you will have issues with timing, unless all you intend to use is iGaging scales. In that case it's up to you :) I will definitely be a good learning exercise. Compared to the Arduino or MSP430, Raspberry PI is a super-computer :)

Thank you
Yuriy


One option may be to use the Maple board which has an ST Micro ARM M3 and the arduino format. I have some of these for a project but have not used them yet. I have done several designs using the ST Micro ARM chip.

http://leaflabs.com/devices/maple/
https://www.sparkfun.com/products/10664
http://www.seeedstudio.com/depot/leaf-maple-cortex-m3-p-670.html
 
One option may be to use the Maple board which has an ST Micro ARM M3 and the arduino format. I have some of these for a project but have not used them yet. I have done several designs using the ST Micro ARM chip.

http://leaflabs.com/devices/maple/
https://www.sparkfun.com/products/10664
http://www.seeedstudio.com/depot/leaf-maple-cortex-m3-p-670.html

I'm almost done with the new version of MSP430 firmware and so far the MCU handles four scales of any type pretty well. Four quadrature encoders (two glass scales and two rotary encoders in my case) pose no issues even when I moved them by had at "warp speeds". The real bottkeneck is UART, actually.
If I were to switch to ARM (which I probably will), there is a number of cheaper options. TI's Tiva (formerly Stellaris) and STM Discovery boards sell for well under $20 shipped. The (very) first version of the DRO used STM32VL Discovery and that MCU was able to handle scales, 3 displays (7-segment), keypad and more.

Thank you
Yuriy
 
Hi Yuiry,

I have been busy but finally acquired an Uno (Arduino) and shield and assembled my reisistors, etc. and put together the interface. I get readings for x, y and z in the serial monitor with the Uno hooked through USB to my laptop. So that all seems to work. I did the mini USB breakout boards. Have yet to encase it...

I still don't have a tablet with bluetooth and while I could go buy one I wondered if anything was happening on the USB idea? And would that run on any device running Java or would it still have to be Android powered? I'm thinking I've got an old Dell laptop that could become my dedicated DRO device if I can USB to it.

Paul
 

Latest posts

Back
Top