search

sharpie7 / circuitjs1

Electronic Circuit Simulator in the Browser
GNU General Public License v2.0
2.28k stars 629 forks source link

Feature- Electrical resolver #679

Open jcmk opened 2 years ago

jcmk commented 2 years ago

I teach electronics maintenance in the military. Students often struggle with understanding how resolvers and resolver chains function, and I struggle with finding better ways to explain them. I use the circuit sim to demonstrate many concepts, and it would be very helpful if you could include resolvers. Resolvers - Wikipedia Ideally, I would like to be able to simulate resolvers with up to 2x rotor coil, 2x sine, 2x cos, connected in a resolver chain, a slider for rotating or selecting rotation speed, and a device to convert the resolver output to either analog or digital output. There seems to be dwindling information on resolvers on the internet, most of what I find are scanned copies of coffee stained textbooks from the 80s, so while my programming skills are not up to the task of forking and implementing, I can certainly provide information on how a resolver is supposed to function.

Thank you.

ipatrol commented 2 years ago

Maybe this would be best implemented with a generic "electrical machine" parent class, based on the DC motor at present?

jcmk commented 2 years ago

Maybe this would be best implemented with a generic "electrical machine" parent class, based on the DC motor at present?

I had thought basing off the transformer class might be the way to go, but you would know better. If you were to base it off a motor, it would have to be AC. I like the idea of an electrical machine class though, as that would pave the way to synchro-servos and the such.

TimFFischer commented 2 years ago

I tried to implement the formulas given in the simscape model with dependent sources. This model seems to have the main ingredients for a resolver, but no coupling capacitors an so on.

Here is the full model, or here as a subcircuit. The behavior looks reasonable to me: When phi is changed, the coupling to the secondary x- and y-coils also changes in a reasonable manner. I haven't checked the simulation deeper - a verification e.g. with the matlab model might be beneficial.

@pfalstad: I'm a kind of confused, that I have to use the factor "400" in order to get the right value out of the derivative within the 6-input and 7-input VCVS. Using "timestep" seems more obvious to me, but does not work... I copied this from the simulation of the variable inductor. Is there a reason for this value?

pfalstad commented 2 years ago

You shouldn't need that... I just tried creating a VCVS that outputs the dadt of i_p (which is a 100khz sine wave of amplitude 199uV) and I got a 125V sine wave as expected (199uV 100k 2pi), so I think the derivatives are being calculated correctly.

The 400 in the variable inductor is just a scaling factor to make the inductance larger (since the input current b is pretty small).

TimFFischer commented 2 years ago

Shame on me... of course, it's not necessary 🤦 (Un)luckily the non-differential terms were so small, that the output looked right. The correct output is for small resistor values therefore not far away from the upper solution.

So, I corrected the model: Here is the corrected one, and this is the corrected subcircuit...

jcmk commented 2 years ago

Thank you both for the quick action on this. I've only briefly experimented with it over coffee this morning, but the modelling looks correct. Where it gets more complicated though is in resolver chains. The output of one resolver becomes the input to another resolver, and the final output can then be decoded to calculate the difference between to two angles.

I missed the update where you added the controlled sources, which is a phenomenal feature. I thought the resolvers would have to be hard coded in, but even for resolver chains, it appears it can be done entirely using controlled sources. Awesome.

As an example of a resolver chain, say you have a steering wheel that isn't connected to the steering arm, but instead have a resolver on the steering wheel and a resolver and actuator on the steering arm. If the steering arm has the same angle as the wheel, the resolver has no output and the actuator is not told to move. If the steering wheel is turned, now the angles do not match, and the actuator will be driven until the angles are identical. Aside from the device that decodes the resolver output and drives the actuator, nothing is "calculating" that angle differential. It is produced purely electromagnetically.

I'll do a quick sketch to demonstrate that. It's near impossible to find information on resolver chains online.

Let me know if I should post it as a separate issue, but it would be really nice to have a "gauge" output. Something that I could map to voltages or phase differential and display as a gauge instead of just a number. In this application, it would be used to show the rotor angle the phi is representing.