Весельчак У - Вклад участника [ru]

FAQ:STL:C++ сериализация данных

2015-08-03T22:41:35Z

RXL:

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

Говоря о сериализации, я подразумеваю механизмы перевода некоторого класса, структуры или набора переменных в определённый формат (бинарный, текстовый, XML, HTML и т.д.), а также сам процесс перевода. Десериализация - процессы и механизмы, обратные сериализации (восстановление состояния из внешнего источника).

Самый простой способ, к которому чаще всего прибегают молодые программисты, - это простое копирование памяти в файл или еще куда-то. Т.е. берём указатель на класс/структуру/переменную и копируем N байт в файл. Пример: <syntaxhighlight lang="cpp">
.......
MyClass m;
..............
std::ofstream f("dump.bin", std::binary);
f.write(&m, sizeof(m));
f.close();
........................
</syntaxhighlight>

Но этот метод сериализации имеет ряд ограничений и недостатков:

*Допустимо использовать только для POD-структур (POD - Plain Old Data) и встроенных типов. Почему, будет понятно из следующих пунктов.
*Если программистом описан конструктор, то компилятор вправе в класс добавить какие-то свои вспомогательные переменные, что превращает класс в не POD-структуру, на самом деле это не так страшно, но формально это так.
*При сохранении указателей членов класса будут скопированы только адреса, хранимые указателями и, естественно, класс с указателями это не POD-тип
*Если в классе объявленные виртуальные функции (или он унаследован от класса содержащего виртуальные функции), это приводит к тому, что класс будет дополнен указателем на таблицу виртуальных функций, и с этим указателем та же проблема, что и со всеми другими. Опять же не POD-тип.
*Если ваш класс содержит внутри себя не POD типы или унаследован от не POD-типа, то ваш класс тоже не под тип, т.е. нет никакой гарантии, что копирование куска памяти позволит постановить состояние класса.
*Различное выравнивание данных внутри класса может сделать невозможным перенос сохранённого класса на другую платформу или даже в программу, скомпилированную с другими параметрами компиляции.
*Различный порядок байт не позволит переносить данные между такими платформами, как: x86 и PowerPC
*И такая сериализация не даёт сохранить в удобочитаемой форме XML, текст или CSV

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

Как только программист задумывается о сериализации данных, ему сразу же хочется выполнять сериализацию всего парой строк кода: легко и изящно, например, так: <syntaxhighlight lang="cpp">
// вывести состояние класса и всех его членов.
std::cout << myClass;

// загрузить состояние класса из XML
myXML >> myClass;
</syntaxhighlight>

И, естественно, самый простой способ быстро добиться результата - это использовать "велосипед", написанный другими. "Велосипед" возьмём хороший, многофункциональный. Он умеет выполнять сериализацию и десериализацию стандартных контейнеров, классов, указателей, ссылок и еще чего-то. Также он умеет сохранять, работать с различными форматами выходных данных: бинарный, текст, XML. Если очень хочется, то он может сохранить не только в поток, но и куда угодно, например, в вектор или в сокет или выкинуть в пропасть.

Полное описание "велосипеда": http://www.boost.org/doc/libs/1_36_0/libs/serialization/doc/index.html

Вот пример использования (взято из описания):

<syntaxhighlight lang="cpp">
/////////////////////////////////////////////////////////////
// gps координаты
//
// illustrates serialization for a simple type
//
class gps_position
{
private:
friend class boost::serialization::access;
// When the class Archive corresponds to an output archive, the
// & operator is defined similar to <<. Likewise, when the class Archive
// is a type of input archive the & operator is defined similar to >>.
template<class Archive>
void serialize(Archive & ar, const unsigned int version)
{
ar & degrees;
ar & minutes;
ar & seconds;
}
int degrees;
int minutes;
float seconds;
public:
gps_position(){};
gps_position(int d, int m, float s) :
degrees(d), minutes(m), seconds(s)
{}
};

int main() {
// create and open a character archive for output
std::ofstream ofs("filename");

// create class instance
const gps_position g(35, 59, 24.567f);

// save data to archive
{
boost::archive::text_oarchive oa(ofs);
// write class instance to archive
oa << g;
// archive and stream closed when destructors are called
}

// ... some time later restore the class instance to its orginal state
gps_position newg;
{
// create and open an archive for input
std::ifstream ifs("filename");
boost::archive::text_iarchive ia(ifs);
// read class state from archive
ia >> newg;
// archive and stream closed when destructors are called
}
return 0;
}
</syntaxhighlight>

Теперь по пунктам, как это работает:

#Создаём внутри нашего класса метод serialize, получаем ссылку на архив и номер версии(можно по-разному сериализовать в зависимости от версии), если метод приватный, то добавляем в друзья class boost::serialization::access. Метод serialize будет вызываться при сериализации и десериализации.
#Открываем файл и создаём архив (text_oarchive текстовый выходной архив), в нашем случае текстовый, архив - это тот самый класс, который выполняет основную работу.
#Вызываем всеми любимый оператор << - этот оператор вызывает метод serialize для классов или же внешние функции(они идут в комплекте) для встроенных типов и стандартных контейнеров.
#text_oarchive::operator<< вызвал наш метод serialize и передал вовнутрь себя, тут возникает вопрос: почему внутри serialize используется оператор &, а не <<? Ответ: потому что у выходного архива операторы & и << по сути это одно и тоже, у входного операторы & и >> - одно и тоже. Т.е. ничто не мешает в коде поменять "ia >> newg;" на "ia & newg;".
#Если нужно изменить метод сериализации, достаточно поменять тип архива (для XML архива придётся сделать еще некоторою работу в методе serialize).

На этом, в общем-то, работа по поддержке сериализации закончена.

При желании, можно разделить методы для сериализации и десериализации. Кстати, boost::seralization гарантирует, что порядок байт при сериализации будет изменён, если потребуется, так что можно спокойно передать long с x86 на PowerPC.

Немного поправленный пример использования и результаты работы:

<syntaxhighlight lang="cpp">
#include "stdafx.h"
#include <iostream>
#include <fstream>
#include <string>
#include <fstream>
#include <vector>

// include headers that implement a archive in simple text format
#include <boost/archive/text_oarchive.hpp>
#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/binary_iarchive.hpp>
#include <boost/archive/binary_oarchive.hpp>
#include <boost/archive/xml_iarchive.hpp>
#include <boost/archive/xml_oarchive.hpp>
// включаем, чтобы сериализация работала с векторами
#include <boost/serialization/vector.hpp>
// включаем, чтобы нормально проходила сериализация XML
#include <boost/serialization/nvp.hpp>

class gps_position
{
private:
friend class boost::serialization::access;

template<class Archive>
void serialize(Archive & ar, const unsigned int version)
{
// то же, что и make_nvp, только имя параметра выводится в макросе
ar & BOOST_SERIALIZATION_NVP(degrees);
ar & BOOST_SERIALIZATION_NVP(minutes);
ar & BOOST_SERIALIZATION_NVP(seconds);
}
int degrees;
int minutes;
float seconds;
public:
gps_position(){};
gps_position(int d, int m, float s) :
degrees(d), minutes(m), seconds(s)
{}
};

template<typename TIArch, typename TOArch, typename TClass>
void TestArch(const std::string & file, int flags, const TClass & cont)
{

{ // Сериализуем
std::ofstream ofs(file.c_str(), std::ios::out|flags);
TOArch oa(ofs);
// make_nvp создаёт пару имя-значение, которая отразится в XML
// если не используем XML архив, то можно пару не создавать
oa << boost::serialization::make_nvp("Test_Object", cont);
}

TClass newg;
{ // Десериализуем
std::ifstream ifs(file.c_str(), std::ios::in|flags);
TIArch ia(ifs);
ia >> boost::serialization::make_nvp("Test_Object",newg);
}

{ // Еще раз сериализуем, чтобы потом сравнить результаты двух сериализаций
// и убедиться, что десериализациия прошла корректно
std::ofstream ofs((file+".tmp").c_str(), std::ios::out|flags);
TOArch oa(ofs);
oa << boost::serialization::make_nvp("Test_Object", cont);
}
}

int _tmain(int argc, _TCHAR* argv[])
{
std::ofstream ofs("filename");

std::vector<gps_position> v;
v.push_back(gps_position(35, 59, 24.567f));
v.push_back(gps_position(36, 60, 25.567f));
v.push_back(gps_position(37, 61, 26.567f));

using namespace boost::archive;
TestArch<text_iarchive, text_oarchive>("text_arch.dump", 0, v);
TestArch<binary_iarchive, binary_oarchive>("binary_arch.dump", std::ios::binary, v);
TestArch<xml_iarchive, xml_oarchive>("xml_arch.dump", 0, v);

return 0;
}
</syntaxhighlight>

Файл text_arch.dump: <pre>22 serialization::archive 3 0 0 3 0 0 35 59 24.566999 36 60 25.566999 37 61 26.566999
</pre>

Как видите, использование NVP никак не отразилось на внешнем виде архива.

Файл xml_arch.dump: <syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="3">
<Test_Object class_id="0" tracking_level="0" version="0">
<count>3</count>
<item class_id="1" tracking_level="0" version="0">
<degrees>35</degrees>
<minutes>59</minutes>
<seconds>24.566999</seconds>
</item>
<item>
<degrees>36</degrees>
<minutes>60</minutes>
<seconds>25.566999</seconds>
</item>
<item>
<degrees>37</degrees>
<minutes>61</minutes>
<seconds>26.566999</seconds>
</item>
</Test_Object>
</boost_serialization>
</syntaxhighlight>

Бинарный архив приводить не стану :) не очень красочно, но занимает он 79 байт, из которых 39 - заголовок и 40 - полезная информация.

<br>

За универсальность boost::serialization придётся заплатить:

*Во время компиляции шаблоны могут разворачиваться довольно долго.
*Скорость: стек вызовов для сериализации какой-нибудь не слишком больной структурки, может быть просто ужасающим - вызовов 20-30.

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

<br> Надеюсь, в общих чертах понятно, как примерно работает сериализация и десериализация, и если понадобится, можно реализовать свою сериализацию.

<br> Вот пример своей реализации архива, который я использую вместо boost:binary_iarchive (была ОЧЕНЬ важна скорость, а универсальность не очень, но для маршалинга хватает), делал так, чтобы можно было использовать один вместо другого без переделки кода:

<syntaxhighlight lang="cpp">
class binary_iarchive
{
public:
typedef serialization::container container;
typedef container::iterator iterator;

container &cont_;
size_t currentPos_;
typedef boost::mpl::bool_<false> is_saving;
binary_iarchive(container & cont, long = 0)
: cont_(cont)
, currentPos_(0)
{
}

template<typename T>
binary_iarchive & operator>>(T & val)
{
deserialize_impl(val);
return *this;
}

void reset()
{
resetPos();
cont_.clear();
}

template<typename T>
inline void raw_read(T beginPos, size_t len)
{
if (static_cast<size_t>(cont_.size() - currentPos_) < len)
throw std::runtime_error("No more data");

iterator pos = cont_.begin() + currentPos_;
iterator endPos = pos + len;
std::copy(pos, endPos, beginPos);
currentPos_ = currentPos_ + len;
}
private:
// Fundamental
template<typename T>
inline void deserialize_impl(T & val, typename boost::enable_if<boost::is_fundamental<T> >::type* dummy = 0)
{
raw_read(reinterpret_cast<char*>(&val), sizeof(T));
}

//Classes
template<typename T>
inline void deserialize_impl(T & val, typename boost::enable_if<boost::is_class<T> >::type* dummy = 0)
{
deserialize_class(*this, val);
}
};
</syntaxhighlight>

Кое-что порезал, чтобы не расслаблялись :)

[[Category:FAQ]] [[Category:FAQ:ANSI_CPP]] [[Category:FAQ:STL]] [[Category:FAQ:STL_BOOST]]

FAQ:STL:C++ сериализация данных

2015-08-03T22:40:59Z

RXL:

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

Говоря о сериализации, я подразумеваю механизмы перевода некоторого класса, структуры или набора переменных в определённый формат (бинарный, текстовый, XML, HTML и т.д.), а также сам процесс перевода. Десериализация - процессы и механизмы, обратные сериализации (восстановление состояния из внешнего источника).

Самый простой способ, к которому чаще всего прибегают молодые программисты, - это простое копирование памяти в файл или еще куда-то. Т.е. берём указатель на класс/структуру/переменную и копируем N байт в файл. Пример: <syntaxhighlight lang="cpp">
.......
MyClass m;
..............
std::ofstream f("dump.bin", std::binary);
f.write(&m, sizeof(m));
f.close();
........................
</syntaxhighlight>

Но этот метод сериализации имеет ряд ограничений и недостатков:

*Допустимо использовать только для POD-структур (POD - Plain Old Data) и встроенных типов. Почему, будет понятно из следующих пунктов.
*Если программистом описан конструктор, то компилятор вправе в класс добавить какие-то свои вспомогательные переменные, что превращает класс в не POD-структуру, на самом деле это не так страшно, но формально это так.
*При сохранении указателей членов класса будут скопированы только адреса, хранимые указателями и, естественно, класс с указателями это не POD-тип
*Если в классе объявленные виртуальные функции (или он унаследован от класса содержащего виртуальные функции), это приводит к тому, что класс будет дополнен указателем на таблицу виртуальных функций, и с этим указателем та же проблема, что и со всеми другими. Опять же не POD-тип.
*Если ваш класс содержит внутри себя не POD типы или унаследован от не POD-типа, то ваш класс тоже не под тип, т.е. нет никакой гарантии, что копирование куска памяти позволит постановить состояние класса.
*Различное выравнивание данных внутри класса может сделать невозможным перенос сохранённого класса на другую платформу или даже в программу, скомпилированную с другими параметрами компиляции.
*Различный порядок байт не позволит переносить данные между такими платформами, как: x86 и PowerPC
*И такая сериализация не даёт сохранить в удобочитаемой форме XML, текст или CSV

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

Как только программист задумывается о сериализации данных, ему сразу же хочется выполнять сериализацию всего парой строк кода: легко и изящно, например, так: <syntaxhighlight lang="cpp">
// вывести состояние класса и всех его членов.
std::cout << myClass;

// загрузить состояние класса из XML
myXML >> myClass;
</syntaxhighlight>

И, естественно, самый простой способ быстро добиться результата - это использовать "велосипед", написанный другими. "Велосипед" возьмём хороший, многофункциональный. Он умеет выполнять сериализацию и десериализацию стандартных контейнеров, классов, указателей, ссылок и еще чего-то. Также он умеет сохранять, работать с различными форматами выходных данных: бинарный, текст, XML. Если очень хочется, то он может сохранить не только в поток, но и куда угодно, например, в вектор или в сокет или выкинуть в пропасть.

Полное описание "велосипеда": http://www.boost.org/doc/libs/1_36_0/libs/serialization/doc/index.html

Вот пример использования (взято из описания):

<syntaxhighlight lang="cpp">
/////////////////////////////////////////////////////////////
// gps координаты
//
// illustrates serialization for a simple type
//
class gps_position
{
private:
friend class boost::serialization::access;
// When the class Archive corresponds to an output archive, the
// & operator is defined similar to <<. Likewise, when the class Archive
// is a type of input archive the & operator is defined similar to >>.
template<class Archive>
void serialize(Archive & ar, const unsigned int version)
{
ar & degrees;
ar & minutes;
ar & seconds;
}
int degrees;
int minutes;
float seconds;
public:
gps_position(){};
gps_position(int d, int m, float s) :
degrees(d), minutes(m), seconds(s)
{}
};

int main() {
// create and open a character archive for output
std::ofstream ofs("filename");

// create class instance
const gps_position g(35, 59, 24.567f);

// save data to archive
{
boost::archive::text_oarchive oa(ofs);
// write class instance to archive
oa << g;
// archive and stream closed when destructors are called
}

// ... some time later restore the class instance to its orginal state
gps_position newg;
{
// create and open an archive for input
std::ifstream ifs("filename");
boost::archive::text_iarchive ia(ifs);
// read class state from archive
ia >> newg;
// archive and stream closed when destructors are called
}
return 0;
}
</syntaxhighlight>

Теперь по пунктам, как это работает:

#Создаём внутри нашего класса метод serialize, получаем ссылку на архив и номер версии(можно по-разному сериализовать в зависимости от версии), если метод приватный, то добавляем в друзья class boost::serialization::access. Метод serialize будет вызываться при сериализации и десериализации.
#Открываем файл и создаём архив (text_oarchive текстовый выходной архив), в нашем случае текстовый, архив - это тот самый класс, который выполняет основную работу.
#Вызываем всеми любимый оператор << - этот оператор вызывает метод serialize для классов или же внешние функции(они идут в комплекте) для встроенных типов и стандартных контейнеров.
#text_oarchive::operator<< вызвал наш метод serialize и передал вовнутрь себя, тут возникает вопрос: почему внутри serialize используется оператор &, а не <<? Ответ: потому что у выходного архива операторы & и << по сути это одно и тоже, у входного операторы & и >> - одно и тоже. Т.е. ничто не мешает в коде поменять "ia >> newg;" на "ia & newg;".
#Если нужно изменить метод сериализации, достаточно поменять тип архива (для XML архива придётся сделать еще некоторою работу в методе serialize).

На этом, в общем-то, работа по поддержке сериализации закончена.

При желании, можно разделить методы для сериализации и десериализации. Кстати, boost::seralization гарантирует, что порядок байт при сериализации будет изменён, если потребуется, так что можно спокойно передать long с x86 на PowerPC.

Немного поправленный пример использования и результаты работы:

<syntaxhighlight lang="cpp">
#include "stdafx.h"
#include <iostream>
#include <fstream>
#include <string>
#include <fstream>
#include <vector>

// include headers that implement a archive in simple text format
#include <boost/archive/text_oarchive.hpp>
#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/binary_iarchive.hpp>
#include <boost/archive/binary_oarchive.hpp>
#include <boost/archive/xml_iarchive.hpp>
#include <boost/archive/xml_oarchive.hpp>
// включаем, чтобы сериализация работала с векторами
#include <boost/serialization/vector.hpp>
// включаем, чтобы нормально проходила сериализация XML
#include <boost/serialization/nvp.hpp>

class gps_position
{
private:
friend class boost::serialization::access;

template<class Archive>
void serialize(Archive & ar, const unsigned int version)
{
// то же, что и make_nvp, только имя параметра выводится в макросе
ar & BOOST_SERIALIZATION_NVP(degrees);
ar & BOOST_SERIALIZATION_NVP(minutes);
ar & BOOST_SERIALIZATION_NVP(seconds);
}
int degrees;
int minutes;
float seconds;
public:
gps_position(){};
gps_position(int d, int m, float s) :
degrees(d), minutes(m), seconds(s)
{}
};

template<typename TIArch, typename TOArch, typename TClass>
void TestArch(const std::string & file, int flags, const TClass & cont)
{

{ // Сериализуем
std::ofstream ofs(file.c_str(), std::ios::out|flags);
TOArch oa(ofs);
// make_nvp создаёт пару имя-значение, которая отразится в XML
// если не используем XML архив, то можно пару не создавать
oa << boost::serialization::make_nvp("Test_Object", cont);
}

TClass newg;
{ // Десериализуем
std::ifstream ifs(file.c_str(), std::ios::in|flags);
TIArch ia(ifs);
ia >> boost::serialization::make_nvp("Test_Object",newg);
}

{ // Еще раз сериализуем, чтобы потом сравнить результаты двух сериализаций
// и убедиться, что десериализациия прошла корректно
std::ofstream ofs((file+".tmp").c_str(), std::ios::out|flags);
TOArch oa(ofs);
oa << boost::serialization::make_nvp("Test_Object", cont);
}
}

int _tmain(int argc, _TCHAR* argv[])
{
std::ofstream ofs("filename");

std::vector<gps_position> v;
v.push_back(gps_position(35, 59, 24.567f));
v.push_back(gps_position(36, 60, 25.567f));
v.push_back(gps_position(37, 61, 26.567f));

using namespace boost::archive;
TestArch<text_iarchive, text_oarchive>("text_arch.dump", 0, v);
TestArch<binary_iarchive, binary_oarchive>("binary_arch.dump", std::ios::binary, v);
TestArch<xml_iarchive, xml_oarchive>("xml_arch.dump", 0, v);

return 0;
}
</syntaxhighlight>

Файл text_arch.dump: <pre>
22 serialization::archive 3 0 0 3 0 0 35 59 24.566999 36 60 25.566999 37 61 26.566999
</pre>

Как видите, использование NVP никак не отразилось на внешнем виде архива.

Файл xml_arch.dump: <syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="3">
<Test_Object class_id="0" tracking_level="0" version="0">
<count>3</count>
<item class_id="1" tracking_level="0" version="0">
<degrees>35</degrees>
<minutes>59</minutes>
<seconds>24.566999</seconds>
</item>
<item>
<degrees>36</degrees>
<minutes>60</minutes>
<seconds>25.566999</seconds>
</item>
<item>
<degrees>37</degrees>
<minutes>61</minutes>
<seconds>26.566999</seconds>
</item>
</Test_Object>
</boost_serialization>
</syntaxhighlight>

Бинарный архив приводить не стану :) не очень красочно, но занимает он 79 байт, из которых 39 - заголовок и 40 - полезная информация.

<br>

За универсальность boost::serialization придётся заплатить:

*Во время компиляции шаблоны могут разворачиваться довольно долго.
*Скорость: стек вызовов для сериализации какой-нибудь не слишком больной структурки, может быть просто ужасающим - вызовов 20-30.

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

<br> Надеюсь, в общих чертах понятно, как примерно работает сериализация и десериализация, и если понадобится, можно реализовать свою сериализацию.

<br> Вот пример своей реализации архива, который я использую вместо boost:binary_iarchive (была ОЧЕНЬ важна скорость, а универсальность не очень, но для маршалинга хватает), делал так, чтобы можно было использовать один вместо другого без переделки кода:

<syntaxhighlight lang="cpp">
class binary_iarchive
{
public:
typedef serialization::container container;
typedef container::iterator iterator;

container &cont_;
size_t currentPos_;
typedef boost::mpl::bool_<false> is_saving;
binary_iarchive(container & cont, long = 0)
: cont_(cont)
, currentPos_(0)
{
}

template<typename T>
binary_iarchive & operator>>(T & val)
{
deserialize_impl(val);
return *this;
}

void reset()
{
resetPos();
cont_.clear();
}

template<typename T>
inline void raw_read(T beginPos, size_t len)
{
if (static_cast<size_t>(cont_.size() - currentPos_) < len)
throw std::runtime_error("No more data");

iterator pos = cont_.begin() + currentPos_;
iterator endPos = pos + len;
std::copy(pos, endPos, beginPos);
currentPos_ = currentPos_ + len;
}
private:
// Fundamental
template<typename T>
inline void deserialize_impl(T & val, typename boost::enable_if<boost::is_fundamental<T> >::type* dummy = 0)
{
raw_read(reinterpret_cast<char*>(&val), sizeof(T));
}

//Classes
template<typename T>
inline void deserialize_impl(T & val, typename boost::enable_if<boost::is_class<T> >::type* dummy = 0)
{
deserialize_class(*this, val);
}
};
</syntaxhighlight>

Кое-что порезал, чтобы не расслаблялись :)

[[Category:FAQ]] [[Category:FAQ:ANSI_CPP]] [[Category:FAQ:STL]] [[Category:FAQ:STL_BOOST]]

Портал Shelek

2015-08-01T15:37:37Z

RXL:

__NOTOC__

# <h3>[http://shelek.ru/ Портал программистов Shelek]</h3>
## <h4>[http://club.shelek.ru/ Клуб программистов "Весельчак У".]</h4> На этом сайте мы размещаем статьи наших авторов, новости Клуба, полезные файлы (например, у нас хорошая коллекция [http://club.shelek.ru/viewfiles.php?id=2 Windows DDK] и [http://club.shelek.ru/viewfiles.php?id=3 патчи для Borland C++ Builder]), [http://club.shelek.ru/viewfiles.php?id=7 книги по программированию], каталог полезных ссылок и [http://club.shelek.ru/viewblog.php лента новостей] о программировании и смежным областям.
## <h4>[http://forum.shelek.ru/ Форум Клуба программистов.]</h4> Здесь находится наш форум. У нас 116 разделов (большинству пользователей доступны более 100) с тематикой программирование, администрирование, начинающим, общение, самоуправление и многое другое. Каждый может себе найти тематику по вкусу.
## <h4>[http://wiki.shelek.ru/ Википедия Клуба программистов.]</h4> Вы как раз находитесь на этом сайте. Движок MediaWiki оказался удобным и гибким для создания множества небольших статей по принципу [[FAQ:Содержание|FAQ]]. Вы можете дополнить его, [[Служебная:Userlogin|зарегистрировавшись]] на нашем сайте (редакторский доступ выдается лично администраторами).
## <h4>[http://forum.shelek.ru/gallery/ Фотогалерея Клуба программистов.]</h4> Здесь находятся фотографии членов нашего Клуба, фотоотчеты наших встреч и личные альбомы.
## <h4>[http://svn.shelek.su/ Сервер SVN.]</h4> Система контроля версий Subversion. Здесь располагаются открытые и закрытые проекты членов клуба.
## <h4>[http://projects.shelek.su/ Сервер проектов.]</h4> Баг-трекер на движке Redmine. Здесь расположены проекты членов клуба.
# <h3>Сайты программ и проектов</h3>
## <h4>[http://dib.shelek.ru/ Сайт Delphi & Interbase.]</h4> Сайт о программировании на Delphi под СУБД Interbase.
## <h4>[http://faq.shelek.ru/ Сайт программы FAQ-Builder.]</h4> К сожалению, автор забросил разработку программы. Может вам было бы интересно продолжить проект?
## <h4>[http://dupsystem.shelek.ru/ Сайт проекта DUpSystem.]</h4> Пока сайт в разработке.

[[Category:Портал]]

Портал Shelek

2015-08-01T15:37:14Z

RXL:

__NOTOC__

# <h3>[http://shelek.ru/ Портал программистов Shelek]</h3>
## <h4>[http://club.shelek.ru/ Клуб программистов "Весельчак У".]</h4> На этом сайте мы размещаем статьи наших авторов, новости Клуба, полезные файлы (например, у нас хорошая коллекция [http://club.shelek.ru/viewfiles.php?id=2 Windows DDK] и [http://club.shelek.ru/viewfiles.php?id=3 патчи для Borland C++ Builder]), [http://club.shelek.ru/viewfiles.php?id=7 книги по программированию], каталог полезных ссылок и [http://club.shelek.ru/viewblog.php лента новостей] о программировании и смежным областям.
## <h4>[http://forum.shelek.ru/ Форум Клуба программистов.]</h4> Здесь находится наш форум. У нас 116 разделов (большинству пользователей доступны более 100) с тематикой программирование, администрирование, начинающим, общение, самоуправление и многое другое. Каждый может себе найти тематику по вкусу.
## <h4>[http://wiki.shelek.ru/ Википедия Клуба программистов.]</h4> Вы как раз находитесь на этом сайте. Движок MediaWiki оказался удобным и гибким для создания множества небольших статей по принципу [[FAQ:Содержание|FAQ]]. Вы можете дополнить его, [[Служебная:Userlogin|зарегистрировавшись]] на нашем сайте (редакторский доступ выдается лично администраторами).
## <h4>[http://forum.shelek.ru/gallery/ Фотогалерея Клуба программистов.]</h4> Здесь находятся фотографии членов нашего Клуба, фотоотчеты наших встреч и личные альбомы.
## <h4>[http://svn.shelek.su/ Сервер SVN.]</h4> Система контроля версий Subversion. Здесь располагаются открытые и закрытые проекты членов клуба.
## <h4>[http://project.shelek.su/ Сервер проектов.]</h4> Баг-трекер на движке Redmine. Здесь расположены проекты членов клуба.
# <h3>Сайты программ и проектов</h3>
## <h4>[http://dib.shelek.ru/ Сайт Delphi & Interbase.]</h4> Сайт о программировании на Delphi под СУБД Interbase.
## <h4>[http://faq.shelek.ru/ Сайт программы FAQ-Builder.]</h4> К сожалению, автор забросил разработку программы. Может вам было бы интересно продолжить проект?
## <h4>[http://dupsystem.shelek.ru/ Сайт проекта DUpSystem.]</h4> Пока сайт в разработке.

[[Category:Портал]]

RC Heli:NE Solo Pro:Описание

2015-08-01T11:33:55Z

RXL: /* Оригинальные запчасти */

{{TOC-right}}

=Микровертолет Nine Eagles Solo Pro=

[[:Category:RC_Heli:Nine_Eagles_Solo_Pro#авторы|Авторы статей]] в данной категории.

Сайт производителя: [http://nineeagle.com/product_view.asp?pid=46 NE R/C 260A]

Четырехканальный электрический микровертолет классической схемы с фиксированным шагом ОР и фиксированным ХР. Автомат перекоса [http://ru.wikipedia.org/wiki/%D0%90%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82_%D0%BF%D0%B5%D1%80%D0%B5%D0%BA%D0%BE%D1%81%D0%B0#.D0.A3.D1.81.D1.82.D1.80.D0.BE.D0.B9.D1.81.D1.82.D0.B2.D0.BE конструкции Сикорского] с микшером [http://forum.rcdesign.ru/f19/thread70404.html#post542312 Белла-Хиллера].

Основные параметры:
* Основной ротор: 190 мм
* Хвостовой ротор: 37 мм
* Взлетная масса: 27 грамм

Двигатели коллекторные. Штатный аккумулятор 120 мАч, но есть сторонние аккумуляторы (например, безымянные на 150 мАч 4.2 грамма) и колхозные подключения аккумуляторов с другими разъемами. В настроенном состоянии в висении и полете очень устойчив. Внешне похож на [[:Category:RC_Heli:E-flite_Blade_mSR|X-flite Blade mSR]], но отличается от него конструктивно. Предназначен для полетов в помещении и на открытом воздухе при скорости ветра не более 2-4 м/с.

Аппаратура управления использует радиочастотный диапазон 2.4 ГГц и не совместима с другими производителями, но совместима с другими вертолетами Nine Eagles. Подключения к компьютеру не предусмотрено (и PPM сигнал в пульте не найден). Радиус действия — 20-30 м от пульта (с ранними версиями плат управления радиус был 100-150 м).

==Варианты названия==

<p style="clear: both;"></p>
<gallery style="float: right;" perrow="3">
Image:NineEagleSoloPro_red.jpg|Nine Eagles Solo Pro
Image:NineEagleSoloPro_yellow.jpg|Nine Eagles Solo Pro II
Image:MerlinTracer90_black.jpg|Merlin Tracer 90
Image:NineEagleSOAR_blue.jpg|Nine Eagles SOAR (синий)
Image:NineEagleSOAR_yellow.jpg|Nine Eagles SOAR (желтый)
</gallery>

* Nine Eagles Solo Pro
* Nine Eagles SOAR
* Merlin Tracer 90

Фактически, название ни на что не влияет. Разные образцы вертолетов, вне зависимости от названия, могут различаться:
*Шасси: разъемом под аккумулятор (старый и новый вариант) — различаются предохранительными шлицами на разъеме (их можно срезать ножом).
*Платой управления: разные версии платы и прошивки.
*Цветом.
*Массой: измерения показывают, что белые детали немного тяжелее черных.

<p style="clear: both;"></p>

==Товарные представления==
<gallery style="float: right;">
Image:NineEagleSoloPro_RTF_in_box.jpg|RTF Deluxe Edition
</gallery>
# RTF Deluxe Edition (вертолет в сборе, пульт, 2 аккумулятора, 4 батарейки AA, инструкция, чемоданчик для переноски (Aluminum Protection Case), зарядное устройство для двух аккумуляторов, запасные лопасти ОР, часовая крестовая отвертка).
# RTF (вертолет в сборе, пульт, аккумулятор, 4 батарейки AA, инструкция).
# BNF (только вертолет в сборе, без аккумулятора и пульта).
# Запчасти.

Вариант BNF стоит дешевле, чем полный комплект запчастей.

Зарядное устройство в вариантах без чемодана не прилагается. Исключение — есть комплект BNF с зарядкой на miracle-mart.com. Другой способ зарядки — через пульт.

Для тех, кто не знает: цена заказа складывается из стоимости запчастей и доставки. Стоимость доставки зависит от веса и способа доставки. Габаритные покупки надо пересылать посылкой (parcel), мелочь можно пересылать бандеролями (обычная почта).

==Где купить==
На данный момент (2011 год) на территории СНГ цены на вертолет и запчасти в 1.5-3 раза выше, чем в онлайн магазинах или на онлайн аукционах типа eBay.com. Конечно, к стоимости покупки за рубежом надо добавить стоимость почтовой пересылки, которая сильно варьируется, в зависимости от массы, габаритов и формата и выбранной услуги пересылки, от единиц до десятков долларов США (службы скоростной доставки типа Fedex и DHL берут за свои услуги раз в десять больше, чем почта — десятки-сотни долларов). Но даже с доставкой (обычной почтой) зачастую стоимость изделий оказывается существенно ниже.

'''Список онлайн магазинов:'''
*[http://hobbyking.com/ Hobby King] (Китай, Гонконг)
*[http://miracle-mart.com/ Miracle Mart] (Китай, Гонконг)
*[http://avionix.ru/ AVIONIX] (Китай, Шеньчжень. Выставочный зал — Россия, Москва)

Также можно купить б/у на онлайн барахолках.

=Составные части=
Материалы, масса (без упаковки), живучесть и ремонтопригодность.

==Оригинальные запчасти==

<gallery perrow="2" style="float: right;">
Image:NE4210007.jpg|Автомат перекоса.<br>NE4210007
Image:NE4918001.jpg|Аккумулятор.<br>NE4918001 (старый разъем), NE4950001 (новый разъем)
Image:NE4260003.jpg|Балансирный вал.<br>NE4260003
Image:NE4260012.jpg|Ось балансирного вала.<br>NE4260012
Image:NE4260011.jpg|Вал ОР: сам вал, головка и стопорное кольцо.<br>NE4260011
Image:NE4902002.jpg|Двигатель ОР.<br>NE4902002
Image:NE4260014.jpg|Капот.<br>NE4260014 (желтый), NE4260001 (красный)
Image:NE4260010.jpg|Крепежные саморезы.<br>NE4260010
Image:NE4260015.jpg|Лопасти ОР.<br>NE4260015 (белые), NE4260002 (черные)
Image:NE4603003.jpg|Плата управления.<br>NE4603003, NE4620001, NE4616001, NE4613001
Image:NE4260009.jpg|Подшипники.<br>NE4260009
Image:NE4260005.jpg|Рама.<br>NE4260005
Image:NE4260006.jpg|Тяги и рычаги.<br>NE4260006
Image:NE4260016.jpg|Хвостовая балка в сборе.<br>NE4260016 (желтая), NE4260007 (красная)
Image:NE10126004007.jpg|Хвостовой ротор.<br>NE10126004007 (белый), NE10126001027 (черный)
Image:NE4260008.jpg|Шасси.<br>NE4260041 (белое)<br>NE4260017 (белое)<br>NE4260008 (черное)<br>NE4260039 (черное)
Image:NE10126004006.jpg|Шестерня ОР. NE10126004006
Image:NE4260020.jpg|Резинки крепления кабины.
</gallery>

Основной материал — АБС-пластик (полиакрилонитрилбутадиенстирол). Если не указано иное, то под пластиком будет подразумеваться АБС. В скобках будут указаны английские названия и каталожные номера деталей.
*'''Автомат перекоса''' (swashplate set, NE4210007). Материал — пластик, внутри — стальной шарикоподшипник. Имеет две пары рычагов с шариками подключения к микшеру — короткие и длинные. Сломать сам АП сложно, но при не аккуратном снятии тяги, можно отломить шарик на рычаге, варианты исправления, замена или ремонт. Пластик на АП отлично клеится и отломившейся Шарик (на первое время, пока ждете посылку из Китая) можно приклеить цианакриловым клеем ("суперклей"), при аккуратной склейки получается очень крепкое соединение.
*'''Аккумулятор''' (battery pack, NE4950001). Штатный: LiPo 120 мАч 1S 10С. Ресурс ограничен, зависит от качества и условий эксплуатации — обязательно нужно иметь запас.
*'''Балансирный вал или флайбар''' (flybar set, NE4260003) и его '''ось''' (fixed pin balance bar, NE4260012). Флайбар из капрона, грузики — сталь. По одним данным внутри плеч есть тонкая упругая проволока типа струны, по другим — ее нет. Материал оси — сталь. Флайбар легко гнется при сильных ударах, но частично выправляется руками. Ломается редко. Ремонт — заменой. Ось продается отдельно по 6 штук в пакете. При резких ускорениях и торможениях флайбар грузиками достает до капота и хвостовой балки.
*'''Вал ОР, стопорное кольцо и головка ОР''' (main shaft set, NE4260011). Вал — углепластиковая труба. Кольцо и головка — пластик, крепятся к валу стальными саморезами. При сильных ударах некоторые элементы головки иногда ломаются — поддается колхозному ремонту. Вал сломать сложно, но если сломается, то ремонт только заменой. Стопорное кольцо часто лопается в месте вкручивания самореза и ползает по валу, что приводит к нестабильности вертолета — лечится склейкой.
*'''Двигатель ОР''' (main-motor, NE4902002). Коллекторный. Диаметр 9 мм. Остальные параметры неизвестны. Ресурс ограничен — стоит запастись. Идет в комплекте с ведущей шестерней-пиньеном (латунь).
*'''Капот''' (canopy, NE4260043). Материал — очень тонкий пластик, фиксаторы в отверстиях резиновые. Передняя часть Капота при сильных ударах может смяться или треснуть, от ударов флайбаром иногда могут образовываться вмятины, также пластик Капота может протираться изнутри, в местах прилегания к Плате Управления. Не большие вмятины на Капоте выправляются, трещины можно устранить подклейкой изнутри обычного тонкого скотча, но слишком много скотча может утяжелить конструкцию. Так что при значительных повреждениях, рекомендуется замена поврежденного Капота на новый. Летать без капота опасно для других частей вертолета, но если вы опытный пилот, и уверены в своих навыках пилотирования, то снятием капота, можно обеспечить лишнюю минуту полета. Также при снятом Капоте центр тяжести немного сместится назад, что особенно актуально при использовании более емкого и длинного Аккумулятора (150 мАч).
*'''Крепежные саморезы''' (screw set, NE4260010). Стальные, черные. Два используются для крепления платы к раме, остальные — для ОР.
*'''Лопасти ОР''' (main rotor blade set, NE4260015). Мягкий пластик. Практически не ломаются, но от ударов образуются вмятины и зарубки. Ремонт не безопасен — только замена.
*'''Плата управления''' (receiver set, NE4616001). Модуль 5-in-1 — самый дорогой компонент вертолета. На плате маркировка "NE260A", в документации обозначен как MTX-474. Сервоприводы размещены на плате и частично (зависит от версии платы) могут быть демонтированы для ремонта. Список неисправностей длинный и зависит от версии и качества сборки. Обычно неисправность платы лечится заменой. Иногда могут выпадать разъемы к двигателям или быть некачественная пайтка проводов (брак сборки).
*'''Подшипники''' (bearing set, NE4260009). Два стальных шарикоподшипника для ОР. Вставляются в раму. Вал ОР входит со скользящей посадкой. Ресурс неизвестен.
*'''Рама''' (main frame, NE4260005). Материал — пластик. Сломать сложно. Лечится склейкой или заменой.
*'''Тяги и рычаги''' (ball linkage rod set, NE4260006). Тяги от сервоприводов на плате управления — стальные с пластиковыми наконечниками под шарики, посаженными на мелкую резьбу (регулируемая длина). Рычаги из пластика: пара рычагов от АП к качалкам, пара качалок (микшеры, крепятся на лопасти ОР), пара рычагов от флайбара к качалкам. Живучесть высокая, но при сильных авариях возможна поломка качалок и рычагов, реже — деформация тяг. Лечатся заменой, в некоторых случаях возможна склейка.
*'''Хвостовая балка в сборе''' (tail set, NE4260016). Состоит из квадратной углепластиковой трубы со стороной 1.7 мм, длинной 113 мм и внутренним отверстием диаметром 1 мм, с пропущенными внутри проводами к двигателю ХР, вертикального пластикового стабилизатора, пластикового держателя двигателя и миниатюрного коллекторного двигателя. Балку можно сломать (расщепить вдоль) — вероятно, при перехлесте с флайбаром (грузиками бьет) или при падениях, но и после этого она годна для полетов. Балка редко может выпадать из рамы — достаточно вставить назад. Стабилизатор практически не ломается, но при падениях могут возникать вмятины и зазубрины по краям, может сползать вперед по балке. Двигатель весьма недолговечен. Продается только балка в сборе.
*'''Хвостовой ротор''' (tail blade, NE10126004007). Материал — пластик. Винт прочный и на оси двигателя сидит надежно, но при поломке подлежит замене. Винт из запчастей может проскальзывать на оси двигателя — лечится приклеиванием.
*'''Шасси''' (landing skid & battery frame w/connector, NE4260041). Материал — полиэтилен. Имеет слабые места по которым часто ломается при падениях. Ремонт склейкой и усилением, либо заменой.
*'''Шестерня ОР''' (main gear, NE10126004006). Капрон. Ресурс большой, убить сложно.

Масса запчастей в граммах. Приведены данные запчастей в сборе и отдельных элементов.
Информация получена от пользователей rcdesing.ru и с сайтов онлайн магазинов. Два столбца "масса": в первом указаны данные производителя, во втором — измеренные данные.

{| border="1" cellspacing="0" cellpadding="2" style="border: 1px solid black; border-collapse: collapse;"
|- align="center"
!Наименование
!Данные производителя
!Измеренные значения *
|-
|Автомат перекоса || align="center" | || align="center" |0.96-1.00
|-
|Вал ОР|| align="center" | || align="center" |0.34
|-
|Двигатель ОР|| align="center" | || align="center" |5.10-5.27 **
|-
|Двигатель ХР|| align="center" | || align="center" |1.83 **
|-
|Капот|| align="center" | || align="center" |1.88
|-
|Лопасти ОР (белые)|| align="center" | || align="center" |2.74
|-
|Лопасти ОР (черные)|| align="center" | || align="center" |2.51-2.60
|-
|Плата управления (2010-1-20)|| align="center" | || align="center" |4.29
|-
|Подшипники вала ОР (пара)|| align="center" | || align="center" |0.42
|-
|Рама|| align="center" | || align="center" |1.25-1.36
|-
|Тяги и рычаги || align="center" | || align="center" |0.45-0.48
|-
|Флайбар || align="center" | || align="center" |1.75-1.77
|-
|Хвостовая балка в сборе || align="center" | || align="center" |2.78-2.81
|-
|Хвостовой ротор (белый)|| align="center" | || align="center" |0.17
|-
|Хвостовой ротор (черный)|| align="center" | || align="center" |0.15
|-
|Хвостовой стабилизатор|| align="center" | || align="center" |0.27
|-
|Шасси|| align="center" | || align="center" |1.54
|-
|Шестерня ОР || align="center" | || align="center" |0.50-0.51
|}

''* Измеренные значения зависят от точности использованных приборов. Возможная погрешность — не более 0.05 грамм.''

''** Взвешивание двигателей затруднено из-за их намагниченности. Возможны погрешности.''

<p style="clear: both;"></p>

==Аккумуляторы==

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

Помимо штатного 120 мАч (NE-B918), в тот же разъем входит аккумулятор того же производителя емкостью 150 мАч (NE-BA925). Для подключения других аккумуляторов придется придумывать крепление и подключение.

Ниже в таблице даны данные стоковых и некоторых сторонних аккумуляторов.

{| border="1" cellspacing="0" cellpadding="2" style="border: 1px solid black; border-collapse: collapse;"
|- align="center"
!Наименование
!Масса - по данным производителя/измеренная (гр)
!Емкость (мАч)
!Максимальная токоотдача (С)
!Разъем
|-
|Аккумулятор NE-B918|| align="center" |3.70 / 3.70-3.77|| align="center" |120|| align="center" |10|| align="center" |NE
|-
|Аккумулятор NE-BA925|| align="center" |4.20 / 4.50-4.58|| align="center" |150|| align="center" |10|| align="center" |NE
|-
|Аккумулятор ZIPPY|| align="center" |5.90 / 5.20|| align="center" |240|| align="center" |20|| align="center" |?
|-
|Аккумулятор Turnigy|| align="center" |4.30 / ?|| align="center" |160|| align="center" |30|| align="center" |E-Flite
|-
|Аккумулятор Turnigy nano-tech|| align="center" |? / 4.21|| align="center" |160|| align="center" |25-40|| align="center" |E-Flite
|}

Для аккумуляторов с разъемом E-Flite продаются провода с разъемами. Примерный вес 0.62 грамма, а если отрезать один разъем, будет еще меньше.

<p style="clear: both;"></p>

==Апгрейд==

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

===AiRY===

<gallery perrow="2" style="float: right;">
Image:Airy-Acc-LP-0046.jpg|Набор Airy-Acc-LP-0046
</gallery>

Данной фирмой для Solo Pro выпущен только один апгрейд - набор для замены вала ОР, головки ОР, автомата перекоса и направляющей для автомата перекоса. Основной материал - алюминиевый сплав. Винты стальные. В автомате перекоса присутствуют элементы из латуни (или бронзы - не установлено).

Масса запчастей в граммах:

{| border="1" cellspacing="0" cellpadding="2" style="border: 1px solid black; border-collapse: collapse;"
|- align="center"
!Наименование
!Данные производителя
!Измеренные значения
|-
|Вал ОР || align="center" | || align="center" | 0.83
|-
|Направляющая АП ** || align="center" | || align="center" | 0.43
|-
|Головка ОР и ось лопастей *** || align="center" | || align="center" | 1.54
|-
|Автомат перекоса || align="center" | || align="center" | 2.02
|-
|Фиксирующее кольцо **** || align="center" | || align="center" | 0.10
|-
|Крепежные винты || align="center" | || align="center" | 0.34 *
|}

''* 8 штук.''

''** Для установки требуется 3 винта.''

''*** Для установки требуется 1 винт.''

''**** Для установки требуется 1 винт.''

<p style="clear: both;"></p>

===Xtreme===

<gallery perrow="2" style="float: right;">
Image:XNE001.jpg|Головка ОР. XNE001
Image:XNE005.jpg|Головка ОР. XNE005
Image:XNE002.jpg|Автомат перекоса. XNE002
Image:XNE003.jpg|Направляющая для АП. XNE003
Image:XNE004.jpg|Фиксирующее кольцо ОР. XNE004
Image:XNE006.jpg|Балансирный вал. XNE006
Image:XNE007.jpg|Шасси. XNE007
Image:XNE010.jpg|Шестерня. XNE010
Image:XNE011.jpg|Микшер ОР. XNE011
</gallery>

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

*'''Головка ОР''' (XNE001). Материал головки — алюминий. Ось лопастей — сталь. На ось надеваются резиновые тороидальные кольца, служащие опорой оси в отверстии головки. Также прилагаются шайбы - назначение пока не выяснено. Прилагаются пластиковые рычаги подключения к АП иной конструкции, чем оригинальные рычаги. Также продается комплект без головки ОР (XNE001-P). Несколько позже выпущена улучшенная версия головки ОР «v2» (XNE005) — немного облегченная, а также не требующая специальных рычагов.
*'''Автомат перекоса''' (XNE002). Нижняя тарелка — алюминий. В нее вложен стальной шарикоподшипник. Внутрь подшипника вставлена верхняя тарелка с шаровым подшипником в центре (под вал) и рычагами для тяг. Материал (предположительно) — латунь или бронза и пластик.
*'''Направляющая для АП''' (XNE003). Материал — алюминий.
*'''Фиксирующее кольцо ОР''' (XNE004). Материал — алюминий.
*'''Балансирный вал''' (Флайбар) (XNE006). Средняя часть - АБС пластик, плечи - улепластиковый пруток 1.6 мм, грузики - алюминий. Грузики съемные, фиксируются винтом с внутренним шестигранным шлицом (ключ прилагается). В комплекте две пары грузиков - легкие и тяжелые, 6 стальных винтов и одна ось, аналогичная штатной. Данный апгрейд крепится на головке ОР аналогично оригинальному балансирному валу. Отдельно продается балансирный вал без остальных комплектующих (XNE006-A). Отдельно продается комплект грузиков среднего веса (XNE006-B) с четыремя фиксирующими винтами и шестигранным ключом.
*'''Шасси''' (XNE007). Материал - пластик. Заметно толще и тяжелее оригинальных.
*'''Лопасти ОР''' (XNE009-x, где «x» - B1, B2, W1 или W2). Лопасти четырех расцветок. Довольно бесполезный апгрейд, учитывая прочность родных лопастей.
*'''Шестерня''' (XNE010). Ценность данного апгрейда пока не выяснена.
*'''Микшер''' (XNE011). Металлический микшер ОР. Ценность сомнительна, т.к. стоковый практически не ломается и весит меньше.

''Быстрее всего используется не чистый алюминий, а некий сплав.''

Масса запчастей в граммах:

{| border="1" cellspacing="0" cellpadding="2" style="border: 1px solid black; border-collapse: collapse;"
|- align="center"
!Наименование
!Данные производителя
!Измеренные значения
|-
|Головка ОР XNE001 || align="center" | || align="center" | 1.62 (1.52 *)
|-
|Головка ОР XNE005 || align="center" | || align="center" | 1.30
|-
|Автомат перекоса XNE002 || align="center" | || align="center" | 2.04
|-
|Направляющая для АП XNE003 || align="center" | || align="center" |
|-
|Фиксирующее кольцо ОР XNE004 || align="center" | || align="center" | 0.20
|-
|Балансирный вал XNE006 без грузиков / XNE006-A|| align="center" | || align="center" | 0.41
|-
|Грузики для балансирного вала (большие) || align="center" | || align="center" | 1.27 **
|-
|Грузики для балансирного вала (средние) || align="center" | || align="center" | 0.89 **
|-
|Грузики для балансирного вала (меньшие) || align="center" | || align="center" | 0.57 **
|-
|Винты фиксации грузиков для балансирного вала || align="center" | || align="center" | 0.05 **
|-
|Шасси XNE007 || align="center" | || align="center" | 2.12
|-
| Лопасти ОР XNE009-x || align="center" | || align="center" |
|-
| Шестерня XNE010 || align="center" | || align="center" |
|-
| Микшер ОР XNE011 || align="center" | || align="center" |
|}

''* Без рычагов. Дано для сравнения с XNE005.''

''** Пара.''

<p style="clear: both;"></p>

=Взаимодействие пульта и вертолета=

Основная статья: [[RC Heli:NE Solo Pro:Взаимодействие пульта и вертолета|Взаимодействие пульта и вертолета]]

Связь между пультом и платой вертолета происходит по эфиру в цифровом формате в одном направлении - от пульта к вертолету (это означает, что пульт ничего не знает о вертолете). Вертолет запоминает последний пульт, к которому он был привязан. При включении вертолет ищет в эфире сигнал от "своего" пульта, и если не находит, то ищет сигнал привязки от любого пульта. Различные источники сообщают, что одновременно в одном месте может работать до 80-и пультов.

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

==Восстановление сбившихся настроек платы==

Основная статья: [[RC_Heli:NE_Solo_Pro:Восстановление сбившихся настроек платы|Восстановление сбившихся настроек платы]]

Плата управления вертолета хранит свои настройки в энергонезависимой памяти (EEPROM) микроконтроллера. Редко, при включении питания (условия не установлены — вероятно дребезг контактов линий питания), может произойти сбой программы микроконтроллера и перезапись EEPROM. Возможны различные проявления этих сбоев. Например, после включения вертолета и установления связи с пультом, любой сервопривод может сместиться в крайнее положение и не реагировать на движение ручками пульта. Или сильные, но управляемые с пульта вращения.

=Рекомендации=

Основная статья: [[RC Heli:NE Solo Pro:Рекомендации|Рекомендации по эксплуатации и полетам.]]

В статье даны рекомендации по запуску, посадке и пилотажу вертолета.

=Индекс вопросов=

Основная статья: [[RC Heli:NE Solo Pro:Индекс практических вопросов|Индекс практических вопросов]]

Составлено по теме "[http://forum.rcdesign.ru/f59/thread163578.html Китайский ответ MSr - Nine Eagles SOLO PRO]" форума rcdesign.ru. Некоторые ссылки указывают на статьи в блоге rcdesign.ru и на форум rcgroups.com.

=Ссылки на другие материалы=

* [http://blog.rc-fever.com/tag/nine-eagles-solo-pro/ RC Fever] (en): различные модификации.
* [http://www.rcgroups.com/forums/showthread.php?t=1337008 Nine Eagles Solo Pro/Bravo SX FAQ] (en)
* [http://forum.rcdesign.ru/blogs/34364/blog10382.html о питании орлов в неволе]: колхоз с аккумулятором Turnigy 160mAh 1S 30C. Замеры потребления тока.

[[Category:RC_Heli:Nine_Eagles_Solo_Pro]]

FAQ:STL:C++ сериализация данных

2015-07-31T19:44:51Z

RXL:

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

Говоря о сериализации, я подразумеваю механизмы перевода некоторого класса, структуры или набора переменных в определённый формат (бинарный, текстовый, XML, HTML и т.д.), а также сам процесс перевода. Десериализация - процессы и механизмы, обратные сериализации (восстановление состояния из внешнего источника).

Самый простой способ, к которому чаще всего прибегают молодые программисты, - это простое копирование памяти в файл или еще куда-то. Т.е. берём указатель на класс/структуру/переменную и копируем N байт в файл. Пример: <syntaxhighlight lang="cpp">
.......
MyClass m;
..............
std::ofstream f("dump.bin", std::binary);
f.write(&m, sizeof(m));
f.close();
........................
</syntaxhighlight>

Но этот метод сериализации имеет ряд ограничений и недостатков:

*Допустимо использовать только для POD-структур (POD - Plain Old Data) и встроенных типов. Почему, будет понятно из следующих пунктов.
*Если программистом описан конструктор, то компилятор вправе в класс добавить какие-то свои вспомогательные переменные, что превращает класс в не POD-структуру, на самом деле это не так страшно, но формально это так.
*При сохранении указателей членов класса будут скопированы только адреса, хранимые указателями и, естественно, класс с указателями это не POD-тип
*Если в классе объявленные виртуальные функции (или он унаследован от класса содержащего виртуальные функции), это приводит к тому, что класс будет дополнен указателем на таблицу виртуальных функций, и с этим указателем та же проблема, что и со всеми другими. Опять же не POD-тип.
*Если ваш класс содержит внутри себя не POD типы или унаследован от не POD-типа, то ваш класс тоже не под тип, т.е. нет никакой гарантии, что копирование куска памяти позволит постановить состояние класса.
*Различное выравнивание данных внутри класса может сделать невозможным перенос сохранённого класса на другую платформу или даже в программу, скомпилированную с другими параметрами компиляции.
*Различный порядок байт не позволит переносить данные между такими платформами, как: x86 и PowerPC
*И такая сериализация не даёт сохранить в удобочитаемой форме XML, текст или CSV

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

Как только программист задумывается о сериализации данных, ему сразу же хочется выполнять сериализацию всего парой строк кода: легко и изящно, например, так: <syntaxhighlight lang="cpp">
// вывести состояние класса и всех его членов.
std::cout << myClass;

// загрузить состояние класса из XML
myXML >> myClass;
</syntaxhighlight>

И, естественно, самый простой способ быстро добиться результата - это использовать "велосипед", написанный другими. "Велосипед" возьмём хороший, многофункциональный. Он умеет выполнять сериализацию и десериализацию стандартных контейнеров, классов, указателей, ссылок и еще чего-то. Также он умеет сохранять, работать с различными форматами выходных данных: бинарный, текст, XML. Если очень хочется, то он может сохранить не только в поток, но и куда угодно, например, в вектор или в сокет или выкинуть в пропасть.

Полное описание "велосипеда": http://www.boost.org/doc/libs/1_36_0/libs/serialization/doc/index.html

Вот пример использования (взято из описания):

<syntaxhighlight lang="cpp">
/////////////////////////////////////////////////////////////
// gps координаты
//
// illustrates serialization for a simple type
//
class gps_position
{
private:
friend class boost::serialization::access;
// When the class Archive corresponds to an output archive, the
// & operator is defined similar to <<. Likewise, when the class Archive
// is a type of input archive the & operator is defined similar to >>.
template<class Archive>
void serialize(Archive & ar, const unsigned int version)
{
ar & degrees;
ar & minutes;
ar & seconds;
}
int degrees;
int minutes;
float seconds;
public:
gps_position(){};
gps_position(int d, int m, float s) :
degrees(d), minutes(m), seconds(s)
{}
};

int main() {
// create and open a character archive for output
std::ofstream ofs("filename");

// create class instance
const gps_position g(35, 59, 24.567f);

// save data to archive
{
boost::archive::text_oarchive oa(ofs);
// write class instance to archive
oa << g;
// archive and stream closed when destructors are called
}

// ... some time later restore the class instance to its orginal state
gps_position newg;
{
// create and open an archive for input
std::ifstream ifs("filename");
boost::archive::text_iarchive ia(ifs);
// read class state from archive
ia >> newg;
// archive and stream closed when destructors are called
}
return 0;
}
</syntaxhighlight>

Теперь по пунктам, как это работает:

#Создаём внутри нашего класса метод serialize, получаем ссылку на архив и номер версии(можно по-разному сериализовать в зависимости от версии), если метод приватный, то добавляем в друзья class boost::serialization::access. Метод serialize будет вызываться при сериализации и десериализации.
#Открываем файл и создаём архив (text_oarchive текстовый выходной архив), в нашем случае текстовый, архив - это тот самый класс, который выполняет основную работу.
#Вызываем всеми любимый оператор << - этот оператор вызывает метод serialize для классов или же внешние функции(они идут в комплекте) для встроенных типов и стандартных контейнеров.
#text_oarchive::operator<< вызвал наш метод serialize и передал вовнутрь себя, тут возникает вопрос: почему внутри serialize используется оператор &, а не <<? Ответ: потому что у выходного архива операторы & и << по сути это одно и тоже, у входного операторы & и >> - одно и тоже. Т.е. ничто не мешает в коде поменять "ia >> newg;" на "ia & newg;".
#Если нужно изменить метод сериализации, достаточно поменять тип архива (для XML архива придётся сделать еще некоторою работу в методе serialize).

На этом, в общем-то, работа по поддержке сериализации закончена.

При желании, можно разделить методы для сериализации и десериализации. Кстати, boost::seralization гарантирует, что порядок байт при сериализации будет изменён, если потребуется, так что можно спокойно передать long с x86 на PowerPC.

Немного поправленный пример использования и результаты работы:

<syntaxhighlight lang="cpp">
#include "stdafx.h"
#include <iostream>
#include <fstream>
#include <string>
#include <fstream>
#include <vector>

// include headers that implement a archive in simple text format
#include <boost/archive/text_oarchive.hpp>
#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/binary_iarchive.hpp>
#include <boost/archive/binary_oarchive.hpp>
#include <boost/archive/xml_iarchive.hpp>
#include <boost/archive/xml_oarchive.hpp>
// включаем, чтобы сериализация работала с векторами
#include <boost/serialization/vector.hpp>
// включаем, чтобы нормально проходила сериализация XML
#include <boost/serialization/nvp.hpp>

class gps_position
{
private:
friend class boost::serialization::access;

template<class Archive>
void serialize(Archive & ar, const unsigned int version)
{
// то же, что и make_nvp, только имя параметра выводится в макросе
ar & BOOST_SERIALIZATION_NVP(degrees);
ar & BOOST_SERIALIZATION_NVP(minutes);
ar & BOOST_SERIALIZATION_NVP(seconds);
}
int degrees;
int minutes;
float seconds;
public:
gps_position(){};
gps_position(int d, int m, float s) :
degrees(d), minutes(m), seconds(s)
{}
};

template<typename TIArch, typename TOArch, typename TClass>
void TestArch(const std::string & file, int flags, const TClass & cont)
{

{ // Сериализуем
std::ofstream ofs(file.c_str(), std::ios::out|flags);
TOArch oa(ofs);
// make_nvp создаёт пару имя-значение, которая отразится в XML
// если не используем XML архив, то можно пару не создавать
oa << boost::serialization::make_nvp("Test_Object", cont);
}

TClass newg;
{ // Десериализуем
std::ifstream ifs(file.c_str(), std::ios::in|flags);
TIArch ia(ifs);
ia >> boost::serialization::make_nvp("Test_Object",newg);
}

{ // Еще раз сериализуем, чтобы потом сравнить результаты двух сериализаций
// и убедиться, что десериализациия прошла корректно
std::ofstream ofs((file+".tmp").c_str(), std::ios::out|flags);
TOArch oa(ofs);
oa << boost::serialization::make_nvp("Test_Object", cont);
}
}

int _tmain(int argc, _TCHAR* argv[])
{
std::ofstream ofs("filename");

std::vector<gps_position> v;
v.push_back(gps_position(35, 59, 24.567f));
v.push_back(gps_position(36, 60, 25.567f));
v.push_back(gps_position(37, 61, 26.567f));

using namespace boost::archive;
TestArch<text_iarchive, text_oarchive>("text_arch.dump", 0, v);
TestArch<binary_iarchive, binary_oarchive>("binary_arch.dump", std::ios::binary, v);
TestArch<xml_iarchive, xml_oarchive>("xml_arch.dump", 0, v);

return 0;
}
</syntaxhighlight>

Файл text_arch.dump: <syntaxhighlight>
22 serialization::archive 3 0 0 3 0 0 35 59 24.566999 36 60 25.566999 37 61 26.566999
</syntaxhighlight>

Как видите, использование NVP никак не отразилось на внешнем виде архива.

Файл xml_arch.dump: <syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="3">
<Test_Object class_id="0" tracking_level="0" version="0">
<count>3</count>
<item class_id="1" tracking_level="0" version="0">
<degrees>35</degrees>
<minutes>59</minutes>
<seconds>24.566999</seconds>
</item>
<item>
<degrees>36</degrees>
<minutes>60</minutes>
<seconds>25.566999</seconds>
</item>
<item>
<degrees>37</degrees>
<minutes>61</minutes>
<seconds>26.566999</seconds>
</item>
</Test_Object>
</boost_serialization>
</syntaxhighlight>

Бинарный архив приводить не стану :) не очень красочно, но занимает он 79 байт, из которых 39 - заголовок и 40 - полезная информация.

<br>

За универсальность boost::serialization придётся заплатить:

*Во время компиляции шаблоны могут разворачиваться довольно долго.
*Скорость: стек вызовов для сериализации какой-нибудь не слишком больной структурки, может быть просто ужасающим - вызовов 20-30.

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

<br> Надеюсь, в общих чертах понятно, как примерно работает сериализация и десериализация, и если понадобится, можно реализовать свою сериализацию.

<br> Вот пример своей реализации архива, который я использую вместо boost:binary_iarchive (была ОЧЕНЬ важна скорость, а универсальность не очень, но для маршалинга хватает), делал так, чтобы можно было использовать один вместо другого без переделки кода:

<syntaxhighlight lang="cpp">
class binary_iarchive
{
public:
typedef serialization::container container;
typedef container::iterator iterator;

container &cont_;
size_t currentPos_;
typedef boost::mpl::bool_<false> is_saving;
binary_iarchive(container & cont, long = 0)
: cont_(cont)
, currentPos_(0)
{
}

template<typename T>
binary_iarchive & operator>>(T & val)
{
deserialize_impl(val);
return *this;
}

void reset()
{
resetPos();
cont_.clear();
}

template<typename T>
inline void raw_read(T beginPos, size_t len)
{
if (static_cast<size_t>(cont_.size() - currentPos_) < len)
throw std::runtime_error("No more data");

iterator pos = cont_.begin() + currentPos_;
iterator endPos = pos + len;
std::copy(pos, endPos, beginPos);
currentPos_ = currentPos_ + len;
}
private:
// Fundamental
template<typename T>
inline void deserialize_impl(T & val, typename boost::enable_if<boost::is_fundamental<T> >::type* dummy = 0)
{
raw_read(reinterpret_cast<char*>(&val), sizeof(T));
}

//Classes
template<typename T>
inline void deserialize_impl(T & val, typename boost::enable_if<boost::is_class<T> >::type* dummy = 0)
{
deserialize_class(*this, val);
}
};
</syntaxhighlight>

Кое-что порезал, чтобы не расслаблялись :)

[[Category:FAQ]] [[Category:FAQ:ANSI_CPP]] [[Category:FAQ:STL]] [[Category:FAQ:STL_BOOST]]

Категория:Толковый словарь

2013-02-08T14:06:53Z

RXL:

=Толковый словарь компьютерного слэнга=

[[Толковый словарь|Старый список терминов]]

Целевая система разработки

2013-02-08T14:05:52Z

RXL:

Система, для выполнения на которой предназначается разрабатываемая программа.

См. также: [[Инструментальная система разработки]].

[[Category:Толковый словарь]]

Фон-неймановская архитектура

2013-02-08T14:05:46Z

RXL:

Архитектура вычислительной машины, в которой адресные пространства программ и данных объединены в единое адресное пространство.

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

Архитектура получила свое название в честь одного из разработчиков [http://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D0%B9%D0%BC%D0%B0%D0%BD,_%D0%94%D0%B6%D0%BE%D0%BD_%D1%84%D0%BE%D0%BD Джона фон Неймана].

'''Ф.-н. а.''' известна также как [[Принстонская архитектура]] но названию университета, в котором она была разработана.

См.также: [[Гарвардская архитектура]]

[[Category:Толковый словарь]]

Три товарища

2013-02-08T14:05:35Z

RXL:

Под этим шутливым прозвищем известны три корифея информатики - Грейди (Гради) Буч (Grady Booch), Ивар (Айвар) Джейкобсон (Якобсон) (Ivar Jacobson) и Джеймс Рамбо (Румбах) (James Rumbaugh). (Имена и фамилии приведены в нескольких вариантах, поскольку все они встречаются в русских переводах).

Основные достижения '''Т. т.''' - разработка универсального языка моделирования [[UML]], который вобрал в себя элементы наиболее передовых на время своего создания методик [[Объектно-ориентированный анализ|объектно-ориентированного анализа]] (OMT, OOSE, Booch) и [[Унифицированный процесс|Унифицированного процесса]], который стал основой для целого семейства технологий разработки программных продуктов.

Свое прозвище троица получила от американской музыкальной комедии "[http://en.wikipedia.org/wiki/Three_Amigos Three Amigos]", снятой в 1986 году (а вовсе не по произведению Ремарка, как иногда думают).

[[Category:Толковый словарь]]

Тестовый двойник

2013-02-08T14:05:31Z

RXL:

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

Можно выделить несколько вариантов '''Т.д.''':

* [[Тестовая заглушка]];
* [[Процедурная тестовая заглушка]];
* [[Тестовый агент]];
* [[Подставной объект]];
* [[Поддельный объект]];
* [[Объект-заглушка]].

В зависимости от возможностей настройки '''Т.д.''' можно также подразделить на следующие варианты:

* [[Ненастраиваемый тестовый двойник]];
* [[Фиксированный тестовый двойник]];
* [[Настраиваемый тестовый двойник]].

----
Литература:

Джерард Месарош. Шаблоны тестирования xUnit. Рефакторинг кода тестов. Вильямс, 2009. ISBN 978-5-8459-1448-4, ISBN 978-0-13-149505-0

[[Category:Толковый словарь]]

Тестирование

2013-02-08T14:05:23Z

RXL:

'''Тестирование''' ([[Testing]]) - деятельность, направленная на обнаружение расхождений между реальными свойствами предмета тестирования и предъявляемыми к нему требованиями. Учитывая тематическую направленность данного ресурса, в дальнейшем мы будем рассматривать лишь две разновидности предметов тестирования:
# программное обеспечение (ПО);
# системы со встроенными микропроцессорами (микроконтроллерами).

Системы со встроенными микропроцессорами (микроконтроллерами) включают в себя как аппаратную часть, так и встроенное ПО, поэтому их '''Т.''' представляет собой более обий случай по сравнению с '''Т.''' ПО.

Вопреки широко распространенному ошибочному мнению, целью '''Т.''' вовсе не является демонстрация работоспособности предмета тестирования. Напротив, задача '''T.''' - выявить как можно больше ошибок в предмете тестирования.

Не следует путать '''Т.''' с [[Отладка|отладкой]].

[[Category:Толковый словарь]]

Рефакторинг

2013-02-08T14:05:15Z

RXL:

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

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

Прямым указанием на то, что необходимо провести '''Р.''' кода, является наличие так называемого [[Запах кода|запаха кода]].

----
Литература:

Мартин Фаулер. Рефакторинг: улучшение существующего кода. - Пер. с англ. - СПб: Символ-Плюс, 2005. ISBN 5-93286-045-6

[[Category:Толковый словарь]]

Разработка, управляемая тестированием

2013-02-08T14:05:10Z

RXL:

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

Широко применяется в "экстремальном программировании".

[http://club.shelek.ru/viewart.php?id=351 Статья "Разработка на языке C, управляемая тестированием".]

[[Category:Толковый словарь]]

Протопоток

2013-02-08T14:05:03Z

RXL:

'''П.''' - это реализация простейших [[Поток|потоков]] с [[Кооперативная многозадачность|кооперативной многозадачностью]].

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

В частности, '''П.''' нашли широкое применение при реализации коммуникационных протоколов, например, стека TCP/IP или протокола для обмена данными с беспроводными датчиками.

Известная реализация '''П.''' на языке C использует [[Машина Даффа (устройство Даффа)|машину Даффа]] для управления внутренними состояниями. Машина Даффа реализована в виде набора макросов C и не видна в коде программы, поэтому код получается простым и компактным.

К недостаткам '''П.''' можно отнести запрет на использование стека для размещения в нем локальных переменных функции, реализующей поток. Однако из этого недостатка вытекает также их достоинство: поскольку стек не используется, оперативная память расходуется очень экономно, при этом не требуется выделять пространство под стек отдельно для каждого потока. Это достоинство может стать решающим при использовании микроконтроллеров с объемом ОЗУ, исчисляемым несколькими десятками или сотнями байт.

----
Литература:

[http://www.sics.se/~adam/dunkels05using.pdf Adam Dunkels, Oliver Schmidt, Thiemo Voigt. Using Protothreads for Sensor Node Programming.]

[http://www.sics.se/~adam/dunkels06protothreads.pdf Adam Dunkels, Oliver Schmidt, Thiemo Voigt, and Muneeb Ali. Protothreads: Simplifying Event-Driven Programming of Memory-Constrained Embedded Systems.]

[[Category:Толковый словарь]]

Принстонская архитектура

2013-02-08T14:04:56Z

RXL:

См. [[Фон-неймановская архитектура]]

[[Category:Толковый словарь]]

Подставной объект

2013-02-08T14:04:47Z

RXL:

'''П.о.''' - объект, которым заменяется ''реальный'' объект [[SUT]] в процессе ''тестирования поведения''.

[[Category:Толковый словарь]]

Отладчик

2013-02-08T14:04:26Z

RXL:

'''Отладчик''' ([[Debugger]]) - программное или аппаратно-программное средство, предназначенное для ускорения и облегчения процесса [[Отладка|отладки]].

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

Минимальный сервис, предоставляемый '''О.''', обычно включает в себя задание точек останова, пошаговое выполнение программы, просмотр/модификацию ячеек памяти и подобные примитивные операции. Более развитые '''О.''' предоставляют дополнительный сервис, например, трассировка/отладка в терминах языка высокого уровня, на котором написана программа (при условии, разумеется, что при компиляции были сгенерированы дополнительные данные для отладки), слежение за значениями переменных, точки останова по заданному условию и т.д.

Аппаратные '''О.''' требуют наличия специального отладочного оборудования (например, [[Внутрисхемный эмулятор|внутрисхемного эмулятора]]). Это оборудование позволяет заглянуть в "недра" отлаживаемой системы, недоступные другими способами извне (например, просмотреть содержимое регистров общего назначения или задать точку останова программы).

Впрочем успехи микроэлектроники привели к тому, что зачастую серийные микропроцессоры (микроконтроллеры) оснащаются довольно развитыми средствами внутрисхемной эмуляции, причем это даже не отражается на их стоимости. Поэтому многие аппаратно-программные '''О.''' либо вовсе не требуют дополнительных аппаратных средств отладки, довольствуясь встроенными, либо эти дополнительные средства просты и универсальны (например, если отлаживаемая система снабжена интерфейсом [[JTAG]].

См. также: [[Отладка]].

[[Category:Толковый словарь]]

Отладка

2013-02-08T14:04:21Z

RXL:

Отладка ([[Debugging|debugging]]) - процесс поиска ошибок в программном и/или аппаратном обеспечении вычислительно-управляющих систем.

Как правило, для проведения '''О.''' используются [[Отладчик|отладчики]], хотя существуют способы, позволяющие в принципе обходиться и без них (например, при поиске ошибок в программах можно вводить в контрольные точки в коде операторы выдачи диагностики на печать или терминал). Путем анализа диагностического вывода можно обнаружить точку, где реальное поведение программы отличается от предполагаемого.

До недавнего прошлого '''О.''' занимала весьма важное место в процессе разработки ПО. Однако грамотное использование [[Тестирование|тестирования]] резко уменьшает потребность в '''О.''', а зачастую и вовсе сводит ее к нулю.

См. также: [[Отладчик]].

[[Category:Толковый словарь]]

Модульный тест

2013-02-08T14:04:09Z

RXL:

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

Типичный '''М. т.''' содержит в себе четыре фазы:

*подготовка;
*выполнение;
*оценка;
*очистка.

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

В фазе '''выполнения''' М. т. вызывает тестируемый метод.

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

Фаза '''очистки''' предназначена для очистки среды выполнения '''М. т.''' и освобождения занятых на предыдущих фазах ресурсов. Многие тесты не используют ресурсы, нуждающиеся в явном освобождении, поэтому на практике эта фаза часто отсутствует.

См. также: [[Модульное тестирование]].

[[Category:Толковый словарь]]

Модульное тестирование

2013-02-08T14:04:05Z

RXL:

Англ. [[Unit Testing]]

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

На практике, как правило, используется автоматизированное '''М. т.'''. Высокая степень автоматизации позволяет проводить '''М. т.''' достаточно быстро (типичные затраты времени составляют порядка нескольких минут), что снижает затраты на тестирование и позволяет часто повторять '''М. т.''' не только кода, над которым в данный момент производится работа, но и всей системы в целом (см. [[Регрессионное тестирование]]).

Автоматизация '''М. т.''' достигается за счет использования специальных инструментальных средств - сред '''М. т.'''. Наиболее известным семейством таких сред является [[xUnit]], в состав которого входят инструменты '''М. т.''' практически для всех популярных языков программирования.

Среда '''М. т.''', как правило, позволяет управлять выполнением [[Модульный тест|модульных тестов]]. При этом можно разрешить или запретить выполнение отдельных модульных тестов, определяя набор тестов, который будет выполнен во время очередного сеанса тестирования.

[[Category:Толковый словарь]]

Машина Даффа (устройство Даффа)

2013-02-08T14:04:00Z

RXL:

На самом деле это не физическое устройство, а идиома программирования на языке ANSI C.

'''М.Д.''' была придумана компьютерным инженером канадского происхождения Томом Даффом (см. [http://en.wikipedia.org/wiki/Tom_Duff Tom Duff]). Оригинальность и непривычность подхода Даффа поражают при первом знакомстве: одни считают это гениальным трюком, другие - грязным хаком (см. [http://forum.shelek.ru/index.php/topic,25760.msg246759.html#msg246759 обсуждение] статьи [http://club.shelek.ru/viewart.php?id=338 "Сопрограммы в языке программирования C"]), но равнодушным не остается практически никто.

Классическая '''М.Д.''' выглядит [http://en.wikipedia.org/wiki/Duff%27s_device#Original_version так]. Операторы '''switch''' и '''do while''' переплетены в ней настолько причудливо, что первый вопрос, который почти у всех возникает при виде '''М.Д.''': "А это в самом деле можно скомпилировать без ошибок???". Но на самом деле '''М.Д.''' не противоречит ни синтаксису ANSI C, ни здравому смыслу; более того, умелое ее использование позволяет красиво решать самые различные задачи, например, "раскручивание циклов", построение конечных автоматов, реализация [[Кооперативная многозадачность|кооперативной многозадачности]] через механизм [[Протопоток|протопотоков]] и т.п.

[[Category:Толковый словарь]]

Кросс-средства разработки

2013-02-08T14:03:51Z

RXL:

Средства, позволяющие разрабатывать программное обеспечение для некоторой вычислительной системы с использованием [[Инструментальная система|инструментальной системы]] с другой архитектурой.

Широкое применение '''К.-с. р.''' находят при разработке встроенных систем на основе микроконтроллеров, построение [[Инструментальная система|инструментальной системы]] на которых затруднено в связи с особенностями их архитектуры. При этом '''К.-с. р.''' работают на инструментальном персональном компьютере, а результирующий код загружается в [[Целевая система|целевую систему]] при помощи ''программатора''.

В качестве примера '''К.-с. р.''' можно привести широко распространенную [[Интегрированная среда разработки|интегрированную среду разработки]] [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=17212&category_id=163&family_id=607&subfamily_id=760 Atmel AVR Studio 5.0] фирмы [http://www2.atmel.com/ Atmel]. Это средство предназначено для работы на IBM PC-совместимых компьютерах в среде операционной системы MS Windows и позволяет разрабатывать и отлаживать программы для всех микроконтроллеров семейства [http://www.atmel.com/products/avr/default.asp?category_id=163&family_id=607&source=left_nav AVR] на ассемблере и языке программирования C.

[[Category:Толковый словарь]]

Инструментальная система разработки

2013-02-08T14:03:47Z

RXL:

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

В зависимости от ситуации '''И. с. р.''' может совпадать либо не совпадать с [[Целевая система разработки|целевой системой разработки]]. Если '''И. с. р.''' отлична от [[Целевая система разработки|целевой системы разработки]], такую '''И. с. р.''' называют [[Кросс-средства разработки|кросс-системой разработки]].

См. также: [[Целевая система разработки]]

[[Category:Толковый словарь]]

Гарвардская архитектура

2013-02-08T14:03:41Z

RXL:

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

'''Г. а.''' получила широкое использование в однокристальных микроконтроллерах, поскольку память программ в этих устройствах реализуется в виде какой-либо разновидности [[ПЗУ]] и конструктивно отличается от памяти данных.

Архитектура получила свое название по имени университета, в котором она была разработана.

См. также: [[Фон-неймановская архитектура]]

[[Category:Толковый словарь]]

Unity

2013-02-08T14:03:26Z

RXL:

Среда модульного тестирования программ, написанных на языке ANSI C.

Авторы: Mike Karlesky, Mark VanderVoord, Greg Williams.

[http://throwtheswitch.org/white-papers/unity-intro.html Домашняя страница проекта].

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

[http://club.shelek.ru/viewart.php?id=348 Статья "Модульное тестирование ПО встроенных систем в среде Unity", часть 1]

[http://club.shelek.ru/viewart.php?id=349 Статья "Модульное тестирование ПО встроенных систем в среде Unity", часть 2]

[http://club.shelek.ru/viewart.php?id=350 Статья "Модульное тестирование ПО встроенных систем в среде Unity", часть 3]

[[Category:Толковый словарь]]

TDD

2013-02-08T14:03:17Z

RXL:

'''TDD''' - аббревиатура для Test-Driven Development (вариант: Test-Driven Design).

См. [[Разработка, управляемая тестированием]].

[[Category:Толковый словарь]]

TDD

2013-02-08T14:03:03Z

RXL:

'''TDD''' - аббревиатура для Test-Driven Development (вариант: Test-Driven Design).

См. [[Разработка, управляемая тестированием]].

[[Category:Русские термины]]

[[Category:Толковый словарь]]

MCH

2013-02-08T14:02:53Z

RXL:

'''MCH''' (аббревиатура для "Model Conductor Hardware", т.е. "Модель-Проводник-Оборудование) - это паттерн проектирования, разработанный сотрудниками Atomic Object: Michael Karlesky
(mailto:karlesky@atomicobject.com), Greg Williams (mailto:williams@atomicobject.com), William Bereza (mailto:bereza@atomicobject.com), Matt Fletcher (mailto:fletcher@atomicobject.com).

Паттерн был разработан по аналогии с известными паттернами проектирования "настольных" приложений MVC и MVP. Его назначение - усовершенствование архитектуры приложений для встроенных систем за счет максимально возможного отделения бизнес-логики приложения от оборудования.

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

----
Литература:

[http://forum.shelek.ru/index.php/topic,26526.msg263486.html#msg263486 Michael Karlesky, Greg Williams, William Bereza, Matt Fletcher. Mocking the Embedded World: Test-Driven Development, Continuous Integration, and Design Patterns.]

[[Category:Толковый словарь]]

HAL

2013-02-08T14:02:46Z

RXL:

Аббревиатура для ''Hardware Abstract Layer'' - дословно "прослойка для абстрагирования от оборудования".

'''HAL''' представляет собой часть кода ("прослойку"), в которой сконцентрирована вся работа с физическим оборудованием. Остальной код взаимодействует с оборудованием не напрямую, а с использованием интерфейса '''HAL'''. Такое разделение позволяет сделать большую часть кода независимым от конкретного оборудования, что повышает мобильность программного обеспечения: при портировании на другую платформу достаточно лишь переписать '''HAL''', который обычно составляет лишь небольшую часть кода, к тому же он достаточно прост и хорошо локализован.

[[Category:Толковый словарь]]

Заглавная страница

2013-02-08T14:02:12Z

RXL:

__NOTOC__
=Википедия Клуба программистов "Весельчак У"=

==Разделы==

===Основной материал.===
* [[FAQ:Содержание|Ответы на часто задаваемые вопросы о программировании]]. Составлено по темам [[Форум программистов|нашего форума]].
* [[FAQ:Oracle|Ответы на часто задаваемые вопросы по администрированию Oracle]].
* [[Русские_термины|Перевод на русский язык различных англоязычных терминов по программированию и из смежных областей]].
* [[:Category:Толковый_словарь|Толковый словарь компьютерного слэнга]].

* [[Дополнительный материал.]]

'''!''' Чтобы быстрее найти необходимый материал, воспользуйтесь строкой поиска в левой колонке страницы.

Вы можете принять участие в подготовке материалов для сайта на нашем форуме в [http://forum.shelek.ru/index.php/board,114.0.html разделе ЧАВО].

[[Category:Портал]]

Заглавная страница

2013-02-08T14:01:32Z

RXL:

__NOTOC__
=Википедия Клуба программистов "Весельчак У"=

==Разделы==

===Основной материал.===
* [[FAQ:Содержание|Ответы на часто задаваемые вопросы о программировании]]. Составлено по темам [[Форум программистов|нашего форума]].
* [[FAQ:Oracle|Ответы на часто задаваемые вопросы по администрированию Oracle]].
* [[Русские_термины|Перевод на русский язык различных англоязычных терминов по программированию и из смежных областей]].
* [[Толковый_словарь|Толковый словарь компьютерного слэнга]].

* [[Дополнительный материал.]]

'''!''' Чтобы быстрее найти необходимый материал, воспользуйтесь строкой поиска в левой колонке страницы.

Вы можете принять участие в подготовке материалов для сайта на нашем форуме в [http://forum.shelek.ru/index.php/board,114.0.html разделе ЧАВО].

[[Category:Портал]]

Заглавная страница

2013-02-08T14:01:01Z

RXL:

__NOTOC__
=Википедия Клуба программистов "Весельчак У"=

==Разделы==

===Основной материал.===
* [[FAQ:Содержание|Ответы на часто задаваемые вопросы о программировании]]. Составлено по темам [[Форум программистов|нашего форума]].
* [[FAQ:Oracle|Ответы на часто задаваемые вопросы по администрированию Oracle]].
* [[Русские_термины|Перевод на русский язык различных англоязычных терминов по программированию и из смежных областей]].
* [[Category:Толковый_словарь|Толковый словарь компьютерного слэнга]].

* [[Дополнительный материал.]]

'''!''' Чтобы быстрее найти необходимый материал, воспользуйтесь строкой поиска в левой колонке страницы.

Вы можете принять участие в подготовке материалов для сайта на нашем форуме в [http://forum.shelek.ru/index.php/board,114.0.html разделе ЧАВО].

[[Category:Портал]]

Заглавная страница

2013-02-08T14:00:34Z

RXL:

__NOTOC__
=Википедия Клуба программистов "Весельчак У"=

==Разделы==

===Основной материал.===
* [[FAQ:Содержание|Ответы на часто задаваемые вопросы о программировании]]. Составлено по темам [[Форум программистов|нашего форума]].
* [[FAQ:Oracle|Ответы на часто задаваемые вопросы по администрированию Oracle]].
* [[Русские_термины|Перевод на русский язык различных англоязычных терминов по программированию и из смежных областей]].
* [[Категория:Толковый словарь|Толковый словарь компьютерного слэнга]].

* [[Дополнительный материал.]]

'''!''' Чтобы быстрее найти необходимый материал, воспользуйтесь строкой поиска в левой колонке страницы.

Вы можете принять участие в подготовке материалов для сайта на нашем форуме в [http://forum.shelek.ru/index.php/board,114.0.html разделе ЧАВО].

[[Category:Портал]]

Заглавная страница

2013-02-08T14:00:15Z

RXL:

__NOTOC__
=Википедия Клуба программистов "Весельчак У"=

==Разделы==

===Основной материал.===
* [[FAQ:Содержание|Ответы на часто задаваемые вопросы о программировании]]. Составлено по темам [[Форум программистов|нашего форума]].
* [[FAQ:Oracle|Ответы на часто задаваемые вопросы по администрированию Oracle]].
* [[Русские_термины|Перевод на русский язык различных англоязычных терминов по программированию и из смежных областей]].
* [[Категория:Толковый_словарь|Толковый словарь компьютерного слэнга]].

* [[Дополнительный материал.]]

'''!''' Чтобы быстрее найти необходимый материал, воспользуйтесь строкой поиска в левой колонке страницы.

Вы можете принять участие в подготовке материалов для сайта на нашем форуме в [http://forum.shelek.ru/index.php/board,114.0.html разделе ЧАВО].

[[Category:Портал]]

Категория:Толковый словарь

2013-02-08T13:59:51Z

RXL: Новая страница: «=Толковый словарь компьютерного слэнга=»

=Толковый словарь компьютерного слэнга=

CException

2013-02-08T13:59:31Z

RXL:

Чрезвычайно компактное средство для обработки исключений в программах, написанных на языке ANSI C.

Автор: Mark VanderVoord.

[http://throwtheswitch.org/white-papers/cexception-intro.html Домашняя страница проекта.]

C. основывается на стандартных библиотечных функциях языка C setjmp и longjmp. Это простое средство с малыми накладными расходами, что делает его пригодным для применения во встроенных системах.

[http://club.shelek.ru/viewart.php?id=343 Статья "Обработка исключений на языке C"]

[[Category:Толковый словарь]]

Категория:Redmine

2012-01-29T13:40:56Z

RXL:

=Игра Redmine=

*[http://www.minecraft.net/ Официальный сайт]
*[http://ru.minecraftwiki.net/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0 Русский мануал]

[[Category:Redmine]]

Заглавная страница

2012-01-29T13:38:58Z

RXL:

__NOTOC__
=Википедия Клуба программистов "Весельчак У"=

==Разделы==

===Основной материал.===
* [[FAQ:Содержание|Ответы на часто задаваемые вопросы о программировании]]. Составлено по темам [[Форум программистов|нашего форума]].
* [[FAQ:Oracle|Ответы на часто задаваемые вопросы по администрированию Oracle]].
* [[Русские_термины|Перевод на русский язык различных англоязычных терминов по программированию и из смежных областей]].
* [[Толковый_словарь|Толковый словарь компьютерного слэнга]].

* [[Дополнительный материал.]]

'''!''' Чтобы быстрее найти необходимый материал, воспользуйтесь строкой поиска в левой колонке страницы.

Вы можете принять участие в подготовке материалов для сайта на нашем форуме в [http://forum.shelek.ru/index.php/board,114.0.html разделе ЧАВО].

[[Category:Портал]]

Дополнительный материал.

2012-01-29T13:38:52Z

RXL: Новая страница: «=Дополнительный материал= * Правила английского языка. * [[Глобальная ав...»

=Дополнительный материал=

* [[Английский язык|Правила английского языка]].
* [[Глобальная авантюра|Глобальная авантюра]]. Материалы о мировом экономическом кризисе.
* [[:Category:RC_Heli|Микровертолеты]]. Подборка материала для новичков и не только.
* [[:Category:Redmine|Игра Redmine]]. Подборка рецептов.

[[Category:Портал]]

Redmine:Станция железной дороги

2012-01-29T13:36:27Z

RXL: /* Схема сборки для вида на север или на запад */

{{TOC-right}}

=Станция железной дороги (игра Redmine)=

==Станция электрической дороги с движением в обе стороны==

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

===Схема с автоматическими стрелками===

<p style="clear: both;"></p>
<gallery style="float: right;" perrow="4">
Image:Redmine-Station-screen-control.png
</gallery>
Логическая схема состоит из трех частей:
#Формирование стартового импульса по нажатию любой кнопки.
#Переключение стрелки и возврат в исходное положение через две секунды. Производится по нажатию левой кнопки (если смотреть из вагонетки, то правой).
#Переключение стрелки при проходе вагонетки по нажимным рельсам.

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

Направление движения выбирается нажатием на одну из двух кнопок. При этом вагонетка сразу начинает движение.
<p style="clear: both;"></p>
<gallery style="float: right;" perrow="3">
Image:Redmine-Station-legend.png|Легенда
Image:Redmine-Station-1.png|Уровень 1
Image:Redmine-Station-2.png|Уровень 2
Image:Redmine-Station-3.png|Уровень 3
Image:Redmine-Station-4.png|Уровень 4
Image:Redmine-Station-5.png|Уровень 5
Image:Redmine-Station-6.png|Уровень 6
Image:Redmine-Station-7.png|Уровень 7
</gallery>
====Схема сборки для вида на север или на запад====

Список необходимых ресурсов:
{| border="1" cellspacing="0" cellpadding="2" style="border: 1px solid black; border-collapse: collapse;"
!Тип блока
!Количество
|-
|[http://ru.minecraftwiki.net/%D0%9A%D0%BD%D0%BE%D0%BF%D0%BA%D0%B0 Кнопка]
|align="center" |2
|-
|[http://ru.minecraftwiki.net/%D0%9A%D1%80%D0%B0%D1%81%D0%BD%D0%B0%D1%8F_%D0%BF%D1%8B%D0%BB%D1%8C Красная пыль]
|align="center" |45
|-
|[http://ru.minecraftwiki.net/%D0%9A%D1%80%D0%B0%D1%81%D0%BD%D1%8B%D0%B9_%D0%BA%D0%B0%D0%BC%D0%B5%D0%BD%D1%8C_(%D1%84%D0%B0%D0%BA%D0%B5%D0%BB) Красный факел]
|align="center" |16
|-
|[http://ru.minecraftwiki.net/%D0%9B%D0%B5%D1%81%D1%82%D0%BD%D0%B8%D1%86%D0%B0 Лестница]
|align="center" |3
|-
|[http://ru.minecraftwiki.net/%D0%9B%D1%8E%D0%BA Люк]
|align="center" |1
|-
|[http://ru.minecraftwiki.net/%D0%9D%D0%B0%D0%B6%D0%B8%D0%BC%D0%BD%D1%8B%D0%B5_%D1%80%D0%B5%D0%BB%D1%8C%D1%81%D1%8B Нажимные рельсы]
|align="center" |1
|-
|[http://ru.minecraftwiki.net/%D0%9F%D0%BE%D0%B2%D1%82%D0%BE%D1%80%D0%B8%D1%82%D0%B5%D0%BB%D1%8C Повторитель (репитер)]
|align="center" |5
|-
|[http://ru.minecraftwiki.net/%D0%A0%D0%B5%D0%BB%D1%8C%D1%81%D1%8B Рельсы]
|align="center" |22
|-
|Твердый блок (например, [http://ru.minecraftwiki.net/%D0%91%D1%83%D0%BB%D1%8B%D0%B6%D0%BD%D0%B8%D0%BA булыжник])
|align="center" |1193
|-
|Твердый блок другого цвета (например, [http://ru.minecraftwiki.net/%D0%A8%D0%B5%D1%80%D1%81%D1%82%D1%8C шерсть])
|align="center" |3
|-
|[http://ru.minecraftwiki.net/%D0%AD%D0%BB%D0%B5%D0%BA%D1%82%D1%80%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D1%80%D0%B5%D0%BB%D1%8C%D1%81%D1%8B Электрические рельсы]
|align="center" |6
|}

Лестницу и люк можно не делать, но так удобнее налаживать, ремонтировать и изменять схему. Также надо поставить факелы по своему усмотрению. Между кнопками рекомендуется установить табличку с указанием направлений и названий станций.
<p style="clear: both;"></p>
<gallery style="float: right;" perrow="3">
Image:Redmine-Station-2a.png|Уровень 2
Image:Redmine-Station-3a.png|Уровень 3
Image:Redmine-Station-5a.png|Уровень 5
</gallery>

====Схема сборки для вида на юг или на восток====

Данный вариант отличается уровнями 2, 3 и 5. Изменения помечены штриховкой. Железнодорожные пути сделаны зеркально относительно оси ветки железной дороги. Различия связаны с особенностями работы железной дороги в Redmine и в частности, с особенностью управления стрелками.
<p style="clear: both;"></p>
<gallery style="float: right;" perrow="3">
Image:Redmine-Station-screen-rails-1.png
Image:Redmine-Station-screen-rails-2.png
</gallery>
Рельсы укладываются вот так (показан вариант север/запад):
<p style="clear: both;"></p>

[[Category:Redmine]]

Redmine:Станция железной дороги

2012-01-29T12:24:00Z

RXL: /* Схема с автоматическими стрелками */

{{TOC-right}}

=Станция железной дороги (игра Redmine)=

==Станция электрической дороги с движением в обе стороны==

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

===Схема с автоматическими стрелками===

<p style="clear: both;"></p>
<gallery style="float: right;" perrow="4">
Image:Redmine-Station-screen-control.png
</gallery>
Логическая схема состоит из трех частей:
#Формирование стартового импульса по нажатию любой кнопки.
#Переключение стрелки и возврат в исходное положение через две секунды. Производится по нажатию левой кнопки (если смотреть из вагонетки, то правой).
#Переключение стрелки при проходе вагонетки по нажимным рельсам.

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

Направление движения выбирается нажатием на одну из двух кнопок. При этом вагонетка сразу начинает движение.
<p style="clear: both;"></p>
<gallery style="float: right;" perrow="3">
Image:Redmine-Station-legend.png|Легенда
Image:Redmine-Station-1.png|Уровень 1
Image:Redmine-Station-2.png|Уровень 2
Image:Redmine-Station-3.png|Уровень 3
Image:Redmine-Station-4.png|Уровень 4
Image:Redmine-Station-5.png|Уровень 5
Image:Redmine-Station-6.png|Уровень 6
Image:Redmine-Station-7.png|Уровень 7
</gallery>
====Схема сборки для вида на север или на запад====

Список необходимых ресурсов:
{| border="1" cellspacing="0" cellpadding="2" style="border: 1px solid black; border-collapse: collapse;"
!Тип блока
!Количество
|-
|Кнопка || align="center" |2
|-
|Красная пыль || align="center" |45
|-
|Красный факел || align="center" |16
|-
|Лестница || align="center" |3
|-
|Люк || align="center" |1
|-
|Нажимные рельсы || align="center" |1
|-
|Повторитель (репитер) || align="center" |5
|-
|Рельсы || align="center" |22
|-
|Твердый блок || align="center" |1193
|-
|Твердый блок другого цвета || align="center" |3
|-
|Электрические рельсы || align="center" |6
|}

Лестницу и люк можно не делать, но так удобнее налаживать, ремонтировать и изменять схему. Также надо поставить факелы по своему усмотрению. Между кнопками рекомендуется установить табличку с указанием направлений и названий станций.
<p style="clear: both;"></p>
<gallery style="float: right;" perrow="3">
Image:Redmine-Station-2a.png|Уровень 2
Image:Redmine-Station-3a.png|Уровень 3
Image:Redmine-Station-5a.png|Уровень 5
</gallery>
====Схема сборки для вида на юг или на восток====

Данный вариант отличается уровнями 2, 3 и 5. Изменения помечены штриховкой. Железнодорожные пути сделаны зеркально относительно оси ветки железной дороги. Различия связаны с особенностями работы железной дороги в Redmine и в частности, с особенностью управления стрелками.
<p style="clear: both;"></p>
<gallery style="float: right;" perrow="3">
Image:Redmine-Station-screen-rails-1.png
Image:Redmine-Station-screen-rails-2.png
</gallery>
Рельсы укладываются вот так (показан вариант север/запад):
<p style="clear: both;"></p>

[[Category:Redmine]]

Redmine:Станция железной дороги

2012-01-29T11:53:25Z

RXL: /* Схема с автоматическими стрелками */

Redmine:Станция железной дороги

2012-01-29T11:47:04Z

RXL: /* Схема с автоматическими стрелками */

Файл:Redmine-Station-7.png

2012-01-29T11:42:12Z

RXL: загружена новая версия «Файл:Redmine-Station-7.png»: Исправлены ошибки.