Parallel Port -> 4-bit DAC driven monolothic chopper controller

More
13 May 2019 19:14 #133654 by fungus
Pre-statement: I am sorry if this has been covered, and I am sure it's been thought of before.

I've been tinkering with the "Etch" example, and I really appreciate that it is available. What a great learning tool.

In taking apart a label printer, I ran across the TI LMD18245T: www.ti.com/lit/ds/symlink/lmd18245.pdf
It's a monolithic full H-bridge with integrated chopper controller, based on an internal DAC for current selection. This means that you can select a drive current based on 4 digital inputs.

It is my understanding in what I've read so far that stepper-based systems are greatly dependent on precise timing (as the motor's angular velocity is entirely dependent on every pulse position/length) whereas in a brushed DC application the motor has little/no cogging effect and therefore can tolerate less precise PWM timing.
That being said...
The CPU is still busy trying to generate the PWM signal, and the PWM is rather noisy (audible).

Would it offload anything from the CPU if one drove a chopper controller such as this one from a 4-bit value based off of PID out? I imagine this would be a component much like PWMGEN. It would consume 4 outputs + direction for each motor, which means that one parallel port could drive 2 motors, bring in 2 encoders, a shared limit switch and still have a couple outputs to spare.

I'm not trying to save money here, I'm just interested.

Please Log in or Create an account to join the conversation.

More
14 May 2019 06:45 #133700 by pl7i92
this is the case as we Talk Hybrid
its a intirer controled Closed loop
with external step Direction signals
You need a 10times faster Cicuit then the PC signals to get a good result

it is not Nessusary if you tweek your Stepper System to a very good timing
as 100.000 (100k) ns time is for 60k steps per second SAFE step rate
most of here are investing in more Voltige and offcause more Torque steppers 8Nm then the speed
it is lower cost about 1/4 then servo

and it workes the same if you dont vneed the speed above 10meter/min

Please Log in or Create an account to join the conversation.

More
15 May 2019 22:25 #133928 by fungus
Hi pl7i92!

I apologize, I didn't explain clearly where I was going with this. I found these in a stepper controller, but I am attempting to use them in a single full-bridge configuration with a brushed DC servo.

My google-foo fails me, but I believe the servo thread is less taxing on the CPU (it runs slower than the base thread). What I am curious about is whether it would be to some advantage (as far as the CPU is concerned) to hand off PWM generation for a DC servo (or power regulation in general) to a slave controller. In this case, it is parallel communication of 4 bits rather than an analog output (which would require a tuned low-pass filter or an external DAC).

The PWMGEN component currently has pins:
pwmgen.N.pwm
pwmgen.N.dir

This would require (for example):
pwmgen.N.bit0
pwmgen.N.bit1
pwmgen.N.bit2
pwmgen.N.bit3
and could probably reuse
pwmgen.N.dir
It would consume a lot of outputs, but would tax the CPU less and get the motor's harmonics above human hearing range.

Again, this is just tinkering. I'm not trying to be a cheapskate ;)

Please Log in or Create an account to join the conversation.

More
19 May 2019 00:15 #134229 by tommylight
Am on a tablet that for some reason does not open the PDF.
PWM does not task the processor that much to cause it any issues, the noise you hear is from the low frequency of that PWM signal or from the chopper in the drive limiting the current to the motor.
PWM frequency can be set in Linuxcnc to pretty much anything within reason, but setting the chopping frequency might be harder or not possible at all for some drive IC's. That is always mentioned in the data sheet when there is a possibility of changing it.
The following user(s) said Thank You: fungus

Please Log in or Create an account to join the conversation.

More
19 May 2019 01:58 #134233 by cmorley
I believe you are right - sending a 4 bit output is easier on the CPU then making a PWM pulse because you can use the servo thread rather then a fast base thread.

Off loading high speed events is exactly what the Mesa/Pico cards do for linuxcnc.

Whether I works well in practice - will be interesting to know.

Chris M
The following user(s) said Thank You: tommylight, fungus

Please Log in or Create an account to join the conversation.

More
19 May 2019 22:47 #134298 by andypugh
I think this could be made to work, Take a PID scaled to give outputs from 0 to 16, pass the output through conv_float_u32 (or maybe ...s32, perhaps you can use the sign bit directly) and then in to
linuxcnc.org/docs/2.7/html/man/man9/bitslice.9.html
to make the output bits.

Actually, I wouldn't do that, I would write a custom HAL component to do it all in one lump, and with error checking etc.
The following user(s) said Thank You: tommylight, fungus

Please Log in or Create an account to join the conversation.

More
21 May 2019 01:12 #134420 by fungus
tommylight, thanks for the tip on being able to set the PWM frequency!
I ended up trying the following in the HAL file:
setp pwmgen.0.pwm-freq 100000000
setp pwmgen.1.pwm-freq 100000000
Then noted the actual frequency in halscope and changed it to something reasonably lower. (6kHz sounds decent)

Yes, the chopping frequency on these chip-level drivers cannot always be changed. In the case of the L298N, it does not do any current regulation, nor does it have an internal chopper. The inputs are literally just hardware buffered before the inputs of the H-bridge. There seems to be a bit of debate concerning the optimum PWM frequency for the L298N, and I'm too lazy to do the math right now ;)

Please Log in or Create an account to join the conversation.

More
21 May 2019 01:17 #134422 by fungus
andypugh, I'm going to try bitslice and report back. That would be an awesome workaround.

I'm returning to school this fall for computer science, and I'm really looking forward to diving deeper into LinuxCNC, make my own HAL components, etc. Currently I work for a company that's bringing me up to speed on FPGA architecture and PCB layout; I'm reading up on VHDL in my spare time. I can see this being my playground for a long time!

Please Log in or Create an account to join the conversation.

More
21 May 2019 02:40 - 21 May 2019 03:20 #134429 by fungus
Added:
loadrt bitslice count=2 personality=4
loadrt conv_float_u32 count=2
addf bitslice.0 servo thread
addf bitslice.1 servo thread
addf conv-float-u32.0 servo-thread
addf conv-float-u32.1 servo-thread

Current:
setp pid.0.maxoutput 1.0
setp pid.1.maxoutput 1.0
Changed to:
setp pid.0.maxoutput 16.0
setp pid.1.maxoutput 16.0

Kept (to preserve Xdir & Ydir via pwmgen):
net Xvel-cmd        <=         pid.0.output
net Yvel-cmd        <=         pid.1.output

Added:
net Xvel-cmd        =>         conv-float-u32.0.in
net Yvel-cmd        =>         conv-float-u32.1.in
net floatToBitsliceX conv-float-u32.0.out        =>         bitslice.0.in
net floatToBitsliceY conv-float-u32.1.out        =>         bitslice.1.in

Kept:
net Xdir                =>             parport.0.pin-0X-out
net Ydir                =>             parport.0.pin-0X-out

Added:
net Xbit00           <=              bitslice.0.out-00
net Xbit01           <=              bitslice.0.out-01
net Xbit02           <=              bitslice.0.out-02
net Xbit03           <=              bitslice.0.out-03
net Ybit00           <=              bitslice.1.out-00
net Ybit01           <=              bitslice.1.out-01
net Ybit02           <=              bitslice.1.out-02
net Ybit03           <=              bitslice.1.out-03
net Xbit00           =>             parport.0.pin-0X-out
net Xbit01           =>             parport.0.pin-0X-out
net Xbit02           =>             parport.0.pin-0X-out
net Xbit03           =>             parport.0.pin-0X-out
net Ybit00           =>             parport.0.pin-0X-out
net Ybit01           =>             parport.0.pin-0X-out
net Ybit02           =>             parport.0.pin-0X-out
net Ybit03           =>             parport.0.pin-0X-out

Does the above sound correct? This does not prevent the calculation of PWM, as I need that component still for direction; it will, however, get things above human hearing AND control the current to the motor via resistor network.
(Pardon my understanding of net, pin and flow direction; I'm still getting a grip on how that is handled)

EDIT: There were a couple syntax issues, but it looks like this will work! I'm going to work over the circuit tomorrow and give it a go. I'll post the HAL, a video and the circuit diagram if it works (or if it fails catastrophically)
Last edit: 21 May 2019 03:20 by fungus.

Please Log in or Create an account to join the conversation.

More
28 May 2019 18:52 #135186 by andypugh
Sorry, I have been tied up. How did this work out?

Please Log in or Create an account to join the conversation.

Time to create page: 0.106 seconds
Powered by Kunena Forum