[PAR_WIG1350]

Originally Posted by techhelpbb

Even with PWM you'll need at the minimum a microcontroller. One can easily perform the functions required with a simple Atmel AVR or Microchip PIC 8bit microcontroller. You can even do it with a BASIC Stamp 2 (which is merely a Microchip PIC with a built in pBASIC interpreter) it's not really a big job.

Fair enough.

[quote]It's not clear to me how you would be able to benefit from inputs on the PWM version. I suppose you could use them to provide basic limit switches. However, generally PWM is an output from the existing control system and an input into the electronic motor control. You'd need to come up with some way to configure the electronic motor control to get more elaborate when using PWM. With CAN I can see having optional input and output modules would add more flexibility.[quote]

One idea is to have a potentiometer input to recreate the function of an RC servo, but with whatever motor, transmission, and range of motion you want.

The idea of stacking things on top of the fan has a slight issue with it. If the footprint of the unit is nearly that of the fan you need some way to get communications to the power module under the fan. That's why originally I had envisioned building the other way and letting the connectors extend out from the sides of the stack.

The headers placed on either side of the fan extend all the way down to the power module. They are rather tall, but I envision metal standoffs providing the structural support for the top of the stack so that is not a huge issue in terms of durability. The inputs wires could stick out the sides that are already blocked so they wouldn't affect airflow.

After all if you look down at the fan on the Victor the footprint extends out where the connectors go. Essentially the issue of your diagram is that you've created several places where we loose PCB space to keep the footprint entirely under the fan.

That is why this is only a concept, besides, this is only one view of the device, if we looked at it from another angle, the footprint would very likely exceed that of the fan.

Perhaps the larger issue is that the air gap between the fan and the processor actually would work against you. With the controls below the power module it's easy to put a laminated foil shield between the bottom of the power module and the top of the processor. With the fan at that spot in the assembly such a shield might become a liability as it could restrict the air flow that's already being blocked by the processor anyway.

The air gap is where it is so that the intake airflow could pass over the processor, which would likely be mounted on the bottom of its module. As for the shield, would a heat-sink be sufficient? the heat-sink could potentially fill the entire air gap as long as the fins would let enough air in to cool the power module sufficiently. This would also improve cooling of the processor.

I will say that this footprint is smaller then what I originally described.

One of the complaints about the Jag is its size, especially its footprint (and its side vents don't help).

I'm just worried that using the space like that might make it hard to put indicators on the unit

The indicator module go on top of the stack using space already occupied by the connectors on the bottom of the input modules. This is an optional module, but I wouldn't be surprised if it would be required should FIRST use the design. FTAs like status indicators.

I'm additionally not really sure that we need too many input and output modules because most of the I/O is going to be directly reflected on the processor card with perhaps the notable execption being the encoder if you install a CPLD or purpose designed IC to track that.

I was sort of feeling that way too.

Course we could take the whole thing a step further and simply use an FPGA and put a small simple processor in the FPGA, along with the encoder tracking functions and skip dedicated processors or microcontrollers all together. The major advantage with that would be we could embed new features that run at raw digital speeds.

Same as above.

I believe that the minimum system should be reduced down to the common H-bridge and a basic processor module. if the team then wants to upgrade then they shouldn't need to buy a new processor. Things like high-speed counters (due to cost) and CAN bus interfaces (due to size) should be add-ons. More advanced users could buy more advanced processors to get systems that exceed Jaguar capabilities, but most of what a Jaguar can do should be possible by adding onto the basic processor module and all of what a Victor can do should be possible with out any add-on parts (beyond the minimum system).