Изпечатай

[laskov]

Пак малко ще гадая. Колко е тънка тази нишка? Според това колко е тънка и каква е стъпката в хоризонтална посока на един оборот на шпиндела, трябва да се предвиди и отместването на следващия пласт, така че нишката да не попада върху нишката от предишния пласт. А колко пласта се навиват? Предполагам, колкото по-малко, толкова по-добре? А има ли вероятност нишката да се скъса? Ще има ли блокировка? Извън темата: В Етъра до Габрово има едни машинки дето правят гайтани и имат блокировка при скъсване на нишка! Ако не се лъжа нишките са 6 или 8. Гледах ги и им се кефих доста време. 

[kennedy]

Нишката варира и като широчина и на тази база се пресмята хода по Х. помислено е за блокировка при скъсване, самия контролер си има съответните изводи за подвързване (има едни изводи за нормално затворен бутон, който се води авариен стоп. нишката ще преминава през едно микро ключе и ще го държи затворено. макар че ми е малко чудно какво би скъсало една карбонова нишка ... ) . Пластовете ще са според зависи .... колкото се наложи 4,5,6 ....
дори различните пластове ще са с различна стъпка ....
но това ще са функции на една команда например "go"
go x6 y100 s200
което ще се преведе така "на всеки 100 стъпки за завъртане на оста трябват 6 по Х интервал между стъпките 200 мс "
тя ще си сметне на колко пулса по Y ще подаде 1 на Х
с помоща на тези параметри се определя и вида на намотките ...
а иначе ще има програма която да генерира параметрите , но това са по-елементарни неща.

[kennedy]

след като изгорих улн2003 на платката , след това и един мощен транзистор заради късо по платката, и след замяната им, и след дозапояването на рейтката, успях да подкарам двигателя отговарящ за оста Х. пин 2 и 3 пин 2 е за посока, пин 3 за стъпка. използвах първата програма която се компилира без проблем. статирайки я с параметър 1 и 3 двигателя славно започна да прави стъпки. т.е. трябва на пина за стъпка да се сетва и 0, защото той не минава сам към 0. ...
другото което ми направи впечатление е, че трябва да съм роот за да имам достъп до порта.

[vstoykov]

Може да се комбинира C и Bash (когато не разбирам някой език добре смесвам няколко езика за програмиране - понякога се получават много бавни програми, но поне не съм губил време в програмиране).  Пример:

Код:

#/bin/bash

lptout някакво_число
usleep 1000000 # 1 секунда
lptout някакво_число
usleep 1000000 # 1 секунда
lptout някакво_число
usleep 1000000 # 1 секунда
lptout някакво_число
usleep 1000000 # 1 секунда

Точността във времето не е голяма, но и при варианта без Bash няма да е кой  знае колко голяма (особено, ако има натоварване в момента с някаква тежка задача).

Ако искаш да пишеш директно двоични числа може да ползваш тази програма на Perl:

Код:

#!/usr/bin/perl

$total = 0;

chomp($binnumber = ($ARGV[0]));

@binnumber = split(//, $binnumber);
$length = @binnumber;

if ( $binnumber[7] == 1 ) {
 $total += 1;
}
if ( $binnumber[6] == 1 ) {
 $total += 2;
}
if ( $binnumber[5] == 1 ) {
 $total += 4;
}
if ( $binnumber[4] == 1 ) {
 $total += 8;
}
if ( $binnumber[3] == 1 ) {
 $total += 16;
}
if ( $binnumber[2] == 1 ) {
 $total += 32;
}
if ( $binnumber[1] == 1 ) {
 $total += 64;
}
if ( $binnumber[0] == 1 ) {
 $total += 128;
}

print "$total\n";
exit(0);

Задължително се пишат и 8-те бита на двоичното число.

Примерно ползване в скрипт:

Код:

#/bin/bash

lptout $(bin2dec.pl 00000100)
usleep 1000000 # 1 секунда

lptout $(bin2dec.pl 00000010)
usleep 1000000 # 1 секунда

lptout $(bin2dec.pl 00000111)
usleep 1000000 # 1 секунда

lptout $(bin2dec.pl 00000000)   # нулиране

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

[kennedy]

проблема е че за 1 оборот ще са необходими 1000-2000 импулса, за една навивка около 20 оборота т.е. 20000-40000 реда.
по скоро команда която подава серия от импулси например
go 1 2000 1 500 200
parameter 1 = посока по х
parameter 2 = брой импулси по х
parameter 3 = посока по y
parameter 4 = брой импулси по Y
parameter 5 = закъснение в милисекунди.
като програмата трябва да си раздели x/y за да види на колко импулса по едната ос трябва д аподаде импулс по другата ос.
това сложно ли ще бъде?

[kennedy]

такаа, има програмата (благодаря Станиславе) но възникна един проблем, при тестовете се оказа, че при зададени например 10000 стъпки през 100 мс се усеща неравномерно въртене, усеща се тук таме някое засичане. Отдавах го на хардуерната част, докат не изпробвах програмата под RTOS (ubuntu 8.10) .. там същата тази програма (дори не съм си играл да я прекомпилирам) работеше гладко без да се усеща някакво накъсване при далеч по-кратки интервали 50мс ....
на какво може да се дължи това нещо и как мога в една не РТОС да подавам информация през порта без да ми се пречкат ?

[spirtbrat]

Ами, дължи се точно на разликите между Ubuntu и RTOS Ubuntu (както и Ubuntu Studio). Ядрото си има особености свързани с многозадачността и поведението му, както сигурно знаеш, зависи от настройката му. В RTOS системите, то е настроено така, че да е много отзивчиво с цел програмите да вървят изключително гладко. А в стандартните системи се залага на по-добрата скалируемост, тъй като отзивчивостта не е критичен фактор при тях.
http://en.wikipedia.org/wiki/Real_time_operating_system
http://www.ibm.com/developerworks/linux/library/l-real-time-linux/
http://www.linuxdevices.com/news/NS8393438079.html

[kennedy]

да, но разликите са фрапантни ... би следвало да има начин и с обивновенна ос да се управлява ...
нещо бъркам някъде.
когато печаташ на принтера, ако така се бави .... ще печата 1 страница на минута

[spirtbrat]

Принтера си има собствена памет. Когато си получи страницата, тогава започва да принтира, а не да му се подава буква по буква
Ти искаш да подаваш сигнали на твоята машинка един по един и без никакво забавяне. Това няма как да стане със стандартна система. Замисли се - като си пуснеш музика, тя трябва да свири без прекъсване, но на обикновената система аудио потока не е непрекъснат. Затова си има буфери, двойни буфери и дори тройни буфери за по-тежките задачи, които трябва да се изпълняват без прекъсване като 3D графика, HD видео възпроизвеждане и т.н.

Стандартната система, като получи команда и се заеме със задача, има нужда да извърши определен брой операции, за да може да е на разположение за следващата команда. Тези операции отнемат различни по-продължителност отрязъци от време в зависимост от типа им. В многозадачна среда организацията на работа на системата е сложна и има множество подробности и особености.

RTOS системите целят да направят тези интервали от време, през които системата не е на разположение, еднакви по продължителност и възможно най-кратки.
На тебе ти трябва точно такава система.

Ако се интересуваш, почети малко в нета. Хората са го обяснили по-добре от мен.

[kennedy]

прав си, не помислих за буферите ....