Spoof the DRO scales to drive a Dividing Head for Helical Milling

[ttabbal]

I've never tried to use an arduino to read quadrature signals. I get the impression that reading them can use a fair bit of cpu cycles. In addition, you need to calculate the pulses and send them to the stepper. The precision required can also require a lot of cycles. And stepping signals need to be somewhat long. That can be handled with interrupts or hardware timers though.

All that can add up to the processor being stressed. The one I mentioned from the ELS project has hardware quadrature decode, so you don't need to use cpu cycles for it. It also means that you will be less likely to miss signals, though you would probably never move the table fast enough for that to be an issue. It also has a floating point unit, so you get high precision calculations for low cycle counts. It's also much faster.

It's hard to say how much that will all matter. I haven't tried it, so it might be a non issue. If you already have the micro, might as well try it. You can write some test code to see how much time things take so you can see if the chip can keep up.

 

[MERLIncMan]

You offer a good detail - floating point - I was thinking about that last night after my post. The 'duino will still need to do operations on the scale pulses to convert them into stepper pulses based on user input. I've never made an arduino do trig before - or any other math for that matter - so I haven't a clue if it has a "math co-processor" or some not-1986 equivalent. If the little thing has to count pulses as well as calculate conversions, she may well let loose the magic blue smoke

Yeah.... going to need a different board. I'll look at yours again and compare it to some others.

You know why it's windy in Utah?

................. because Nevada sucks, and Colorado blows

 

[ttabbal]

Arduinos are great for the price, but they are low cost low power devices. They can do a surprising amount, but there are limits. You wouldn't damage it trying, unless some sort of wiring problem fried it. But my suspicion is that it would be a bit much to expect of the little guy. Particularly without heavy use of interrupt driven code. The usual wait loop would waste too much time. They don't have a floating point math unit. It's not necessary to use float, but if you have one it's usually faster than fixed point integer work.

lol... our neighbors can be amusing for sure. I can't give my home state a complete pass on crazy though, we all have our issues.

 

[Joe in Oz]

Any thoghts on putting an encoder on the divider's stepper motor as an 'angular readout' for feedback?

 

[MERLIncMan]

Any thoghts on putting an encoder on the divider's stepper motor as an 'angular readout' for feedback?

I certainly considered this avenue. It isn't a bad idea for giving certainty to the drive - accounting for lost steps - but using closed-loop adds more complexity to a project that is already at the distant end of my skill-set.
I am confident that I can get a microcontroller to blip a stepper according to some maths, and I'm certain that I can program a menu-tree into said controller, and show it on an LCD. I am nervous about trying to make a TTL govern the maths, uncertain of how to get that TTL into the program to begin with, and entirely lost on how I would get said program to use a second source of TTL to test its math on the first TTL.

But, all the quadrature decoder modules that I've seen so far are at least 2 channel - I had thought just to add the option to read from the Mill's Y as well as X - your thought would be reading from the Mill's X, and the dividing-head's A axis....

Then I'd have to try to understand the algorithms used to compare closed-loop. I can compare variables without a problem (if U = A then yay! - U being User's intention), but if steps go weird, such that U <> A, then what do I tell the gizmo to do?

Your idea is of better quality than my skills with a microcontroller

 

[MERLIncMan]

Gentlemen!

You may or may not have seen my drive to cause the DRO of the X axis to then slave my BS-0 dividing head, such that I can do helical cuts by virtue of a microcontroller and a stepper - no money or room for a universal-gear-driven-dividing-head.
The intention is essentially an expanded clone of a Division Master (which I would buy if it had the ability to index its divisions to another axis' readout).

In investigating the linear scale signals (5V ~90mA, Quadrature TTL) for my EL400 DRO (PM-727v Milly), I wanted to know what was the function of the USB-B connector on the back of the DRO...

Microcontrollers (had considered Arduino) aren't exactly ready as-is to drive a stepper based on user-defined ratios of a TTL signal, so I was looking at other options, primarily for the input of the TTL signal. (Yes, I know that some microcontrollers are better suited to this task, vis. the robotics guys).

Then I saw it.... that USB sends a Hyper Terminal Readable serial signal of the real-time position of the scales... already decoded... I found it on DROPros version of the instruction manual (same machine as mine, but the PM version of the manual has no information about the USB connectivity)

!!!!

If the USB sends a 9600 baud generic serial signal of the already-decoded position of the scale, then it seems my task shifts from making a microcontroller read a TTL (hardware issue with dropping pulses), to causing a microcontroller to read a simple data-stream from a USB serial.....

YAY! (I think)

So.... while I have an RPi B+, I am disinclined to confine it to this project (hope to build a tricorder with it some day). I have an Arduino Uno. I also have a 16key membrane keypad and an LCD.

I intend to investigate whether or no an Arduino can read serial stuff (or is its USB only for downloading firmware) - but Arduino doesn't have floating-point (as another member pointed out to me in my other thread)

I think that using the serial signal from the DRO itself is a much better avenue than attempting to breakout the raw TTL from the scales - I won't have to try and solder anything into the DRO and risk ****ing it up.

It would be a simple USB cable from the DRO brain to my Helical-driver brain.

My question for you guys: Which cheap and simple microcontroller is able to use USB serial in this manner to then drive a stepper-motor based on a user-defined ratio?

Thank you for reading

 

[ttabbal]

Nice that you confirmed that. So what you're looking for is USB Host. Rpi can do it, as you know. The easy mode here would probably be a Rpi, and it would be tough to beat the price and ease of use. The older V1 units might be available cheap. Pi Zeros can do it if you add the little adapter cable. The newer PIC32s can do it, along with a host of ARM based boards. Some of the newer Arduino ARM boards might be able to, I've never looked into it.

For example, a Pi Zero could read the USB data, calculate the changes and toggle a GPIO pin connected to the input of a stepper driver. If you start from one of the stripped down Linux distros I would think it would be plenty fast for the required math, but you would have to test it. And the up side is that if you do need a faster one, you can always get a Pi4.