Остановка программы без выведения ошибки

[dry-krutoy]

Добрый день! Я пишу программу для управления нагрузкой и вольтметром, оба Keithley. После нескольких десятков часов работы, программа зависает, помогает только принудительная остановка через abort execution. При этом никаких ошибок не выскакивает. Я предполагаю, что ошибка вызвана переполнением памяти прибора, но не умею это поменять. Может кто-то имел похожий опыт, подскажите, пожалуйста?

[Artem.spb]

Добрый день! Я пишу программу для управления нагрузкой и вольтметром, оба Keithley. После нескольких десятков часов работы, программа зависает, помогает только принудительная остановка через abort execution. При этом никаких ошибок не выскакивает. Я предполагаю, что ошибка вызвана переполнением памяти прибора, но не умею это поменять. Может кто-то имел похожий опыт, подскажите, пожалуйста?

Exe или исходники?
Если второе, то при зависании попробуйте открыть BD и включить "лампочку", есть шанс найти зависший участок.
А так без конкретики гадать шансов мало.

[dry-krutoy]

Спасибо за ответ!

Вот мой файл и subVI к нему.
К сожалению, мой рабочий компьютер не выдерживает режим "лампочки", вылетает, так как программа большая. Да и зависание происходит в случайный момент, по прошествии от 12 до 60 часов (пока такая статистика). В идеале понять ограничение по количеству измерений (если проблема в не очищаемом буфере), либо победить это вовсе.

[Artem.spb]

вылетает, так как программа большая.

Программа такая большая, что компутер и лампочка вылетает, а вы хотите, чтобы мы в этом разобрались?

vesr.JPG (23.76 КБ) 1430 просмотров

[dry-krutoy]

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

[Artem.spb]

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

Откуда такая уверенность?

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

Лампочка нужна не до, а после зависания.
Если повезёт, то будет видно, какой участок задумался и не выходит.

run.JPG (19.52 КБ) 1407 просмотров

Огм.
посмотрел код. Если это "попытка сделать рациональнее", то в "нерационально" даже лезть не хочется. Вот что мне показывает в масштабе 25%

[dry-krutoy]

Да, про лампу я понял, спасибо! Но перед этим надо как-то облегчить программу, Вы правы:)
Это мой первый опыт LabView да и написания большого кода тоже. Верю, что и более сложные вещи можно сделать красивее, подскажите, пожалуйста, как? Повторяющиеся куски в VI поместить, это я умею, но как в целом не занимать алгоритмом 4 экрана.. И как Вы смогли уменьшить BD :0?

[dry-krutoy]

P.S. Спасибо за ответы)

[Artem.spb]

И как Вы смогли уменьшить BD :0?

Это функция V23+

По архитектуре посмотрите машину состояний, например, в примерах State Machine Fundamentals.vi и Queued Message Handler Fundamentals.vi

[IgorTitov]

Но перед этим надо как-то облегчить программу, Вы правы:)
Это мой первый опыт LabView да и написания большого кода тоже. Верю, что и более сложные вещи можно сделать красивее, подскажите, пожалуйста, как? Повторяющиеся куски в VI поместить, это я умею, но как в целом не занимать алгоритмом 4 экрана..

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

Можно почитать "The LabVIEW Style Book", посмотреть на форумах дизайн-паттерны (шаблоны проектирования) LabVIEW, и непрерывно рефакторить свой код, пока не начнёт себе нравиться:)

[maxim_MA]

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

Смотря какое разрешение экрана=) да и фантастическое утверждение, "очевидно и читабельно". Должны быть приложены алгоритмы/блок-схемы, что бы было все очевидно и читабельно, и то не всегда сразу понимаешь логику происходящего=).
Наличие большого количества усложняет читабельность и понимание, пока между ними переключаешься уже забываешь, что было в первой , везде нужна золотая середина.

[IgorTitov]

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

Смотря какое разрешение экрана=)

Любое разрешение экрана:)

да и фантастическое утверждение, "очевидно и читабельно". Должны быть приложены алгоритмы/блок-схемы, что бы было все очевидно и читабельно, и то не всегда сразу понимаешь логику происходящего=).

Утверждение про "очевидно и читабельно" - не фантастическое. LabVIEW само по себе предоставляет код в виде блок-схем, поэтому если комментарии и картинки повышают качество кода, то конечно их нужно использовать. Но нужно стремиться к тому, чтобы код сам собой был читаемой документацией. Начиная от иконок и нейминга, и заканчивая расположением проводников, VI, подписей и т.п. Логика происходящего должна быть понятна из самой блок-диаграммы. И из использованного шаблона проектирования. Если на экране спагетти-код, то это не нормально при любых приложенных алгоритмах/блок-схемах.

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

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

[Borjomy_1]

То, что видно на bd, подлежит рефакторингу следующего вида: найти одинаковые фрагменты кода и оформить их в один VI. Далее можно эту vi обернуть в цикл и подать на нее массив наборов данных. Это резко сократит объем блок-диаграммы