Перейти к содержанию
Поиск
    

firstvald

Свой
 Профиль  Обзор контента

  • Постов

    1 005

  • Зарегистрирован

  • Посещение

  • Победитель дней

    2

 Тип контента 

Сообщения, опубликованные firstvald

  1. Опубликовано · Пожаловаться

    Удалось обмен отладить - в структуре тайм-аутов тайм-ауты, начиная со скорости 19200 (хотя не понятно: для 38400 57600 115200 можно оставить то, что есть), пришлось увеличить в два раза по сравнению с теми значениями, при которых обмен работает нормально через обычный RS (замечу еще раз , что нормально обмен работает не при вычисленных значениях, а при подобранных, винда тайм-ауты считает практически никак, а менее 10 мс вообще никак).

     

    Теоретически, на символьных посылках с большими тайм-аутами этой проблемы не заметно вообще. Поэтому у кого-то работало и он уверял , что проблемы нет. На самом деле, если предполагается, что железяка должна работать и через RS и через мост или сразу только через мост, нужно потренировать обмен и посмотреть как там дела.

     

    В старых разработках, которые работали через RS, а теперь возможно будут работать через мост или в устройство вделывается мост и устройство становится как-бы USB, возможно, во внешнем софте придется подкорректировать константы в структурах тайм-аутов.

     

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

  2. Опубликовано · Пожаловаться

    Все как надо подтянуто. Дело не в фронтах. На скоростях 115200 работает. Ессно скорость 19200 правильно генерируется. В серии у нас на многих сотнях метров через кабель бегает. Наиболее вероятно - отклонение генератора в микросхеме, но это только догадка.

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

  3. Опубликовано · Пожаловаться

    Ну Вы даете. :) Так это проблемы использования MODBUS под Win, а не FTDI. Она передает и принимает все как надо. И, насколько мне известно, паритет она за Вас считать/проверять не будет - это должны делать передающие/принимающие модули. Могу только посоветовать установить бит паритета в 1 постоянно. Модбас такой режим допускает. Установить таймаут ожидания ответа порядка 100мс. А так как винда может, все равно, вставить паузу в непрерывный поток байтов при приеме/передаче - придется смириться с каким-то количеством ошибок и организовать повторные запросы.

     

     

    Нет не так. MODBUS под виндой спокойно работает во всем диапазоне скоростей. Правда, нужно очень аккуратно заполнять для каждой скорости структуру тайм аутов. И вовсе не теми числами, которые туда просятся теоретически :biggrin:

     

    Дело тут не в MODBUS - он просто обнаруживает те ошибки , о которых, гоняя символьные посылки, можно было до пенсии и не подозревать.

     

    Паритет должен проскакивать через FTDI насквозь без изменения. Так, как его сформировал передатчик. И мы должны иметь возможность работать со всеми возможными сочетаниями параметров связи. Получается, что надо нащупать какие работают , а какие - с вопросами. Чтобы заказчику потом объяснить - ты сюда не ходи, снег башка попадет.

     

    С тайм аутами да, очень аккуратно надо их выставить. Но то , что работало во всех диапазонах скоростей через честный RS, должно работать и сейчас (возможно некоторые тайм ауты надо увеличить - расстояние между байтами, скорее всего - да). Иначе скандал - RS в каком-нибудь небуке не бывает , а в цеху надо посмотреть. Начинаем смотреть и выясняется, что все посмотреть то и нельзя! У меня уже несколько раз была мысль о большом компе на тележке :lol: Персоналом, как бред не воспринимается.

     

    Про паузы. Непрерывные потоки не смотрел. На, скажем, в 256 байт, выходящих из машины, разрывов и пауз не видел ни разу. Этот вопрос я первым делом проверял. При приеме, уже написал, что если заполнить аккуратно структуру тайм аутов, каких - то провалов не наблюдается (но не на непрерывных данных). Но, это при значениях в структурах, которые сильно отличаются от того, что бы туда надо было прописать подсчитав карандашиком. Тайм ауты винда точно не считает.

     

    Вот интересно - окуда FTDI берет тактовые импульсы? ВМ их из кварца брала. А у этой?

     

    Буду еще смотреть.

  4. Опубликовано · Изменено пользователем firstvald · Пожаловаться

    Вы не торопитесь с выводами. Мы, также, FTDI давно и успешно используем. Что-то не так в вашей схеме или программе. Чудес-то не бывает. :)

     

    Бывает , бывает! Вот прогнал скорость 19200 без паритета - 1616 циклов без ошибок (вот уже 2180 без ошибок :) ). Значит FTDI не всегда удается передавать посылки с использованием паритета. А на 38400 и 9600 удается! Вот так вот.

     

    0 не появляются, я гоняю сырые байты - MODBUS RTU, он очень критичен ко всему и если в канале какие затыки сразу вытрясает их. Пришлось, правда, практически до безобразия, расширить допустимый интервал между байтами на стороне компа, но это на маленьких пакетах никак не улучшило дело.

  5. Опубликовано · Пожаловаться

    Почему на питание-то? Сигналы TTL инвертированные. Нужно на землю.

     

    А это уже не важно. Они просто доходят как битовые сигналы в комп,а уже там если используются, то тогда надо и думать каким его ставить.

     

    Я вот вижу: при CTS на землю - доходит в комп как 1 и так же DSR.

     

    Кстати, число сбоев не зависит от того, куда затянуть выводы.

     

    А вообще - общее впечатление - кошмар! Никакого ответственного оборудования (медицинского, промышленного) через такой порт делать нельзя. Что -то не так: "открывай кашелку, доставай сумочку", вытащить разъем из компа, закрыть программу, вставить разъем в комп, запустить программу.

  6. Опубликовано · Пожаловаться

    Если висят, то нужно отключить управление потоком в ПК. Но проще соединить между собой RTS-CTS и DTR-DSR, чтобы не думать на эту тему. Скорости передачи и объемы у Вас небольшие, поэтому управление потоком можно не использовать. Оставлять же висящими управляющие входы не стоит. Хотя там, наверняка, есть внутренние подтяжки, лучше подстраховаться от наводок...

     

    Управление потоком никогда не использую. Сразу же его в dcb отключаю.

     

    Нет, не влияет заведение этих сигналов на питание на обмен (заводил CTS DSR), как сбивалось, так и сбивается.

     

    Буду выяснять: вообще тот конец посылки, который откусывается , он когда -нибудь выходит из FTDI, или вообще остается в ней навеки?

  7. Опубликовано · Пожаловаться

    В FTDI232, кроме выводов RX и TX, есть еще сигнальные выводы управления потоком (как в COM-порту). Вы их используете или нет? В любом случае, не стоит оставлять их болтаться "в воздухе"... ;)

     

    Не, они у меня висят. Как висят в pdf от FTDI. Попробую сейчас CTS посадить куда. Только не в этом дело . Вот смотрю 9600 - 1600 циклов обмена без ошибок. Тут же на 19200 8 сбоев на 380 циклах.

  8. Опубликовано · Пожаловаться

    Хотя что - то подобное в нескольких темах видел - точно такого - нет.

     

    Вижу: при обмене (запрос ответ) через FTDI232RL происходит потеря окончания посылки ответа от прибора. Причем посылки-то небольшие : байт по 16.

    Игры с настройками тайм-аутов и величины буфера вообще никак не влияют. Данные от машины в сторону прибора доходят без ошибок. В передаче в сторону машины время от времени не хватает нескорльких байт в конце.

     

    По статистике получается самой плохой скорость 19200, на ней бъется в среднем каждый 50 цикл. На других скоростях сбой примерно раз в 200-300 циклов (и от скорости не зависит). Обмен редкий - цикл в секунду.

     

    Кто какую статистику получал? Какую микруху понадежнее использовать? Насколько подвержено этому 2102/3?

  9. Опубликовано · Пожаловаться

    У первого операционника в обвязке надо по постоянке выход с инверсным входом соединить. Или RC цепочка неправильно нарисована или надо к ней впараллель скажем в 510 кОм сажать резюк. Это предполагается фильтр? Вроде ФНЧ 2 порядка? Все же наверное у первого опера надо так сделать

    : два резистора последовательно , один 100 кОм, второй скажем 510 кОм и его шунтировать электролитом.

     

    Судя по офигительным емкостям фильтр на очень низкие частоты, может всеже что то ьнадо в схеме подправить - какое задание то?

  10. Опубликовано · Пожаловаться

    Давно пора в обязательные правила раздела ввести : "зарплата указывается после всяких там, так сказать, налогов и прочей ереси". Так как вся эта дурь разработчика совершенно не интересует, а если начать разбираться, то налоги составляют порядка 40-45% начисляемой суммы, вот и сравнивайте со шведами там или еще кем с победившим социализмом.

  11. Опубликовано · Изменено пользователем firstvald · Пожаловаться

    А мне вот это понравилось по ссылке:

     

     

     

    http://www.rabotka.ru/spravkval/155.php

     

    Кто этот бред придумывает?

     

    Если б Шишкин всему этому соответствовал, то он бы не Рожь написал, а Рожу, а Утро в сосновом бору выглядело бы так как оно сейчас на фантиках конфет Мишка косолапый намалевано.

     

    Но забавно , забавно. Попробуем сформулировать должностные обязанности Леонардо Да Винчи? (типа 8 часов - подвиг)

  12. Опубликовано · Пожаловаться

    планета вроде Земля, но как раз не Москва :)

     

     

    Вижу то же самое.

    Выход один - ни в коем случае не продавать свой труд за 3 копейки.

    Сначала вроде будут говорить - куда вы блин денетесь, но еще пара Шуяно Сусенских и , думаю, начнут нервно озираться.

  13. Опубликовано · Пожаловаться

    Мастерство как раз и заключается в том, что непредвиденных вещей практически не бывает и все основано на готовых, обкатанных когда-то решениях.

     

     

    Это до тех пор пока не задали абсолютно х***ю задачу. Типа , сделать атомную бомбу к 7 ноября, 7 ноября через неделю. Не утрируя, могу сказать, что подобные задачи встречаются периодически. Все сложности вижу сразу, в течении получаса при постановке задачи они выплывают. Как правило, не готовым к задаче оказывается предприятие (постоянно). Причем никто не заботится как и за какие коврижки ты будешь повышать свое мастерство. Не думаю, что у вас по- другому.

    Справедливости ради, могу сказать, что то, что видел сам у буржуев: те же яйца, только в профиль. Та же беготня тараканов при включении света. Может мне не повезло, и у буржуев я видел далеко не лучший образчик (просто уверен в этом), да и тут тоже попал в не самый Айс?

  14. Опубликовано · Пожаловаться

    Был бы нужен единичный образец, я сделал бы еще проще.

    Спасибо за внимание, но, к сожалению, предложенный Вами "паровоз" не соответствует требованиям простоты и неубиваемости.

     

    А банально пульс пару на двух автомобильных релюшках пробовали, одна из релюх по катушке зажигания работает. Собственно я такую штуку пользую. У меня задача другая стоит , но катушка на свечку все равно нагружена - чтобы не пробилась обмотка .

  15. Опубликовано · Изменено пользователем firstvald · Пожаловаться

    хм, искренне удивлён отзывами на описанные уважаемой Ольгой Николаевной требования к соискателю..., там нет ничего сверхестественного, - просто подробно и, надо скозать, проффесионально расписаны навыки трассировщика ПП в полном цикле разработки..., да к тому же ещё по старинке(старый добрый пикад), чувствуется рука госпредприятия(ЕСКД и прочее)..., на практике все эти пространные и витиеватые требования выливаются в просто грамотного, адекватного трассировщика средней руки(не хочу никого обидеть, сам такой), так что ишите и обрящите)..., а хотя бы за половону от 60000$ в год, я бы от человека требовал чтобы он и схемотехнику сделал и устройство оное запрограммировал..., а может ещё и на стороне PC-ки чтонить навоял(без этого обычно не обходится)... IMHO

     

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

     

    Я все это уже видел. :biggrin:

     

    То что на практике надо и то и то и то, но платить за это никто не хочет, и считается что с каких то кренделей все это надо занть, становится нормой. А это совковая норма привела к тому что инженеров то и повывели у нас . Не размоножаются , вот тек-с.

     

    Пора консерваторию апгрейдить.

  16. Опубликовано · Пожаловаться

    Лазерный дальномер подключен к сети Profibus DP посредством Unigate Profibus(RS232/422). Лазерный дальномер поддерживает интерфейс RS-485. Поэтому дальномер связан с Unigate через преобразователь ADAM 4520 (RS232-RS485). Длина кабеля от Unigate до ADAMa состовляет 40 см, а длина кабеля от от ADAMa до дальномера - 3 м. Для связи по RS485 применен кабель SINEC. Unigate, дальномер настроены на 19200 бит/сек, ADAM - 19200 бит/сек. Количество стоповых битов, стартовый бит, наличие бита четности и количество бит данных установлены на всех устройствах одинаково. В документации к ADAM сказано, что определение направления потока определяется автоматически или по сигналу RTS. Но Unigate не предусматривает RTS. Поэтому используется автоматический контроль. Возникает следующая ситуация: данные от дальномера поступают в Unigate через ADAM(направление потока от RS485->RS232), данные от Unigate проходят через ADAM. Но не воспринимаются дальномером.

    С помощью ноутбука подсоединился к ADAMу по RS232 c одной стороны и RS485 с другой. Данные идут в обоих направлениях. Сигнал RTS не используется. Ноутбук по RS232 соединил с ADAM, а ADAM к дальномеру по RS485. Ситуация аналогичная, что и с Unigate.

     

    Давнишний пост, но вдруг вы все еще ищите.

    Смотрите, у ADAM есть погрешность , она доставляет неприятность многим. Вообще говоря , линии A и B должны быть растянуты . Между линиями надо включить резистор 120 Ом. Линию А надо подтянуть к +5 вольтам через 510 Ом. Линию В - к -питания (земле) через 510 Ом. Скорее всего +5 у вас нет:) Тогда линию А подтягиваем через 5.1 кОм к +24.

  17. Опубликовано · Пожаловаться

    А мы вот таким устройством "сигнал в катушке генерируем". Если по голове несфокусированным магнитным полем шандарахнуть - мышцы всех конечностей сократятся. Это вот реальная "катушка", а не шарлатанство.

     

    Индуктор очень похож на заводной ключик!

    Я бы даже сказал, на разводной ;)

     

    Я вот думаю: берем магнитофон, для пущей важности -DAT, на вход подключаем то что заказчик хочет и вперед. Потом на выход подключаем опять же что он хочет и опять вперед.

    Можно и к звуковой карте компа все это напрямую подключать и все как заказчик хочет! И софт уже есть.

    Чё еще надо -то?

  18. Опубликовано · Пожаловаться

    Заглянул в фотки устройств. По своему опыту: несмотря на то, что, скажем, материнки в компах примерно так и выглядят, мы свои устройства так никогда не делаем. Даже, если оно полностью гальванически развязано от внешнего мира, тАкие длинные провода к альтере погубят всю работу. Лизать надо каждый провод- нужен он и если да, то КАК нужен и что будет, если по нему прибежит в гости помеха и с каждым проводом работать индивидуально.

  19. Опубликовано · Пожаловаться

    по-моему, YIG прав.

     

    Конечно прав. Даже разрабатывая с прицелом под электромагнитную совместимость приходится целый комплекс мер принимать. Ну и плата тоже соответственно развуодится не абы как:)

  20. Опубликовано · Пожаловаться

    мы думаем над программным способом решения проблемы. зависает не вся схема. центральный MCU шуршит как миленький. а вот периферия...

    и, если по-хорошему, импульс не должен доходить до логики (там, в частности, слетает прошивка fpga).

     

    ps. ссылки ушли в личку.

     

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

  21. Опубликовано · Пожаловаться

    Я с удовольствием пишу на C#, на нем 400 строк в _день_ не является чем-то необычным. Со всеми вытекающими.

     

    Отлаженные и документированные. Ага. Видел. К сожалению. И дооолго потом заставлял отлаживать.

  22. Опубликовано · Изменено пользователем firstvald · Пожаловаться

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

     

    Как ни странно у меня сложилось мнение что СВЧ узлы в своем большинстве разрабатываются удаленно. В свое время Москва или Нижний свои задания сваливали нам в университет и тут проверялись идеи и реализовываемость того или иного узла. Потом потенциальный заказчик приезжал и ему при необходимости показывалось работает или не работает то то или то то. Разработка СВЧухи штука специфическая и она тяготеет не к заказчику а к местам где и кто это умеет сделать. Другой вопрос кто должен работать удаленно - один человек грубо говоря дома или небольшая группа. Как правило еще с социализма повелось что заказывают группам , у них какие никакие приборчики есть.

     

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

     

    Чтобы разработчик ушел в манагеры - не слышал!!! Видно все таки это кастовая штука. Может если не очень хороший разработчик или если это совсем не его , хотя если ты дожил до того что стал разработчиком , то это значит что прошел ступеньки - радиолюбмтель, студент , студенческое КБ или там лаборатория какая и на одном двух предприятиях поварился. Если только после этого стало понятно что это не твое - тогда да, не твое :))) Хотя вот вспомнил в КТЦ МК есть менеджер который завязать не может - все че-то паяет пробует на вкус то что продает. :))

    Кто работал с КТЦ наверняка его знают.

    А так наверное если по деньгам приспичит то придется уходить.

  25. Опубликовано · Пожаловаться

    Предложение, конечно, невысокое, но всегда можно встречное сделать. Кому нибудь будет приработок. Предложений работы не так много.

    Чего кипятится, посмотрите результаты опроса по з.п.

    Или в Перми платят как в Москве?

    А дело то в том что в Москве уже практически и не пишут а валят например в Пермь. И это не шутка, а скорее норма.

     

    Про функции устройства и 300 р - крепко насмешили. Я когда оцениваю производительность и сроки на работу то исхожу из расчета SLOCов - исходных строк кода. Причем я примерно знаю что регулярный код где нет заморочек я питшу в среднем 400 строк в месяц. Сильно усреднено но примерно так. Дальше я ввожу поправки на сложность . Если пишется аппаратное устройство (там таймер или еще какая приблуда в процессоре) с которым работаю в первый раз, то коэффициент порядка 10, это значит что под работу с этой аппаратной штучкой я буду работать с производительностью 40 строк в месяц. Если пишется обмен с устройством в котором все работает и не очень сложно , то часть кода отвечающая за обмен пишется с коэффициентом 3 т е около 130 строк в месяц. Если обмен нужно отлаживать с двух сторон или разрабатывать протокол то коэффициент 5 иои больше.

     

    При прикидке сроков ориентируюсь на предыдущие работы - там примерно понятно сколько строчек какой блок занимает.

     

    Теперь про цифру 400 строк в месяц. Америкашки примерно так и оценивают производительность труда программеров. Для этого служит модель учета сложности кода и производительности COCOMA 2(в ней учитывается сложность кода и объем кода на основании анализа разработок американских программеров). Ориентировочно они считают что в год программер пишет 4000-6000 SLOC - документированных строк кода.

     

    Я зачем все это написал:

     

    Таперича про 300 р за функцию, боюсь, что даже для энтузиастов не серьезно. А там надо возиться и возиться как с обменом так и памятью . Микросхемка то ведь не простая - там целая система команд. И не зря у нее есть вывод сброса (!!!!). Я когда ковырялся , то понял зачем :)

×
×
  • Создать...