Hey, All: I have a device which outputs a PWM signal which I want to capture for processing and subsequent output. I want to catch the PWM from the controller then feed a modified signal to the motor which was originally driven by that controller.
I understand enough to solve some of this myself: DAC or RC low-pass filter to get a signal I can feed into an Arduino input. I don't know the details yet, but I believe that's doable.
The twist is that the controller is monitoring a sensor and driving the motor using that sensor as the feedback. As the sensor gets closer to the setpoint, the controller first retards the PWM duty cycle and then pulses the motor output intermittently, pausing to let the sensor input settle.
I got the PWM signal on an oscilloscope, I have not caught the brief pulses sent to "nudge" the motor. When I say brief, I mean milliseconds, just enough to make the motor shaft twitch.
My real question here is: how can I not only catch the PWM stream but also the short-burst nudges sent to the motor? I feel I can catch, process, and output the "running" signal but I don't know about catching the intermittent bumps at the end of the sequence.
An RC low-pass filter could be used to turn the PWM signal into an analog voltage which could be read by an Arduino analog input. But it would probably be simpler to use a digital input pin to measure the duty cycle of the PWM signal directly.
The forum may not be able to help much until you can show what these nudge pulses look like. If they are milliseconds long, that should be no problem for an oscilloscope.
could you use a logic analyzer to capture a pulse sequence then examine it in detail?
or even a fast microcontroller (STM32, ESP32, RP2040, etc) using interrupt on change to capture the sequence timing? e.g. have a look at manchester-decoding
Paul, sorry for the delay; I was out of town and waited until I could get the captures from the oscilloscope.
Re using a DAC: I could have misunderstood something I read. I've been pondering this project for weeks and have read a lot about several topics, maybe I cross-channeled something. If "using a DAC" isn't viable/possible then it's me making a mistake.
In response to asking for the waveforms, here they are.
First, this capture shows the "running" pulses as the device heads towards setpoint.
I'm not especially good with any oscilloscope and I borrowed this one. This may all be garbage. This is one of two waveforms I tried to capture when the device was "dialing in" on the target.
This shows a 4.3% duty cycle. I'm not sure I caught the whole sequence. Yes, this is just a portion of the sequence, but I didn't see a clear flatline at the end to indicate the sequence was over while the feedback loop settled and was read/checked. I'm going to have to work on that some more but I'm not good with getting the oscilloscope to capture a sequence based on a trigger. When the device is near setpoint the oscilloscope goes from the steady trace shown in the first image to dancing around indicating an irregular pulse sequence. I tried to capture that by adjusting the trigger settings but...yeah, I've got "room for improvement".
Thank you, John. This is a Rigol DS1102E. I borrowed this one which means I'm not familiar with it for beans. Honestly: not that I'd be any better with another as I have practically no experience with using one. The screenshot you show has, it appears to me, many more trigger options than the one I have.
Regardless, thank you for the input. At the very least it shows that I need to spend some time learning about the triggering options on this unit.
No, I do not have a logic analyzer. I do not have any microcontrollers other than the ATMega328P.
I spent some time reading that post you made about the decoding. That's beyond my skill level but it seems that's an input to an ESP32 which is then turned into text to "describe" what the pulses are doing. That's pretty slick.
a logic analyzer is a useful tool for debugging microcontroller software/hardware
think of moving to a 32 bit microcontroller such as the ESP32 - onboard WiFi, Bluetooth Classic (original ESP32) and BLE, plenty of memory (in microcontroller terms) and IO functionality - cost about £7 on Ebay in UK
the advantage of 520K of SRAM is one can collect a large amount of data over a period of time for later analysis as in the Manchester Decoder referenced in post 5
Let me see if I have understood what's going on here.
The controller is aiming for some target position and the sensor tells it how far away from the target it is.
When the target is far away, the motor is run at high speed (74% duty cycle). As the target approaches, the controller reduces the duty cycle so that it does not risk overshooting the target due to momentum in the mechanism.
But below some low duty cycle, the motor stalls, and at this point the target has still not quite been reached.
So the controller then sends "nudge" pulses what are just long enough to cause a slight movement of the motor. After each pulse it waits for the sensor reading to settle and repeats as necessary until the target has been reached.
Paul, you have nailed it all except for the part where I reported information which I mis-identified. I'm an idiot and I made a couple of errors, see below.
As I stated in a post last night, I spent some time today further trying to identify/capture the "final" sequence waveform/pulses/nudges. I was able to fool the system into running as-normal while being torn apart: high-speed run-up slowing to the "nudges", all in one go. In doing so, I took out the motor assembly and found my first mistake: the motor, while tiny (3/8" in diameter or so, and maybe 1/2-5/8" long), is either a gear-reduction motor or feeds into a gear-reduction transmission. I had not caught that detail before. That affected the output of the device and that effect was misunderstood by me. That mis-identification is my second error.
The low duty cycle seen today was, indeed, in the 26% range over several tests. I probably bungled my use of the oscilloscope when I got the 4.3% or so seen in a screenshot. I borrowed the oscilloscope just for this project; I'm not good with it. I was unable to find an "end" to the PWM sequence because, apparently, there is no end other than the device terminating the drive when the setpoint is reached. The "nudges" I was seeing were, also apparently, not electrical bumps but rather backlash/mechanical friction/transmission loading/unloading which evidenced themselves as short "nudges" of the final output. Doh!
Ugh, this seems to have been much ado about nothing. As I see/read the results now: the unit runs at "full speed" which is around 74% duty cycle PWM and which drops to "creep speed" of around 26% which is so low that the drive mechanism hiccups and bumps and "nudges".
The goal is to feed the output from the controller to an input on a uC and then lower the PWM duty cycle and feed that separately to the motor. The device is horrible about overshooting the setpoint and no amount of running the device's calibration routine will eliminate it. It runs at "full speed" until it's very close to the setpoint, exceeding the feedback sensor reading rate: by the time it thinks it's time to slow down, it's over the setpoint. A 70% failure rate is common. The manufacturer's answer was to send it back to them for a refund. I missed that window because I had a devastating fire in the Spring of 2024 and spent the rest of the year trying to recover and rebuild (lost stuff/building, not personal injury, thank God). I had more pressing life problems than messing with shoddy equipment. Now I'm stuck with it and I've (sort of) picked up some skills (few) with uCs...maybe I can hack it. As it is, it's useless; might as well try to improve it.
Thank you for your help. I'm embarrassed I didn't more-accurately understand what I was seeing.
Horace, I've been intrigued by the myriad other uCs available and the ESP32 has come up elsewhere and caught my attention. I'm very new to any of the uCs in terms of programming them and finding projects for them and haven't exhausted the capabilities of the 8-bit AVR (yet).
I need a project for the solution; if I can come up with a goal which I can use those enhanced capabilities for, I'll be all on it. I really wish I had such a project...those features are calling me.
Back to the LA: I don't know much about what one can do with them. I read some about using the LA to diagnose I2C and other comms. I'm doing really simple stuff and haven't had a problem yet; I just use an I2C library and haven't encountered a problem in my very-limited use of it. Just like the more-capable uCs, I need an application to get me involved in it. I am "in the market" for an oscilloscope and I see some models have the capability or it can be added with accessories...I need to know what I'd use it for.
As for the project in this thread: I made mistakes (like usual) and you can read my reply to Paul where I didn't hold back on them.
I missed this line. If you clearly understand and are closely following "calibration" instructions, my guess is that the device is defective.
On the other hand, what you describe is one of the behaviors of an incorrectly tuned PID controller, which usually have several adjustable constants (Kp is the most critical). You might look for additional adjustable parameters associated with the controller.
If that goes nowhere, you will end up building and tuning your own PID controller to bypass the incorrectly performing PID controller.
Yes, I've followed the calibration numerous times. I made a video about the problem and others have had troubles, too. The manufacturer's tech support final answer was: send it back. Before I got around to sending it back, I set 25 years worth of tools/equipment on fire (May 2024) in a brand new, 4k sq ft shop and spent the remainder of the year (and a good bit of this year) cleaning up and rebuilding. That disaster caused me to miss the window to send this ^&#$ thing back.
It's a commercial unit, I have no access to any of the code or logic behind how it does what it does. I'm certain that catching the controller's output and just reducing the PWM duty cycle and then feeding that to the motor will make it work well enough. It's useless as it is and it cost $400: too expensive to replace "just for fun" but too useless to worry about damaging or destroying it tinkering on it.
it sounds like proportional control was attempted (as the set point is approached the PWM duty cycle is reduced) but is failing
a common problem with proportional control is either overshooting or under shooting the set point
a problem could be that below a particular PWM there is insufficient power to overcome the inertia and friction in the motor and it stalls
perhaps ignore the current PWM and implement your own proportional control
Yes, I agree. There was (is) a "lesser" version of the product. Ironically, if I had that "lesser" unit, I could press a couple of buttons on the unit and enter a diag/adjustment mode (reportedly) where I could set thresholds for speed. The auto calibration on this unit seems to be an attempt to fine-tune the device for different materials instead of the rote behavior: if this close, go this fast, if closer, go slower, if really close go slower yet, all based on defined proximities. Hypothetically, it's brilliant! In reality it's trash. There's no firmware updating to be done (no obvious user-serviceable port or software offering on their site or mentioned by support).
I further agree about overcoming the inertia/friction of the mechanism and that's why I was seeing "nudges" which show up on the oscilloscope as constant PWM signal: it's binding/loading up and releasing.
The problem is that I have zero access to the feedback/sensor unless I suddenly become an electronics genius and figure out how to start decoding what's going on "inside". If I was that good I'd be rich instead of so darned good looking. <rolls eyes>
I feel very confident that I can now read the PWM with an Arduino and reduce the duty cycle by some percentage if the read signal is over some percent I choose. Like if the percentage is over 70 then output 60%. I believe that if I can retard the bulk metering then it will be okay.
I have three electronics projects simultaneously, bouncing from one to another as materials or understanding are received: one of them involves PID control which may have been useful on this device, if I had complete access to the various components. I'm hacking together a reflow oven and there's a library by Brett Beauregard (sp?) that looks promising. But for this mess: duct tape, a snorkel, and an avocado!
