В продаже МКОН - преобразователь протокола Modbus!

[capzap]

Получив ответ от slave - МКОН, естественно, не ждет еще 300мс. а вот не получив - ждет. И мастер, опрашивающий МКОН, по идее должен иметь таймаут не менее этих 300 мс.

ну вот взяли и разрушили стройную теорию мелкого что вы не умеете делать приборы

[melky]

Валенок почему перебор? просто столкнулся с тем, что есть протоколы, где длина ответа НЕИЗВЕСТНА, вот такие пакостные протоколы бывают.
И в коде нет возможности задать четкий размер буфера для принятия байт, только заведомо бОльший по размеру, при этом штатные средства работы с COM в ОС не предполагают динамическое изменение буфера на лету. В некоторых случаях можно посчитать длину, в некоторых нет,и тут вступает в дело timeout, который ждет несчастные несколько байт, которых уже не будет никогда, так как ответ пришел полностью.

з.ы. в Modbus длина ответа известна, так что там проблем нет, timeout работает только при обрыве связи....

[melky]

Филоненко Владислав каким образом МКОН знает, что ответ полный если он сквозной преобразователь а не сам опрашивает ? вот это и интересно.

capzap а при чем тут МКОН, когда речь о Мастере, который опрашивает прибор через МКОН ?
Если правильно понимаю, МКОН всего лишь преобразует TCP запросы в RTU и придерживает в очереди запрос, если в этот момент опрашивает другой мастер.

[capzap]

capzap а при чем тут МКОН

вот именно причем тут прибор, если Ваша роль городского сумасшедшего изрядно поднадоела. С чего появился повод высказать такое предположение:

Филоненко Владислав тут зависит как у вас работают timeout-ы. Если стоит 1000 мс, ответ пришел через 50 и 950 мс ваше ПО будет тупо ждать, то это простым словом "жопа" а не ПО.

иди сейчас в одном посте у Вас прибор и сковозной и одновременно ставит запросы в очередь. Нет прибора, не тестировали, не высказывайте своего мнения о чем не знаете

[Филоненко Владислав]

Филоненко Владислав каким образом МКОН знает, что ответ полный если он сквозной преобразователь а не сам опрашивает ? вот это и интересно.

capzap а при чем тут МКОН, когда речь о Мастере, который опрашивает прибор через МКОН ?
Если правильно понимаю, МКОН всего лишь преобразует TCP запросы в RTU и придерживает в очереди запрос, если в этот момент опрашивает другой мастер.

Ну какой сквозной, помилуйте сударь! С одного конца модбас ТСП, с другого RTU. Ясно что надо принять пакет, проверить CRC, преобразовать и переслать. Он сквозной, но с преобразованием

[melky]

capzap вы мне запрещаете узнавать принципы работы шлюза перед выбором его в кандидаты к покупке? Тогда зачем нужен форум вообще?

Не знаю, к счастью или нет, но голый Modbus и чтение его с двух мест меня мало интересует, вот был бы он сквозным для любых протоколов, и выстраивал бы в очередь мастеров, наверное уже приобрел бы...

з.ы. надоело, не читайте, пропускайте мимо глаз и ушей.

[capzap]

capzap вы мне запрещаете узнавать принципы работы шлюза перед выбором его в кандидаты к покупке?

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

[e.filatov]

Филоненко Владислав каким образом МКОН знает, что ответ полный если он сквозной преобразователь а не сам опрашивает ? вот это и интересно.

Пробовали спецификацию ModbusRTU читать? Пауза между символами 3,5 символа на текущей скорости обмена означает завершение передачи. И если, простите, slave тупица и порвал пакет - проблемы индейцев

[melky]

Пробовали спецификацию ModbusRTU читать? Пауза между символами 3,5 символа на текущей скорости обмена означает завершение передачи. И если, простите, slave тупица и порвал пакет - проблемы индейцев

И мастеру МКОН сообщает как-то что ответа не будет? то есть мастер будет выжидать 300+ мс в то время, когда МКОН точно знает, что пакет оборвался и ждать уже ничего никому не надо ?

capzap если двумя Scada системами я могу синхронизироваться по времени и опрашивать ОДНО RTU устройство, то вот сделать синхронизацию между Scada и например ПЛК может оказаться проблематичным или с танцами и бубном. То такое устройство становится очень интересным. Но вот судя по жалобам тратить деньги под объект может оказаться печальным. А тратить свои для тестирования не очень интересно, и так уже столько игрушек за свои купил, что уже как-то и хватит.

[capzap]

capzap если двумя Scada системами я могу синхронизироваться по времени и опрашивать ОДНО RTU устройство, то вот сделать синхронизацию между Scada и например ПЛК может оказаться проблематичным или с танцами и бубном. То такое устройство становится очень интересным. Но вот судя по жалобам тратить деньги под объект может оказаться печальным. А тратить свои для тестирования не очень интересно, и так уже столько игрушек за свои купил, что уже как-то и хватит.

использовать ОРС который единолично опрашивает устройства, а скады обращаются, как клиенты, это более надежно и профессионально.

жалобы, а какие жалобы? Довести до общественности что есть проблемы, не рассказав как воспроизвести, не предоставить лог опроса, заявить что уже полгода не пользуюсь это эмоция а не жалоба. Валенок говорил правильные вещи, был бы прибор попробовал бы "нагнуть" его чтоб он сломался, но у меня его тоже нет, позиция овена тут не совсем верная наверное это не зная суть переписки полугодичной давности. В базовом варианте все работает, мне нет оснований не верить что исследования проводились и тестировалось не на одном приборе, не стоит забывать что на шине время на запрос-ответ для первого и для последнего слейва может существенно отличаться.

а по играться мне приборы приходят бесплатно, а за свои деньги Вы видимо покупаете, то что потом не можете применить на месте, так это не игрушки а Ваши навыки и умения