. Задача стоит очень интересная... а может быть и нет=)

На данный момент работает установка(самая прибыльная на заводе) по производству Майонеза, на которой установлено:
1) TWIDO plc
2) Magelis hmi
3) ATV312 (3 штуки)
4) доп. двигатели для циркуляции и замывки
5) 5 накопительных емкостей с весовыми платформами (тензодатчиками), обрабатываемые Весоиндикаторами WE2108 (RS232), который связан в свою очередь через ICPcon I-7520 (RS232 to RS485) с TWIDO по "прошивочному порту с конфигурацией ASCII".

Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

И... к превеликому сожалению залили водой операторскую панель, которая уже была разобрана\собрана и высушена дважды, думаю третий раз она не выдержит... но вроде чуть живет, промигивает, полоски бегают... страшно...
В общем я, будучи инженером АСУ , очень переживаю по этому поводу. Предложение от начальства "ПЕРЕДЕЛАТЬ!!!" поступило, как ни странно, в мягкой форме. В общем сейчас идет сбор информации и денег на данную работу и приступаем с коллегами (втроём) где-то после 9 мая.
Переделывать будем 100% , т..к необходимо заменить все клапана с пневмоприводом на другие более устойчивые к тем условиям окружающей среды. Так что и мы меняем и клапана и панель сенсорную и софтину в ТВИДО и перекоммутируем всю эту радость. И еще хочется на 100% знать как оно работает и как отображать ВЕС с накопительных емкостей на панель Кинко.


Интересуют такие моменты как:
1. Как подключить ICPcon I-7520, которые "общаются" с Весоиндикаторами, к ТВИДО по ASCII? Распайка?
(Все провода серьозно спрятаны и идут через стену, в общем с "продернуть или прозвонить" тяжело)

2. Какие адреса использовать в ТВИДО, дабы обработать "вкусные килограммы"?

Дело в том, что этот опыт у меня первый=) с весоиндикаторами, и с ICPcon'ами.

А вот подключить "Weitek HMI+АЦП с тензодатчика+ Kinco PLC" получилось,
и работает отлично как отбраковщик по весу. По модбасу красиво всё увязалось, правда с адресацией пришлось повозиться...

Сейчас перечитываю кучу инфо по весоиндикаторами, в довесок пытаюсь на коленках разобраться и обработать блок RAYTEK с пирометром, подключая его через ICPcon I-7520 к близлежащему ТВИДО, застрял с подключением ICPcon к Twido по порту №1 [ASCII] (прошивочному).

Спасибо за внимание. Жду помощи. И огромная просьба не посылать в мануалы дальше рыться=) лучше конкретные ссылки на мануал, страницы, а то перелистывание полтонны бумаги может затянуться надолго... Благодарю за ответы.

"Переделывать будем 100%" или "Переделывать будем, 100%". Твидо остается, а программа в нём будет изменяться или заменяться?

Дело в том, что будем 100% менять Магелис на Кинко. Человек, который владел информацией -- исходниками, послан и забыт. А если просить его поделиться чем-то ... то услуги будут стоить "Дэо Ланос=)
Схемы от ЩУ нет, программы от Магелиса нет, программы от Твидо "не хватит" чтоб обойтись малой кровью...
Следует из этого, что панель будет либо Кинко (вероятней всего), либо Магелис (но цены не нравятся начальству на данную фирму). Программа будет переписываться мной, схема заново отрисовываться мной, новая панель разрисовываться мной, ну и соответственно остается все переподключить заново не забыв про Весоиндикаторы... + ко всему этому добавляется 4 клапана и одна емкость к тем 5-м что уже установлены.


Вот так работали люди до моего прихода... Отпускали человека, который сделал, и еще платили кучу денег.
А мне теперь расхлебывай. Панель кстати стоит 10 дюймов, а это сумма не маленькая...

То есть исходники с Твидо слить не удалось?
Почитайте ещё эти темы.
http://forum.abok.ru/index.php?showtopic=6...hl=MSG&st=0
http://forum.abok.ru/index.php?showtopic=79370&hl=EXCH
Не понятно почему связь должна быть ASCII, если Twido поддерживает Modbus Master/Slave и .
Распиновка Port1 где-то тут на форуме была (в хелпе тоже есть). Помню, что кроме A(+) и B(-) нужно перемычить две ноги, чтоб заставить Твидо на этом порту работать в режиме, как сконфигурировано в проекте.

Благодарю, перечитаю. А с Твидо слить удалось, но суть в том что это всё не нужно, выследить момент, где установлена нужная адресация чтоб вычитать информацию от весоиндикаторов.
Распиновки у меня вся есть, сегодня времени не хватило разобраться с ней и напаять нужные штеккера. А вот с адресацией проблемы , что посылает весоиндикатор, а их 5, и что именно нужно для преобразования математического в программе ТВИДО, чтоб потом высветить на панельку, - вот тут загвоздка...
Слил я с Твидо, но там коней можно двинуть с программой. Туча всяких присваиваний в шестнадцатеричной системе исчесления слову, а потом операции сдвига вправо 8 бит, и дальнейшее присваивание результата слову , которые потом объединяются в одной двойное слово , которое потом конвертируется в слово с плавающей запятой... в общем суть этих операций я не понял, ну конкретно что они из себя представляют - тут без вопросов, ну а на деле - как выбраться с проблемы??? подключить я подключу , а как заставить их общаться? В настоящей программе выследить тяжело , да и не понятно половину... талмуты пока-что результатов не дают. Лишь только описание и описание и описание....

Там же ещё и CanOpen, так что работы предстоит немало. Для обмена по Modbus есть функция EXCH1 (для 1-го порта), пример тут:
https://sites.google.com/site/fieldbusbook/...s-rtu-ascii-rus
Я так понял, что к весоиндикатору Вы уже подключались с Weitek HMI, то-есть регистровая память Вам известна? Если так - дальше по примеру. Если нет - надо достать адресацию регистров этого весоиндикатора.

CanOpen для частотников , с этим не проблема - уже наработано достаточно. Меня обмен как таковой не интересует, мне "вычитать" данные (вес), а посылать ничего не нужно... хотя я чтото не до конца допонимаю в этом деле... =)
А вот на счет Wentek HMI ,- то я связывал его напрямую через RS485 (com1) непосредственно к KINCO PLC (com0) и тем же RS485 (com1) конкретно к АЦП от фирмы ОВЕН, к которому был подключен тензодатчик. Эта связочка была попроще. Т.к. в книжечке по АЦП от (Овен за $100) было всё что необходимо, там и адресация указывалась , и какой регистр считывать и какой отправлять для обнуления/тарирования... Вычитывал панелью регистры, передавал через "выборки данных" в плк конкретные адреса, в которые записывались данные считанные панелью... всё довольно таки понятно и толково...
А с этим весоиндикатором чуть посложнее , тем более что с ICPcon'ом я еще не встречался вообще... но думаю что там всё просто, он тупо переводит интерфейсыдруг в друга... Вот только читая к WE2108 мануал я недопонял по какому регистру вычитать вес. ДАЖЕ, если бы я нашел этот регистр , то там 100% двойное слово, или слово с плавающей запятой, %MD или %MF... Я ж описал выше что я увидел когда "слил" с ТВИДО программу...
p.s. утром выложу код. оцените и возможно чтото прокоментируете. Просто сложно понять зачем сдвигать биты вправо, и потом соединять слова в двойное слово или слова с плавающей запятой... ну и т.д. И да , кстати , EXCH1 использовалась. Нужно рыть дальше...



А это перечитаем. Спасибо. Не сразу обратил внимание на данную статью.

Так, пробовал вязать ТВИДО как слэйв, и панель Кинко как мастер по RS485. Всё норм , как выглядит модбасс адресация в твидо - знаю.
Но как сделать так , чтоб вычитать вес, ну или "полный пакет функций" с весоиндикатора этого,
потом обработать его программно в Твидо и вывести на экран панели?!!!! - Пока что стоит в этом задача.



Проблемно!!! Вот его мануал, возможно вы поможете с этим недугом=)
http://www.hbm.com.pl/pdf/a1632.pdf
http://www.assortis-electric.cz/documents/WE2108_1ru.pdf

Тут смотрели?
http://www.hbmdoc.com/en/weighing-technolo...ors/we2108.html


http://www.hbmdoc.com/fileadmin/mediapool/...nical/i1709.pdf

Читаю... но пока что глухо.... С чем еще поможете? Я пока в недоумении... тяжело с нуля самому разобраться.

Вот перерываю слитую программу, помогите растолковать... Ну и я попытаюсь быть "немолчаливым"...
Таких комбинаций у меня пять штук. Я тут выделил одну, ту что разбираю досконально... пытаюсь т.е.

Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

И так, поехали:
1. RUNG0-RUNG9 Заполнения таблицы управления функцией и заполнения таблицы передачи. Растолковать тяжело конечно, но надеюсь вы с этим чуток поможете... Ну или хотя бы намекните куда копать))
2. RUNG7-RUNG9 --> почему слова записывать самих в себя?
3. RUNG40 - это понятно "функция обмена" , по выполнению обмена MSG1.D засветит 1. когда будет выполнено. и так по кругу --> получили\отправили\получили\отправили...
4. RUNG46 - там перезаписываются 2 слова в другие два слова. (%MW414:=%MW406; %MW415:=%MW407). Скорей всего это результаты весоизмерений, передаваемых от весоиндикатора.
5. RUNG47 - Объединение двух слов в одно двойное MD414.
6. RUNG48 - Сдвиг 8 бит вправо, и запись значения в слово MD416.
7. RUNG49 - Преобразования из двойного слова в слово с плавающей запятой MF418.
8. RUNG50 - Запись слова с плавающей запятой, деленное на 10.0, и записанное в новое слово с плавающей запятой MF500. - Это его нужно считывать панелью??? Только вот возможно я и ошибаюсь, но адресация в МОДБАСе у него будет 4x501, и DATA TYPE компонента визуализации для HMI - DOUBLE (4WORDS) или FLOAT (DWORD). Тут нужна подсказка будет=) ну раз мы конвертировали двойной слово в слово с плавающей запятой , то обязано быть FLOAT...

Это я решил обойтись малой кровью, но всё равно остается желание понять полностью с нуля.

Для чего бывший автор этой программы делал пункты 5,6,7?

Вечером туго соображаю, но попробую:
1. Тут надо разбираться с протоколом по вышеприведенной ссылке. Это не Модбас, по этому:
- %MW400: тип функции (01 прием/передача) и количество передаваемых байт (09)
- %MW401: смещение в приёме (00) и передаче (00)
- %MW402: начало передачи запроса в ASCII кодах (первые 2 байта) 53 31
- %MW403: 3,4 байт 31 3B
- %MW404: 5,6 байт 4D 53
- %MW405: 7,8 байт 56 3F
- %MW406: 9 байт 3B 00 (это лишний 10-й байт, на этом месте уже должен начинаться 1-й байт приема)
- %MW407-%MW411 - еще 5 слов для приема
2. Думаю это просто времянки. Наверное когда-то туда что-то писалось, потом на всяк случай не удалили.
3. наверное так и есть
4. Возможно, только 406-й содержит один байт запроса
5-6. MD414 содержит 4 байта, из них 3 байта ответа и один запроса, по этому в MD416 лишний байт сдвинули в небытие функцией SHR (сдвиг вправо), получили тот же INT только в DINTе; только вот лучше бы было пустотами заполнять с помощью 2 слова
7. да
8. да
Адресация будет 4x00501 если панель поддерживает вытягивания FLOAT через Modbus (в самом модбасе это не прописано). Кроме того нужно учесть порядок регистров (HI/LO) у панели и у твидо могут не совпадать, тогда придётся шифтить по кругу. Вобщем идёте Вы в правильном напрвлении, только с протоколом нужно разобраться

Кстати с панели с таким же успехом омжно обращаться к %MW416, так как там и содержится полезный вес, умножениый на 10, только в формате INT.

Вот вот. Я об этом и твердил , или я плохо листал мануал по весоиндикатору, и не нашел таких вот кодов для ASCII... Но выяснил что 3 байт отвечает за номер устройства в сети, работающей под ASCII. Остальные связки со отправкой/приемкой кодов отличаются лишь 3 байтом: 31, 32, 33, 34, 35. Ну и заполняются другие слова... А так всё идентично и аналогично.

Возможно вы имели в виду %MD416? Да, панель KINCO прекрасно справляется со словами с плавающей запятой. Но экспериментировать всё такие придется, т.к. не знаю в каком виде передается "нужный" вес, в граммых или в граммы*10(во второй степени), ну это уже методом подбора выберу.
И мне чтото кажется что 9 байт - это уже ответ от весоиндикатора с реальным весом нетто, т.к. его перезаписывают в слово %MW414, потом добавляют еще непоятно почему пустое слово, возможно уже с какимто ответом , и соединяют , тоже не понятно почему два INT в DINT. И зачем же тогда необходимо сдвигать вправо биты в DINT??? , чтоб заполнить все младшие биты информацией, или добавить точности вычитываемой информации, ну и ко всему еще переведено все в REAL , тоже не пойму для чего... Человек, которые лепил прогу к данной уставонке занимался около 1.5 месяца, и каждый раз "приезжая в гости" чтото допиливал, поэтому возможно стоит упростить? Подкинете идею? Вроде бы информация нужная есть, вот только пересчитывания меня пугают... недогоняю покачто)

Спасибо за помощь. Очень вам благодарен. Возможно и я когда-нибудь поделюсь мудрыми советами... =)

Нет, именно %MW416. На сколько я понял в %MW417 (старшем слове %MD416) будут нули.
Думаю, что нет, поскольку записано 9 байт в указании длины передачи. Получается %MW406 содержит один байт буфера передачи (старшие 8 бит) и один буфера приема (младшие 8 бит).
Вот для того и смещают, что один из байтов из буфера приема перекрывается с буфером передачи %MW406, по этому забивают два слова, в одном из которых один байт от приема, а в другом - другой. Сместив на 8 бит в право, от лишнего куска избавляются.
Такова моя версия. Возможно ошибаюсь, так как на живую не эксперементирую.

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

Итак, согласно формату отправки/приема высшеуказаного pdf:
Запрос от Твидо:
S11; MSV?;
//запрос на значение измерения
в ответ Твидо должен получить
То есть надо знать, как сконфигурирован формат значения измерения. Но судя по всему у Вас формат binary. А вот зачем эти сдвиги и вобще использовать %MW406 - пока не понянтно.

Формат данных слова %MW416 будет INT, без всяких запятых, хотя это не столь важно, т.к. там до 2-х тонн идут измерения, и граммы роли не играют особо.

И всё же не могу понять откуда взяты значения присвоенные словам от %MW401-406. Ну не пойму хоть убей.



Это ваще темный лес, что такое S11; MSV?;

MSV? - ну понятно , там конфигурирование, но какими способами - непонятно блин.

Вот что накопал в русском руководстве по весоиндикатору... Как с этим правильно работать? Растолкуйте=)
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Автор , делая операции присвоения словам %MW414:=%MW406 и %MW415:=%MW407, что хотел показать этим? Но ведь %MW406 входит в состав тех 16бит, которые задействованы в ОТПРАВКЕ запроса весоиндикатору....

И непонятен такой момент, почему "собирают" вместе в двойное слово %MD414 два слова %MW414 и %MW415, которые, как вы говорили:

Т.е. получается в двойном слове %MD417 состоят такие слова как %MW417, которое уже занято, и мы просто обязаны его пропустить, и использовать %MD418.

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


Нажмите для просмотра прикрепленного файла

Из картинки видно что всё же в младшем байти старшего слова находяться величины, которые и отвечают за часть тех цифр измеренного веса... и их все равно необходимо использовать. Ведь так?

Я взял англоязычную доку с вышеказаного пути http://www.hbmdoc.com/fileadmin/mediapool/...nical/i1709.pdf
ASCII режим предвидит обмен символами. Согласно символьной кодировке
53 31 31 3B 4D 53 56 3F 3B
S 1 1 ; M S V ? ;
На счёт смещения мне тоже непонятно, киньте проект, буду смотреть в реальном проекте, может что-то упущено с контекста

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

Без проблем, раз уж на таком уровне вы помогаете, вам цены нет=)

Нажмите для просмотра прикрепленного файла

MSV - например на странице 77
S.. - на странице 117

.

К с этой информацией работать? Вы даже не намеаете в какую сторону смотреть , возможно переводить что-то нужно, то что там написано - я не пойму,
(Select)
(Addressing WE2108 in bus mode)
Command: S(xx);
Parameter: 1
Range: 0...31, 98
Factory setting: 31
Password protection: no
Parameter backup: not possible
Query: not intended

Мне допустим ничего (пока что) не дают эти значения и описания.

(Measured Signal Value)
Output measured values (format depending upon parameter COF)
Command: not intended
Query: MSV?;
Answer: outputs the current measured value
Parameter: −
Range: "1.35 V scale nominal value (ASCII / binary)
Factory setting: −−
Password protection: no
Parameter backup: not possible

Что тут считать важным, а что переводить в 16#.... ??

Я не говорю, что она (документация) отличная, я просто взял символы программы, нашел соответтсвующие комманды и сделал определённые умозаключения :-)

На вскидку

(Addressing WE2108 in bus mode) адресация WE2108 в режиме шины
Command: S(xx); комманда Sxx, где xx какие-то цифры
Parameter: 1 - кол. параметров
Range: 0...31, 98 - диапазон 0..31 или 98 (например S11)
Factory setting: 31, заводские установки - 31 (очевидно адресс устройства по умолчанию)
Password protection: no - не защищенные паролем
Parameter backup: not possible - не хочу копаться в доке
Query: not intended - не хочу копаться в доке

(Measured Signal Value) - значение измеряемого сигнала
Output measured values (format depending upon parameter COF) - выходное измеряемое значение (формат зависит от параметра COF)
Command: not intended - не хочу копаться в доке
Query: MSV?; - запрос:MSV?;
Answer: outputs the current measured value - ответ: значение
Parameter: −
Range: "1.35 V scale nominal value (ASCII / binary) - диапазон +-1.35...
Factory setting: −−
Password protection: no
Parameter backup: not possible

Далее идут примеры, которые вместе с синтаксисом многое чего объясняют. Просто объём материала большой, по этому всё гамусом тяжело принимается. Я б на Вашем месте поэксперементировал с весами через обычный СОМ-порт компа, передавая и принимая символы ASCII например через гипер-терминал или другие подобные проги (я для себя когда-то выцепил Compt.exe написаную каким-то замечательным автором, и пользуюсь ею на лабах)

Почему вы неправильно "ручкой" указали присвоение?
У Вас %MW414:=%MW406 а в программе %MW414:=%MW408, это же в корне всё меняет.

Торопился описать суть дела, и косонул... ну там я понял что во что преобразуется и зачем это делается. Остается лишь экспериментировать. Ну завтра буду с блоком обработки пирометра играться, там тоже через Порт1 и тоже EXCH1, результаты напишу. Да дело в том что у меня на компе программ как таковых для связи весоиндикатора и пирометра нет, искать-непереискать. Будем пытаться, стараться. Нужно чтоб ктото взял за руку и голову и "потыкал" в информацию, чтоб типо "искать от сих до сих", переводить "это и это", передавать "это и то"... а то помню препод чтото рассказывал, но конкретным примером было твидо-зелио связочка , там ваще всё прозрачно, в мануалах описано красиво- если хочешь получить данные чтения слова - вот тебе адресация и коды, и т.д.

Спасибо и на том что помогли доРАЗЖЕВАТЬ программу, коды буду перебирать... дело за малым=)

Великая благодарность.

а я (препод) их(студиков) заставляю приложения читать к лабам, где "всё написано". И когда они стонут типа а как делать - я говорю: "Читать приложения, там всё написано". Конечно это проще, чем в реальной жизни, но тяжелее чем когда всё разжевано. Вот и получается, что лаба делатеся за 10 минут, а попотеть надо две пары чтоб понять как её сделать. Это лирика....
А в реалии надо посмотреть какой формат отправки значения у весоиндикатора. Программер явно перемудрил, так как очень много лишних присвоений. Но вот зачем делать сдвиг - для меня осталось загадкой.

Буду пытаться выяснять и сравнивать... думаю, что толк будет.

...мыши плакали, кололись, но продолжали жрать кактус.. музыкой навеяло.. все эти пляски с MW,MD,MF на twidoпсевдонедоассемблере во времена CoDeSys выглядят как предсказания погоды по куриной лапке в эпоху спутников.. ничего личного.. самому не раз приходилось вязать железо с самопал-bus протоколами, но только я сразу объяснял заказчику, что это добро разжевать на типа-ПЛК очень проблемно, поэтому надо ставить что-то типа одноплатника ICP CON 7188, на котором на C хоть свой стэк TCP-IP сдуру можно написать, ну или на худой конец что-то под CoDeSys, в нем тоже неплохо работа с протоколами доступна...

Такое врядли купят, не дешево стоит. Мне покупали АЦП от ОВЕН для тензодатчиков 2 месяца. Типо денег столько не выделяется. Бедные блин. А что как минимум нужно проверить-попробовать на железе - это мало кто понимает. Тут дело в том что контроль идет за тем что лежит дольше 2х месяцев и не идет в оборот, а если залежалось - то выясняют кто заказывал и для каких целей, а потом могут легко высчитать с ЗП. Бардак блин. Да и за компом не получается столько времени усидеть... дабы проникнуться в суть дела, в основном если стоит задача - то делаю, а если для своих нужд, ну и дальнейших воплощений в реальность на производстве - то времени не дадут... со словами "Хули сидишь? Дуй работай!" проходят большее кол-во трудовыЕбудней.

Дабы разрешить обмен данными по Modbus & ASCII для Твидо с помощью EXCH, предварительно осушив и запарафинив мозги документами подключаемого устройства, не просто. А когда всё на англ, а иногда завуалировано, - то еще веселее)
С пирометром получается так же как и с весоиндикаторами... Что откуда брать - загадка=)

"Дабы разрешить обмен данными по Modbus & ASCII для Твидо с помощью EXCH"

...я может глубины всей ситуации не улавливаю, но почему бы сначала не "потренироваться на кошках"?.. а именно добиться обмена с этим зоопарком просто с ПК через OPC сервер какой-нить типа KEP Server или подобное, благо под ModBus отладчиков достаточно?...

...ICP CON I-7188 в самой навороченной конфе $230, ОВЕН ПЛК 110 с CoDeSys где-то 12-13 круб, это так, к сведению...

Все это хорошо, но прежде чем тренероваться на кошках, необходимо выудить с мануалов весоиндикатора (и пирометрического блока-измерителя) коды, отвечающие за измерения и параметры настроек.... Так вот стоит первым делом задача сформировать таблицу передачи\получения информации, это то в чем главная загвоздка.

Возможно вы подскажете=) каким макаром , юзая мануал, что представлен в первых постах темы, и что конкретно использовать. То что я пытался сопоставить, используя ПРОГРАММУ с Твидо и Мануал Весоиндикатора, результата не принесло...

Меня не интересует прикладываемые к этим устройствам программы для настройки параметров устройства... Там всё банально. Рабочий интерфейс до боли прост и не интересен, не использую я столько настроек для работы с весоиндикатором, меня лишь интересует процедура вычитывания веса нетто в единицах с точностью 0.1кг.

Вобще-то о Modbus сейчас речь не идёт. Обмен осуществляется по специфичному символ-ориентированому проткоолу, так что ОРС не помогут.
Топикстартеру: то что я Вам объъяснил, Вам понятно? Если нет , то что именно не понятно?

В Модбасе выглядит ведь так же таблица...

Почему именно такой порядок передачи запроса, почему не другой? Я имею в виду то, что идет 31 3В, почему не наоборот? Откуда это проследить? Т.е. я должен в руководстве к устройству увидеть такое как: для получения измеренного значения веса необходимо отослать в первых двух байтах передачи данных к устройству ВОТ ТАКИЕ коды, а для получения до граммов измерения необходимо ВОТ ТАКИЕ КОДЫ, и так далее... выбирая нужные нам ПАРАМЕТРЫ ответной информации... так?





Понятно до момента "Нужно найти описание, где сказано какие байты и зачем отправлять устройству и какие байты и с чем их получим... т.е. сформировать таблицу передачи\получения данных.
То из чего таблица состоит - понятно, как её правильно составить непонятно... Откуда смотреть описания на "НОМЕР ФУНКЦИИ" в Младшем байте (как в передаче , так и в приёме)
то какие манипуляции делать в Твидо - понятно... Что означает "Счетчик байт" ??? в Младшем байте ответа? Где смотреть о типах функции???
Вопросов куча, только хотелось бы разхлебать досконально.

Начнём по порядку.
1. В Вашем случае Modbus нет вобще. Первоначально я об этом не знал, пока не почитал мануал по весоизмерению. Используется свой символьно-ориентированый протокол весоизмерителя.
2. Учитывая п.1, Твидо работает в символьном режиме (ASCII), что и сконфигурировано в проекте. Этот режим даёт возможность что угодно отправлять и что угодно получать независимо от содержания.
3. При Модбасе в режиме Мастера, Твидо бы автоматически генерировал и проверял контрольную сумму и выставлял/реагировал на межкадровые интервалы, а в режиме Слейва - автоматически отвечал бы на запросы Мастера.
4. В режиме ASCII (символьном) реакция на окончание посылки конфигурируется в самом порту. В Вашем случае в проекте стоит LF, хотя протокол устройства весоизмерителя работает с последовательностью символов CR LF. Протокол предполагает, что каждая посылка последовательности байтов (читай символов) должна заканчиваться двумя символами CR LF по которой получатель узнает о конце этой последовательности (читай кадра).
5. Твидо работает с ком.портами для отправки и получения сообщений используя функцию EXCHx (где x - номер порта) независимо от протокола (Mdobus либо ASCII), но синтаксис заполнения таблицы (которая передается в качестве аргумента функции) отличается. Заполнение таблицы в символьном режиме показана в хелпе ТвидоСьют. Таблица состоит из 3-х частей: настроечные параметры (2 слова), буфер для передачи (n слов), буфер для приема (m слов). Твидо в режиме ASCII абсолютно побарабану какие байты там будут содрежаться. Из буфера передачи он передаст столько байт, сколько вы укажете в настроечном параметре, все остальные байты он будет считать как буфер приёма, куда будет ложить всё что принял. В конце последовательности он будет добавлять символ LF (в Вашем случае), хотя меня это смущает. Конец приёмного кадра он будет определять тоже по LF (это меня тоже смущает так как должно быть CR LF).
6. Протокол весоизмерителя базируется на принципе запрос-ответ. Твидо должен выдавать запрос, весоизмеритель должен дать ответ (на некоторые запросы не должен). Запросы и ответы в основном кодируются псоледовательностью ASCII символов. Например MSV?; -запрос на вес. Каждый символ этой строки кодируется одним байтом, который представляет код символа в кодировке ASCII. Так например "M" кодируется числом 4D(в 16-ричном формате).
7. При шинной связи (несколько весоизмерителей) нужно впереди запроса указывать адрес в формате: Sxx; где xx - номер устройства, который задается при конфигурации.
8. Устройство на запрос "MSV?;" может отвечать в разном формате. Например может передать последовательность ASCII "456.67" а может передать вес в бинарном формате (очевидно Ваш случай).

Где-то возможно ошибаюсь, но в целом, согласно доке, где-то так.

Подкинте ссылочку, где можно ознакомитсья с переводом ASCII в 16, 10, 2-ричной систем исчесления (бинарной).
ИЛи я правильно нашел , там по абзацу ASCII printable characters. Вроде похоже...

Вот где собака зарыта. Я бы так уже понял в чем заключается перевод символьной кодировки, в 16-ричную систему исчесления.
выходит что:
53 = S
31 = 1
31 = 1
3b = ;
4D = M;
53 = S
56 = V
? = 3F
3b = ;

А я голову ломал , как переводить команды, возможно в них "сущность в виде гномика" кроется.
Сейчас еще поверевариваю... и попытаюсь назадавать вопросов. тут в этом месте я понял всё прекрасно, видимо ваши утверждения я не правильно "расшифровывал.

http://en.wikipedia.org/wiki/ASCII - тут вроде нужная таблица.
по абзацу ASCII printable characters.

С этим прекрасно всё понятно. Досконально, как и ожидал. И последние несколько вопросов:

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


(для справки: я 2 года как выпускник просто... еще пожинаю плоды некоторые,- самообучение, как говориться, параллельно с работой на производстве- ремонты,монтажы,демонтажы.)

Да всё верно, вы не ошиблись , я тоже мануал перелистал и только сейчас увидел истину. А теперь такой вопрос: "автор программки Твидо оставил под заполнение информацией 3 слова, но использовал два первых %MW407 , %MW408, но при "сложении" двух слов в одно двойное CONCATW, он выбрал MW408 как старшее слово, а MW407 - как младшее. Но ведь их заполнение было по порядку: в начале информация "упала" в MW407, а потом в MW408. Да и потом сдвинул вправо на байт. В общем возможно эта была правильная "махинация", либо просто запутывание... хотя о запутанности тут дело не может идти , т.к. вес на сенсорной панели отображается идентично весоиндикатору.
Ну вот в принципе и всё что хотел узнать по ASCII=) Вы очень помогли мне. Благодарю. В скором времени выложу фото своих работ, уже задействованых в производстве. (и если не забуду скину ссылочку Вам, оцените мой труд... возможно прокоментируете что-то.)

Макеевка украинская? Если да, можете купить нашу книжку: "Промислові мережі та інтеграційні технології в автоматизованих системах". Админы не баньте как за рекламу.
А вобще тут путаница всегда сплошная. Есть Modbus RTU, есть Modbus ASCII, а есть просто символьный обмен (также называемый ASCII), по которому Вы сами реализуете протокол.
Например, есть протокол DCON (поддерживаемый ICPDAS) а в Твидо такой протокол не поддерживается. Берёте символьный режим и сами его реализуете.
Другой пример. Есть Симатик 300 (S7-300). Чтоб реализовать там Modbus RTU надо или купить доп. лицензию на софтовый драйвер, или написать Modbus в символьном (ASCII) режиме.
Так что это не Шнейдер для Твидо придумал, а типичный подход. Кроме того, можно выводить данные на разные принтеры, поддерживающие символьный режим и другие устройства.

Да , всё верно, Макеевка, Дон.область, учился в университете ДонНТУ. Возможно вы оттуда знаете кого-нибудь. Например, Коротков А.В., он тоже Шнайдером заведует, учебным центром, но там больше упор был, когда я его посещал, на обучение программных сред твидо\зелио и работа с ПЧ... а так чтоб была серьозная связка этих всех устройств по сети - увы было лишь только упоминание на словах..



Сможете помочь эти действия растолковать? И да, там

Забудьте за номера функции. Этот формат таблицы указан для Модбаса, а у Вас не Модбас, а символьный обмен. А там наполнения таблицы передачи и приема описывается документом от весоизмерителя.
Махинации со старщим и младшим словом я заметил. Мало того, конткатенацию можно бы было не делать, так как %MD414 уже в старшем слове содержит %MW415 а в младшем %MW416. По поводу сдвига пока не понятно, если бы был известен выбраный формат кодирования веса - было бы проще.

Выбора нет, надо брать комп, связывать ноль-модемным кабелем с весоизмерителем и общаться.
1. Берёте какую-то прогу для работы с СОМ-портом, например тут http://www.compt.ru/ru/download.php
2. Настраиваете ком-порт на параметры, указанные в вашем проекте Твидо для Port1
3. Отправляете S11;MSV?; и смотрите, что прийдёт. Далее уже будет понятнее.
Так же можете пообщаться с другими типами проборов. Только надо разобраться в ихних протоколах.

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