Before doing cutting tests I decided to test the spindle driver, PWM, RPM etc. setting to see how closely the spindles actual RPM is vs Gcode input.
I am using the unmarked PWM Chinese made driver I think most are using, see photo.
*Here are preliminary results. *
I plan to redo them with more measurement resolution.
*Settings: *
PWM freq = 1Khz
Max RPM = 12,000 rpm
Spindle voltage = 48.2
Tests Setup
Monitor: PWM with scope, spindle voltage with DVM.
Test: send M3 commands with various values that match specific DF as verified on scope .1, .2, .3 etc. Measure RPM with optical detector and read spindle voltage. Log data series.
*I found: *
1.) The TinyG would not properly send PWM values with freq setting of 5Khz. I plan to retry this as its hard to believe. Perhaps I had a scope operator error. These tests were done @ 1Khz.
2.) The TinyG would not output @ DF of >than .95 so the motor voltage never got fully to 48V.
3.) The driver voltage vs rpm function is linear.
4.)The drivers PWM vs voltage is a log function and not very linear below 30% DF.
5.) The Gcode speeds I am programming are not accurately represented by my system … yet.
…
I also added a switch in the spindles 48V source. I found this generally very useful for quick and safe control of the spindle.
…
Since I cannot find schematics on the driver I will probably be tracing it …uggh … so I can see if its linearity can be improved.
i have a question, i bought a ox machine from smw3d with a quiet 400 w spindle that works suposedly until 12.000 rpm, since the chillipeppr command line in m3 set up to 8000, that means when i programmed m3 s8000 means that the spindle works to the max rpm?(meaning 12.000) or 8.000 rpm?, this is crucial to figure out the set up of feed and what kind of bits are using it, and depth.etc.
How do you connect this spindle driver to the Tinyg? Can you post a photo of the wires going into the tinyg? I get the pwm port gets one wire…I’m assuming the + wire? Where does the other go?
Nick - tinyG PWM signal is 3V logic relative to tinyG GND.
There are sort of loosey specs on what the spindle controller wants as input levels, some sellers say 5V logic or higher, others say 3.3V. The input to the spindle controller is an opto isolator.
I would suggest a buffer stage between PWM out and PWM in.
An example circuit can be found here https://github.com/synthetos/g2/wiki/G2core-on-DUE---External-Interfaces
DonK - Your logarithmic Voltage curve might be the input response of your measurement device. Only a true RMS responding voltmeter can handle AC signals like this, typical VOMs have an averaging circuit that is not real good over frequency. True RMS VMs are $$.
Nice test document. I ran a similar test a while ago, with similar results. What I found was that above PWM=0.9 or so, the spindle would not spin up on command, but would if I manually spun it after the M3 command. That could be motor or controller
And, like you, found degraded performance with $p1frq >2.5kHz https://github.com/cmcgrath5035/G2core-DUE-External-Interfaces/blob/master/Spindle%20Test%201.doc
I thought…
That nearly any controller was known to not be linear… that it had to be tested and characterized before it’s behaviour could be predicted. Which is exactly what you are doing… and at the end you would have a table that would be put through some math, which would give the desired result so it would be input->math->output->desired behaviour…
I don’t think you are wrong, but I interpreted DonK’s quest to find a “best linear fit” to the actual performance of the spindle over his range of interest (use) because tinyG implements a 2 point linear approximation in setting PWM phase between those two points when translating gCode S(speed) to PWM phase.
@cmcgrath5035@Nick_Portelli am using the driver below.
The pwm input specs say 3.5 - 12vpp.
I am directly connected to the controller from the tinyG which is probably marginal at 3v. Depending on how the pwm input interfaces to the assumed optocoupler it may or may not be good design which is why I will trace the controller. Eventually I will probably isolate the pwm signal with MOSFET driver.
@cmcgrath5035@Josh_Rhodes I have been looking at and testing pwm controllers for my laser. I expect some non linearity but this one is the worst I have seen. @cmcgrath5035 I see your point on the use of DVM creating an error. I will check this but I think the pwm DF vs speed looked the same.
Ultimately a function can be derived (see on graph) to calculate the Gcode value vs actual speed.
I agree with “interesting”, I see a lot of users with $p1cph=1.0 reported as working; did not work for me. I assume you are measuring tinyG output? I bought from Amazon back in Oct 2014, from Rio Rand and One other seller. If you search around, you find(found at the time) several sellers of same or very similar units. I did find a typical schematic at the time, Opto Isolator input, a 555 based pwm oscillator for manual control, bypassed if the PWM input was so configured with the jumper. The output of the opto isolator was amplified by a medium power fet on the controller which in turn drove the main power FETS that were clamped to the heat sink.
And in that same timeframe folks were having issues trying to control SSRs for router spindles from tinyG, same opto-isolator input configuration. I actually saw spec sheets getting changed from 5V to 3.3v minimum., to please the customer?
The Xmega device does not have great current sourcing capability, I don’t like driving led loads directly where intensity is important, so use a bipolar or FET switch to improve drive capability.
Also, FYI, I experienced at the time the need to reset tinyG after making $p1___ parameter changes for them to be effective. That was not always necessary, but sometimes.
I don’t find your curves to be at all surprising, there is a lot of mass in these spindles, there is a minimum amount of torque required at the low end.
That controller is still only $15, seems to work well in these 400-500W applications. I never had the nerve to try it at 10A/160VDC.
Doesn’t help here, but this is exactly what Sonny did for me in GRBL. I pulled data and was going to do a one shot polynomial equation. The 328 is maxed though.
Instead he created a piecewise function and added a few lines of code to GRBL that allows a great fit.
This should easy to add to TinyG. I’ve mentioned it few times. Using a TinyG to control a VFD results in similar non-linear activity.
@cmcgrath5035 would be my reference glad to see he’s on here. I used his settings and got great results. It isn’t perfect but it does work well.
@cmcgrath5035 I completed the circuit trace and will post the schematic soon. A couple of immediate observations:
1.) The pwm input will work (ran the #) with direct tinyg connections although I don’t like direct and external connection at 3.3v. Still need to check Atmega source and sink specs.
2.) The PWM signal is ac coupled through a filter to the driver. I am pretty sure this is why you cannot send a 100% DF.
3.) The driver is a simple single ended type. Doh! Realized the ccw-cw gcodes wouldn’t work, why would you expect that since there is no direction signal routed to driver?
4.) If high voltage (not sure why hv is needed) and local control is not needed this driver could be much simpler. Maybe not worth optimizing…
5.) The remote pwm signal directly controls the motor driver.
@Brandon_Satterfield since the motor voltage vs rpm is pretty linear I don’t see why the tinyg should need correcting. I am wondering if the error might be created by the ac coupling and filter on the driver.
@donkjr I wondered were the non-linear behavior was being created. I pulled the O-Scope and found it to be generated at the TinyG output.
It was the same on the GRBL board. As someone mentioned I understand that this is inherent to these systems. More testing could certainly be done.
The fix in GRBL was done at the software level. Now the relation is much better.
Was going to mention as well Don, I have many machines, I’ve had the need to turn the spindle backwards once and this was on a lathe. I’ve never had the need to turn it backwards on a router or mill, less your counting compression tappers.
Brandon, I am curious about your comment " I pulled the O-Scope and found it to be generated at the TinyG output. ". Are you saying you measured the PWM duty cycle on the O-Scope and determined it was non-linear, vs what setting, the S command?
DonK, I keep forgetting to ask, what does PWM “DF” stand for?
I presumed early on that it probably meant On Duty Cycle, just can’t translate that to DF, but we all went to different schools and some in different countries.
For both - you do realize (?) that the Synthetos implementation is (approximately) linear only between speeds $p1csl and $p1csh, with those points specified by $p1cpl and $p1cph. DonK, you did not specify what those parameters were set to.
Note that I ran my test somewhat differently than DonK. I used $p1pof to directly set a phase value (what I normally call a fractional duty cycle) and measured RPM. In my case, phase = 0.08 measured 5500RPM, nothing reliably happened phase <0.08, so I used 0.08 and 5500 as ($p1cpl,$p1csl) and similarly determined 0.95 and 12000 as ($p1cph, $p1csh). Different methodology but very similar results.
@cmcgrath5035 My approach was first to measure voltage vs S# from the spindle speed control. My graph looked exactly like the one above. In fact think it’s on here somewhere. Your settings resolved some of this issue.
During testing I backed up and went to the TinyG output. This could not reliability be read on a volt meter. I pulled out the O-scope to measure output frequency vs programmed. Since everything was out anyway I started sampling. Again your settings were sufficient for my need. It really shows up on a VFD still but it is looking for DC voltage so not the best pickup.
@cmcgrath5035 DF = Duty Factor :).
Gosh, I have been wondering what the phases meant. Couldn’t find a good explanation. So I left those alone from the config file I copied. I will have to play with that when I get home !
