Proteus модели

[OldDriver]

В моей шпаргалке есть раздел "Аналоговое моделирование" и много примеров.
В Вашем же коде, не вижу определений матриц/режимов. В моем понимании, так, как у Вас, работать просто не должно

Я его безусловно посмотрел. Так же как как и примеры найденные с VSM SDK.
У меня несколько проще задача. Есть светодиод. 2 ногий. Анод-катод. Есть его ВАХ. Есть формула интерполяции этой ВАХ с приемлимой точностью. Есть зависимости видимой яркости экрана LCD от тока через светодиод. Формально - элемент простой. Всего 2 ноги. Из примеров близко подходит пример резистора и источника тока. Только зависимость сопротивления нелинейная. В первом варианте я пробовал считать динамическое сопротивление светодиода исходя из полученного напряжения и вычисленного тока, занося результат проводимости в матрицу проводимости. Результат тот же. В рабочей точке все считается на раз. Стоит спустится по графику ВАХ ниже(меньше ток), начинаются проблемы со сходимостью. Видимо точку перегиба не может посчитать. Второй вариант проще по вычислительным затратам. Раз я все равно считаю ток, то и помещать его в вектор токов.(пример источник тока), только направлениею тока естественно противоположное. Я что то не учел? Нужно объеденить эти два моих варианта. Нужны и проводимость и ток? А двойного счета при этом не будет?

[OldDriver]

Сделал согласно шаблону диода. Заработало. Но смысла не могу понять в таком разделении. Как 2 элемента проще чем 1. Зависимости от времени же нет.?
Еще непонятно как правильно считать проводимость для моей формулы.

[ProtAS-13]

как правильно считать проводимость для моей формулы

Как, как - дифференцированием: Geg=dId/dVd
Функция Id(Vd) у Вас есть, так что, все очень просто, если, конечно, с дифурами на ТЫ.

[OldDriver]

Как, как - дифференцированием: Geg=dId/dVd
Функция Id(Vd) у Вас есть, так что, все очень просто, если, конечно, с дифурами на ТЫ.

Эх, пришлось вспоминать 30 летней давности знания.
Ну где то так получилось:

#define R_LED_PARALELL      10000000
#define R_LED_SERIALS       0.025
#define IWHITELEDVAX_K1     3.268
#define IWHITELEDVAX_K2     13.98
#define IWHITELEDVAX(X,Y)   ((X / R_LED_PARALELL) + exp(IWHITELEDVAX_K1 * (X - R_LED_SERIALS * Y) - IWHITELEDVAX_K2))

// Расчет по постоянному току.
VOID JDT1800::dcload(REALTIME crt, SPICEMODES cmode, DOUBLE *oldrhs, DOUBLE *newrhs) {
    //ainstance-›log("Current dcload time %f, modes: %s.\n", crt, getNameOfSpiceMode(cmode));
    //--- Расчет тока через пару паралельных белых светодиодов
    if ((cmode & (SPICEINITTRAN | SPICEINITPRED))) {
        DOUBLE сvoltage = oldrhs[LEDA_PIN] - oldrhs[LEDK_PIN];  //--- Предидущее значение напряжения на пинах светодиода.
        ccurrent = IWHITELEDVAX(сvoltage, ccurrent);            //--- Экспоненциальная апроксимация ВАХ для белого светодиода.
        ainstance-›log("For voltage=%f V, current=%f A.\n", сvoltage, ccurrent);
        //if (SpicePopup) SpicePopup-›print("For voltage=%f V, current =%f A.\n", сvoltage, ccurrent);
        conduction_equ = (1 / R_LED_PARALELL) + (IWHITELEDVAX_K1 * ccurrent);
        ccurrent_equ = ccurrent - conduction_equ * сvoltage;
        ainstance-›log("Ccurrent_equ=%f a, conduction_equ=%f, current via conduction=%f A.\n", ccurrent_equ, conduction_equ, conduction_equ * сvoltage);
    }
    *nodeaa += conduction_equ;
    *nodekk += conduction_equ;
    *nodeak -= conduction_equ;
    *nodeka -= conduction_equ;
    newrhs[LEDA_PIN] -= ccurrent_equ;
    newrhs[LEDK_PIN] += ccurrent_equ;
}

[ProtAS-13]

Ну где то так получилось

У самого "счастливые" воспоминания о дифурах погребены 40 летним слоем всякого мусора, но, на мой взгляд, Ваш код должен выглядеть так:

...
DOUBLE сvoltage = oldrhs[LEDA_PIN] - oldrhs[LEDK_PIN];
conduction_equ = (1 / R_LED_PARALELL) + (IWHITELEDVAX_K1 * exp(IWHITELEDVAX_K1 * (сvoltage - R_LED_SERIALS * ccurrent) - IWHITELEDVAX_K2));
ccurrent = IWHITELEDVAX(сvoltage, ccurrent);
ccurrent_equ = ccurrent - conduction_equ * сvoltage;
...

Надеюсь ничего не напутал.
Это из условия, как я понял, что в IWHITELEDVAX(X,Y) - Y соответствует предыдущему значению тока.
Впрочем, разница между обоими вариантами будет равна (IWHITELEDVAX_K1 * сvoltage)/R_LED_PARALELL, что при очень большом R_LED_PARALELL, наверное, несущественно.
Да, и в функции ...::dcload, oldrhs это ВЫЧИСЛЕННЫЙ, т.е. ТЕКУЩИЙ вектор узловых напряжений/токов, а newrhs - ЗАДАВАЕМЫЙ вектор.

[OldDriver]

У самого "счастливые" воспоминания о дифурах погребены 40 летним слоем всякого мусора, но, на мой взгляд, Ваш код должен выглядеть так:

Код:

... DOUBLE сvoltage = oldrhs[LEDA_PIN] - oldrhs[LEDK_PIN]; conduction_equ = (1 / R_LED_PARALELL) + (IWHITELEDVAX_K1 * exp(IWHITELEDVAX_K1 * (сvoltage - R_LED_SERIALS * ccurrent) - IWHITELEDVAX_K2)); ccurrent = IWHITELEDVAX(сvoltage, ccurrent); ccurrent_equ = ccurrent - conduction_equ * сvoltage; ...

Надеюсь ничего не напутал.
Это из условия, как я понял, что в IWHITELEDVAX(X,Y) - Y соответствует предыдущему значению тока.
Впрочем, разница между обоими вариантами будет равна (IWHITELEDVAX_K1 * сvoltage)/R_LED_PARALELL, что при очень большом R_LED_PARALELL, наверное, несущественно.
Да, и в функции ...::dcload, oldrhs это ВЫЧИСЛЕННЫЙ, т.е. ТЕКУЩИЙ вектор узловых напряжений/токов, а newrhs - ЗАДАВАЕМЫЙ вектор.

Ну если посмотрите, в condaction_equ после IWHITELEDVAX_K1 и есть ccurrent. То есть множитель в экспоненте перед х выполз из экспоненты. И у вас примерез на диод так же.
Так что выгоднее сначало посчитать его а потом использовать при расчете проводимости.
Кстати грабля вылезла в этом коде. При попытке построить ВАХ средствами протеуса (пример sweep analysis example) грохается где внурри dll. Завтра буду искать где и почему.

[ProtAS-13]

И у вас примерез на диод так же

Согласен, поленился написать подробный вывод формулы - для себя то было понятно.
В шпаргалке, эквивалентная проводимость для диода является не 100% результатом дифференцирования, а его приблизительным значением (см. рисунок).
Да, и по DC SWEEP.
Учитывайте, что для данного режима вызов функции ...::setup будет многократным.

[OldDriver]

Да, и по DC SWEEP.
Учитывайте, что для данного режима вызов функции ...::setup будет многократным.

Да, проблема в этом оказалась. Простой игнор повторных вызовов привел к полному непросчету. Она просто в блок расчета не попадает. Таких битиков не разу не выпало.
А в этом есть какой то глубокий смысл ( в повторных вызовах setup, они для чего то делаются?
Основные режимы при этом:

PROSPICE 8.04.00 (Build 21720) (C) Labcenter Electronics 1993-2017.
Loaded netlist 'C:\Users\AB68~1\AppData\Local\Temp\LISA6761.SDF' for design 'Sweep Analysis Example'
SPICE setup. [LCD1]
DSIM setup. [LCD1]
SPICE dcload. [LCD1]
Current dcload time 0.000000, modes: SPICEDC, SPICEDCOP, SPICEINITJCT. [LCD1]
SPICE dcload. [LCD1]
Current dcload time 0.000000, modes: SPICEDC, SPICEDCOP, SPICEINITFIX. [LCD1]
SPICE dcload. [LCD1]
Current dcload time 0.000000, modes: SPICEDC, SPICEDCOP, SPICEINITFLOAT. [LCD1]
SPICE dcload. [LCD1]
Current dcload time 0.000000, modes: SPICEDC, SPICEDCOP, SPICEINITSMSIG. [LCD1]
Repeatable SPICE setup. Ignored. [LCD1]
Repeatable DSIM setup. Ignored. [LCD1]
SPICE dcload. [LCD1]
Current dcload time 0.000000, modes: SPICEDC, SPICEDCOP, SPICEINITJCT. [LCD1]
SPICE dcload. [LCD1]
Current dcload time 0.000000, modes: SPICEDC, SPICEDCOP, SPICEINITFIX. [LCD1]
SPICE dcload. [LCD1]
Current dcload time 0.000000, modes: SPICEDC, SPICEDCOP, SPICEINITFLOAT. [LCD1]
SPICE dcload. [LCD1]
Current dcload time 0.000000, modes: SPICEDC, SPICEDCOP, SPICEINITSMSIG. [LCD1]

[OldDriver]

Да и с расчетом какая то лажа. Вид тот что надо. Результат не тот.
Светодиод стал источником тока. Круто.

[OldDriver]

Кстати, у вас примере также получается.
Если для Iequ1 развернуть с учетом вышестоящего выражения:
Ieq1 = ID*(1 -LAMBDA*(oldhrs[D1_1]-oldhrs]D1_2]);
LAMBDA = 38.9.
Разница на переходе 0.7 v. получаем псевдоисточник тока противоположной полярности почти в 35 раз больше чем пропускает диод по своей ВАХ.