Count quadrature shaft encoder signal with max frequency (for a single phase) of about 90kHz.
Output a 16 bit word where each of the 16 bits changes state at some specific angle of the shaft encoder. There could potentially be an arbitrary number of state changes per bit per revolution, so there would be a list of angles at which to go high or low for each bit. But the list is unlikely to be more than 3-4 in length.
However, the word pattern from one revolution to the next might not be the same, but would repeat after N revolutions. So there is not only a list of angles to flip bits within each revolution, but a new list for each revolution.
On 1-4 of the 16 output bits, the angular event should trigger a time-domain pulse width sequence, with up to at least 4 pulses with adjustable widths and separations. At least 1us resolution and jitter, preferrably
One significant item you don't mention: For the 16 bit outputs, can the outputs be readily calculated "on the fly" (i.e., there's a reasonably simple forumula to get from one output to the next)? Or is it something so esoteric you'll need a bunch of look-up tables?
Good.
That's a lot of cash to play with!
This is always pretty nebulous. Do you have anything in particular in mind? Good design certainly allows for changes in design specifications, but you can pretty much always kill off whatever remaining budget or time you might otherwise have by deciding you can obtain just one extra bit of 'flexibility' by adding a chip or something that will probably never be used.
Wow! That's a looonnnng time these days! All of the approaches you mention "more or less" meet that requirement... it's highly unlikely you'd be able to find the same FPGA or data acquisition cards available 10 years from now, much less 20, but by sticking with an HDL or PC development environment, you will be able to migrate the design.
My own recommendation, though, would be to shoot for something more like a
5-10 year maximum lifespan (and if you build these things right, they'll last that long anyway) -- it's very non-obvious how to design a system that, 20 years from now, is still going tbe considered easy to use, maintain, interface to, etc.
All the PC-based approaches sound like massive overkill to me, unless those 16 bit outputs you describe above are so complicated in nature that a microcontroller/FPGA couldn't hack it.
You mighit be able to get away without an FPGA. With a fast microcontroller (something operating at, say, 50MHz), with 'tight' programming you should be able to meet your 500ns jitter spec on the outputs, since the quadrature input sampling at 90kHz is quite leisurely (i.e., it's not like your micro would be pre-occupied doing much else that couldn't be easily interrupted).
On the other hand, these days you can get free or inexpensive CPU cores (compatible with PICs, AVRs, or at least the manufacturer's own tool sets, which normally include things like GCC) and just forego the physical CPU option. This approach gives you a lot of that extra flexilibty that you're after...
Yeah, but again, unless you're going to be sending this thing to Mars, it's just not worth it to try to plan for more than a 5-10 year life now. Anything with requirements that are likely to "chance and expand in very unpredictable ways" is almost always best served by a re-design (incorporating re-usable components wherever possible -- which is something that tends to happen more often in theory than in practice!) rather than trying to stretch some older design for just a few more miles.
Yes, although if you're going with that big of an FPGA, unless you actually need a bunch of really fast multiplier blocks or already have some DSP algorithms developed in C, I'd still stick with the FPGA+soft core approach.
Yes. A good approach here would be to just find someone's "general purpose" FPGA development board... they usually have a bunch of headers on them, so then you stick your custom board on top (for only 6-10 units, you could probably even get away with just hand soldering those interface boards -- no custom PCB needed at all).
Do you already know an HDL and/or have experience with FPGAs? For someone who does, if you go with an off-the-shelf FPGA development board and hand solder your first interface board or so, from what you're said so far, this doesn't sound like it would take more than a month to get the first prototype up and running.
Certainly true, the usual problem, of course, is that that documentation is about the lowest priority of anything around the shop (slightly lower than replacing the toilet paper in the bathroom) so it often never gets done. With good documentation, I expect that most people would prefer to work on small, self-contained systems than some big PC-based one.
This gadget is to develop firing control signals for an internal combustion engine. We need to not fire the engine for say 9 cycles, then fire it once, then repeat the pattern. So there's two crank revs per engine cycle, with a 1/4 degree encoder so 2*1440*10=28800 counts per program. Thus, there could be a maximum of 28800 unique 16-bit output conditions. In practice, each bit may only have one pulse per engine cycle. So even if statistically there are say 2 pulses (4 edges) per cycle per bit, and all at different crank angles from bit to bit, then there may be about 16*4*10=640 unique output states to index. So there's a data structure of 640 two-word items: the counts at which something changes, and the output word when that count is reached.
Pretty simple. I will probably have this going on my F2812 ezDSP development board within a few weeks, with only 2-3 hours of effort a day.
I think a SBC or PC solution could be done for $1500-$3000, so that's an upper bound.
Yes it's nebulous. But you will notice that I mentioned a bunch of additional likely things the gadget must do later in my OP, based on another encoder input. That is par for the course. In the middle of the design, or a year later, they come to me and say, we need to do this new stuff now. What should I do? Since there is no profit motive, and the hardware cost is trivial compared to PC DAQ/DIO hardware, I could easily install an order of magnitude more logic and processing resources than I need based on today's specs, for effectively negligible additional cost.
So if that gives me a better than 50% chance that I'll have the additional capacity to handle future additions of functionality, why not do it?
This is no different than what most people do who design marketable products these days, they leave a little room for add-ons that they didn't think of for version 1.0, but not too much because for them 2x the horsepower than they really need will cut profits. But for me, the cost difference between a 300k Spartan3 vs. a 50k is negligible.
Yes, but it's based on the lifespan of the legacy system. There is no guarantee that the whole methodology of what we do won't change at any time years. But it is also quite likely that 10 years from now they will be doing things very similar to how they do it now. They are not engine developers. They are combustion scientists.
The most likely expansion of the unit will come in the form of needing more IOs and delay generators. I already plan to make the board capable of much more than 16 IOs, probably the 56 that the F2812 has, but patched through the FPGA so the FPGA can map any CPU IO to any physical IO pin on the board. Then a modularized buffering PCB that can make it very easy to expand IO. Need another 16? Just punch 16 more holes in a rack panel, bolt in another pair of 8-channel general purpose IO buffers, plug the ribbon into an unused IO header on the main PCB, stick on some labels, and go!
All of the approaches you mention
I wonder about the F2812 in that regard. CPU makers tend to like to help customers not have to discard old code. So they had the C2x and C20x series before C2000.
Remember, originally I planned only a small uC to link the FPGA to the PC for passing setup parameters. But I figured the DSP makes it possible to do some things algorithmically if desired, which can be moved over to the FPGA in time.
Unless the thing breaks, then nothing will be different 20 years later, right? If spare parts are in stock, then no problem. Oh, also the USB or serial interface would be easy to replace if in the future all the PCs move to the XYZ port. That's because there will be tons of surplus IO on the board. So the game's not over until they consume all the IO.
Yes. Like I said, the F2812 can do this in it's sleep. The thing is the delay generators. They tend to always want more of those. We probably have 2-3 per each of 7-8 labs, at $3500 each, that's about $65k. The FPGA is mainly intended to allow for creating time-domain pulse sequences on the IO ports after the DSP has done its thing based on crank angle (but I may move that to the FPGA as well). They will probably want at least 4 channels with the ability to have 10 unique pulse widths and delays on each. F2812 may even be able to do all of this. But that will be pushing it.
It also has to be able to have the parameters changed on the fly, so it must have leftover cycles to respond to new parameters from the PC.
Yes, but that I'm afraid takes it into a realm of being too complex. It is very easy to use a microcontroller chip. I think it would be much more involved to use a soft-core. That's because it'd be like using a bare microprocessor, where you have to build up the whole peripheral structure, glue in memories, etc. I don't want to get that involved. There's no point. The DSP and FPGA don't cost anything. But together they provide a very wide set of choices of how to accomplish any of the required tasks.
No this time, but I will learn more about that in time. I don't think my software software guy would be any less opposed to my ideas if I proposed using a soft-core.
Yes. I may do it that way. I have considered using the ezDSP as is, and plugging it into a backplane. Could do the same with an FPGA board. That is a good idea, and is under consideration.
I have an introductory capability in Verilog. I have developed some camera synchronization logic and some delay generators using Verilog.
Yes. I tend to be good with documentation.
Thanks for the input.
Good day!
--
_____________________
Christopher R. Carlen
crobc@bogus-remove-me.sbcglobal.net
SuSE 9.1 Linux 2.6.5
Hi, have a look at the Hitachi H8\\3048F processor. It has a 2phase counter linked to a 16 channel timing pattern generator plus all the usuall other periferals. Most of your software effort would be loading the pattern table and setting up the periferals. Might take you all morning
You missed 3.b) Use a commercial FPGA and/or uC eval PCB, as the hardware engine. - or a number of these.
At the top end, the new STW2200 nust have an Eval PCB comming, and at the bottom end, Boards like the C8051F064DK have full USB flows, and 16 bit 1Msps, 25 MIPs cores, so can do a lot for ~$25. ST also have a capable DK for their uPSD3400, which is uC+CPLD.
Also, even if you use #3, you will still need a substantial level of #1, only now the DAQ is your FPGA/uC remote PCB ?
You want the horsepower nearer the coalface, and easily distributed.
For recent projects I was in the exact same situation as yours. The application was to controll fuel injection magnetics with high accuracy to crancshaft angle. The only diffrence: I had only one output (not 16) per device and additional PWM for pressure regulation. Totally number of about
20 pcs for pump test required. Angle Parameters has now to move with the pressure error and crancshaft speed becouse magnet delay is constant.
I believe we all agree, those things are impossible with PLC. As far I am familiar with HW and SW, the first attempt was a PLD solution using several Lattice CPLD. Somewhat later I remembered a recent desgin what was a servo controller for DC brushless motor using a Texas Instruments F240 DSP. That Device is about $800 usable from stock without any HW modification and I was lucky to have the complete firmware sources.
1) The CAN Bus links to a PC for parameter setup and test result statistics
2) The power stage can drive the magnets directly
3) Interface to both incremental encoder and resolver are available
4) SW updates in field possible to meet new requirements
To mention in my case, a software comparision of the angle position was not accurate enough. The servo motor controllers most time have several HW comparators for commutation control what can be used to switch the outputs by HW and generate a interrupt to enable the SW to load next event distance
In the meantime there are 5 years over and it was a good desicion not to use a CPLD solution with less flexibility. The SW had about a dozen of changes and the magnets changed for more speed. Formerly they were simply on-off and today they have low inductance with start pulse and further PWM current limiting to reduce the heat...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.