I found those files in both folders!

Yes. That's where LTspice writes files by default; but apparently it only reads the ones in the Documents path. I assume this is intended as some sort of backup arrangement.

 

I think I have done some mistake when simulating or something is missing

The resistor at place of the motor, what more should be added there ?

I have used IR2101, and also shorted HIN and LIN to control all 4 MOSFETs with 2 signal i\p

Need your suggestions on this one , and change to be made

Do i need to place diodes across (N-channel FETs )

freq is less than 1KHz, i\P range is from (0-5V) ,across the resistor which is in place of the motor need to have 8- 12V (is it feasible )

 

its important before proceeding for the pcb , to get the simulation work properly ..

Is it the input values that I have made mistake?

Or Sine wave input to the HIN input parameters?

I will be using Myrio from NI to give inputs to the MOSFets Drivers

 

A few errors spotted at a quick glance:
1) Your load (R5) is not connected between the sources of M1 and M3,
2) The way you have Hin and Lin connected, M1 and M3 switch on at the same time. Likewise M2 and M4 switch on at the same time. You need to swap the Hin and Lin drive on one of the IR2104's.
3) Why the common connection symbol on M2 drain?

 

Did you mean this way ?

I have made the changes , I am not clear about giving input to the IR's from the MYrio (Analog input to the IR HIN and LIN)


Are the values in the sinewave correct to the HIN and what shall be given to the LIN ?

 

@cmartinez

Can you check once if the .sch file is missing something. I feel the voltage across the load R5 is more than expected

LIN is low side input , what shall be given to drive the low side switch ?

 

The VS pins of U1 and U2 should connect to the sources of M1 and M3 respectively.
Hin and Lin are logic inputs, not analogue inputs.
If you want PWM control and reversing of the motor you will need 4 control signals. First direction: PWM M1, constant M4 on. Second direction: PWM M3, constant M2 on.

 

Are the values in the sinewave correct to the HIN and what shall be given to the LIN ?

Sine wave won't work on a mosfet driver. It needs to be a DC voltage of the correct value.

 

Other than what Alec and Shortbus have already suggested, I'd say that the values of C5 and C1 are way too high! ... you should change them to something in the range of 0.2µF to 0.4µF ... I've been using 0.22µF in real life circuits with perfect results...

 

Update. I've been using the new circuit for several weeks now, and it's proven itself quite robust and reliable. Plus the EMI filter is behaving beautifully. I haven't activated yet the current sensors. But I've been testing them, and it seems that I'm going to have to tweak that part of the circuit because the motor's current is too low and it's extremely hard to adjust the comparator's pot to a range of acceptable behavior. So it seems that I'm going to have to amplify the current sensor's output to narrow the adjustment window.

But as it stands, it's behaving now in such a way that it's extremely simple to program a velocity profile in its firmware. And it can also be easily controlled using a PC's serial port.

 

It has been a long post, I don't recall the nature of the serial command, is it Modbus?
What was the application again?
Did you do a rpm read out?
Max.

 

It has been a long post, I don't recall the nature of the serial command, is it Modbus?
What was the application again?
Did you do a rpm read out?
Max.

I'm using a simple UART communication protocol through RS232. I know Modbus, but I've never actually used it. Besides, with the proper protocol, simple RS232 can be just as reliable. As long as one includes all the timeout monitoring routines. Feel free to correct me or add your own observations if you think otherwise.

The application is a drill feeding mechanism to drill through up to 4" of wood. The complete system also monitors the drill's current to prevent overstraining and to tell when it becomes necessary to resharpen or change the tool.

And no, I don't have an RPM readout as of yet. But I want to include it in the next version. For that purpose, right now I'm trying to decide between monitoring back emf, or installing an encoder. Back emf would probably be more robust and reliable, but I don't have any experience with that technique yet. And I'm afraid of all the hurdles I might find regarding proper noise suppression and filtering circuits ...

But what the hell, one has to start somewhere. And besides, I'm not going to have to solve this problem completely alone, right?

 

An encoder is a little overkill maybe, I have used a dual slot disc with a slotted opto.
What is the max rpm? ~2k?
Max.

 

An encoder is a little overkill maybe, I have used a dual slot disc with a slotted opto.
What is the max rpm? ~2k?
Max.

Overkill, yes. And it would also add moving components to the design, which I'm trying to avoid.

Max rpm is about 1,200, lowest would be about 20. At such low rpms, I find it hard to visualise a proper back emf circuit. The noise produced by the commutation brushes would be a bit of a problem at such low voltages.

 

Overkill, yes. And it would also add moving components to the design, which I'm trying to avoid.

Max rpm is about 1,200, lowest would be about 20. At such low rpms, I find it hard to visualise a proper back emf circuit. The noise produced by the commutation brushes would be a bit of a problem at such low voltages.

A pair of IR proximity sensors and a black/white encoding "checkerboard" (quadrature pattern) on the spindle or even the non-business end of the motor shaft will give you all of the info you'll meed with no moving parts.

 

Update

I've built this circuit four times already, and this last time I configured it to work at 7.2 KHz, with a PWM resolution of 8 bits. I was expecting less EMI at this frequency, which is about twice of what I had originally been working with. And sure enough, the sporadic MCU resets characteristic of the previous versions decreased significantly, but not entirely.

My original aim has always been to build a circuit that can work at voltages that are 1:1 compatible with standard mains used in the american continent (respecting, of course, the use of an isolation transformer that is requested by the TOS of this site). And 120 VAC at 60 Hz has proven to be a difficult source to work with when mixing highly inductive loads with digital electronics in the same PCB.

Among the changes that I did to make the circuit more robust and reliable are:

#1) Increasing the working frequency from 3.92 KHz to 7.2KHz. This was possible because I'm now using the standard PWM function that an AT89LP4052 MCU is able to execute. And as I understand it, because a higher frequency normally generates less EMI when switching inductive loads. If someone here thinks (or knows) otherwise, I'd appreciate it if you took the time to explain why and correct me.

#2) Using a high-speed optical isolator (6N137) instead of the original, magnetically coupled one (HCPL-9030). The latter proved to be disastrous under real-world circumstances because it runs the risk of "latching" and therefore short circuiting both mosfets on the same-side of the H-bridge ... and I have a post-pyrotechnics picture to prove it:​

​

My wife was the tragic witness to this mishap ... I'm only glad that she's known me for more than 30 years, and that she's aware that I wasn't trying to impress her.... that would've been (even more) embarrassing

Thankfully, the component that blew up in my face was a 3-amp current-limiting thermistor (which is change #3), whose original function was to limit the initial inrush current to a large 560 µF capacitor that in the end I decided to scrap because down here the standard mains voltage is 127 VAC and not 110 VAC (and when that is rectified and filtered it reaches 180 VDC instead of the 120 VDC that I was [stupidly] expecting)
In the end, the thermistor performed the duty of an absent fuse (and of a very much present torch) and prevented a larger catastrophe.

Anyway, I'm not too uncomfortable with the prospect of running a 90VDC motor at 120 VDC (RMS), and in fact that hasn't proved to be a problem. The motor has hardly heated up while performing its work. And besides, not that much torque is being demanded from it anyway.

After the sight of those fireworks, I decided to keep the thermistor in the circuit for safety's sake, and also added a much-needed fuse (change #4).

#5) Installing several large value (22 µF) caps around the PCB in addition to the standard 0.1 µF decouplers at each chip, to make sure that the normal logic-level working voltage (5V) is kept reliably steady when the motor is started.

#6) Adding a ramp-up routine in the firmware that increases the PWM duty cycle from a startup value of 1/255 to the desired working value. This way a sudden, jerky start is avoided, and the initial current being demanded by the motor is limited to an extent. The rate of change (and therefore, the motor's acceleration) of the duty cycle is programmable.

#7) This is the most dramatic change that I made to the circuit, and by that I mean that this is the definite adjustment that solved 90% of its instability problems (the other 10% was solved by the previous adjustments ... which were actually finishing touches): I actually dared to install (sacrilege!) 1.5k resistors in series with the mosfets' gates! ... yes, you read that right, I used high-value resistors at the gates, and not the low-value (normally in the order of 10 to 50 ohms) that are traditionally used to limit ringing at frequencies higher than 10 KHz. Which is a frequency range that this circuit does not come close to be working in.​

To be honest, I'm not entirely sure why that last adjustment worked. But work it did, and it's been working wonderfully ever since. I haven't had a single sporadic MCU reset ever since. And that's saying a lot because this circuit has been working in an industrial environment. My theory is that the resistors are acting as (obviously) current limiters to the mosfets' gates, so that they take a little while longer to fully charge. And therefore they are preventing a sudden, sharp inrush of current to the motor's windings while switching. And I'm guessing that that sharp switching of current has been mainly responsible for most of the EMI that was being produced by the circuit.... I'd very much like to hear @Danko 's opinion on this matter.

Either way, I took the time to sim how the FET's gate that I'm using (the FDP33N25) would act like under the conditions I've described, and the results have been surprisingly similar to what I scoped in the real circuit. The 2.2 nF used for C1 represent the Mosfets' gates when they're switched with 12V, according to the datasheet.

Here's the sim at 8% PWM:

​

And here's what the real measurement looked like:

​

One last interesting note: The mosfets are not heating up at all, as I had expected them that they might, considering that they spend a bit of time at the "linear" region (or is it saturation? ... I remember that @crutschow once mentioned that mosfets have the definition backwards when compared to normal bipolar transistors)

 

@cmartinez, I was looking at making a similar circuit controlled from a STM32 chip, and this seems like its a really good starting point to work off of. Do you have the layout of your final circuit with the latest changes you made?

 

@cmartinez, I was looking at making a similar circuit controlled from a STM32 chip, and this seems like its a really good starting point to work off of. Do you have the layout of your final circuit with the latest changes you made?

Sure thing. Here's my final, working draft:



The transistors I'm using are the FDP33N25, and they're installed at the wago connectors at the center of the diagram. And BTW, the IR2101 has been discontinued. But it's been replaced by a new model which is pin-compatible and performs the same function. Look it up.