Budżet: 13000 UAH Termin: 30 dni
Готов взяться. Богатый опыт разработок систем управления электро аппаратов. Необходимо уточнить некоторые моменты по ТЗ.
1) режим разогрева
Тэн включается на пред установленную мощность,от 100 ватт до 5 кВт,шаг регулировки по 10ватт.
2) Произошел нагрев до температуры 58-60°С на датчике 3 ,нагрев выключился на 2 минуты.
3)Нагрев включается на ранее пред установленную мощность(от 100ватт до 5000кВт,шаг регулировки по 10ватт).
4)температура на датчике 2 резко подымается и после стабилизации на одной температуре(примерно 78°С),фиксируется.
5)После стабилизации температуры и полу часа работы в этом режиме,открывается электромагнитный клапан (12 вольт) со скоростью отбора 100 мл в час(в пред установках от 50мл до 400мл,шаг регулировки по 10 мл).
6) после отбора определенного количества в мл (допустим 250 мл, количество отбора устанавливается заранее), электро магнитный клапан открывается на заранее заданную скорость отбора (от 50 мл до 3 литров в час) отбирается еще 5% (примерно 250мл), от общего заранее заданного литража .
7) Далее электро магнитный клапан открывается на заранее пред установленную скорость,от 100мл до 3-х литров в час.Отбор происходит стабильно с одной скоростью,пока температура датчика 1, не достигнет 84°С,далее,с каждым поднятием температуры на 1°С,на датчике 1,скорость отбора уменьшается на 5%, от общего литража.
8)После достигнутой температуры 80-98°С(температура на датчике 1 выставляется заранее,от 80 до 98°С,шаг 1°С) на датчике 1(куб),скорость отбора уменьшается,до скорости отбора хвостов(от 50 мл до 2-х литров в час,шаг регулировки 10 мл).
После достигнутой температуры 90-98°С(устанавливается предварительно,шаг 1°С),нагрев тэном закончен.
Автоматика остается включенной и сигнализирует миганием экрана и звуковым сигналом.пока оператор не нажмет кнопку стоп.
9)Датчик 3 ,пред установленная температура от 55 до 65°С,если на датчик 3, поступает температура заранее заданная,то выключатся нагрев и сигнализирует звуком и мерцанием экрана до того,как оператор не нажмет кнопку стоп.Пишет перегрев ТСА.
10) Датчик 2, после достигнутой стабильной температуры(примерно 78°), температура должна быть стабильной и перепад температуры может быть максимум на 0,1-0,2°С,если же температура на датчике 2 поднялась на 0,3°С, электро магнитный клапан закрывается на 20-30 минут и сигнализирует оператору о превышенной температуре датчика 2, после 2-х - 3-х таких "залетов" по температуре датчика 2, автоматика выключает нагрев и сигнализирует об этом оператору "превышена температура датчика 2".
11)Датчик 1( в кубе), при превышении температуры 100-102°С, сигнализирует об оголенном тэне,в баке нет жидкости,нагрев тэна выключается и сигнализирует оператору "В баке нет жидкости".
12)Так же, каждый отдельный процесс,первых 5 %,вторых 5%, отбор тела 90%,отбор хвостов 5%, на табло отображается во времени каждого процесса и всего процесса в целом.
13)Каждое окончание процесса,за 5 минут сигнализирует о смене тары(звуковым и световым эффектом).
14) температурные датчики должны иметь возможность калибровки.
15)Мощность подаваемая на тэн,должна быть стабильной +1 -1 вольт.
Автоматика должна быть с сенсорным экраном(тач) 3.2"-3,5".
Должно быть несколько режимов.Автоматический процесс(ректификация),задается оператором и сохраняется и ручной режим, в котором оператор задает параметры каждый раз отдельно,оба режима имеют возможность корректироваться во время работы(шим регулировка скорости отбора и нагрев тэна).
Так же в перспективе возможность оснащения вайфай модулем,что бы была возможность передавать информацию на мобильный телефон.(небольшое приложение как для андроид, виндовс и для айфонов).Рассматривается,как доп. функция, не факт что понадобится.
Так же,рассматриваем вариант в этом же устройстве функции дистилляция и пивоварения, принцип задач сброшу позже.
Интересует разработка полной прошивки с возможностью доработки,а так же совет по железу(Какие комплектующие нужны и возможно единоразовый макет).
Так же, будет отображаться определенная не сложная графика на дисплее автоматики.
Какая может быть стоимости данного объема работы и сроки выполнения.
С уважением Анатолий.
Budżet: 13000 UAH Termin: 30 dni
Готов взяться. Богатый опыт разработок систем управления электро аппаратов. Необходимо уточнить некоторые моменты по ТЗ.
Budżet: 30000 UAH Termin: 30 dni
Здраствуйте.
Предлагаю свои услуги по выполнению данного проекта.
У меня есть практический опыт разработки и наладки автоматики технологического оборудования.
В указанную цену входит стоимость разработки принципиальной схемы, написание прошивки контроллера, изготовление рабочего прототипа устройства и монтаж и пуско-наладочные работы на Вашем оборудовании.
С уважением, Сергей.
Budżet: 30000 UAH Termin: 21 dni
Здравствуйте. Сделаем!
Budżet: 30000 UAH Termin: 60 dni
Первый вопрос, который возник у меня, есть ли определенность с исполнительными механизмами и датчиками то есть с клапаном, датчиками температуры и т.д.
Budżet: 15000 UAH Termin: 25 dni
Добрый вечер! Могу сделать ваш проект. Можем обсудить подробнее. Цена и сроки указаны примерно, точнее можно будет сказать после обсуждения.
Dzień dobry Należy stworzyć moduł, który będzie działał z bazą danych Firebird w C++ do sprzedaży towarów. Są przykłady gotowych rozwiązań oraz opis funkcjonalności modułu. Główne funkcje: autoryzacja, wybór towaru na ekranie z grup/podgrup, przejście do koszyka, płatność kartą oraz druk paragonu. Program powinien działać na Windows 10 i wyżej, korzystać z istniejącej bazy danych.
Wymagana jest разработка łatki do sterownika karty graficznej, rozszerzającej możliwości zarządzania adapterem graficznym poprzez dodanie dodatkowych ustawień użytkownika. Łatka powinna integrować się z istniejącą architekturą sterownika bez naruszania jego podstawowej funkcjonalności i zapewniać zgodność z obsługiwanymi wersjami systemu operacyjnego. Głównym celem jest zapewnienie bardziej elastycznego dostępu do parametrów, które są niedostępne w standardowej panelu sterowania, z możliwością ich zmiany przez interfejs użytkownika lub programowe API. Łatka powinna przewidywać modułową strukturę, umożliwiającą w przyszłości dodawanie nowych parametrów bez istotnej przeróbki kodu. Należy zapewnić poprawne przetwarzanie błędów, rejestrowanie zmian, możliwość przywrócenia ustawień do wartości domyślnych, a także zachowanie zgodności z przyszłymi aktualizacjami sterownika, o ile to możliwe. Rozwiązanie powinno być dostarczone z dokumentacją techniczną opisującą architekturę, zrealizowane możliwości, ograniczenia oraz zalecenia dotyczące testowania.
Jesteśmy dużą firmą logistyczną, która ma własny eksport. Dysponujemy dużym parkiem samochodowym i nieustannie wysyłamy nasze pojazdy na eksport do krajów Europy.Opis Strona: https://echerha.gov.ua/ Na tej stronie umieszczamy nasze samochody w elektronicznej kolejce do przekroczenia granicy państwowej. Podczas rejestracji należy wprowadzić następujące dane: imię i nazwisko kierowcy; numer paszportu zagranicznego; adres e-mail; numer telefonu logisty do otrzymywania powiadomień; typ pojazdu (ciężarowy); nazwa producenta samochodu; numer rejestracyjny ciągnika; numer rejestracyjny przyczepy; numer deklaracji celnej. Dla każdego samochodu z góry określono konkretny dzień i godzinę przekroczenia granicy. Na przykład, samochód musi przejść przez punkt kontrolny „Rawa-Ruska” w poniedziałek o 10:00.Nasz problem - Kolejka na stronie https://echerha.gov.ua/ porusza się nieprzewidywalnie. - Na przykład, dzisiaj jest piątek, a samochód musi przekroczyć granicę w poniedziałek o 10:00. - Nie wiemy, kiedy dokładnie kolejka zacznie się posuwać. Może to nastąpić w piątek wieczorem, w dowolnym momencie w sobotę lub niedzielę, wcześnie rano, w ciągu dnia lub późno wieczorem. - Kiedy kolejka zaczyna się poruszać, jest to od razu widoczne na stronie. Czasami w ciągu zaledwie kilku minut może przesunąć się z piątku na poniedziałek lub nawet na wtorek. - Z tego powodu logistycy muszą nieustannie kontrolować aplikację mobilną lub stronę internetową, aby nie przegapić momentu, gdy kolejka dojdzie do potrzebnej daty i godziny. Jeśli ten moment zostanie utracony, fizycznie nie zdążamy umieścić samochodu w kolejce na odpowiedni slot czasowy.Zadanie - Po wprowadzeniu danych o samochodzie (na przykład do tabeli lub innego interfejsu, w zależności od realizacji programisty) system powinien automatycznie śledzić ruch kolejki. - Kiedy kolejka dojdzie do wcześniej określonej daty i godziny, system powinien automatycznie wypełnić wymagane dane i umieścić samochód w kolejce bez udziału logisty.
Szukam doświadczonego programisty TrinityCore 3.3.5a, który dobrze zna się na strukturze jądra, systemie Battleground, C++, SQL i kliencie WoW 3.3.5. W projekcie zintegrowano już niestandardowy Battleground „Dolina Niewolnictwa” (Slavery Valley), przeniesiony z AzerothCore na TrinityCore. Główna część pracy została już wykonana, jednak wymaga doprowadzenia do poziomu Blizzard.Co już zrobiono TrinityCore 3.3.5a + Eluna. Serwer w pełni skonfigurowany. Battleground zintegrowany z jądrem. Działa wejście do BG. Działa interfejs klienta (częściowo). Przeniesiono większość SQL i DBC. Buduje się bez błędów.Co należy zrobić Naprawić pozostałe błędy Battleground. Doprowadzić mechanikę do poziomu oficjalnych Battleground Blizzard. Naprawić fazę startową meczu. Wdrożyć poprawne bramy startowe/ściany ognia. Naprawić mechanikę przejmowania punktów. Naprawić zakończenie meczu. Sprawdzić przyznawanie punktów i działanie WorldState. Naprawić pozostałe problemy C++ i SQL. Przeprowadzić pełne testy gry.Wymagania Obowiązkowe doświadczenie: TrinityCore 3.3.5a; C++; SQL (MariaDB/MySQL); DBC; MPQ; Visual Studio; CMake; Git. Dużym plusem będzie: AzerothCore; Eluna; doświadczenie w tworzeniu Battleground; znajomość części klienckiej WoW 3.3.5a.Format pracy Praca etapowa. Po każdym etapie obowiązkowe testowanie. Każdy etap akceptowany tylko po weryfikacji w grze. Potrzebne są zrozumiałe raporty dotyczące zmian.W przyszłości To długoterminowy projekt. Po zakończeniu Battleground planowane jest: przeniesienie nowych Battleground; przeniesienie nowych aren; nowe rasy; nowe klasy; nowe systemy gry; dalszy rozwój własnego serwera World of Warcraft 3.3.5a. Szukam programisty, który już pracował z TrinityCore i będzie w stanie nie tylko pisać kod, ale doprowadzić system do w pełni działającego stanu.nie serwer z 0 jak chcę Jeśli szukasz programisty nie tylko na jeden Battleground, ale na stworzenie serwera od podstaw, to ogłoszenie powinno wyglądać mniej więcej tak.Nazwa projektu Rozwój serwera World of Warcraft 3.3.5a od podstaw (TrinityCore / C++ / SQL / Eluna)Opis projektu Szukam doświadczonego programisty TrinityCore 3.3.5a do długoterminowej współpracy. Potrzebuję osoby, która będzie w stanie od podstaw stworzyć w pełni gotowy serwer gry World of Warcraft 3.3.5a na bazie TrinityCore z dalszym rozwojem projektu. Projekt jest duży i przewidziany na kilka miesięcy rozwoju.Podstawa projektu TrinityCore 3.3.5a. Jak najbardziej stabilna i zbliżona do Blizzard baza. Eluna Lua Engine. MariaDB. Visual Studio + CMake. Git.Co planuje się zrealizować W pełni działający serwer 3.3.5a. Naprawa błędów jądra. Rozwój nowych systemów gry. Integracja niestandardowych Battleground. Integracja nowych aren. Przeniesienie użytecznych modułów z AzerothCore na TrinityCore. Rozwój własnych modułów. Nowe systemy PvP i PvE. Nowe wydarzenia w grze. Balansowanie klas. Dodatkowe systemy progresji. Poprawa wydajności serwera.W przyszłości Po zakończeniu podstawowej części planowane jest: nowe rasy; nowe klasy; nowe strefy; nowe lochy; nowe rajdy; nowe Battleground; nowe profesje; nowe mechaniki gry; integracja nowoczesnych systemów w kliencie 3.3.5a.Wymagania dla programisty Obowiązkowe: Doskonała znajomość TrinityCore 3.3.5a. Pewna znajomość C++. SQL (MariaDB/MySQL). Git. Visual Studio. CMake. Znajomość architektury TrinityCore. Doświadczenie w pracy z Battleground, PvP i mechanikami gry. Dużym plusem będzie: Doświadczenie w pracy z AzerothCore. Eluna Lua Engine. Praca z DBC i MPQ. Doświadczenie w tworzeniu własnych systemów gry.Format pracy Praca etapowa. Każde zadanie jest dokumentowane jako osobne zadanie techniczne. Po każdym etapie przeprowadzane są obowiązkowe testy. Praca akceptowana tylko po weryfikacji bezpośrednio w grze. Potrzebny jest programista, który potrafi doprowadzić funkcjonalność do w pełni działającego stanu, a nie tylko pisać kod.