Help with a PWM switch

Hey guys, I’m sort of new to the forum, I’ve been reading it, but never posted, so here goes:

I recently bought a PWM switch from trossen robotics: http://www.trossenrobotics.com/store/p/3206-Electronic-R-C-PWM-Switch-RC-110-.aspx
And I’m wondering how to program it, I contacted a friend on youtube.com about it and he said it should be programmed as digital since it was On/Off. Im really just wondering how to do that.

P.S. I’m also wondering where it should be put in, motor, or a sensor.

This means that this takes a PWM signal from a receiver/micro controller. Therefore, it cannot be connected to a digital port. It must be connected to a motor port. Then, you would set the motor port to the correct value(trial and error should find the correct values to turn it on and off).

Okay, so I hook it up to a motorport (thats what I assumed). But what do you mean find the values, and how would I do this, just hook up a simple light bulb to a circuit and keep testinging it. If so how do I do this on EasyC Pro?

This is very simple, hook it up to a motor port and then use it as if it were a regular motor. When you want to switch it on set that motor port to 127 which is around 1.5ms and the device should switch the relay on. When you want to turn it off set it to 0 or 255. Your device should be hooked up like in the diagram on the website.

Thats what I thought at forst, but my friend said it wouldn’t work since motors were analog. Thanks to both of you. Oh and btw this is for a Vex Rocket Launcher :smiley:

Cool! We would love to see your project when you finish!

Alrighty then, I’ll show you guys. Currently its going great, I have my motor assemblies set up andeverything. Just waiting for the paint to dry on my rocket, and my treads and PWM switch to come in. I’ll post a forum when its done.

pippintoon,

My interpretation of “The RC-110 is designed to switch around the center pulse of a servo command (1.5 ms).” differs from robofreak’s. My interpretation is that it means that the switch is open on one side of that value and closed on the other. Given the imprecision and variability of both the microcontroller and the switch, I would expect unstable performance if one were to send it a mid-point value. I suggest sending it a value of no more than one-quarter scale for one state and no less than three-quarter scale for the other.

As for where to connect it:
a) My understanding is that the “motor” ports of the Vex microcontroller have an unregulated connection to the battery voltage. For most motors, this is a good thing, as it makes more power available to the motors. AFAIK, a motor port will work for a relay, as long as the battery voltage is acceptable to the relay. In that lies the concern, as what I believe to be the manufacturer’s description of the relay:
http://www.rcatsystems.com/cube/index.php?act=viewProd&productId=6
explicitly cautions about running it above 6.5 V. The nominal voltage of six NiMH or NiCad cells in series is 7.2V.
b) My further understanding (See Page 7-5 of the Inventor’s Guide) is that the “ANALOG/DIGITAL” ports on the microcontroller are software-controlled and can be used for input or output. The default configuration is that 1-12 are sensor inputs and 13-16 are used for jumpers. However, you should be able to program them to switch your relay. The voltage supply to these ports, I believe, is regulated to 5 Vdc, the manufacturer-recommended operating voltage for the relay.
c) Although it is true that most DC motors are analog, Vex motor modules are not. Two of the wires carry power and ground, the third carries a pulse width modulated (PWM) digital control signal. There is circuitry within the motor modules that translates the width of the pulses to a voltage setting (including reversing voltage to reverse rotation direction) for the motors. Therefore, the motor control outputs of a Vex microcontroller are digital signals.

Lastly, I noticed that the Trossen site includes the statement “LED under label will light when relay is closed.”. This clearly indicates the best way to test it. BTW, I have a couple of servo testers which I find useful in situations such as this. They can ouput pulses of various widths, so it’s very easy to plug in a device and try various pulse widths to see what happens.

Good Luck,
Eric

Okay so I am using Easy C Pro for this project. And what you are telling me is to use it in sensor bays 1-12. In Easy C Pro, what would the programming look like?

pippintoon,
As I’ve never used EasyC or anything else, for that matter, to program a Vex microcontroller, I can’t help.

Have you, to put it bluntly, RT*M?:rolleyes: My understanding is that EasyC is well documented. If you can’t find sufficient guidance in the official documentation, I encourage you to try searching this site.

When you’ve done your “homework”, if you post a specific problem description or question, there’s an excellent chance that someone here will help you.

Happy Researching,
Eric

hahaa yes I have :D. Well the vex programming manuel, and most of the pdf files for Easy C Pro. I think I will just keep trying values, and get it too work via trial and error.

pippintoon,
For reasons I haven’t the time to investigate at the moment, I’m not being allowed to respond to your other thread on this topic. So, here’s my response to the recent posts there:

You reported getting the RC-110 to work when plugged into a motor port. If you’ve tried sendng it a variety of speed settings, do you mean you got it to change state only by plugging/unplugging it, or do you mean you could control it from software?

If the former, I suggest you check the pin assignments to make sure the ones on your relay match the Vex ones. If the latter, that’s as good as it appears, from the documentation I have on hand, as it is going to get, at least without some effort.

What I had envisioned is setting one of the analog/digital ports as an “analog output”, so you could send the PWM signal to it and have the regulated 5 V power supply. However, it appears that the only convenient PWM outputs available are the motor ports.

Here are suggestions for hardware and software approaches, if you’re not comfortable supplying the unregulated battery voltage.
Hardware:

  1. I don’t know if you intend to use the controller for anything else (particularly motor and servo loads) at the same time. If not, you could try running the microcontroller on a 6 V source ( 4 X alkaline or 5 X (NiCad or NiMH). According to:
    https://vexforum.com/t/example-program-writing-your-own-aarcade-control/15031/1&highlight=minimum+voltage
    That should work, as long as you don’t have any substantial loads (e.g., motors or servos) on the system.
  2. Get the signal line from a “motor” port and the power line from an “analog/digital” port. This will require a bit of wiring, so I suggest using a few rows of breadboard and jumpers to test the strategy.
    Software:
    In theory, you should be able to use a digital output port to provide a PWM signal. You would need to program the microcontroller to set it high for the desired pulse width (e.g., 1.1 ms for one state and 1.9 ms for the other), then go low long enough for the RC-110 to recognize the interval between pulses, then repeat that sequence fast enough to have the RC-110 to recognize it as a pulse train. (If I’d had better luck yesterday when I made my first attempt to get EasyC running, I’d be very tempted to try this and put my oscilloscope on the output, but I can’t yet get programming access to my microcontrollers.)

Good luck,
Eric

Using EasyC, I believe you only get to write code for the user CPU in the Vex microcontroller, not the master CPU. Because the master controls the digital outputs, and because the user CPU only tells the master CPU what to put out on those outputs about 55 times a second; I presume that any attempts to predictably switch those outputs on and off faster than 55 Hz will fail. If I’m right you won’t be able to convert a digital output into a PWM output that requires the pulse widths you described. :frowning:

Blake

I just happened to be doing some tests on I/O port speed, so I have some relevant info to share. The 16 I/O ports are directly connected to the User processor (via some protection components). In fact, I believe all the 3-pin ports (I/O, interrupt, serial, and motor) are wired directly to the User Processor. The motor ports are special in that they are wired to both the User and the Master processor, so either can drive them. Usually the Master processor drives them, but you can set any of them to be controller by the User processor instead.

The first four motor ports are wired to User processor pins with CCP modules, which means you can use the first four motor ports to generate custom PWM signals. The Vex Starter Code even has some commented-out initialization code that shows how to set such a thing up. (look around line 200 in user_routines.c)

For the tests I was running, I was trying to determine how quickly I could bit-bang a serial protocol using digital I/O ports. To do this, I set up a test rig with a frequency counter and an oscilloscope to monitor both maximum signal speed and signal quality.

I was able to get a clean 1MHz signal out of a digital output port. This was in a while(1) loop doing nothing but updating the port pin. The loop was actually setting the port high 4 times in a row, and then low 4 times in a row. This was necessary to give the signal enough time to settle at each state.

The next hurdle will be how consistent the delay is from a timer interrupt firing to the point in your code where you toggle the output pin. It looks like the Master-to-User processor communication manifests itself as a block of 33 interrupts every 18.6ms. Each interrupt takes about 8µs to service, and I believe this is configured as a high priority interrupt, so it’ll override your timer interrupt. This means your PWM pulse will have up to 8µs of extra latency if it arrives around the same time as an IPC interrupt. 8µs of jitter is probably not a problem for this application.

A few notes on signal quality (while I’m on the topic): The protection components on the I/O lines add both parallel capacitance and series resistance. This has the desirable effect of protecting the ports from a variety of potentially damaging conditions, but it also has implications for how the ports can be used:

When used as an output, this means that limited current is available to change the signal state. If the device you are driving has a high load capacitance (like a MOSFET gate), then you will have slow rise times resulting in a lower maximum frequency. In the case of MOSFETs, it also means you spend more time in the undesirable linear region causing higher switching resistance and heating losses.

When used as an input, this means that current must be provided to overcome the built-in capacitance. This current flow is limited by a 1KΩ resistor, which effectively sets a maximum frequency. I don’t have a signal generator, so I didn’t measure the exact frequency, but the math says it would limit the usable input frequency to about 500KHz.

Cheers,

  • Dean

Well - Color me surprised

I believed the Master handled all of that messy I/O and the User only got updated through a 55 Hz exchange of blocks of data (sensory data from M to U, output commands from U to M) with the Master.

Were you working all of that I/O magic using EasyC’s drag and drop functions, plus perhaps a little C code in a User Code block; or did you have to go outside of EasyC’s built-in tools?

Blake

It is a reasonable assumption, and there isn’t really much documentation to the contrary. The analog and digital I/O ports don’t really require any sophisticated I/O, since the PIC pretty much makes those single-instruction operations. The serial port (USART2) is about the same complexity to drive as the SPI port, so offloading that to the master wouldn’t be a net win. The interrupt ports need to be directly wired in, or you loose the benefit of real interrupts (low latency).

As far as I can tell, the Master processor is primarily responsible for decoding the signals coming from the receivers, and generating the 8 PWM signals for the motors. Both of those tasks are somewhat resource intensive and would “swiss-cheese” your program’s runtime if you had to share a processor.

The thing that surprised me the most is that the programming port appears to be wired to the User Processor (USART1). I had assumed the programming port talked only to the Master Processor, and that it negotiated with the User to download new code, but that appears not to be the case at all.

It actually would be handy if some tasks, like optical encoder decoding, could be offloaded to the Master, but that all appears to be fully handled on the User processor.

BTW, When I need to figure out how something in the Vex microcontroller is wired up, I use the PIC18F8520 specification along with the ifi_aliases.h file (and sometimes ifi_picdefs.h) to figure it out. It does require some deep digging, but nearly everything on the User Processor side is spelled out there.

The Master-to-User IPC (Inter-processor communication) is not directly documented. From observation, I believe it uses the SPI port (MSSP module) and is interrupt driven. I was able to sort this out by examining various registers and observing the 8µs blackout periods.

Part of my experiment was to compare the development environments w.r.t. efficiency.

EasyCv2 and EasyCPro both scored about 81KHz using just the program blocks.
MPLAB scored about 820KHz if I allowed any other code to run, and over 1MHz if not. (I had to artificially limit it to 1MHz because the I/O pins can’t go faster).

The big difference between MPLAB and EasyC is due to the fact that setting a digital pin in EasyC is a function call with some parameter processing, whereas in MPLAB it’s a single instruction.

I have not yet tried using User C code in EasyC Pro to directly toggle the pins, but I expect it would net results similar to MPLAB if I did. I’ll try this shortly.

Also, I wanted to try RobotC, but I could not figure out how to control a digital output pin. As far as I can tell, there are no library functions for doing this. [Any RobotC experts out there care to give me some pointers?] I should be able to use the same C code I used with MPLAB and get similar results, but I didn’t try that yet either.

Cheers,

  • Dean

Thanks for the good info and clear description

I guess while you were doing that, I was distracted by woking on this: 5th Gear.

It’s so much easier just to make magic happen in a simulator than it is to actually get real equipment to work. :wink:

Blake