Paper on development of a Polyphase Tachometer

That was my thought too, zeus; the only thing I can think of (in our case) is that the female thread is a blind cavity, and it probably fills with water over time, so there may be resistance to advancing threads…slight, but some.

And…we are way off on a tangent for Spar’s tachometer thread…shoulda posted this as a stand-alone thread perhaps. Shrug.

Somewhat back on topic - the idea of a flowchart for an interrupt-driven program has been rattling around in my head, not sure if you care to see what I’m thinking, Spar, or if it would be worthwhile to you at this point?

Absolutely, I would love to see what you think would work in a flow-chart.
I really don’t use them much, maybe I should, but I come up blank when I try for this device.

Do you have tools to build flowcharts? I haven’t investigated that subject, either.
I mean, aside from just drawing shapes and putting text in them. Is there anything that works at a more nuanced level that tracks the data you enter, makes them make sense?

Dunno about software, beyond simple 2d CAD/drawing programs. I’ll try and sketch up what I was thinking in the next day or two, and scan it and post it here.

Ok here is a pdf of what I was thinking - was going to post a sketch, but I kept making mistakes…it was easier to lay it out in a Word document with shapes and lines and clicky grid points.
tach flowchart.pdf (21.4 KB)

Holy smoke! All of a sudden there’s a flowchart.
OK, that’s capturing the logic and includes the variables that flag the state of the system at any given point. I think one of the steps that set the flags needs to reset Flag1 to “0”, but details aside I get the concept.

My previous reluctance to try this came from not knowing where to show the inputs that trigger the interrupts. Maybe simplest to just ignore it and move on to the logical expressions. But I feel like this doesn’t represent the way the program operates unless it has its 3 separate inputs. If a flowchart is supposed show inputs, where to they go? I think I can show a separate process in its own loop, that includes a “check for interrupt” and “goto” that would answer.

Different program codes read the internal clock time differently, so at least that can can be simplified to the just the basics.

Yeah, I think I made a mistake or two…but the flow, showing a continuous loop, I think captures the gist of what your algorithm does?

Regarding inputs…dunno. Flowcharting just shows a process, and has to be translated to specific processors. The flowchart I show could just be looped conditionals, checked sequentially as shown, or driven by an interupt-service processor like you use, or possibly by a state machine of fixed logic flip-flops like waross described (though how do you get the timer in a state machine, I guess it is just a parallel process that gets stopped/reset but dunno how you would do that with relays…)

Inspired by your efforts, this is what I’ve come up with.
I hope this is legible…

Yup, that reads pretty smoothly, and captures the interrupt method more correctly.

Many years ago, when I spoke Boolean, there was an encoder system with some similarities to part of your system.
The system is probably still in use.
The encoder had two detectors, optical, magnetic, or other.
One target extended from the 12 o-clock position to the 6 o-clock position The second target extended from the 6 o-clock position to the 9 o-clock position.
The first signal enabled either the up register or the down register. The second signal entered one count into the selected register.
The segment from the 9 o-clock position to the 12 o-clock position reset the system for the next count.
The register contents could be used for either frequency or counting.
I see the unique part of your development as an ability to work over a wide range of frequency and amplitude and to reject noise on the signals.
Well done Spar.

Thanks everyone.

I’m going to see if I can add this flow-chart as an appendix to my paper submission. It may be too late, but maybe it doesn’t hurt to ask.

Hello,
Some trusted colleagues of mine have strongly encouraged me to include a flowchart with this journal paper submission. I have attempted to summarize the operation of the tachometer program as an aid to the understanding of the program flow and action of the interrupts. Please advise if this can be added to the article as an appendix.
Thank you
Steven

Hi Bill,
I’m having a bit of fun, and it seems like you have noticed. My answers to the respondents on the “other” forum are a bit coy at the moment. I have used them as “guinea pigs” to test my ideas without giving the whole method away. I admit it is a disingenuous thing to do, but it also sharpened a lot of my thinking as I was writing my paper. I plan to give them credit when/if my paper is published.

I received a response from IEEE that they won’t accept any late changes to my paper. They still haven’t reviewed it, yet.

Spar,

Did your paper ever get published?

No, I didn’t. It was rejected on (what sounded to me) pretty shaky grounds, but I didn’t have time any more to do a rewrite to their request.
On my part, I realized only after submitting that the section of IEEE actually has 2 instrumentation journals. I should have subb’d to the other journal. The other one is much more expensive to submit to, however. Since this isn’t worth a thousand dollars to me, I gave up.
Last point, these journals print mostly papers from kids getting their masters. I don’t think there is a quota, but usually space is limited. So I don’t need to make it any harder for them to get space.
Last point (for real) I started reading these journals when I started trying to publish. Most stuff in them is dross. I bet none of you EE’s would read most of it. The IEEE Spectrum is excellent. But instrumentation is pretty bland.