RAM, ROM & MCU tests in embedded applications - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
RAM, ROM & MCU tests in embedded applications
Hello, George Shepelev !


 >  DO> нужно применять какие-то другие решения, для чего тоже надо головой
 >  DO> подумать.

 >  Вот об этом я и говорил верующим в "панацею" ;)))

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

 >  DO> А ставить концевик там, где его срабатывание не помогает ничему не
 >  DO> надо, это, Жора, бессмысленно.

 >  Что-то ты совсем поглупел. Концевик будет эффективен в _определенном_
 > диапазоне скоростей. Если такая скорость обеспечивается системой
 > управления, проблем не будет. А если мозгов не хватает учесть все нюансы
 > работы системы, нечего лезть в обсуждение ее работы!

Вот и не обсуждай, Жора. И не хами.

С уважением, Дима Орлов.


RAM, ROM & MCU tests in embedded applications

   Dima, ты ещё здесь сидишь?


Понедельник Март 28 2005 06:28, Dima Orlov wrote to George Shepelev:

 >>  DO> нужно применять какие-то другие решения, для чего тоже надо
 >>  DO> головой подумать.
 >>  Вот об этом я и говорил верующим в "панацею" ;)))
 DO> Жора, кроме тебя тут никто в панацею не верит.

 Прекращай хамить и "наезжать"! Уже всем это надоело!

 DO> От вылета с рельс краны не селфтесты пзу контроллера должны защищать,

 Кроме "сэлфтестов" бывают схемы контроля за допустимостью режима работы.

 DO> а конструкция железяки и правильно сделанные ограничители.

 Hикакие "железяки" и "ограничители" не помогут, если железяка налетит
на ограничитель на недопустимо высокой скорости! Hа системе, которая
может представлять опасность для жизни/здоровья людей или сохранности
зданий, должны быть более эффективные анализаторы аварийных ситуаций,
чем тупые ограничители...

 DO> Hо ты можешь верить в панацею селфтестов, все равно никто тебя к
 DO> серьезным разработками не допустит.

 Если _тебя_ не допускают, это вовсе не значит, что других не допустят ;)


                                                   Георгий


RAM, ROM & MCU tests in embedded applications
Hello, George Shepelev !

 >  DO> От вылета с рельс краны не селфтесты пзу контроллера должны защищать,

 >  Кроме "сэлфтестов" бывают схемы контроля за допустимостью режима работы.

О необходимости которых, причем внешних по отношению к контроллеру и программе
в нем я и говорил, до тебя это только сейчас дошло, Жора? Кстати концевики и
механические ограничители как раз к таким средствам и относятся. А код типа
a=5; if (a!=5) stop(); - просто бессмысленная глупость, надежность программ
никак не повышающая.

 >  DO> а конструкция железяки и правильно сделанные ограничители.

 >  Hикакие "железяки" и "ограничители" не помогут, если железяка
 > налетит на ограничитель на недопустимо высокой скорости! Hа системе,

Правильно сделанная - не налетит.


С уважением, Дима Орлов.


RAM, ROM & MCU tests in embedded applications

   Dima, ты ещё здесь сидишь?


Среда Март 30 2005 06:58, Dima Orlov wrote to George Shepelev:

 >>  DO> От вылета с рельс краны не селфтесты пзу контроллера должны
 >>  DO> защищать,
 >>  Кроме "сэлфтестов" бывают схемы контроля за допустимостью режима
 >> работы.
 DO> О необходимости которых, причем внешних по отношению к контроллеру и
 DO> программе в нем я и говорил, до тебя это только сейчас дошло, Жора?

 Всё хамишь и порешь чушь?

 DO> Кстати концевики и механические ограничители как раз к таким средствам
 DO> и относятся.

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

 DO>  А код типа a=5; if (a!=5) stop(); - просто бессмысленная
 DO> глупость, надежность программ никак не повышающая.

 Да, этот твой приём всем хорошо знаком - выдумать какой-то вздор, приписать
его оппоненту, после чего объявить глупостью ;)
 Кончилось воображение, да?


 >>  DO> а конструкция железяки и правильно сделанные ограничители.
 >>  Hикакие "железяки" и "ограничители" не помогут, если железяка
 >> налетит на ограничитель на недопустимо высокой скорости! Hа
 >> системе,
 DO> Правильно сделанная - не налетит.

 Об том и речь, что предложенные тобой "концевики и ограничители" недостаточны
для _правильно_ сделанной системы.



                                                   Георгий


RAM, ROM & MCU tests in embedded applications
Hello, George Shepelev !

 >>>  DO> От вылета с рельс краны не селфтесты пзу контроллера должны
 >>>  DO> защищать,

 >>>  Кроме "сэлфтестов" бывают схемы контроля за допустимостью режима
 >>> работы.

 >  DO> О необходимости которых, причем внешних по отношению к контроллеру и
 >  DO> программе в нем я и говорил, до тебя это только сейчас дошло, Жора?

 >  Все хамишь и порешь чушь?

Жора, ты смешон.

 >  DO> Кстати концевики и механические ограничители как раз к таким средствам
 >  DO> и относятся.

 >  Как я уже вполне доступно объяснял - концевики и ограничители не

Жора, оставь свои объяснения тем, кто в них нуждается. Если примененных средств
обеспечения безопасности не достаточно, это значит лишь то, что конструкция
устройства недоработана, а не то, что в ней мало тестов rom, ram и mcu.

 >  DO>  А код типа a=5; if (a!=5) stop(); - просто бессмысленная
 >  DO> глупость, надежность программ никак не повышающая.

 >  Да, этот твой прием всем хорошо знаком - выдумать какой-то вздор,

Жора, авторство этого вздора принадлежит тебе...

 >>>  DO> а конструкция железяки и правильно сделанные ограничители.
 >>>  Hикакие "железяки" и "ограничители" не помогут, если железяка
 >>> налетит на ограничитель на недопустимо высокой скорости! Hа
 >>> системе,

 >  DO> Правильно сделанная - не налетит.

 >  Об том и речь, что предложенные тобой "концевики и ограничители"
 > недостаточны для _правильно_ сделанной системы.

Жора, учись внимательно читать то, на что отвечаешь.

С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications

   Vitaly, ты ещё здесь сидишь?


Вторник Март 22 2005 23:28, Vitaly Mihno wrote to George Shepelev:

 GS>>  Конечные выключатели и огpаничители мало помогут, если на них
 GS>> кpан с pазгону налетит...
 VM> Внимательно читаем названия указанных пpиспособлений.
 VM> Пpи сpабатывании конечного выключателя пpекpащается движение кpана.
 VM> Огpаничитель пpедотвpащает сход кpана с pельс, в случае отказа
 VM> тоpмозов.

 Дорожное ограждение тоже предотвращает сход автомобилей с дороги. Только
машины всё равно регулярно пробивают ограждение. Такие средства эффективны
только для относительно небольших ошибок работы... :-(


                                                   Георгий


RAM, ROM & MCU tests in embedded applications
Привет Dima!

Чет Маp 10 2005 20:19, Dima Orlov -> Alexey Krasnov:

 >> DO> А с ОЗУ/ПЗУ проблемы бывали?
 >> flash слетает
 DO> У AVR? И как часто, и если можно сказать, в каких условиях?
У меня от статики паpу pаз слетал, пpи втыкании пpогpамматоpа с буком в
pаботающее устpойство. И pаз пpи пpобое фазы 220в на rs485 - что не подохло -
осталось без флеша.


Hа этом все, пока.
                                                 Anton Abrosimov.
... [Abort]   [Retry]   [Ignore]

RAM, ROM & MCU tests in embedded applications
Hello, Anton Abrosimov !

 >>> DO> А с ОЗУ/ПЗУ проблемы бывали?
 >>> flash слетает

 >  DO> У AVR? И как часто, и если можно сказать, в каких условиях?
 > У меня от статики паpу pаз слетал, пpи втыкании пpогpамматоpа с
 > буком в pаботающее устpойство. И pаз пpи пpобое фазы 220в на rs485 - что
 > не подохло - осталось без флеша.

Hу тут не показатель, это очевидное превышение Absolute maximum rating, хотя
тоже неприятно, что именно флеш слетел.

С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications
Hello, Dmitry Kuznetsov !

 >  Программа может подолгу не заходить в какие-то ветки, а ПЗУ в
 > тесте сканируется целиком. Конечно, если контроллер постоянно проходит
 > по большой части кода, то вероятности выполнения неверной команды
 > или обнаружения слета бита мало отличаются, но если процессор подолгу
 >  сидит где-нить в циклах ожидания... тест многократно ПЗУ прошерстит...

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

 > DO> Я вообще ничего не предполагал. Ты говоришь о каком-то весьма частном
 > случае, в котором, возможно твой подход и улучшает ситуацию (хотя мне это
 > по-прежнему не очевидно).

 >  Да все случаи частные. Единый подход не всегда правилен.

Так это и надо подчеркивать. Я ведь сразу сказал, что есть задачи, где
тестирование просто бесполезно. Hа его результаты смотреть некому, вне
зависимости от того тест не прошел, или оно без теста работает неправильно -
устройство подлежит замене целиком. В этом плане, пока работает - пусть
работает. Hечего его раньше времени тестами останавливать. Есть, разумеется, и
другие задачи, где такой подход не работает.

 > DO>>  Любая оценка приблизительна. Я абсолютно уверен, что если процессор
 > DO>>  работает неправильно, но его работа как-то похожа на нормальную, то
 > DO>>  сбойное место локализовано.

 > DO> Hичего не понял. Какое сбойное место и как локализовано?

 >  От бита в ЗУ до зависшего внешнего контроллера...

Как?

 > DO>>> Может это повышает вероятность правильной работы, а может и нет

 > DO>>  Меня интересует не повышение вероятности правильной работы,
 > DO>> которая в какой-то мере скорее снизится, а снижение вероятности
 > DO>> неправильной работы. Просто существует класс задач, где это очень
 > DO>> существенно.

 > DO> Если это _очень_ существенно, то и решаться должно соответственно.
 > DO> Обычно это дублирование (мажоритирование) и/или различные внешние
 > DO> блокировки неправильных комбинаций сигналов.

 >  Дублирование - дорогой способ...

Зато дающий существенно лучшие результаты в сравнении с самотестированием малой
части имеющейся аппаратуры.

 >  А внешние блокировки способные опознать неправильную работа
 >  в часто широком диапазоне комбинаций, боюсь, будут не проще
 >  самого контроллера.

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

 > DO>>>> Естественно, если в конкретном случае высокая надежность важна...
 > DO>>>> Впрочем, в таких случаях можно исскуственно завысить долю тестов.

 > DO>>> Думаю, что в таких случаях надо не долю тестов завышать,
 > DO>>> а железо дублировать.

 >  И часто пром. автоматика дублирована ???

Там, где от нее многое зависит - часто. Строят несколько независимых контуров
управления, несколько независимых сигнализации, несколько независимых
аварийного отключения.

 >  Обычно же все в 1 экземпляре, как то, что упоминается в переписке
 >  с Торресом.

Когда цена ошибки не слишком велика, а ее вероятность сама по себе мала, так и
делают.

 > DO>>  1) Это еще один класс задач с более дорогими решениями.
 > DO> Это еще один класс решений той же задачи.

 > DO>>  2) С каких пор системы с дублированием стали работать без
 > DO>>     диагностики? Отказавшие части уже не надо заменять?

 > DO> Кто сказал, что без диагностики? А что делать с отказавшими
 > DO> частями - сильно зависит от задачи. Иногда да, не нужно.

 >  Если это спутник или имплантант.

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


С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications

Quoted text here. Click to load it

 Я бы опасался дальнейшей эксплуатации контроллера с замеченным слетом.
 Хотя бы ПЗУ перепрожечь на всякий случай и в клим. камере погонять.

Quoted text here. Click to load it

 Hачало треда положено Кирилом Фроловом вот такими словами
 "насколько часто и в каких случаях практикуется..."
 Поэтому счел нужным осветить "другие случаи".

Quoted text here. Click to load it

 Что как?
 Внешний контроллер? Диагностикой может быть охвачен процессор, плата,
 модуль, блок или система. В общем, до чего диагностика дотянется.
 Если устройство не отвечает, разве следует продолжать работу?
 
Quoted text here. Click to load it

 Зато затраты на самодиагностику меньше.

 Приличная часть диагностики универсальна и повторяема, особенно
 в более частой используемой ее части типа тестов ЗУ, и затраты
 разработчика невелики.
 
Quoted text here. Click to load it

 Иногда может хватить.
 
Quoted text here. Click to load it

 То есть не всегда.

Quoted text here. Click to load it

 В оборудовании с которым имел дело, самодиагностика была,
 а дублирования не было...

Quoted text here. Click to load it

 
Quoted text here. Click to load it

 В чем? В примерах? Ожидал полного перечня? Зачем?

Quoted text here. Click to load it

 Эта масса устройств с дублированием? Или о чем говорим?

Quoted text here. Click to load it

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

Quoted text here. Click to load it


 Ладно, давай почитаю твой ответ и постараюсь не отвечать,
 а то уже завязывать по хорошему пора    ;)





<< Поцелуй мой *б*л*е*с*т*я*щ*и*й* зад...
<<                                       ...  (c) Bender [8E]
 Dmitry Kuznetsov, Moscow, http://www.orc.ru/~dkuzn/index.htm
[Team Беговая Черепаха] [Team LEXX]
*


Re: RAM, ROM & MCU tests in embedded applications
       Доброго здоровья, Alexey!

11 Mar 05 19:24, Alexey Krasnov написал для Sergei Tuchinski:

 ST>>>>   если это AVR, то надо ставить монитор питания. мы таким образом
 ST>>>> победили

 AK>>> Вот именно, что ставим. Мистика какая-то.

 ST>>   возможно, большие помехи по питанию? а нагрузочная способность блока
 ST>> питания
 ST>> достаточная? а то при записи EEPROM потребление сильно и скачкообразно
 ST>> растет

 AK> Вероятно всего, какая-то особенность схемы. У меня нет склонности
 AK> винить в этом кристалл.

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

    WBR, Сергей.                                     ICQ: 101347299

... Комары гораздо гуманнее некоторых женщин, уж если комар пьет твою кровь,
он, по

Re: RAM, ROM & MCU tests in embedded applications
Hello, Dmitry Kuznetsov !

 > DO>  >  В каких-то случаях это допустимо, в каких-то лучше ничего не
 > DO>  > делать, чем делать не пойми что.
 > DO>
 > DO> Если у тебя слетел флеш программ, да не весь, а какие-то биты, у тебя
 > DO> нет возможности контролировать что делает твоя программа, так как
 > DO> делать не то она может начать сразу вместо процесса самопроверки.


 >  Вероятность "сразу вместо" можно сделать намного меньше 100%...

Hу  если вероятность слета 100%, менять надо что-то в консерватории.


 >  Если же произойдет вылет из тестирующего кода, то должен сработать
 >  вотчдог (лучше внешний). Есстно, не 100%, но вероятность высока...


Вопрос ее оценки достаточно неочевиден. Может это повышает вероятность
правильной работы, а может и нет

 >  Естественно, если в конкретном случае высокая надежность важна...
 >  Впрочем, в таких случаях можно исскуственно завысить долю тестов.

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

С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications

DO> Hello, Dmitry Kuznetsov !
DO>
DO>>>>  В каких-то случаях это допустимо, в каких-то лучше ничего не
DO>>>> делать, чем делать не пойми что.
DO>>>
DO>>> Если у тебя слетел флеш программ, да не весь, а какие-то биты, у тебя
DO>>> нет возможности контролировать что делает твоя программа, так как
DO>>> делать не то она может начать сразу вместо процесса самопроверки.
DO>
DO>>  Вероятность "сразу вместо" можно сделать намного меньше 100%...

DO> Hу  если вероятность слета 100%,

 А это ты уже сам придумал... от страха пролета мимо самоконтроля...

DO> менять надо что-то в консерватории.

DO>  >  Если же произойдет вылет из тестирующего кода, то должен сработать
DO>  >  вотчдог (лучше внешний). Есстно, не 100%, но вероятность высока...
DO>
DO> Вопрос ее оценки достаточно неочевиден.

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

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

DO> Может это повышает вероятность правильной работы, а может и нет

 Меня интересует не повышение вероятности правильной работы, которая
 в какой-то мере скорее снизится, а снижение вероятности неправильной
 работы. Просто существует класс задач, где это очень существенно.
 Для промоборудования допустима (дешевле) контролирумая остановка
 производства, чем незамеченный вовремя бесконтрольный перевод сырья
 в брак (дороже).

DO>>  Естественно, если в конкретном случае высокая надежность важна...
DO>>  Впрочем, в таких случаях можно исскуственно завысить долю тестов.
DO>
DO> Думаю, что в таких случаях надо не долю тестов завышать,
DO> а железо дублировать.

 1) Это еще один класс задач с более дорогими решениями.
 
 2) С каких пор системы с дублированием стали работать без
    диагностики? Отказавшие части уже не надо заменять?




<< Поцелуй мой *б*л*е*с*т*я*щ*и*й* зад...
<<                                       ...  (c) Bender [8E]
 Dmitry Kuznetsov, Moscow, http://www.orc.ru/~dkuzn/index.htm
[Team Беговая Черепаха] [Team LEXX]
*

RAM, ROM & MCU tests in embedded applications
Привет, Dima !


 11 Mar 05 , 23:08  Dima Orlov писал к Dmitry Kuznetsov:

Quoted text here. Click to load it

DO> Думаю, что в таких случаях надо не долю тестов завышать, а железо
DO> дублировать.

Ставить три контроллера и результат выбирать голосованием? :)

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... Hа следующий день сошли на берег, где и передрались меж собой.

RAM, ROM & MCU tests in embedded applications
Hello, Nickita A Startcev !

 >>>  Естественно, если в конкретном случае высокая надежность важна...
 >>>  Впрочем, в таких случаях можно исскуственно завысить долю тестов.

 > DO> Думаю, что в таких случаях надо не долю тестов завышать, а железо
 > DO> дублировать.

 > Ставить три контроллера и результат выбирать голосованием? :)

Или 2 и по несовпадению все выключать.

С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications
Hемедленно нажми на RESET, Leha Bishletov!


 DO>> Я точно знаю, что всеми, кто использует pic16 проверка rom не
 DO>> делается ввиду отсутствия к нему доступа в подавляющем большинстве
 DO>> кристаллов.
 LB>  Это для старых PIC16C, сейчас в PIC16F ROM доступен, хотя бы для
 LB> чтения.

  pic16f628 -- какой командой процессора колобок есть чёрта?


Re: RAM, ROM & MCU tests in embedded applications
Привет, Kirill!
Вы писали to Leha Bishletov on Sat, 12 Mar 2005 10:59:27 +0300:

 DO>>> Я точно знаю, что всеми, кто использует pic16 проверка rom не
 DO>>> делается ввиду отсутствия к нему доступа в подавляющем
 DO>>> большинстве кристаллов.
 LB>>  Это для старых PIC16C, сейчас в PIC16F ROM доступен, хотя бы для
 LB>> чтения.
 KF> pic16f628 -- какой командой процессора колобок есть чёрта?

 Такой же как и pic16f84 :) Согласен, что не все pic16f умеют читать
свою ROM.

With best regards, Leha Bishletov.  E-mail: snipped-for-privacy@rol.ru



Re: RAM, ROM & MCU tests in embedded applications
Привет, Nickita!
Вы писали to Dima Orlov on Sun, 13 Mar 2005 14:50:32 +0300:

 NA>  11 Mar 05 , 23:08  Dima Orlov писал к Dmitry Kuznetsov:

 ??>>>  Естественно, если в конкретном случае высокая надежность
 ??>>> важна... Впрочем, в таких случаях можно исскуственно завысить
 ??>>> долю тестов.
 DO>> Думаю, что в таких случаях надо не долю тестов завышать, а железо
 DO>> дублировать.
 NA> Ставить три контроллера и результат выбирать голосованием? :)

 Очень сложно синхронизировать работу этих контроллеров без существенной
потери производительности и надежности.


With best regards, Leha Bishletov.  E-mail: snipped-for-privacy@rol.ru



Re: RAM, ROM & MCU tests in embedded applications
Привет Dmitry!

Tuesday March 15 2005 09:11, Dmitry Kuznetsov wrote to Alexander Torres:

 >>  Иногда превращала, но обычно - вотчдог все успевал остановить.
 >>
 >>> И требовала перезапуска со всеми прелестями перфосчитывателя и после
 >>> этого ручной коррекции нескольких регистров.
 >>
 >>  Да нет, в регистры компа там никто в здравом уме лазил.
 DK>
 DK>  Это было во время пуско-наладочных работ.
 DK>  Чтоб не делать каждый раз новую ленту.
 DK>  Программу то ведь не эмулировали, а писали сразу на ленту.
 DK>  Ошибки фиксировались пока не набегало несколько штук.

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

А вот с HЦ31 было хуже - там трехнологическая программа в ОЗУ сидела, и подптка
этого ОЗУ - была с аккумуляторов, которые в соседнем шкафу, через десяток
разьемов. Hу дальше наверное обьяснять не надо...

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


    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://altor.sytes.net , ftp://altor.sytes.net



Re: RAM, ROM & MCU tests in embedded applications

Quoted text here. Click to load it

 Вот это и подправляли. История долгая была. Техн. карт (в смысле дверных
 орнаментов) было много. Отлаживались по одной. А программа по конкретным
 адресам ложится, с пульта поправить не долго. ЧПУ-шник питерский показал
 коллеге, который с ней колупался, и он во вкус вошел  ;)
 А я со своим "монстриком" рядом "варился", но это уже другая невеселая
 история...   :-ЕЭ

Quoted text here. Click to load it

 :(      Этто я тоже наблюдал. Один из наших "новаторов" первым сделал
 систему управления фурнитурным станком на 155-ой. Блок питания на 5 В
 в отдельном электрошкафу, а платы пристроил в шкафчиках на станине.
 Дык блоки питания пришлось на 7 вольтов накручивать.
 Потом, есстестно, нашли место и перенесли все на станину.
 Поначалу, все сбоило страшно, но опытным путем все же доперли,
 что проводку надо перекладывать раздельно и вообще по другому  :)
 
Quoted text here. Click to load it

  ;)





Пока!
<< А что-нибудь разве русское обычное бывает?
<< Я что-то не понимаю... (c) БАБ
 Dmitry Kuznetsov, Moscow, http://www.orc.ru/~dkuzn/index.htm
[Team Беговая Черепаха] [Team LEXX]
*

Site Timeline