PDA

Просмотреть полную версию : Считывание архива из SMH\Pixel


SMH
03.06.2008, 22:39
Вобщем, такая задача всплывает уже не первый раз... Кое-как это получается сделать, но существующие способы реализации, через сервер ДДЕ и Ексель нельзя признать ни удобными, ни пригодными для тиражирования из-за необходимости подгрузки дополнительного софта и достаточно сложных манипуляций с ним, которые должен производить пользователь. Почему-бы Сегнетиксу не разработать универсальную программу для считывания архивов с возможностью сохранения данных в общепринятых форматах?

Max2114
04.06.2008, 07:46
Это было бы неплохо... сделать программу которая бы читала данные их Еprom... просто если сделать чтение из журнала так как это сделано сейчас в екселе и при помощи DDE то программу надо делать OpenSoruce (тоесть выкладывать исходники) так как прочитать архив сделанный самостоятельно не будет никакой возможности.... я так думаю Сегнетиксу стоит над этим подумать....

Arsie
04.06.2008, 10:55
Open sourse? Пример закрыть не для того, чтобы его нельзя было посмотреть, а для того, чтобы этот пример даже случайно не был испорчен - а в экселе это сделать очень и очень просто.

Я высылаю исходники всем желающим.

Наверное мало кто обратил внимание, но к серверу прилагаются примеры работы с DDE в экселе. Работающие простые примеры.

Sergey Cherevko
04.06.2008, 11:09
Кое-как это получается сделать, но существующие способы реализации, через сервер ДДЕ и Ексель нельзя признать ни удобными, ни пригодными для тиражирования из-за необходимости подгрузки дополнительного софта и достаточно сложных манипуляций с ним, которые должен производить пользователь.
Странно, вы перекладываете на пользователя манипуляции с ДДЕ сервером и прочим софтом? Один раз разобраться с этим софтом, создать некий шаблон, требующий минимальных телодвижений пользователя, а потом только его тиражировать...
Почему-бы Сегнетиксу не разработать универсальную программу для считывания архивов с возможностью сохранения данных в общепринятых форматах?
А чем Лектус ОПЦ сервер и Ексель нестандартны? И разве Ексель не сохраняет в общепринятых форматах?
На мой взгляд, пусть лучше Сегнетикс сконцентрирует усилия на развитие контроллеров и средств разработки...

Arsie
04.06.2008, 11:17
За протыми словами "Читала данные из EEPROM" стоит:

1) Динамическое распределение памяти в контроллере влечёт за собой создание собственного протокола передачи данных.

2) Ограниченность производительности контроллера и EEPROM повлечёт общее замедление работы контроллера во время выгрузки архива, как отнесётся к этому пользовательская программа?

3) Как распределить приоритеты между выгрузкой архива и работой программы?

4) Как ограничить количество записей в EEPROM со стороны внешнего устройства?

Поясню более детально.

1а) Протокол - данные могут размещаться в разных областях EEPROM, области могут быть различных размеров.

1б) Простое открывание "окна EEPROM в модбас" невозможно, т.к. модбас адресует только 64К, а у нас в Пикселе уже 256К ЕЕPRОМ.

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

2а) Если программа не расчитана на "растяжку" времени цикла и/или в установленном времени цикла не оставлено достаточно "запаса" для работы "выгрузки архива", то работа алгоритма такой программы может быть нарушена.

3а) Во время выгрузки архива выгоднее всего работать блоками большой длины. А если в это время программе тоже потребовалось чтение или запись в EEPROM?

3а1) Можно посылать блок заново. Тогда может сложиться ситуация, когда программа постоянно прерывает передачу, что сделает невозможным выгрузку архива.

3а2) Можно посылать блок данных из буфера, но как быть, если программа обновляет данные, которые помещены в буфер? Не забываем о памяти, требующейся для буфера и затратах производительности на копирование данных.

3а3) Можно пересылать данные мелкими партиями. Это повлечёт увеличение как времени передачи, так и потерю производительности контроллера.

3б) Если запись в EEPROM с утилиты и из программы совпадут по времени? Да ещё и в одну и ту же ячейку? Кто главнее?

4а) Если открыть "окно EEPROM в модбас", то как защитить EEPROM от частых перезаписей? Не секрет, что периодические запросы в модбасе используются повсеместно. Такие запросы быстро исчерпают ресурс EEPROM. Можно сначала читать данные и сравнивать их с записанными, но это займёт ресурсы процессора. При большом количестве запросов пользовательской программе будет "некогда" выполняться. К тому же это не защитит от постоянной перезаписи изменяющихся данных.


Есть ещё пара-тройка десятков рисков. Но не нужно думать, что легко произносимые вещи также легко реализуются.

Вам от контроллера нужна стабильность Windows'95 ??? Мне - не нужна.

Именно поэтому реализация каких-либо функций (не только архивных, но и любых других) будет проведена только после снятия ВСЕХ рисков.

Max2114
04.06.2008, 12:16
А как тогда у вас организуется обмен данными с смлоджиком когда запускаешь программу на контроллере в режиме эмуляции и видишь значение всех входов-выходов?

Max2114
04.06.2008, 12:31
На мой взгляд, пусть лучше Сегнетикс сконцентрирует усилия на развитие контроллеров и средств разработки...
Полностью согласен... я бы лучше имел более продвинутый контроллер и среду разработки, чем возможность читать архивы из контроллера.

Arsie
04.06.2008, 12:38
В специальном режиме контроллера, при этом всё дико тормозит, данные часто теряются и т.д. Т.е. реализован протокол передачи данных, не учитывающие всех рисков.

Но глобальная разница - данные берутся из быстродействующего ОЗУ, висящего на параллельной шине, а не из тормозного ППЗУ, висящего на последовательной.

Arsie
04.06.2008, 12:40
Все в нашей фирме тоже считают, что рестайлинг SMH2010 и Модули Расширения гораздо важнее чтения архивов и даже важнее, чем маштабирование схемы в лоджике ;)

SMH
04.06.2008, 19:33
Все в нашей фирме тоже считают, что рестайлинг SMH2010 и Модули Расширения гораздо важнее чтения архивов и даже важнее, чем маштабирование схемы в лоджике ;)
"Важнее" - это то, что даёт больший экономический эффект?
Многие задачи можно возложить на однократно нанимаемых программистов, особенно, если это прикладные задачи, типа озвученной мною.

SMH
04.06.2008, 19:41
Странно, вы перекладываете на пользователя манипуляции с ДДЕ сервером и прочим софтом? Один раз разобраться с этим софтом, создать некий шаблон, требующий минимальных телодвижений пользователя, а потом только его тиражировать...
Вы это сами делали? Писали инструкции для пользователей? "Минимальные телодвижения" при самом благоприятном раскладе всё равно превращаются в геморрой.

А чем Лектус ОПЦ сервер и Ексель нестандартны? И разве Ексель не сохраняет в общепринятых форматах?
Да всем стандартны... Но я уже написал выше - геморрой. Сравните, например, с считыванием архивов из теплосчётчиков при помощи специализированного ПО.

SMH
04.06.2008, 20:40
За протыми словами "Читала данные из EEPROM" стоит:

Возможно, Вы меня не так поняли. На уровне СМШ всё реализуется стандартными функциями, через соответствующий макрос, наподобие выложенного Вами. Весь вопрос в ПО на ПК. Хотелось бы считывать эти данные используя всего одну легко настраиваемую программу.

AlexG
05.06.2008, 06:01
Рестайлинг это в смысле новый корпус? :confused:

AlexG
05.06.2008, 06:06
Можно дать доступ к EEPROM только на чтение. Это снимет часть проблем.

Sergey Cherevko
05.06.2008, 10:59
Вы это сами делали? Писали инструкции для пользователей? "Минимальные телодвижения" при самом благоприятном раскладе всё равно превращаются в геморрой.
Не хотелось бы здесь устраивать личную переписку, но...
Конечно, сам делал. Причем стремился заранее предусмотреть возможный "геморрой" и избавиться от него еще на этапе проектирования.
Да всем стандартны... Но я уже написал выше - геморрой. Сравните, например, с считыванием архивов из теплосчётчиков при помощи специализированного ПО.
Не буду по себе судить обо всех, но специализированное ПО, умеющее только читать архив, вряд ли целесообразно вследствие своей функциональной ограниченности. А расширять функции - прямая дорога к нормальной скаде.

Sergey Cherevko
05.06.2008, 11:05
Можно дать доступ к EEPROM только на чтение. Это снимет часть проблем.
И "привязать" журнал фиксированным адресам, чтобы не искать его по всей EEPROM

AlexG
05.06.2008, 11:38
В нормальных скадах с чтением архивов из контроллеров тоже не все гладко. Для этого вроде как существует OPC HDA, но он далеко не везде поддерживается.

Arsie
05.06.2008, 12:06
Сравните, например, с считыванием архивов из теплосчётчиков при помощи специализированного ПО.

Одно "но": теплосчётчики никто не программирует пользовательской программой. Т.е. архив имеет раз и навсегда определённый набор данных, расположение и, может быть, размер.

Сделать софт, вынимающий данные из определённого написанного нами макроса просто. Сложно его отладить так, как был отлажен, например, сервер, выпускающийся уже несколько лет. И как быть, если вам макрос не подходит? Вы же наверняка будете в первых рядах тех, кто скажет "Через попу сделали!" ;)

Arsie
05.06.2008, 12:14
Не путайте. Сторонних разработчиков нанимают, чтобы решить отдельную _законченную_ задачу. Типа, написать драйвер или утилиту.

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

Arsie
05.06.2008, 12:16
Нет.

Вообще, SMH2010 сменил оформление уже раз 6-7 за свою жизнь :)

Arsie
05.06.2008, 12:18
Хорошо, жду от вас проекта такого макроса. Макроса, позволяющего передавать _любые_ данные в _любюм_ количестве.

Arsie
05.06.2008, 12:21
А как поступить, если кого-нибудь не устроит ни объём, ни содержание (количество данных) стандартного макроса?

Кстати, упомянутое "только чтение" - это решение самых простых проблем. Что делать со сложными?