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

В общем есть обмен с одним устройством. Раньше его подключали за преобразователем портов, так что к преобразователю подключались по TCP-IP, а от того шло по RS-232. Для програмы - всё равно, что просто по TCP-IP. Потом к этому устройству стали подключаться напрямую по UDP. В принципе почти всё одно и то же, есть несколько отличий. Ну, при подключении создаем сокет для UDP например.
ВместовызываемИ в первом случае, не прервалось ли подключение, можно проверить просто - открыт ли сокет. А во втором случае, в UDP ведь нет понятия подключения, так что надо как-то проверять на уровне приложения. Например если сколько-то подряд раз не получили ответ от устройства, можно считать, что связь нарушена.

В общем я написал класс, реализующий обмен с устройством по UDP как наследника класса, который обменивался данными по TCP. У них есть предок с самыми общими методами, некоторыми - абстрактными. Но от этого предка есть наследник и могут быть другие и для железок других производителей. А тут надо было бы наверное сделать ещё промежуточный класс для этой конкретной железки со всеми общими методами, а от него уже унаследовать один для TCP, один для UDP. Я сделал, как меньше труда :) В принципе это задачи решило, дальше иерархия не планируется.
Но вот в другой программе тоже нужен был такой обмен, скопипастил один старый вариант. А там в одном из методов, переписанных (override), сначала вызывается метод предка (inherited). А потом уже обмен по UDP. НО! не надо было вызывать метод предка, надо было бы вызвать метод предка предка (такую манипуляцию Паскаль напрямую вроде не позволяет), чтобы зачистить кое-какие структуры, или впрямую (как я сейчас сделал) очистить их. В более новой версии основной программы этой фигни нет, а тут она была. Получилось, что во-первых два раза запрос и чтение ответа делалось.
Но что более важно, из-за чего ошибка была. В TCP протокол обеспечивает доставку пакета, причем, если не ошибаюсь, может его разбить, доставить по частям. И читать из сокета мы можем кусочками, по сколько хотим. Соответственно, там читался сначала заголовок пакета, в котором указана общая длина данных, а потом читалось остальное - нужное количество байт.
А при UDP такого делать нельзя. В UDP приходит датаграмма целиком и её надо читать целиком. В документации на функцию recv написано: Соответственно, когда у меня для UDP сокета вызывался метод его TCP-предка, вот эту ошибку я и получал. Убрал inherited, добавил код очистки структур и всё заработало, как надо. Спектр стал нормально сниматься. Формат пакетов известен, в том числе длина, так что можно сразу пытаться читать весь пакет.
Вот.

s62 [игнорируется] 

А у нас в офисе, когда есть собранный макет, бывает по-разному собран - или датчик подключен через преобразователь портов, или напрямую по UDP. Я когда эту штуку писал, было как раз собрано в первом варианте. Я потестил, всё вроде работает ок. А на фабрике наш сотрудник начал использовать - не работает (там - второй вариант подключения). Я тоже посмотрел, да, прекращается измерение, непонятно почему. Ну, не катастрофично, т.к. именно это долго делали в другой программе, и так и тут продолжилось. Хорошо, что на днях появился программный эмулятор железки. Запустил с ним в офисе и в отладчике Delphi увидел, что в одной команде непонятно почему вдруг работает функция от TCP. Ну, увидел потом это ненужное там inherited.

s62 [игнорируется] 
Хм, может я нарушаю соглашение о неразглашении, что написал вот это на форуме... Ладно, уже не удалить, вроде особо чувствительной информации и тайн тут не было.