Полная версия этой страницы:
Ошибка LNS#25 DB#2017
При восстановлении базы данных из сети (Recover database from network) в LonMaker 3.1
после того как нажали service pin для определения домена
во время процесса "Creating network interface device"
выскакивает ошибка
Database error (Subsystem: LNS,#25)[DB#2017]
Очевидно заблокирован доступ к базе данных?
Есть ли у кого мануал с описанием ошибок LNS по типу NodeBuilder Errors Guide?
Lon-теоретик
15.7.2007, 12:06
Позвольте дать Вам совет - НИКОГДА ТАК БОЛЬШЕ НЕ ДЕЛАЙТЕ. К сожалению Lonmaker глючил, глючит и будет глючить при попытке восстановить базу LNS по реальной сети. Если у Вас количество узлов более 4-х - забудьте об опции "recovering from network".
Терпения Вам и удачи!!!!
ggg__ggg
15.7.2007, 14:12
Есть в HELPe List of errors. Можно использовать HELP от LNS Report Generator.
Да, очевидно это глюк, но который пока удалось обойти, указав Domain ID в явном виде.
Для контроллеров Vitotronic от Viessmann это 7, как известно.
Пока вычитали сеть из двух контроллеров - 333 и 100.
На реальной котельной еще не экспериментировали.
Но придется, деваться некуда.
Чем еще еще реально можно вычитать сеть
Не знаю, я делал на ТАС ( его "глюки" в чистом LONe - это песня !!!). Никаких проблем. Маленькое уточнение - а чем конфигурили контроллеры?
LONMaker не очень любит конкурентов, т.к. ( такое у меня сложилось впечатление) , он использует некоторые недокументированные особенности LNS. Если нет Domain ID - то, может, неправильная длина домена? Не все используют 1 по умолчанию. Тот же ТАС, для своих нужд, использует нулевую длину.
Тоже сталкивался с подобными проблемами, связанными с Domain ID. Как-то LNS все-таки не дорабатывает с вычитаванием Domain ID нулевой длины. К слову, сам LonMaker не позволяет установить домен нулевой длины.
Как правило, нулевая длина используется для "внутренних" нужд тех производителей (типа ТАС) , которые придумывают свои NVT, и не хотят пересекаться с "чистым" LON.
Чем Viessmann конфигурит свои Витотроники - не знаю, по крайне мере в московском офисе Viessmann нас отослали
интересоваться этим вопросом в Германию. Нет в московском представительстве кого-либо, кто знает что такое LON,
а если и был, то думается сплыл
Вот из-за этого и весь сыр-бор. В документации по LONMaker такая ситуевина прописана. Выход - ручками его, ручками. Скорее всего, нулевая длина домена. Выставляете ручками - и понеслось. А LONMaker'oм конфигурить будете - можете иметь сюрпизы. Cоmission protocol- обычно есть такая бумага.
Нет, в обратную ничего конфигурить не будем, упаси боже.
Вычитать, подцепться через OPC server далее в Genesis и в кассу за зарплатой
Цитата(ggg__ggg @ 17.7.2007, 9:45) [snapback]145801[/snapback]
Как правило, нулевая длина используется для "внутренних" нужд тех производителей (типа ТАС) , которые придумывают свои NVT, и не хотят пересекаться с "чистым" LON.
Нет, не для внутренних. Обратимся к "первоисточнику"
LONMARK Application-Layer Interoperability Guidelines, раздел 4.1.3. Domain-Table Entries:
"With regard to the number of domain-table entries, it is often useful to have a device be a member of the zero length domain so that it may be queried with out knowing its NeuronID. This is useful when the network database is lost and must be recovered from the network itself. While the NeuronID may be acquired by activating the device’s servicepin, and the domain table read with a second command using the NeuronID, the servicepin may not be easily accessible on devices in some applications. For example, the device may be on a roof or behind a wall. If it is inconvenient, or not practical, to activate the servicepin on a device which has only a single domain-table entry, and that device’s configured domain is unknown, then the device cannot be recovered. In these cases, the QueryID network management message must be used to get the NeuronID. While the servicepin message is always sent as a domain-wide broadcast on the zero-length domain, the QueryID network management message is domain specific. Thus, a network tool must know one of the domains of the device to use the QueryID network management message, or it must already know the NeuronID. Since the zero length domain is not typically used for normal system operation, the need for the second domain entry arises from the need for devices to be members of their own system domain and the zero-length domain so that the QueryID network management message may be used on a known domain to assist in database recovery. Once the system domain is known, all devices that are members of that domain may be recovered."
ggg__ggg
17.7.2007, 10:12
Цитата(KDVectra @ 17.7.2007, 6:58) [snapback]145869[/snapback]
Нет, не для внутренних. Обратимся к "первоисточнику" LONMARK Application-Layer Interoperability Guidelines, раздел 4.1.3. Domain-Table Entries:
". Since the zero length domain is not typically used for normal system operation, the need for the second domain entry arises from the need for devices to be members of their own system domain and the zero-length domain so that the QueryID network management message may be used on a known domain to assist in database recovery. Once the system domain is known, all devices that are members of that domain may be recovered."
Вы сами подтвердили мои слова

Именно для того, чтобы реализовать СВОИ прибамбасы, некоторые фирмы и используют эту нулевую длину.
Не хочу вдаваться в технические подробности, но это самый удобный способ...
KDVectra
17.7.2007, 10:59
Цитата(ggg__ggg)
Как правило, нулевая длина используется для "внутренних" нужд тех производителей (типа ТАС) , которые придумывают свои NVT, и не хотят пересекаться с "чистым" LON.
Цитата(ggg__ggg @ 17.7.2007, 11:12) [snapback]145883[/snapback]
Вы сами подтвердили мои слова

Именно для того, чтобы реализовать СВОИ прибамбасы, некоторые фирмы и используют эту нулевую длину. ...
С Вашего разрешения перефразировал бы "Пользуясь
особенностями домена нулевой длины (zero-length domain) некоторые фирмы реализуют СВОИ прибамбасы".
ggg__ggg
17.7.2007, 11:01
Let it be !
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.