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

    

Diko

Свой
  • Публикаций

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

  • Посещение

Репутация

0 Обычный

Информация о Diko

  • Звание
    Частый гость
  • День рождения 17.04.1981

Контакты

  • Сайт
    http://
  • ICQ
    173727719

Информация

  • Город
    Харьков, Украина

Посетители профиля

989 просмотров профиля
  1. Изделия, действительно, стоящие, но если я правильно понял они предназначены для измерения и протоколирования параметров дуговой сварки. Там немножко всё по другому, напряжение чуть повыше, ток чуть пониже, длительность сварки и подавно больше. В этом плане есть вот такое изделие : Mobiles_Messgeraet_1600_S_eng.pdf Не исключено, что будет принято решение о его покупке. Но здесь несколько но 1) цена; 2) доставаемость; 3) срок поставки; Я сокорее не верно описал конструкцию. Дело в том что от трансформатора непосредственно идёт медная шина примерно 120х30 мм., К ней прикручены две гибкие медные шины общей площадью 500мм2 длиной около 40см. В своих изысканиях именно эти две шины рассматривал как шунт. Вот так это выглядит. Скорее всего условия не противоречивые, а не полные, и не определённые ( скорее всего это правильное слово, которое описывает ситуацию). Один из моментов создания этой темы был как раз самопонимание что мне нужно. Глупо, конечно наверное звучит, выглядит из разряда как измерить то не знаю что. Но в конечном итоге я хотел выслушать предложения по имеющимся вводным, в том числе и критику из разряда не хватает таких-то данных и проанализировав всё это подумать ещё раз Что можно измерить и что нужно измерить мне ( вернее то что от меня хотят). С одной стороны, как мне кажется, достаточно измерить средний ток за достаточно большой промежуток времени и сравнить его со средним током за другой промежуток времени. Параметры изготовления детали постоянны. Из того что было написано + то что я думал сам по этой теме, мне кажется достаточно обычно стрелочного вольтметра и смотреть напряжение на шине и с ним работать. Из-за чего этот сыр бор, условно в начале детали устанавливают ток 1500А ( реальное значение не известно, устанавливается в условных единицах, связь с током не известна), сварка идёт как надо, но с течением времени к концу детали этот ток приходится оператору изменять т.к. визуально изменилось качество сварки, и ток изменяют для получения нормальных характеристик. Плюс ко всему прочему на одинаковых деталях в разные смены приходится устанавливать разные значения силы тока. С другой стороны, технолог по сварке хочет знать точное значение силы тока в момент сварки дабы оператору сказать что ему нужно устанавливать... Здесь всё значительно сложнее и непонятнее. Не думал, что тема вызовет такой живой интерес, настолько живой, что я не успеваю анализировать, то что предлагается, не говоря уже о тому что бы попробовать. Не говоря уже о других текущих делах. Да и машина загружена сейчас то одним то другим, нет однотипности для анализа. Не думал, что возникнет такая полемика. Скорее всего я сам виноват, как я уже писал, не конкретизированной задачей... Поэтому 50% текста связано с тем что каждый эту задачу понял по своему, и решает СВОЮ задачу, так как он её понял. В целом, задча конечно и не решена, но я считаю, что её можно считать решённой. Всем принявшим в обсуждении огромное спасибо. Судя по всему самым оптимальным получается, как я и думал, снимать падение напряжения на шине ( измерив её сопротивление) и уже с полученным напряжением проводить математический анализ, как душе заблагорассудиться. Жаль только что техническая реализация этого проекта скорее всего не будет реализована. Но я всё таки постараюсь.
  2. Прошу прощения, но что я тогда получу в конечном итоге ? Как величина мною измеренная будет соотносится с протекающим в шине током ? Моя вина :( Следовало бы, действительно, нарисовать график тока. К сожалению времени на изыскания рисунков не было, да и сейчас не больше ( но всё же выполню график). Ток действительно постоянный импульсный. Пакетами длительностью по 15-20 мс (на тех деталях что изготавливали находилось в этом пределе), между пакетами 180 мс ( пауза между пакетами зависит от геометрии детали и может меняться). Внутри пакета импульсы с частотой 40кГц - ( не исключаю ШИМ, в режиме в котором я измерял внутри пакета скважность была близка к 50%).
  3. Да, вот у меня и возникают крутые сомнения, что хотят измерить совсем не то, что говорят измерить :)
  4. Скажем так, наверное, именно по этому я и создал эту тему, т.к. на мой взгляд я уже полез в какие-тол дебри и есть ОЧЕНЬ большой шанс, что не вижу какого-то простого и изящного решения. Особенно учитывая тот факт,что обсудить проблему здесь на месте просто не с кем :( А варение в собственном соку, в моём случае, не самый продуктивный способ решения проблемы. USB осциллограф применён ни из каких-то хитрых умыслов, а просто потому что он есть в наличии и я имею его в распоряжении своём безвозмездном. Мой личный девайс, на большее личный бюджет не позволяет, да и как-то не особо требуется пока. Можно по этому пункту поподробнее? Что касается импульса то нет никакого импульса, да и в импульсе импульсов хватает :) Но при наличии возможности измерить ток в момент сварки ( пусть и усрежднённый) это уже было бы круто. Токовый трансформатор это конечно хорошо, но мой жизненный опыт никак меня с изготовлением ТТ не сталкивал. В моём понимании получается нечто громоздкое, либо по количеству витков, либо по толщине провода. Могу конечно и ошибаться. Подскажите тормозу параметры ТТ для данной системы, ток 2000А. Да и форма проводника на который можно напялить ТТ прямоугольник примерно 30х150 мм. Скажем так. Моё личное мнение не совпадает с мнением руководства :( Но руководство хочет знать ток чуть ли не до Ампера в момент сварки, с целью подставить это значение в формулу и получить волшебный комплекс параметров для сварки. В плане финансирования, сейчас предложено купить прибор разработанный специально для таких целей, предприятием которое производит трансформаторы для точечной сварки(который стоит у нас). На мой взгляд на текущий момент достаточно проконтролировать параметр пропорциональный силе тока во время сварки. Но, зараза, время сварки 20мс, а пауза между сварками 180мс, к тому же значение ни разу не постоянное, от изделия к изделию. Ну хотя бы совсем усреднённое значение получить и то уже будет хлеб. Можно будет хотя бы утверждать, что ток изменяется или не изменяется, в ходе работы. Хотя я пока не смог для себя объяснить как он может изменятся. Стоит инвертор за инвертором трансформатор с выпрямителем и судя по всему с ТТ или его аналогом. Сварочный ток задаётся инвертору и надо полагать этот заданный ток поддерживается. Хотя вот сам написал сам подумал и вспомнил, что ток устанавливается аналоговыми сигналами, а не цифрой... Может и здесь собака порылась. Именно так и есть, никуда от этого не деться. Думаю, что постоянна только частота в импусле сварки, а импульсы сварки зависят от изделия и установок. Но в пределах одного изделия постоянны.
  5. Да вот как-то в этом направлении и посматриваю. Скорее всего некое среднее значение получить будет вполне достаточно Скорее как этот сигнал скажется на измерении :) Отнюдь. Даже улыбки не вызвало, т.к. единственный в наличии осциллограф который у меня есть, это простой китайский USB осциллограф, вот им-то сейчас и пытаюсь проанализировать и форму сигнала и всё остальное. Ну, в плане высоковольтности здесь немного не так :) 11В максимум :) Но ток 1500В. Но с точки зрения развязки полностью согласен. Сейчас пользую осциллограф USB подключенный к ноутбуку, а ноутбук на АКБ, от сети отключен. Резюмируя всё выше сказанное и предложенные варианты, судя по всему в моём случае самым оптимальным вариантом будет измерение падения напряжения на шина милливольтметром. Что думаю вполне сможет показать изменение тока, в случае его изменения. Так как временные характеристики в процессе изготовления детали меняться не должны, то единственный вариант изменения показаний прибора будет изменения силы тока в момент сварки. Осталось выяснить какое ж там падение напряжения. Когда тыкался осциллографом получилось около 2х В.
  6. Это скорее всего через верх. Задача состоит в том чтобы отобразить текущее значение тока, так что бы можно было оператору посмотреть какой сейчас ток. И при необходимости изменить его. Значение самого тока требуется инженеру-технологу, но лично я сильно не уверен, что это ему поможет. В общем есть ситуация, что качество сварки изменяется от начал детали к концу, и приходится на глазок уменьшать ток сварки ( кажется уменьшать). Более того в разные смены разные уставки приходится делать при одинаковых условиях сварки (те же детали). Одно из предположений, что ток сварки изменяется в зависимости от входного напряжения в сети. У меня на это другое мнение. Но факт остаётся фактом в процессе изготовления детали оператору приходится изменять настройки сварочного тока, для получения удовлетворительного результата. Но здесь дело в том что есть и другие параметры которые могут изменяться, например, сила "сдавливания" (что-то не могу правильно сформулировать). Поэтому требуется проконтролировать имеющуюся силу тока. В целом устроит и стрелочный прибор который будет отображать текущее положение дел. Но у меня как-то возникли проблемы с током в 1500А и тем что ток импульсный, "дважды" импульсный.
  7. Чуть выше я уже писал, что вполне возможно встать на шину и измерить падение напряжения на ней. Шина это медяха 520мм2 длинной примерно сантиметров 40. И в целом можно поставить осциллограф, но физически это кране не удобно. Так как требуется моё лично присутствие и контроль. Есть вторая особенность это наличие 2 смены, крайне не хочется жить на заводе, чтобы измерять ток :)
  8. Здравствуйте. Возникла необходимость измерить ток точечной сварки. Параметры того что измеряется примерно следующие: Ток в диапазона от 1500 до 3000 А ( на машинах с аналогичным техпроцессом и установкой тока в "А" присутствуют именно такие значения, да и теория говорит о них). Сварка происходит с частотой порядка 5Гц, длительность 15-20мс. (Длительность, если и меняется то в небольших пределах, частота зависит от размеров детали, скорости). Ток постоянный, но импульсный частота 40кГц. Т.е. идёт время сварки 20мс с частотой 40кГц заполнение, пауза 180мс, и так далее. На данный момент к точности измерения требования не предъявляются. Необходимо проконтролировать не изменяется ли ток во время процесса. Т.е. изголтовление детали длится порядка 2-х часов, интересует изменение тока от начала процесса и до конца. Так же было бы не плохо иметь значение этого самого тока, но это уже вторая задача. Притом желательно это сделать так что бы была некая индикация не требующая специальных манипуляций, т.е. что бы контролировать изменение тока мог оператор. На данный момент единственно что пришло в голову это встать на шину осциллографом и измерять падение напряжения на ней. С точки зрения контроля изменения тока в начале процесса и в конце, наверное вполне приемлемо. Но стоять с осциллографом у машины крайне не удобно. Заранее спасибо за предложения.
  9. Всем откликнувшимся огромное спасибо. Благодаря этой теме удалось узреть несколько практических реализаций протоколов обмена, что и являлось одной из целей данной темы. Второе я почитал хорошие тем в плане протоколов и их реализаций в частности Wake, он основан на SLIC который а свою очередь описан в РФЦ. А что касается старттопика, то я сделал следующим образом. Использовал компонент TAdpDataPacket. В событии OnPacket сделал обработку принятонго пакета с отправкой подтверждения. OnTimeout сделал обработку если таймаут(логично вроде). Настроил на пакеты длинной 7 байт PacketSize= 7, EndCond = ecPacketSize; StartCond = scAnyData и на данный момент поставленные задачи выполняются. На будущее конечно буду переписывать протокол, скорее всего в разрезе RFC1055 или чего нибудь подобного, но позднее.
  10. Цитата(AlexandrY @ Nov 18 2016, 10:55) В AsyncPro этих протоколов уже есть как собак нерезаных. Простейший путь кинуть на форму компонент ApdDataPacket Читайте APRO_ReferenceGuide.pdf стр. 141 Сапсибо! Вариант решения возникшей проблемы
  11. Спасибо. Буду поизучать в этом направлении.
  12. Цитата(zltigo @ Nov 17 2016, 11:43) В огороде бузина, а в Киеве дядька - у "любого" протокола таймауты это обязательные АВАРИЙНЫЕ ветки. Использование таймаутов для фрейминга, это фича УБОГИХ протоколов. Использование убогих протоколов с таймаутами для фрейминга в системах типа Windows не имеющих поддержки реального времени есть 100% махровая любительщина . Так что протокол менять однозначно, а не бороться до конца жизни с тем, что надежный фреймиг по небольшим таймаутам под Win нереализуем в принципе. ЭЭхххх, даже не могу ничего возразить - просто потому что "протокол" это очень громко сказано, и определение УБОГИЙ вполне себе подходит. Никогда до этого не сталкивался с организацией передачи данных между устройством и ПК. Посему и наступил на эти грабли. В связи с тем что само по себе устройство не весть что, думал как-то обойтись малой кровью точнее малыми трудозатратами. Т.е. раз в интервал времени сформировать пакет и отправить его на ПК, а уже на стороне ПК всё это собрать. Скорость передачи не имеет большого значения - не первостепенная задача. Сейчас у меня передача 32кБ занимает около 5 минут, меня это вполне устраивает. Чтение данных в таком объёме предполагается раз в месяц в лучшем случае, а то и реже. От скорости передачи СОМ это не зависит, скорость ограничена именно интервалами отправки пакетов. т.е. и на 9600 и на 115200 время передачи занимает одинаковое. И да это любительщина эпитеты к слову любительщина можно подбирать самостоятельно и долго, я с ними согласен. В данном проекте я наступил на идиологические грабли. Сделать сейчас как-нибудь чтобы побыстрее, а потом уж переделаю как надо... Сам за такое "вжаривал". Протокол менять... Ну, менять можно то что есть и работает Сейчас вобщем-то ничего нет. Что вы порекомендуете ? Как изменить протокол и как его реализовать ? Цитата(AlexRayne @ Nov 17 2016, 20:05) чем городить такое лучше поправить протокол - для этого не нужно городить железо, и оно будет надежно работать почти везде. неужели невозможно ввести маркер заголовка? CTS-RTS вам поможет мало. лучше посмотрите в сторону линии DTR-DSR - кажется они дают прерывание и можно повесить обработчик этого события. но вы покладете комп на обработку этих прерываний если они будут лететь интенсивно, а судя по размеру ваших пакетов - они будут свистеть интенсивно. - на вендовой (да и на линуховой) машине гораздо быстрее будет работать обмен с маркером чем с прерыванием. Да можно ввести и маркеры, сейчас над этим и думаю. Пакеты коротки не потому что они идут с большой скоростью, а просто так сложилось .... Без особых на причин. 32кб передаются около 5 минут.
  13. Цитата(k155la3 @ Nov 17 2016, 10:05) без претензий на звание специалиста -- Абсолютно !!! Я ни разу не претендую на звание специалиста, всязи с чем и задаю этот малоинтересный местному сообществу вопрос. Цитата(k155la3 @ Nov 17 2016, 10:05) Вам правильно подсказывают насчет таймаутов. Каким бы компонентом Вы не пользовались, они (скорее всего) в конечном итоге делает ситемный вызво ReadFile() или ReadFileEx() и подготавливает блок DCB - структура управления-настройками СOM-порта, а также COMMTIMEOUT структура. Это понятно, что так оно и есть. Была даже идея заморочится самостоятельно разбираться с АПИ и т.д. Хоть и понятно что знани для этого прямо скажем совсем мало... Но общее представление о работе с компортом я получил. Цитата(k155la3 @ Nov 17 2016, 10:05) Так вот, если компонента позволяет настраивать эти таймауты - проблем не будет. Если же нет - Вы не сможете обеспечить надежный и быстрый обмен в Вашим устройством, а таймауты (они потребуются в любом случае) придется организовывать самому. Я использую прямой вызов ReadFile() с настройкой DCB. Устойчиво принимаются на PC пакеты от моего девайса на 57600 c межпакетной паузой 50 мс Компонент позволяет настраивать какие-то таймауты - какие и как достоверно не разбирался пока что. Цитата(k155la3 @ Nov 17 2016, 10:05) По этой теме есть хорошая книжка Агурова, там есть описание всей низкоуровневой "кухни" работы с компортами. На данный момент занимаюсь более углублённым изучением этой книги.
  14. Цитата(AlexRayne @ Nov 17 2016, 00:54) вот непонятно почему тут вы отвечаете 32 а вот тут - 31? одинаковые же пакеты? Вот здесь-то как раз и засада В том что устройство отвечает "правильно", а вот ПО на стороне ПК немного неправильно вычитывает из буфера. И соответственно считает, что пакет неверен и отправляет 32 - хочу ещё раз этот пакет. Вот что видно на стороне ПО... B8 3D 94 01 4F 00 09 E5 B8 3D 9E 50 00 50 CD E5 B8 3D 9E 50 00 E5 B8 3D 9E 50 00 CD Цитата(AlexandrY @ Nov 17 2016, 01:02) Функция ReadByte для AsyncPro написана идеологически неправильно. Нельзя ждать там прихода данных и делать ProcessMessages. ProcessMessages очень скверная функция могущая застрять на неопределенное время. Надо перехватить событие поступления данных и читать столько сколько событие скажет. AsyncPro - это многопоточный движок. Ему не надо помогать циклами ожидания. Как-то так я и думал... Точнее я даже в этом был уверен. Почему-то у меня не сложилось с событиями ( что точно я уж не поминю, точно делал функцию приёма в событии но толи не доконца разобрался толи ещё какая-то беда была. Работала функция не совсем так как я хотел, а всвязи с тем что не доконца понимаю что не так, решил сделать так как понимаю, ну или кажется что понимаю. Подозрения на ProcessMessages были, но здесь два но. Первое то что я решил ну раньше или позже будет вычитан байт из буфера ... не важно, никуда из буфера не денеться. Второе я убирал ProcessMessages из функции, координально ничего не изменилось). Можете ли привести пример как правильно организовать приём "пакета" с использованием событий в AsyncPro, пакет не большой 7 байт. Цитата(AlexandrY @ Nov 17 2016, 06:36) Таймауты - стандартная фича любого протокола. Реальное там время или не реальное не так важно в данном случае. В Windows нет понятия реального времени. В компоненте AsyncPro есть собственное поле задания таймаута. Им и надо пользоваться, а не пытаться заново строить велосипед. Где-то в хелпе я это видел, но когда занимался общим изучением, поэтому сейчас потерял этот момент, и отложил на день другой поиски.
  15. Покопался в том что у меня происходит и вот что увидел : это пакет которые у меня программе: B8 3D 94 01 4F 00 09 E5 B8 3D 9E 50 00 50 CD E5 B8 3D 9E 50 00 E5 B8 3D 9E 50 00 CD Пакет полностью выглядит правильно E5 B8 3D 9E 50 00 CD. B вот как выглядит лог asyncpro : 0002.442 Dispatch ReadCom 00000007 [B8][3D][94][01][4F][00][09] 0002.443 Dispatch WriteCom 00000001 [31] 0002.470 Dispatch ReadCom 00000006 [E5][B8][3D][9E][50][00] 0002.470 Trigger Avail 00000003 0002.471 Dispatch ReadCom 00000001 [CD] 0002.472 Trigger Avail 00000001 0002.472 Dispatch WriteCom 00000001 [32] 0002.501 Dispatch ReadCom 00000007 [E5][B8][3D][9E][50][00][CD] 0002.502 Dispatch WriteCom 00000001 [32] 0002.530 Dispatch ReadCom 00000007 [E5][B8][3D][9E][50][00][CD] 0002.532 Dispatch WriteCom 00000001 [31] 31 - байт подтверждения удачного получения пакета 32 - байт для повторной отправки пакета (в данном случае возникает т.к. пакет на соответствует CRC) B log.trc того же куска Transmit: [31] Receive: [E5][B8][3D][9E][50][00][50] Transmit: [32] Receive: [CD][E5][B8][3D][9E][50][00] Transmit: [32] Receive: [E5][B8][3D][9E][50][00][CD] Transmit: [31]