back for now: PWM + Serial (single wire)

[BGB]

earlier, I wrote some code (for an MSP430) for implementing a 3 phase VFD, using both servo-style PWM and I2C for control inputs.

then I was thinking, it is a little pointless, as the I2C and PWM are both partially redundant and also one ends up with the worst of both worlds. so, I had an idle thought for combining them so that the PWM wire can also be used as a half-duplex (and rather asymetric) serial link.

general info:
with the PWM, one has pulses between 1000us and 2000us, where:
1000us=full speed reverse;
1500us=motor is stopped;
2000us=full speed forward.

this is normally sent as part of a "pulse train", where the desired value is regularly re-sent at 50Hz or so (but can conceivably go up to around 300Hz).

typically, no other data is sent over the PWM wire besides PWM, but a separate interface is needed to send data to/from the VFD.


so, an idle thought comes up, say:
pulses between 32-95us encode a 0 bit (nominal=64us);
pulses between 96-160us encode a 1 bit (nominal=128us);
around 64us dead-time is left between pulses.
possibly a 256us pulse could be used as an "end of message" marker (256us high="make it so", 256us low="no data" / "abort").

so, a series of bits encoding command bytes are sent over the PWM line, and no separate interface is needed. likely a simplistic byte-oriented protocol would be used, with most commands likely being fairly short (and intermixed with the normal pulse-train).


however, this seems obvious enough that probably someone would have done it already, so I am left wondering if there is any sort of standardized protocol for this?

other idle mysteries (mostly speculative ATM):
if doing an oil-cooled 440V induction motor, what sort of oil is best? (vs motor-oil or similar, better options?).
effects of running a 440V motor at 360V using square-waves? (say, lower voltage to allow cheaper transistors in the VFD H-bridges, hoping square-waves can compensate for the reduced voltage, probably using 580V on the main DC rail).

(note: mostly all hobbyist-level stuff thus far...).

any thoughts?

 

[dorke]

I was under the impression that a VFD-Motor system looks like in the pic below.
The VFD controls the motor via the PWM "link".
And the User "communicates" with the VFD via "RS-485 link".
The RS-485 is a standard serial async protocol.
You can also find per-made software for the "userinterface" (RS-485) for MPC430.

If you build your own VFD you can implement it anyway you like, including I2C.
The I2C would only need to convey the "userinterface",
while the PWM do the actual control work.

What would you gain from combining them together?
Are you trying to save "pin count " at the MSP430?

 

[BGB]

no, it would actually be a fair bit different.

the use of multiplexing data and PWM control is that the main control interface (say, a Raspberry Pi), only needs a single wire (from a GPIO pin), going to each motor-driver.

the motor driver would be an MSP430 connected to an H-Bridge, possibly with some built-in back-EMF sensing (needed for BLDC, but can also be used to improve the efficiency of induction motors). the H-bridge would then supply 3 Phase to the motors, while powered off the main DC rail. the VFD here is, essentially, the combination of MSP430 and H-Bridge drivers.

voltage and other things will depend highly on the size and power of the motor. for smaller motors, the DC rail would be 24 volts (this would be derived from power from a battery pack or lead-acid batteries, *). conceivably it could also be used for bigger motors (ex: 440 volt), but there the control interface would likely be different (and the DC rail would be supplied via a boost converter, as the needed voltages would be impractical to get directly from batteries). (ADD: basically, for larger motors, motors designed to run off of 208v or 440v mains voltages become a cheaper option).

*: the device, such as a rolling robot, may be powered say, using a pair of 12V 20Ah SLA/VRLA batteries or similar. smaller or bigger may be used.


the image uses a Raspberry Pi as a main controller, but others may be used.


traditionally (in things like hobbyist robotics and RC applications), things like motors and servos are controlled via a PWM signal, which encodes either the desired speed or the desired position. usually this is sent using a PWM cable, which has 3 wires (generally: comm, +5v, 3.3v-5v PWM signal).

typically, this PWM goes 1000us to 2000us, with 1500us as a center position (leaves the motor idle), duty-cycle doesn't generally matter, merely the pulse-width. typically, no other data is sent over this wire.

however, pulses significantly smaller than 1000us are generally ignored, so the thought is that, conceivably, these could be used as an extension to allow limited data communication (such as for querying or modifying motor parameters), rather than needing a separate interface for communicating with the motor controllers. like, after all, we already have a PWM wire dedicated to each motor.

the interface would remain backwards compatible with controllers which are unable to utilize the extended capabilities, or which don't care. in this case, the 3ph driver will behave basically the same as a typical DC motor driver.