Особенности измерения сопротивления на S7-1200

Как известно, к контроллерам S7-1200 можно подключать модули расширения для измерения сигналов сопротивления, но предназначены эти модули, в первую очередь, для сигналов с датчиков температур (термосопротивлений), потому модули так и называются RTD - Resistance Temperature Detectors. Но ведь может быть задача, когда мерить надо вовсе не сигнал от термосопротивлений, может стоять задача измерить сопротивление от 0 до нескольких килоом, например. В настройках данного модуля в TIA Portal можно выставить диапазон измерений для каждого канала:

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

- мерить сопротивление от 0 до 600 Ом - значения в этом случае будут в тех же единицах, что и для аналоговых модулей 0..10 В и 0..20 мА, т.е. значение 27500 будет соответствовать 600 Ом. Экспериментально выяснилось, что померить удаётся чуть больше, чем 700 Ом (у меня получилось максимум 714 Ом, после этого показывает 32767 - ошибка датчика).

- мерить сопротивление для датчика Pt1000. Конечно, у самих таких датчиков диапазон изменения сопротивления гораздо уже, чем может понадобится (от 800 до 1800 Ом), но это вовсе не значит, что модуль RTD не способен охватить бОльший диапазон. Экспериментально выяснилось, что можно померить таким образом сопротивление от 60 Ом до примерно 4900 Ом. Значение получается градусах (точнее, в целых числах, где последняя цифра - это знак после запятой, т.е. как бы градусы помноженные на 10), его надо масштабировать в Омы самостоятельно. Если брать по таблице, то значение -500 (т.е. -50 град) должно соответствовать 803.15 Ом, а 1000 (т.е. 100 град) - 1385 Ом. У меня так оно и получилось. Но есть один нюанс: нельзя померить слишком маленькое сопротивление (ниже 60 Ом). Верхняя граница в 4.9 кОм определяется исходя из того, что максимальное значение может быть 10000 (т.е. 1000.0 град).

У меня была задача померить сопротивление от 0 Ом. Как видим, вариант 60..4900 Ом для этого не подходит. Поэтому я вышел из положения следующим образом: я подсоединил датчик одновременно к двум каналам модуля RTD, настроил их: первый на 0..600 Ом, второй - на Pt1000 и написал алгоритм переключения:

R_.isR1_actual := (AI_RTD_R1 <> 32767 AND AI_RTD_R1 <> -32768);

R_.isR2_actual := (AI_RTD_R2 <> 32767 AND AI_RTD_R2 <> -32768);
 
OBRYV_R := R_.isR1_actual = false AND R_.isR2_actual = false;
 
R_average := (Read_AI_R1.OUT_value + Read_AI_R2.OUT_value) / 2.0;
 
useAverageValue := false;

IF(R_.isR1_actual AND R_.isR2_actual) THEN 
   R_.PV := R_average;
   IF(R_average > R_.R_switch - R_.R_delta AND
      R_average < R_.R_switch + R_.R_delta)
   THEN
      useAverageValue := true;
      IF(Read_AI_R1.OUT_value < R_average) THEN R_.mode := 0;
      ELSE R_.mode := 1; END_IF;
   END_IF;

   IF(R_.isUseR2 = false AND
      ((R_.mode = 0 AND Read_AI_R1.OUT_value > R_.R_switch) OR     
       (R_.mode = 1 AND Read_AI_R2.OUT_value > R_.R_switch)))
   THEN
      R_.isUseR2 := true;  
   ELSIF(R_.isUseR2 AND
      ((R_.mode = 0 AND Read_AI_R2.OUT_value < R_.R_switch) OR     
       (R_.mode = 1 AND Read_AI_R1.OUT_value < R_.R_switch)))
   THEN
      R_.isUseR2 := false;
   END_IF;
ELSE
   IF(R_.isR1_actual) THEN R_.isUseR2 := false;
   ELSIF(R_.isR2_actual) THEN R_.isUseR2 := true; 
   END_IF;
END_IF;

IF(OBRYV_R = false) THEN
   IF(useAverageValue = false) THEN
      IF(R_.isUseR2 = false) THEN R_.PV := Read_AI_R1.OUT_value;
      ELSE R_.PV := Read_AI_R2.OUT_value;
      END_IF;
   END_IF;
ELSE
   R_.PV := 99999.0;
END_IF;

В этом фрагменте кода:
OBRYV_R - это такой бит, который предназначен для проверки аварии обрыва датчика
Read_AI_R1.OUT_value - это такое значение Real в Омах, которое получилось в результате масштабирования сигнала AI_RTD_R1 c первого канала модуля RTD (0 - 0 Ом, 27500 - 600 Ом)
Read_AI_R2.OUT_value - это такое значение Real в Омах, которое получилось в результате масштабирования сигнала AI_RTD_R2 cо второго канала модуля RTD (-500 - 803.15 Ом, 1000 - 1385 Ом)
R_.R_switch -  значение сопротивления, при котором будет происходить переключение между каналами (у меня выставлено значение 693 Ом)
R_.R_delta - дельта (плюс/минус) к R_.R_Switch (у меня выставлено значение 1 Ом)

Таким образом, задействовав два канала, можно померить весь диапазон от 0 до 4.9 кОм.

Нюансы

В настройках TIA Portal можно выбрать двух, трёх и четырёхпроводную схему подключения датчика. Я не знаю, зачем эта настройка, но факт в том, что если не подключить все 4 клеммы, то работать нормально ничего не будет. Т. е. даже если выбрана двухпроводная схема и датчик подключен на клеммы I+ и I-, то остальные две клеммы (M+ и M-) всё равно нельзя оставлять неподключенными, т.е. надо ставить перемычки с M+ на I+ и с M- на I-. В общем-то в сименовской инструкции об этом тоже написано.

По ходу проведения экспериментов я заметил, что модуль RTD ведёт себя как-то странно: то показывает ошибку при нормально подключенном датчике, то показывает одно и тоже значение, какое бы сопротивление я не подключал (т.е. как будто бы "зависает", при этом при отключении датчика исправно показывает 32767). Выяснилось, что модуль немного "сходит с ума", если к нему "на горячую" то подключать что-то, то отключать, то провода местами менять и т.д. Делать надо так: обесточили контроллер, подсоединили всё, что нужно, после этого включили, тогда никаких глюков нет.

Какие ещё варианты

1. Использовать модуль обычных аналоговых входов и преобразователь сигнала сопротивления в унифицированный сигнал в mA. Следует отметить, что у многих производителей (например, Schneider или Овен) такие устройства изначально заточены на термосопротивления, т.е. для нестандартных диапазонов у них преобразователей нет. Но, всё таки можно что-то найти. Например:

- у ABB есть такой преобразователь TTR200 с входным сигналом до 5 кОм. Сколько стóит не знаю.

- есть российская такая штука: НПСИ-ПМ, которая позволяет измерять до 10 кОм (диапазон выхода в mA настраиваемый). Цена его около 6000 р., делают в Ростове-на-Дону.

- у Овен есть контроллер ПР200 примерно за те же 6000 р., у которого 4 аналоговых входа на борту, которыми можно померить в т.ч. и сопротивление до нескольких кОм и есть аналоговый выход 0..20 мА, т.е. остаётся дело за малым - написать примитивную программку для этого дела.

2. Изменить входное сопротивление через дополнительный резистор, т.е. сместить диапазон, чтобы не от 60 Ом по факту мерить, а от 0. Верхняя граница также, естественно, сместится.

3.Использовать распределённую станцию ET200SP, к которой цеплять модули от контроллера S7-300 ($$$ money, money, must be funny...).

Распароливание контроллеров FATEK

Недавно появилась задача слить программу с запороленного тайваньского контроллера FATEK FBs-40MA. В общем и целом задача оказалось весьма простой. Для того, чтобы слить программу, необходимо скачать взломанную версию среды разработки WinProladder.
В интернете архив со взломанной версией называется WPlad300-12308-ENU_CR2.rar, он содержит исполняемый файл установки, скачать его вы можете здесь:

WinProladder 3.00 Build 12308 CRACKED

Для тех, кто не знаком с ПЛК FATEK, может показаться странным отсутствие кнопок Download и Upload. Действительно, интерфейс немного нетипичный. Т.е. там есть кнопка Online, которая означает не только переход в соответствующий режим, но и запрос на загрузку и выгрузку проекта в/из ПЛК. Причём, в этом режиме все изменения тоже автоматически отправляются на контроллер. Ну, вот такая странная у них среда разработки.

Взломанная версия - это не последняя версия WinProladder, сейчас уже есть версия 3.24, но я никакой разницы не заметил.

Что касается установки пароли и его отмены

Значит, во-первых, не факт, что вот это взломанное ПО 100% поможет слить вам программу из ПЛК. Дело в том, что пароль может запрашиваться как в момент установки соединения при переходе в режим Online, так и уже после того, как программа слита. Если вы подключаетесь к ПЛК и программа сразу просит пароль - взломанная среда вам не поможет.

Но может быть и так, что программа сливается, а потом просит пароль, и если он введён не верно, то программу нельзя ни посмотреть (она снова просит пароль), ни сохранить. В этом случае считайте, что вам повезло. Во взломанной версии WinProladder на запрос пароля в таком случае просто ничего не надо вводить, а сразу нажимать OK. После того как программа успешно выгрузилась нужно убрать пароль и Project ID. Для этого заходим в меню Project -> Project Setup -> Password, там сначала просят ввести старый пароль (ничего не вводим), потом просят новый пароль (опять ничего не вводим). Повторяем процедуру для Program ID в том же меню. Сохраняем файл проекта. После этого проект, при желании, можно открывать уже в более новой версии WinProladder.

Повторюсь, такой способ работает не всегда. Я не знаю тонкостей работы с этими ПЛК, но суть в том, что я один и тот же проект сначала успешно слил из контроллера FBs-40MA, а потом ради интереса залил в свой контроллер FBs-20MN, и когда я попытался уже со своего контроллера программу слить, то у меня сначала запросили пароль, т.е. не зная его слить программу уже было нельзя ни в какой версии WinProladder.

Внимание, FAKE!

Помимо всего этого дела, есть ещё какая-то странная программа под названием что-то типа All PLC and HMI Crack или как-то так. Программа платная. Вы её легко найдёте в интернете по дебильному салатовому внешнему виду. Разработал её какой-то вьетнамец. Вообще, внешне есть определённый намек на истину, т.е., например, в меню его программе есть пункты для снятия пароля с Siemens S7-200, так вот только для прошивки 2.0 предлагается снимать пароль с ПЛК, а для прошивки 2.1 - только пароль с файла проекта. Это действительно так и есть у Siemens S7-200 (только для это давно есть бесплатные программы). Так вот, я не берусь утверждать, что вьетнамская программа - это прям 100% фейк, но тот факт, что программа стоит не особо и дорого (что-то вроде $200), и то, что она рекламируется как ПО с функциями по взлому сразу многих моделей ПЛК разных фирм, но при этом никто ещё не выложил такой программы в общий доступ в интернет, намекает на то, что это всё-таки фейк. Тем временем, вьетнамец усердно постит ролики на youtube о том, как его программа замечательно работает, при этом подделать всё, что в этих роликах показано не составляет труда, поскольку его чудо-программа расшифровывает пароли с ПЛК, которые сам вьетнамец и запоролил, т.е. не факт, что прога просто не показывает заранее известный пароль всегда чисто для того, чтобы снять доказательное видео для youtube.

 

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

Проблемы совместимости S7-200 и китайских PLC: глюк с оператором JMP

Читай также:
Проблемы совместимости S7-200 и китайских PLC: глюк с оператором FOR
Китайские поделки на тему Siemens S7-200

Итак, я хочу рассказать об интересном дефекте китайских контроллеров, который я на днях случайно обнаружил. Как уже известно, если вам нужен ПЛК Siemens S7-200 (снятый с производства в Германии в 2012 году), то есть два способа его купить: это выкупить остатки со склада каких-нибудь торгашей, которые берегут это добро уже больше пяти лет, чтобы продать по цене в 2 - 4 раза превышающей его былую стоимость, либо (самый простой способ) - купить S7-200CN на Aliexpress.

Контроллеры с маркировкой CN производятся в КНР официально, т.е. это оригинальный Siemens, но сделанный в Китае. Его отличие от немецкого Siemens's только в том, что Step-7 Micro/Win отказывается с ним работать при активированном английском интерфейсе, по крайней мере так было раньше (после переключения интерфейса на иероглифы проблема решается).
 Update. Аллелуя! Похоже, Siemens таки убрал необходимость переключения на китайский язык при заливки контроллеров S7-200CN (покупал тут, залился в английском MicroWIN без проблем, на вид, вроде, настоящий Siemens, label присутствует, цвет корпуса с зеленоватым оттенком как у немецких S7-200)

Однако, на Aliexpress есть и другие ПЛК, которые повторяют функционал S7-200. О них я уже как-то рассказывал в этой статье. Все они деляться на три группы:
1. Имеют полную совместимость с S7-200. Т.е. программируются в среде Step-7 Micro/Win и совместимы с модулями Siemens (GIPENG, AMSAMOTION, SHENJUYE (продаются под лэйблом LOLLETTE)).
2. Имеют совместимость с модулями S7-200, но имеют свою среду разработки (CO-TRUST, среда - MagicWorks PLC)
3. Не имеют совместимости с модулями S7-200, но программируются в среде Step-7 Micro/Win (FONIN)

Итак, я никогда не приобретал не полностью совместимые с Siemens контроллеры, такие как Co-Trust или Fonin, ничего не могу о них пока сказать.
Но у меня в распоряжении имеются контроллеры Gipeng, Amsamotion и Shenjuye (Lollette). И вот, добавив в программу для Amsamotion ранее написанную функцию ПИД-регулирования (я использую только свои собственные функции регуляторов), я внезапно обнаруживаю, что она не работает. Удивительное дело, ведь функция уже проверена на контроллерах Siemens S7-200, как же так? Оказывается, в контроллере Amsamotion наблюдается непонятный глюк: неправильно работает оператор JMP. Я проверил выполнение этого оператора на том же примере на контроллерах Siemens, Gipeng и Shenjuye (Lollette) и вот оказалось, что глюк не проявляется на оригинальном Siemens S7-200 и на Shenjuye (Lollette) LE-200, а на Gipeng GF-200 проявляется в том же виде, что и на Amsamotion AMX-200CN.

Описание проблемы оператора JMP

В общем, напомню, что оператор JMP (jump) из набора команд S7-200 является оператором условного перехода, что является косвенным аналогом оператора JE в классическом ассемблере и оператора JC в языке STL для S7-300. В языках программирования высокого уровня для ЭВМ обычно называется GOTO (go to).

Суть работы оператора JMP # в том, что при логической 1 в вершине стека он осуществляет переход на указанную метку, которая задаётся командой LBL #, где # - это номер метки.
При компиляции этот номер заменяется адресом строки кода, куда осуществляется переход. Т.е. весь код программы, который находится между операторами JMP и LBL чисто физически не должен выполняться.
Соответственно, после выполнения перехода стек сохраняется в том виде, в котором был на момент перехода. А поскольку переход условный, то если он выполнен, то после перехода в вершине стека может быть только логическая 1, т.к. это и есть условие для перехода. Инструкция от Siemens для особо одарённых даже содержит специальное уточнение:

The Jump To Label (JMP) instruction performs a branch to the specified label (n) withon program. When a jump is taken, the top of stake value is always is logical 1.

И вот представьте моё удивление, когда на моём ПЛК Amsamotion AMX-200CN переход выполняется, а в вершине стека при этом логический ноль. Взаимоисключающие параграфы сие называется. Я начал разбираться и выяснил, что, оказывается, не всем операторам одинаково везёт, как говориться. Т.е. большинство операторов спокойно игнорируются, когда оказываются между JMP и LBL при переходе, но есть операторы, которые таки выполняются! Невероятно, но факт. Смотрим.
 

Для удобства восприятия я выбрал адреса переменных похожими на адреса системных битов, т.е. в моих примерах бит M10.0 должен всегда быть равен 1 (т.е. равен SM0.0), а бит M10.1 всегда быть равен 0 (т.е. равен SM0.1, который равен нулю во всех циклах программы, кроме первого).
Я немного добавил линий, чтобы было понятно, какие команды выполняются правильно, а какие - нет (зелёные - это правильно, красные - нет).
В синей рамке находится то, что по правильному алгоритму работы программы должны быть пропущено.

Как видим на представленном выше скриншоте перед командой JMP находится команда LD SM0.0, результат которой всегда = 1, что подтверждается тут же в самой правой колонке. На скриншоте видно, что команда NOT расположена между JMP и LBL, т.е. выполняться не должна, но она таки выполняется и первое же присваивание M10.0 заканчивается записью туда не 1, а 0, поскольку произошло инвертирование, которого быть не должно.

Таким же точно глючным образом выполняются и некоторые другие команды, работающие только со стеком, а именно команды: OLD, LDS, LPS, LRD, LPP. Глючно выполняются команды LB=, LB<>, LB<, LB>, LB<= и LB>=, а также аналогичные команды для WORD (LW= и т.д.) и DWORD (LD= и т.д.). Вот пара примеров:

Команды LD, A и O, а также команды фронта EU и ED не выполняются между JMP и LBL, т.е. работают корректно:

Ну, и напоследок, есть команда, которая работает вообще непонятным образом в такой ситуации - это команда ALD. Она не просто выполнилась между JMP и LBL, хотя не должна была, но и дала результат равный логическому нулю, несмотря на то, что в обоих первых уровнях стека были единицы. Вот гляньте, картина маслом:

Контроллер команду ALD выполняет нормально в обычной ситуации, чему также даю подтверждение:

 В общем и целом, хочу заметить, что для написания новых программ тут нет проблемы: обойти эти препятствия нет никакой сложности. Совсем другое дело, если требуется использовать контроллер вместо уже существующего оригинального Siemens как резерв. Да, можно сказать, что вероятность, что результат работы будет иным, не так и велика. Но у меня, лично, в программе нашлось аж две функции, а всего три конкретных места кода, которые пришлось исправить. Т.е. если кто-то на предприятиях, где находятся мои программы с этими функциями в ПЛК Siemens S7-200 решит заменить эти контроллеры на Amsamotion или Gipeng, то, в лучшем случае, алгоритм не будет работать, а в худшем даже и не знаю.

Более-менее застрахованы от проявления глюка те, кто использует более примитивные языки LAD и FBD, поскольку интерпретатор, автоматически переводящий в STL, не осуществляет особо сильной оптимизации, т.е. не заботиться о более рациональном использовании стека, поэтому вероятность проблем меньше, хотя они и не исключены.
Кроме того, не застрахованы также и те, кто использует функции от Siemens, поскольку гипотетически и они могут содержать небезопасный код. Я бы рекомендовал, на всякий случай, распароливать функции от Siemens (смотри здесь) и проверять код.


Какой код можно считать небезопасным и как это проверить.

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

Условно говоря, если до оператора JMP в стеке были какие-то значения, которые будут использоваться после команды LBL путём вызова команд A, O, LPP, LRD, LDS, NOT, EU, ED и др., то надо до оператора JMP выполнить присвоение значений стека определённым битам (желательно тем, которые больше в программе нигде не участвуют), а после команды LBL изменить код так, чтобы использовать эти самые биты, а не стек. Да, это будет дольше выполняться (хоть этого никто и не заметит), будет менее рационально, но зато обезопасит всех от потенциальных проблем с китайскими ПЛК. Операторы, использующие стек и меняющие его значение, расположенные между JMP и LBL, имеют право на существование, поскольку, если JMP не выполнится, то их выполнение не будет иметь проблем, однако, важно понимать, что использования этих значений после LBL не должно быть, или же эти значения еще до оператора LBL нужно присвоить каким-то битам памяти.
Вот примитивный пример:

 
Как видим, выполнялась команда LPP, которая не должна была выполняться, и результат, записанный в M10.2, оказался рассчитан неправильным образом. Исправить это можно так:

Ну, я думаю, что все понимают, что речь идёт об абстрактном примере, поэтому в нём значение M10.0 присваивается биту M20.0, естественно, что можно это упростить, просто это не делается именно потому что предполагаются гораздо более сложные алгоритмы, где подобное упрощение не будет возможно.

Проблема с прямой адресацией на S7-1200

Как известно, TIA Portal использует косвенную адресацию, но, одновременно с этим, не запрещена и прямая адресация. Для этого в Data Block надо просто снять галочку в разделе Attributes под названием Optimized block access (это для версии TIA Portal V13 SP1).

В общем и целом адресация пародирует S7-200, только нет привычных нормальных команд (типа ANDB и т.д.), приходится обходиться тем, что есть в языке SCL.
Однако, и с этим оказались проблемы.

Описание проблемы я разместил на сайте Siemens.

Вот вам русское описание этого примера.

Я создал data block DB1 с именем "HMI_DB". Добавил в него 4 переменных:

var1  Real  DB1.DBD0 
var2  Real  DB1.DBD4
var3  Word  DB1.DBW8
var4  Word  DB1.DBW10
 
Я хочу использовать HMI_DB.var3 и HMI_DB.var4 как буфер для моих операций пересылки байтов.
В частности, данная операция востребована при приёме и дальнейшем использовании данных по интерфейсу RS485, где данные принимаются по количеству слов данных.

Итак, я хочу передать два слова данных из HMI_DB.var1 в два отдельных слова HMI_DB.var3 и  HMI_DB.var4, затем я хочу передать результат из var3 и var4 в переменную var2:

"HMI_DB".var1 := 24.7; // (для примера), это 16#41C5_999A
-------------
%DB1.DBW8 := %DB1.DBW0; // 16#41C5
%DB1.DBW10 := %DB1.DBW2; // 16#999A
%DB1.DBD4 := %DB1.DBD8; // (oops!) 16#4E83_8B33



Нежданчик! Программа автоматически конвертировала (DINT_TO_REAL), хотя никто этого не просил, значение 16#41C5_999A (что является 1,103,468,954 в DEC-формате) в 16#4E83_8B33 (что является 1.103469e+009 в Real-формате).
 

Если я напишу таким образом, то всё работает нормально:

%DB1.DBW4 := %DB1.DBW8;
%DB1.DBW6 := %DB1.DBW10;

Вот такая интересная система конвертации в TIA Portal, т.е. среда разработки как бы "знает", что %DB1.DBD4 имеет тип Real. Какая умная среда разработки, правда? Да, не совсем. Попробуем написать вот такое присвоение:

%DB1.DBD0 := 24.7;

И что мы видим? На такую запись компилятор отругался следующим сообщением:

Datatype "LReal" cannot be converted implicitly to datatype "DWord".

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

В обсуждении на форуме Siemens разъясняют, что компилятор просто не умеет автоматически преобразовывать LReal в DWord, т.е. число с плавающей точкой компилятор всегда понимает как LReal, а если его присваивают переменной типа Real, то автоматом происходит преобразование LREAL_TO_REAL. Таким образом, для присвоения DWord дробного числа требуется два поочерёдного преобразования: LREAL_TO_REAL, а затем - REAL_TO_DINT, чего компилятор делать автоматически не умеет.

Панель быстрого запуска в Windows 7

Как известно, корпорация Microsoft, начиная с Windows Vista, последовательно ухудшает интерфейс операционной системы, который в совершенном виде присутствовал в Windows XP и не требовал никаких изменений. В настоящее время (ноябрь 2017 года) единственной приемлемой для работы операционной системой является Windows 7 SP1. Несмотря на изуродованный интерфейс, его можно преобразить до уровня Windows XP, используя Classic Shell.

Однако, вернувшись в нормальный классический вид, я обнаружил, что панель быстрого запуска работает как-то странно: значки ярлыков, расположенные слева от панели задач пропадают сразу после запуска соответствующего приложения, а если уже были открытые окна, то новые, вызванные через панель быстрого запуска, добавляются в панель задач не справа, как положено, а на том месте, где располагается ярлык вызова.
Оказалось, что это никакая не панель быстрого запуска, а всё то же продолжение панели задач, на которую тоже можно добавлять ярлыки. А панель быстрого запуска в WIndows 7 вообще отсутствует. Но её можно организовать, делается это просто:

1. Правой кнопкой мыши на панели задач, в выпадающем меню выбираем Панели -> Создать панель инстументов...


2. В появившемся диалоговом окне ввести в нижней строке

%AppData%\Microsoft\Internet Explorer\Quick Launch

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

3. Правой кнопкой мыши на панели задач, в выпадающем меню снимаем галочку с пункта "Закрепить панель задач"

4. Правой кнопкой мыши по надписи "Quick Launch", снимаем галочки с пунктов "Показывать подписи" и "Показывать заголовки" (любители ублюдочного "ленточного" интерфейса последнюю галку могут не снимать)

5. Левой кнопкой мыши за вертикальную линию (слева от ярлыков) перемещаем наш раздел с ярлыками на удобную позицию на экране (рядом с кнопкой "Пуск", конечно же).

6. Правой кнопкой мыши на панели задач, в выпадающем меню ставим галочку на пункте "Закрепить панель задач"

Отключить встроенный автоматический просмотр PDF в Firefox

давно раздражает совершенно ненужная функция браузера - просмотр pdf. Раздражает, потому что ни в одном браузере эта функция пока не реализована по-человечески, постоянно всё тормозит, глючит и ни в какое сравнение с просмотром в нормальном просмотрщике (читай - Foxit Reader'e) ни идёт. Это касается как встроенный плагинов, так и внешних. Причем внешние плагины легко отключаются, как известно, а встроенные через одно место. Ну, в частности, для отключения ненужной функции просмотра pdf в Firefox нужно следующее:

1. открыть страницу about:config

2. найти пункт pdfjs.disabled

3. установить его в состояние true

Проблема с WinCC Flexible - перестали открываться проекты

Несколько лет назад была у меня проблема с WinCC Flexible 2008 SP3 касательно того, что проект во время открытия вдруг переставал загружаться (т.е. ProgressBar на экране доходил примерно до середины - и arrivederci). Тут намедни возникла всё та же проблема, только с WinCC Flexible Smart. Видимо у них это общая болезнь, поэтому не лишним будет вспомнить способ исцеления, а именно сброс настроек WInCc Flexible.

Итак, удаляем вот эти папки и всё:
C:\Documents and Settings\All Users\Application Data\SIEMENS AG\SIMATIC WinCC flexible ХХХ
C:\Documents and Settings\USER NAME\Application Data\SIEMENS AG\SIMATIC WinCC flexible ХХХ
C:\Documents and Settings\USER NAME\Local Settings\Application Data\SIEMENS AG\SIMATIC WinCC flexible ХХХ
(вместо "ХХХ" будет конкретная версия программы)

У меня в связи с этим всплыл ещё один нюанс. Как известно, Microsoft с некоторых пор зачем-то озаботился никому не нужной безопасностью в Windows (никому не нужной, потому что те, кому нужна безопасность, Windows'ом не пользуется), и напридумывал всяких ограничений по доступу к файлам. Т.е. попытка открыть папку "Documents and Settings" приводила к сообщению, что отказано в доступе. Не оказалось проблемой это обойти, но не лишним будет вспомнить, как сие делается:

1. Заходим в свойства папки, вкладка "Безопасность", жмём кнопку "Дополнительно"



2. В окрывшемся окне выбираем вкладку "Владелец" и меняем его на себя, конечно же