Labview и Делфи

[Kayfolom]

Хорошего утра.

Есть задача по созданию автоматизированного
измерительного комплекса, который будет состоять(условно) из двух
частей:
1. сбор и анализ данных(через Com порт), писаться на Делфи
2. управление термокамерами(через GPIB) и др. приборами, писаться на LV.

Есть делема, что во что вставлять? Либо в LV делать DLL и их запихивать в Делфи?, но не знаю будет ли работать, либо в Делфи делать DLL и сувать в LV, но тогда что мне сказать человеку, который будет писать DLL в Дельфях. Есть ли спец требования в данном случае??

[Pavel Krivozubov]

а смысл писать управление компортом на дельфях? пиши уж все тогда. могу дать 99% вероятности что это будет в разы быстрее ну если твой товарищ конечно не гений кода.

[mzu2006]

Всё зависит от того, какого типа общение между этими двумя модулями предусмотрено ТЗ.

Если передаётся 1-2-3 числа то всё равно.

Если необходимо делать операции с памятью (выделение освобожденеи массивов итд итп средствами менеджера памяти ) то писать dll в Дельфи смысла мало - нужно будет вручную перебивать extcode.h (и некоторые включаемые туда файлы).

Если требуется серьёзная синхронизация процессов, запуск дополнительных нитей, то я бы писал всё что можно в одной среде разработки, оставив в другой только простейшие вещи, сложно реализуемые в другой среде. Мне приходилось писать автоматизацию на Kylix (Delphi for Linux). При желании можно сделать нормальную многонитевость, обмен сообщениями, конечные автоматы и там.

Я - за однородность среды разработки

[Pavel Krivozubov]

Да кстати если уж от дельфиста никак не отвертеться, то.. то первичен вопрос в чем будет писаться оболочка. Если оболочка пишется в LV, то длл-ка в дельфях и наоборот. Скажу сразу - первый вариант будет красивей и быстрее. А что сказать товарищу, который будет писать ддл-ку на дельфи? Дай ему прикрепленный документ. Там правда описан пример подключения с С++. Если будет непонятно, тогда поищите в сети книжку "LabVIEW в исследованиях и разработках" , автор : Р.Ш. Загидуллин. Там есть раздел где описано подключение длл-ки именно на примере дельфей.
На автомейшенлабс и софтвебе можете не искать - нету Остаются торренты или осёл.
Ну а если уж и там не найдете, скажи тут, я отсканирую этот раздел и выложу.

upd. Видишь, какой гемор.) Пиши сам

[Kayfolom]

за выложенные страницки, отдельный благодарчик.)
Я тоже обеими руками за оболочку в LV, думаю так в финале
и будет. А вот сбор и обработка будет на Дельфях.
Сам бы писал всё с удовольствием, только вот не дают,
продвигаю LV как могу, пока лишь отдельные небольшие програмки ваяю
для управления того или сего..

[Pavel Krivozubov]

за выложенные страницки, отдельный благодарчик.)
Я тоже обеими руками за оболочку в LV, думаю так в финале
и будет. А вот сбор и обработка будет на Дельфях.
Сам бы писал всё с удовольствием, только вот не дают,
продвигаю LV как могу, пока лишь отдельные небольшие програмки ваяю
для управления того или сего..

Ну понятно.. Должны же и другие программисты себе на хлеб зарабатывать.
Однако сразу предупреждаю - если будет масштабный проект с развесистыми длл-ками: готовься к трудностям на этапе стыковки двух сред, тем более ни у тебя ни у дельфиста нет опыта в этой области. Я сейчас занимаюсь чем то подобным, правда длл-ки пишутся в Embedded Visual C++ и таргетом является PDA, да и часть кода в сях мне приходится лопатить самому, но тем не менее.. Да и в твоем случае положение будет осложняться тем, что длл-ки будут осуществлять сбор данных, а это штука коварная, чуть что где не так - все будет виснуть. Например сбор данных может быть критичен ко времени последующей обработки и визуализации, могут возникать переполнения буфера и тд, т.е. работа его длл будет зависеть от работы твоей визуалки, что уже подразумевает какую-то синхронизацию. Когда все вращается в одной среде - это реализовать проще.
Вообщем ладно, чего я тебя пугаю, может все еще и нормально будет
Кстати, если не сложно, запомни - сколько времени твой дельфист потратил на разработку сбора данных, мне просто интересен порядок (ну день, месяц, год ) Может просто мне одному с коллегами так не повезло..

[mzu2006]

сколько времени твой дельфист потратил на разработку сбора данных

Можно я?

Часть моего дипломного проекта - автоматизация масс-спектрометрической установки на базе ми 1201 (7 лет назад).
Делал на Kylix (Delphi for Linux) и С (драйвер режима ядра).
Начал в октябре. Драйвер написал за месяц (был мой второй драйвер), первый вариант автоматизации за 2.5 месяца. К концу февраля закончил. Параллельно с измерениями доводил месяца 2. Получилась конфетка, НЯЗ, люди до сих пор пользуются и радуются жизни. Автоматизация содержала несколько (>5 <15) потоков, синхронизация осуществлялась сообщениями, большинство потоков были выполнены в виде конечных автоматов.
Мне повезло, что я списался тогда с человеком из Австралии, который делал свой компонент графика и я смог внести в него все нужные мне изменения.

сейчас, наверное, делал бы на . Но, ИМХО, выбор среды разработки - это больше политика, чем реальные достоинства или недостатки среды. По крайней мере у меня всегда выходило так ...

[Pavel Krivozubov]

Но, ИМХО, выбор среды разработки - это больше политика, чем реальные достоинства или недостатки среды. По крайней мере у меня всегда выходило так ...

хе. ну ты же все-таки из каких то соображений пересел на LabVIEW?

[Konstantin Sumenko]

сколько времени твой дельфист потратил на разработку сбора данных

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

сейчас, наверное, делал бы на . Но, ИМХО, выбор среды разработки - это больше политика, чем реальные достоинства или недостатки среды. По крайней мере у меня всегда выходило так ...

Библиотека MPI или аналог?
По поводу сред разработки: было пару случаев, когда у знакомых проекты затягивались из-за наспех выбранных сред разработки (в одном случае не было графических контролов и им так же приходилось долго разбираться с асинхронными вызовами и распараллеливанием, от LV они отмахнулись сразу )

[Pavel Krivozubov]

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

Вообще понятие "выбор" среды разработки немного от лукавого, как правило программы пишутся в тех IDE, которые программист знает и пишет в них не один год. Не будет же он для каждого нового проекта изучать с нуля новый язык программирования, который по каким либо причинам лучше подходит для этого проекта. Естественно он будет приспосабливать свой "старый добрый" С++ (Дельфи, Матлаб etc.) под текущие задачи. Именно это скорее всего и послужило причиной отказа от LabVIEW в твоем случае. Поэтому National Instruments совершенно правильно делают ставку на ВУЗы, поскольку мозги студентов "закостенеть" еще не успели и поработав в ВУЗе в двух-трех IDE человек как правило выбирает лучшую из них, т.е. LabVIEW.

[mzu2006]

Библиотека MPI или аналог?

самописный аналог. Сейчас бы использовал MPI.

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

согласен, но по другой причине. Представим себе большую программистскую контору, занимающуюся встроенными системами, системной интеграцией ... (держу в голове реальный пример где работал) В конторе есть сложившийся набор инструментов, решений привязанных к какому-то языку програмирования, среде разработки, типичному железу, традициям индустрии итд итп. Entry & Junior level программисты не могут влиять на выбор среды разработки (переключение на другую среду - как правило стоит больших денег и времени). Такие решения могут принимать только Team Leads по согласованию с управленцами. А это ответственность которую никто не хочет на себя брать.

Маленькие конторы, (опять таки реальный пример) там всё гибче. Там будут учить новую среду разработки по необходимости (если руководитель умный). Мне пришлось разбираться с python в C++ конторе, например. Но тут тоже всё предопределено высокой стоимостью перехода на другую среду разработки.

National Instruments совершенно правильно делают ставку на ВУЗы

Они не одиноки. В своё время, была академическая программа Borland, Microsoft сейчас раздаёт Visual Studio студентам бесплатно. Здесь, ПМСМ, есть желание "подсадить" на какую-то среду разработки (и, отчасти, способ мышления). Это такое же капиталовложение с просчитанной окупаемостью.

мозги "закостенеть" еще не успели

.

В вузах технических специальностей студентам, аспирантам, научным сотрудникам приходится писать софт для управления чем-то. И опять роль играет традиция. Есть наработанный объём кода на C++ (хоть и под Measurement Studio) будут писать на C++. Есть под Labview - будут писать под LV. Delphi - будут делать на Delphi. Есть автоматизация на матлабе - будут использовать матлаб и дальше. А не приходилось видеть автоматизацию под MacOS 8.x? Там "родной" язык - Паскаль (не объектный). Действительно выбор есть в редком случае, когда новый проект начинается с нуля и среды разработки доступны со значительной скидкой, время не очень лимитировано, и нету жёсткой ориентации на результат. Вот в этом редком случае всё будет определяться просто оптытом этого конкретного научного сотрудника или его студентов.

В моём конкретном случае, я старался сдвигать разработку ПО в сторону в моей нынешней лаборатории преследуя конкретную цель: приобрести опыт самому и отвоевать для себя свою экологическую нишу на кафедре. (Ну и красивый , просто красивый )

человек как правило выбирает лучшую из них, т.е. LabVIEW.

ни в коем случае не желая начинать holy war, скажу, что про лучшую вообще мне не очевидно.

[Pavel Krivozubov]

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