Ethernet, Повышение времени скана Опции

[Dima_Od]

FX3U - OWEN Ethernet. Здравствуйте. Первый раз на форуме. Интересуюсь вопросом о возможных причинах повышения времени скана при отправке 200 байт на устройство сторонних производителей (ОВЕН PLC100). При отправке такого же количества байт на другой FX3U - скан в среднем 30 мс, а на ОВЕН - 150..200 мс, а при старте FX3U - время скана 6000 мс (менял D8000 пока не перестал "виснуть"). SendTCP раз в 100 мс, вся программа 20000 steps. Если есть опыт "дружбы" Mitsubishi и OWEN - давайте делиться. Есть личные победы (в "шлемах" ) и вопросы.

Сообщение отредактировал Dima_Od - 19.02.2011 - 21:53

[KAZAH]

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

[Dima_Od]

Используется библиотека EthernetFX3UFixedBuffer_V230 и функциональный блок FX3UFixBuffSendActive. В общем, передача данных на "ОВЕН" всегда происходит полностью и корректно, но при этом скан программы резко увеличивается до безобразия. Также скан растет при добавлении портов оттдачи. При приеме данных скан особо не меняется. Попытки выяснить причину привели к заключению "слабовастости" FX3U и небольшой любви сего девайса к "ОВЕНу". Может, увидев "ОВЕН PLC 110" Mitsubishi "полюбит" переодетого "собрата". Может Q-серия будет шустрее, что по случаю проверю.

[KAZAH]

те блоки на которые ссылаетесь предназначены для передачи данных между двумя FX3U.для работы с овном нужно писать свой .ситуация при использовании кушки будет такая же тем паче что быстродействие у них примерно одинаковое (если не брать новые модели процессоров).при этих функциональных блоках хелп есть почитайте там ведь не сказано что мицубиши дружит с овном.или есть упоминание.про победы сильно.

[Dima_Od]

Уважаемый KAZAH, во первых: используемые мною функциональные блоки предназначена для работы в сети Ethernrt вобщем, и никак не ограничены в использовании по моделям, типам и производителям устройств. Устройствами Ethernet сети для этих функциональных бллоков могут быть АБСОЛЮТНО РАЗНЫЕ устройства (читайте "мануалы"), подтверждаю опытом.
Во вторых: сравнивать FX с семейством Q в плане производительности, по меньшей мере не корректно, т.к. внутри Q-серии различия меж собой ВЕСЬМА заметны, архитектура FX и Q разная да и масса других отличий, которые по данному контексту вопроса ВСЕГДА выгодно отличают Q от FX (кроме стоимости).
В моих уже давно завершенных и эксплуатируемых проектах основной сетью является Ethernet. Большенство учасников этой сети Qшки, меньше FX, еще меньше - разные другие, и все они дружат.
По теме: причину неприятностей скана решил - специфика работы своих програмных алгоритмов (другого характера).
Вобщем ОВЕН не является проблемой сети, даже наоборот.
Жаль что мало ответов по теме и не услышал ни одного толкового.

[KAZAH]

а что нам скажут из столицы Урала?а давайте разведем дискуссию.топик стартер доки в студию в подтверждение ваших слов.Было бы интересно услышать мнение rxs.там где время на логическую операцию все написано.если не брать те процы что с индексом Н то выигрыша в быстродействии нет.количество команд и архитектура значения для вашего случая не имеют.

Сообщение отредактировал KAZAH - 23.02.2011 - 00:37

[Dima_Od]

Все чудесные характеристики с прайсов и другой продавальческой инф видал до Вашего иллюстрирования. Дело в том, что есть вещи, которые для Q - родная мать, а для FX - ну его ..ать, т.е. для решения одной и той же задачи на - FX надо "упрашивать". Не буду выкладывать свои задачи и методы их решения которые не касаются Ethernet, но косвенно влияют. Да, в обсуждаемом мною случае колличество команд значения не имеют но каких и как - важно (еще важнее зачем), но вопрос не в этом. Вобще вопрос главный - ПОЧЕМУ отправка n Байт влечет увеличение скана, пропорциональное n? Почему так трудно "засунуть" n Байт по TCP, так UDP? Какие причины и как сними бороться или жить? Кто rxs?

[KAZAH]

болтун вы батенька.одни понты.общие фразы видимо и специалист вы особенный.и у одного и другого типа контроллеров возможно передавать данные по ТСР и UDP дело не в этом.претендовать на ваши особенные методы мы не будем тем паче что их нет.а стыковка 2х разных производителей контроллеров один из которых является откровенным отстоем вашими методами может быть признана изобретением.напишите что ли в представительство мицубиши и расскажите про осуществившееся чудо.когда нет аргументов напускают побольше тумана чтобы прикрыть собственную некомпетентность.вы на форуме CodeSys выложите блоки стыковки вашего чуда с мицубиши дайте ссылку посмотрим что вы там наваяли.надеюсь не запатентовали изобретение.читайте книжек больше вам будет полезно.

[Dima_Od]

хоть один ответ без понтов был? был ли ответ по существу? что за переход на личные наезды? а я спец ОСОБЕННЫЙ!!!!!!!!!!!! "те блоки на которые ссылаетесь предназначены для передачи данных между двумя FX3U" - ОТСТОЙ изречение!!!! по CoDeSys-темам и OWEN ответов больше и, зачастую, конструктивные. ВЫ KAZAH хоть раз работали с железяками в Ethernet? форум из 2х участников переходит в ерунду. "и у одного и другого типа контроллеров возможно передавать данные по ТСР и UDP" - У ВСЕХ (спасибо за открытие новых горизонтов). "претендовать на ваши особенные методы МЫ не будем" - мы это кто? "один из которых является откровенным отстоем" - у этого отстоя возможно по TCP 15 socket и по UDP 4 socket одновременно, а у FX3U их всего 8. книги читать полезно всем, но "многознание уму не научает" - помните об этом.

тему открывал не для выяснения компетентности участников форума, а для поиска возможных вариантов решения вопроса.

Сообщение отредактировал Dima_Od - 23.02.2011 - 20:48

[rxs]

Dima_Od если KAZAH что-то сказал, то как минимум надо отнестись к этой информации с уважением, почти всегда она верна. Ну и не нужно так реагировать резко
Не понял смысла вашего спора: доказывать друг перед другом - что могут одни железки и чего не могут другие.
Если есть вопрос, то он должен быть основной темой.
Блоки для связи писать все равно самому - если нет под нужное железо готового.

Вобще вопрос главный - ПОЧЕМУ отправка n Байт влечет увеличение скана, пропорциональное n? Почему так трудно "засунуть" n Байт по TCP, так UDP? Какие причины и как сними бороться или жить?

Надо уточнить видимо, отправка с FX3U на ОВЕН PLC100.

Сообщение отредактировал rxs - 8.03.2011 - 23:25