Форум РадиоКот

Fizik_S писал(а):Но это решение только для Multisim. В симуляторе Proteus модели устроены иначе.

У меня тот проект лежит для Протеза и Мультисима. Не помню, в котором проверялся финишный вариант.

Если не сложно, поделитесь файликом модели.
diplodok преложил вот такое успешное решение, которое было проверено:
"Oшибка вышла вот о чём молчит"

У меня Multisim 14.3. Должно работать и на другие

1.Мышь на компонент.
2,Нажимаем правый клавиш.
3.Выбираем "Properties".
4.Выбираем "Едит модел"

5 ...

При очередной доработке схемы Орион-128 обнаружил ошибку в симуляции CPLD AM20V8
Заметил эту тему и вспомнил, что когда-то разбирался с одной схемкой и решил её промоделировать. Выяснилось, что модель 74хх191, она же КР1533ИЕ7, не_правильно работает. Вроде, кто-то на этом форуме мне подсказал, что ...

Учитесь программировать.
Учитесь программировать МК.
Учитесь программировать МК с ограниченными ресурсами.
Странный подход. Хочешь скорость- бери современный МК, периферия которого тот же Модбас принимает аппаратно, вплоть до сравнения адреса узла, и дёргает прерывание тогда, когда есть фрейм для ...

Если же устройство изготавливают на какой-нибудь убогой 8-битной АВРке, понятно, скорость шины больше 19200 лучше не выставлять. А то и 9600…
Вот именно, а то выставят на дохленькой восьмибитке 115200, а потом сетуют на большие паузы между байтами.
Помню, гоняли повторители для 485-го, так 922 ...

Идея ловли окончания кадра по IDLE, даже на стандартной скорости в 115200, шла по пи*де.
Просто скорость передачи была очень высокая для используемых МК и алгоритма их работы, другими словами, время входа в обработчик по отправке байта было больше длительности байта. Думаю, достаточно было просто ...

Поизучайте протокол, товарищи.
Их разрабы любезно придерживались стандарту и делали межбайтовые паузы согласно нему.
В Стандарте сказано, что пауза должна быть не более 1.5Т. Меньше- пожалуйста. Видимо, в китайских девайсах нет DMA, а программа написана так, что между отправками байт возникает ...

Будет зависеть от реализации программы на компе/ПЛК.
Не должен зависить. Есть Стандарт, который все программы тем или иным образом соблюдают. Поставьте демо-версии нескольких ОРС-серверов для Модбас и посмотрите, как в них настраивается опрос, может, тогда станет понятней, что критично, а что нет ...

Вы конечно можете настроить ведущему минимальный интервал между опросами ведомых, и я могу потормозить, но если вы этого не сделали - я могу не успеть к 3,5T, и провороню запрос к себе.
На практике ни кто не ставит миллисекундые периоды опроса ведомых, в этом просто нет смысла. И слушать начинать ...

На высоких скоростях в Modbus RTU, по IDLE, будешь постоянно ловить таймаут после первого байта. Если общаешься с устройством, для которого разработчики придерживались стандарту.
Враньё. По IDLE принимает без ошибок. IDLE взводится не через 1, и даже не через 2 бита, поэтому STM32 прекрасно ...

Ведомый вынужден слушать ВЕСЬ трафик, в том числе чужие ответы (других ведомых), по той причине, что у него нет надежного способа определить, этот пакет от ведущего или другого ведомого?
Приплыли. Вы внимательно смотрели форматы фреймов? Вы разобрались с ADU и PDU? подсказываю: _все_ фреймы ...

Если настроите на всех остальных ведомых паузу перед ответом, что бы ни кто не смел отвечать через 3,5T, по тому что я могу не успеть.
Приплыли. Вы так и не поняли, _как_ работает Модбас.
Уясните уже простые вещи, лежащие в основе протокола: отвечает только тот ведомый, которого спросили ...

Если я не успею к его началу - приму "битый" пакет.
Успеете. Уже устал объяснять, почему кадры не слипнутся. Возьмите для примера настройки _любого_ ОРС-сервера для протокола Modbus/RTU. В любом из них в том или ином виде есть настройки периодов запросов и _таймаутов_ для ответа ведомого. И пока ...

А ждать этого может придется недопустимо долго.
"Долго"- это сколько?
Всё имеет численное выражение, требования ТЗ или здравого смысла. Я ведь не зря несколько раз упоминал про таймауты узлов. И пример с вольтметрами приводил. У нас на том объекте было несколько контроллеров, которые нужно было ...

~Dimon~ писал(а):Можно ножку программно дернуть, на которой аппаратное прерывание.

Есть третий способ.
Если программа имеет архитектуру суперцикла, то можно просто в конце суперцикла обработать пришедший фрейм. И никакой многозадачности не нужно.

jcxz писал(а):Судя по сентенциям, вы не сумели реализовать широковещательную передачу по Modbus-RTU. Потому и доказываете, что оно не нужно. Вместо того, чтобы сознаться в этом.

Странное, конечно, утверждение. У меня в драйверах Модбас есть реализация широковещательных запросов.

~Dimon~ писал(а):С кварцем 18,432МГц, расчёт CRC 256 байт - около 0,4мс.

Считаете через вычисление полинома или по таблице? Как-то больно долго для табличного метода для 256 байт.

~Dimon~ писал(а):Я пока под AVR пилю.

Бросайте вы эти древние AVR, осваивайте RISC-V и ARM.

- Ожидание тишины 1,5T
- проверка CRC и адреса ведомого
- ожидание пока тишина достигнет 3,5T
Да, есть такое, но Стандарт писался во времена, когда не было UART с аппаратной поддержкой Modbus и производительность ЦП была низкой. Вот и запускали расчёт CRC с упреждением. Но что это даст сейчас при ...

После 1,5T начинаем считать CRC, но если до 3,5T прилетает ещё один байт - Галя, отмена?
При этом нужно успеть рассчитать CRC до истечения 3,5T, так как следующий пакет может пойти.
Нет, всё не так.
CRC вычисляется после паузы 3.5Т.
Если при приёме между байтами была пауза больше 1.5Т, то для ...

linux_rulezz писал(а): но даже несчастные 115200 они никак не могут ☹

Это проблема китайских частотников.Технических ограничений со стороны протокола на скорость нет, хоть 10Мбит/с, лишь бы трансиверы могли качать линию на такой скорости.