Too many iterations without convergence

[Brougs]

Hi,

Could you please help me with this error message. There is no reference to it in the manual. It occurs when I press the play button on a 555 circuit I have drawn up. Its my first attempt at using VSM so perhaps I am missing something.

I checked any other references on this forum to this error message and there is only one post which does not relate to my problem.

If I have attached the design. Any help would be most appreciated

Many Thanks

 

[Technical]

This is a known issue that can arise on some circuits when using the battery symbol. It will be fixed in the next ISIS release.

In the mean time simply replace the battery with a power and ground terminal instead (right click > terminals). The simulation will then run correctly.

 

[Brougs]

Hi Technical,

You Beauty !

Really appreciate your response. Now I can get on with checking it out.

Cheers

Buzbot

 

[tiscando]

I often get this error when I am creating frequency-involving circuits:

[SPICE] Gmin step [46 of 120] failed: GMIN=3.54813e-007
[SPICE] Gmin stepping failed
[SPICE] Source step [0 of 120] failed: source factor = 0.0000
[SPICE] Too many iterations without convergence.
Real Time Simulation failed to start.

Could anyone suggest a global remedy please?
Or do I have to provide an example?

EDIT: At the moment, I keep having to work around this problem, which unneccessarily narrows my possibilities.
I don't use the battery symbol.

 

[tiscando]

hi,

I didn't get a reply to the above post yet. I think this means that I have to give you an example of this glitch (whick keeps mentioning "GMIN") that happens in my frequency circuits.

See the attachment, I am trying to make a declining square-wave delay for a brushless optical-sensor motor driver circuit, because there is a slight delay in the signal from the optical encoder to the change of the magnetic field on the windings, which is a problem when one of the signals goes above 800Hz. This is why if I set the encoder so it changes state a bit before it is supposed to change state, the motor spins at a faster speed.
For example, A logic circuit would be on the starting state, where the signal from the encoder goes to the right inputs on the driver. When one of the signals go above 200Hz, a state change from a picaxe switches the logic circuit so the encoder's earlier signals go through this declining delay into the corresponding driver inputs. As the frequency gets higher, the delay time lowers a bit more than the frequency, in a way that compensates the processing and winding delay.

Anyway, when I click on 'run' in this circuit diagram, I often get the simulation terminating after a split second with the error log saying (I can't copy the error messages into this so I had to type them. If I try to by pressing ctrl+C, an error message says "TBD".):

[SPICE] transient GMIN stepping at time=0.0018281
[SPICE] transient GMIN stepping at time=0.00193992
[SPICE] transient GMIN stepping at time=0.0020315
[SPICE] transient GMIN stepping at time=0.00212308
[SPICE] transient GMIN stepping at time=0.00221465
[SPICE] transient GMIN stepping at time=0.00230612
[SPICE] transient GMIN stepping at time=0.00239528
[SPICE] transient GMIN stepping at time=0.0024868
[SPICE] transient GMIN stepping at time=0.00257832
[SPICE] transient GMIN stepping at time=0.00266984
... (the number of extra ones like the above varies before the next one)
[SPICE] TRAN: Timestep too small; timestep = 1.25e-019: trouble with node #U1:B VE#branch.

Could anyone give me a solution please?

In the 'so many axevsm errors...' thread, is anyone investigating why programs go wrong in addresses higher than $4000? (limiting the possible X1 program size down to 2048 (half of 4096).

 

[Technical]

This is complicated to fix, but is a limitation of simulation.

In simple terms this basically means that the 'maths' to generate the waveforms requested simply can't be achieved by the SPICE simulation engine. This is normally caused by bad simulation circuit design, e.g. unconnected nodes.

As an example in this case you have lots of capacitors which are effectively floating at one end via the DIL switch (when in the off position). This gives lots of capacitors that are not connected at one end and so difficult to model.

Start with a very simple model and then gradually add components to get an understanding of where the errors are occurring.

 

[Labcenter]

Such errors can be either poor design or genuine numerical convergence failure.

If the problem really is numerical convergence, you can try the following tactics:

· Increase the value of GMIN. This is a leakage resistance for reverse biased semiconductor junctions, and lower values make the circuit look more and more like a network of resistors (which will always solve). But this is at the expense of accuracy. The default is 1E-12; values above 1E-9 will give fairly meaningless results.Note in any case, that SPICE3F5 will try what is called GMIN stepping if at first the circuit will not converge. This means that a large GMIN is used to find an initial solution, and the value is then ramped back to its original value in order to maintain accuracy.

· Increase the value of ABSTOL and/or RELTOL. These values control the accuracy that is required for the simulation to be deemed to have converged. However, the larger you make these tolerances, the less accurate the results will actually be.

· If the circuit uses op-amps, try specifying MODFILE=OA_IDEAL instead of a specific device type - this model is much easier to simulate.

· Lower the value of TRTOL. This will make SPICE use smaller timesteps so it will be less likely to ‘lose’ a convergent solution, but at the expense of longer run times. This will only work if the simulation has failed part way through a transient analysis.

· You should also try reducing TRTOL if plotted traces look ‘spiky’, or contain mathematical noise. This often manifests itself as oscillation of a value after a rapid level transition.

 

[tiscando]

Thanks for your suggestions. Just realized another op-amp is there so I changed it's model to "OP_IDEAL", and the simulation now does not stop within 1 minute, although the error log gets lagged with recurring "transient GMIN..." messages.

Labcenter,
I tried all of your suggestions but the simulation kept on stopping after 1 second.

 

[tiscando]

I've just got the same problem in the 555 astable demo sample!

At one random time in the simulation when the voltmeter reads 6V, the supply rails briefly flash different colours, then the simulaion terminated with the error log saying:

[SPICE] DELMIN increased to 7.10543e-015 due to lack of time precision
[SPICE] transient GMIN stepping at time=40.1737
[SPICE] TRAN: timestep too small; timestep = 8.88178e-016: trouble with node #00000

The help buttons don't work. Message box says "cannot find the windows.hlp file" Using windows Vista.

The error log does not receive the above if I replace the battery symbol with the power symbols, although now the 0V line is green rather than blue.

 

[tiscando]

Charge pump simulation...

Anyway, the cause of all the yellow messages mentioning GMIN in the error log, is in the LM2907 charge pump (frequency to voltage converter) circuit in the attachment.

Basically, the error log gets lagged up with endless:
"[SPICE] transient GMIN stepping at time=(elapsed simulation time)"
wih a few:
"[SPICE] DELMIN increased to ### due to lack of time precision"
where ### = this sequence: 6.93889e-018, 2.77556e-017, (much later) 1.11022e-016.
This slows the simulaion down to about 0.02sec per sec (with 1.73ghz pentium M).

Could anyone report about the error-lagging simulation of the charge pump or something in the circuit please?

EXTRA: The charge pump doesn't work properly when the supply voltage is 5V. It only works correctly when the supply voltage is 8V or more. Is this normal for the LM2907 charge pump? Does a real LM2907 only work properly on an 8V-26V supply?

When the GMIN message lag happens is when the supply voltage is 8V or more. I don't see the GMIN messages when the supply is 7V or less.

 

[tiscando]

On my new computer, core 2 quad q8200, about200 yellow messages smoothly appear in the error log every second, and with the oscilloscope, the simulation runs between 0.03 and 0.04 virtual sec per sec.

If I remove the oscilloscope, just because I thought it hogs the processor, the simulation speed doesn't seem to go much faster.


Of course I can create a charge pump just using diodes, resistors, capacitors, and op-amps, and the result is that there are no GMIN messages, even with the opamp lisa models being oa_bip.
edit: but at low frequencies, it doesn't provide a constant voltage anyway, so the proper frequency to voltage converter is the most ideal.

 

[tiscando]

A simple question I have is:

How do I increase the number of iterations without convergence allowed?