proiect interesant (zic eu) cu microcontroler

[vsurducan]

[quote name="townkat

Si pentru ca am pomenit de coeficientii de inertie' date=' trebuie sa va spun ca asa ma si gandisem sa rezolv si problema inertiei, prin niste algoritmi de anticipatie. Aidica la prima rulare a ansamblului modul-putere-motor in sistem, se vor face cateva teste in gol si in sarcina pentru determinarea timpilor si distantelor de accelerare si franare. Apoi totul ramane o problema de fizica. Algoritmii vor fii implementati in microcontroler iar coeficientii vor fii transmisi fiecarui microcontroler in parte la fiecare pornire a sistemului (pentru ca memoriile din microcontroler sunt read-only aceste informatii vor fi stocate pe PC).

[/quote]

 

Este vorba despre o bucla de reglaj realizata fie cu feedback digital de la PC (datele de la encoder sunt prelucrate de PC, corelate cu distanta urmarita si retransmise pentru comanda motorului) fie cu feedback local (microcontrolerul realizeaza integral atat citirea encoderului cat si comanda motorului) datele de la encoder trimise spre PC avand efect doar la o noua comanda de rotire motorului.

 

Orice varianta ati alege din cele doua, utilizand un motor DC tot prost este, deoarece poate avea loc oscilatia mecanica a sistemului in jurul punctului de reglaj. Motorul trebuie obligatoriu franat (cel putin electromagnetic din comanda) si orice estimare a inertiei mecanice a sistemului prin software (pe baza de experiment prealabil) este sortita esecului pentru ca nu exista sistem mecanic perfect reproductibil.

Daca o fi CAN sau RS485 asta nici nu mai conteaza.

Apropo, memoriile sunt read-write ca altfel n-ar fi EEPROM sau flash.

 

Trebuie adaugat ca initiatorul topicului nu are experienta in lucrul cu microcontrolere si acesta ar fi un proiect de debut (daca il va realiza), asa ca pastrati va rog lucrurile cat mai simple.

[Vizitator townkat]

Este vorba despre o bucla de reglaj realizata fie cu feedback digital de la PC (datele de la encoder sunt prelucrate de PC, corelate cu distanta urmarita si retransmise pentru comanda motorului) fie cu feedback local (microcontrolerul realizeaza integral atat citirea encoderului cat si comanda motorului) datele de la encoder trimise spre PC avand efect doar la o noua comanda de rotire motorului.

deacord, ma gandeam sa il fac cu feedback local

 

Orice varianta ati alege din cele doua, utilizand un motor DC tot prost este, deoarece poate avea loc oscilatia mecanica a sistemului in jurul punctului de reglaj. Motorul trebuie obligatoriu franat (cel putin electromagnetic din comanda) si orice estimare a inertiei mecanice a sistemului prin software (pe baza de experiment prealabil) este sortita esecului pentru ca nu exista sistem mecanic perfect reproductibil.

corect, sunt deacord cu franarea din comanda

 

Apropo, memoriile sunt read-write ca altfel n-ar fi EEPROM sau flash.

ma gandeam ca este destul de complicat sa scrii in flash niste date la runtime care sa ramana acolo si dupa un reset.

 

Trebuie adaugat ca initiatorul topicului nu are experienta in lucrul cu microcontrolere si acesta ar fi un proiect de debut (daca il va realiza), asa ca pastrati va rog lucrurile cat mai simple.

foarte adevarat, chiar ma gandesc sa-mi trec in semnatura asta :smt003

 

Multumesc.

[puiu]

1. Din cate am inteles eu este vorba de realiazrea unei magistrale de comunicatie intre mai multe noduri, pe care se transmit date (comenzi si stari ca sa le zic 'finale' si nu cele de comanda propriuzisa a motorului (acestea fiind prelucrate la nivelul nodului si in functie de motor) ) care accepta o mica intarziere (10-100ms). Daca ipoteza mea este corecta atunci cred ca trebuie neaparat sa analizam problema neaparat pe bucatele si ca alegerea BUS devine oarecum independenta de comanda efectiva a motorului si de pozitionarea lui.2. Oricum alegerea motorului este esentiala pentru modul de reglaj si modul de comanda utilizat. Oricum precizez ca motor AC nu inseamna stepper (asa mi se pare ca am inles dintr-un raspuns anterior). 3. Din cate inteleg din discutia pe forum am devenit fara sa vreau un sustinator al magistralei CAN. Pentru ca trebuie sa analizam toate variantele si sa dicutam chiar contradictoriu dar constructiv, am sa dau cateva elemente pro aceasta magistrala: -Controller Area Network (CAN) (controlerul de reţea zonal) este un protocol de comunicaţii serial care realizează eficient comenzi în timp real distribuite cu un înalt nivel de securitate. -Domeniul sau de aplicaţii este în reţele de mare viteză la cost redus interconectate multiplexat, în automatizările electronice , unităţile de control pentru motoare, senzori, sisteme ??anti-skid?? (antiderapante), etc. se fac conectări utilizând CAN cu viteza de 1Mbit/s. în acelaşi timp trebuie considerat costul său efectiv pentru a-l implementa în electronica din interiorul vehicolului, de exemplu pentru becuri, geamuri cu comanda electrica etc. pentru a înlocui mulţimea de fire necesare în caz contrar. -Legătura de comunicaţie seriala CAN este un ?bus? la care pot fi conectate un număr de unităţi. Acest număr este teoretic nelimitat. Practic numărul total de unităţi va fi limitat de timpii de întârziere şi/sau încărcarea electrica a liniei de bus. Pentru MCP2551 (driver care se conecteaza intre magistrala si PIC) sunt acceptate maxim 112 noduri.Cu respect,

[vsurducan]

Am aruncat o privire sumara pe datasheetul lui MCP2551 si pot sa spun ca-mi place, deci nu mai sunteti unicul sustinator pro CAN.

Dpdv hardware, diferentele intre driverele de RS485 si acest MCP2551 sunt minore, exceptand controlul slew rate-ului si faptul ca viteza minima de comunicatie este fixata. Inteleg ca si conversia RS232-CAN poate fi realizata relativ usor. Ceea ce inca nu am studiat este topologia retelei CAN si cum se realizeaza full duplex-ul (banuiesc ca prin dublarea bus-ului)... oricum n-ar fi nevoie decat de half duplex aici.

In ceea ce priveste algoritmii de lucru, nu ma pot pronunta pentru ca n-am cititi nimic despre ei.

 

Despre motor insa, daca e musai sa fie DC, atunci solutia ar putea fi ceva similar cu aceasta:

http://www.robotechsrl.com/robodesigner/output.asp

Eu am aceste reductoare, le-am pipait si sunt extraordinare. Se poate chiar schimba turatia/puterea prin reconfigurarea rotilor si merge la tensiune redusa (4-5V). Cuplul este incredibil (nu poate fi oprit cu mana).

[Vizitator townkat]

cred ca trebuie neaparat sa analizam problema neaparat pe bucatele si ca alegerea BUS devine oarecum independenta de comanda efectiva a motorului si de pozitionarea lui.

deacord

 

Oricum alegerea motorului este esentiala pentru modul de reglaj si modul de comanda utilizat.

nu pot alege un motor pentru ca nu am o aplicatie anume de facut, daca nu m-am facut inca inteles in aceasta privinta ganditiva pur si simplu ca modulul meu nu comanda un motor ci doua leduri . (encoderul nu stiu cum il adaptez la analogia asta dar... )

 

comenzi în timp real distribuite cu un înalt nivel de securitate.

securitate = integritatea datelor?

 

se fac conectări utilizând CAN cu viteza de 1Mbit/s

cred ca 1kb/sec e suficient pentru ce imi trebuie mie , da nici 1MB nu ma deranjeaza

 

Despre motor insa, daca e musai sa fie DC, atunci solutia ar putea fi ceva similar cu aceasta:

http://www.robotechsrl.com/robodesigner/output.asp

nu este musai sa fie DC, insa este musai sa mearga si cu DC, si cu AC si cu OriCe

foarte interesant motorasul cu reductor , cred ca destul de potrivit pentru multe aplicatii, insa e important si pretul, cat e unul?

[vsurducan]

Towncat, datele de intrare sunt suficiente. SICU-SICU nu se poate, motiv pentru care intepenim proiectul pe motor DC. Daca doriti sa ajungeti sa vindeti un modul universal o sa trebuiasca sa-l construiti in etapa a doua pe baza experientei acumulate.Asadar, astept cu nerabdare schema electronica pe care o propuneti, in format eagle.Despre preturile motoarelor exista un "inquire form" pe siteul respectiv, scrieti va rog si intrebati producatorul (este o companie italiano-japoneza, italienii fac mecanica, japonezii electronica). Intregul robot costa in Japonia $100, banuiesc ca motoarele nu sunt mai scumpe de $20.

[puiu]

1. Asa cum am spus intregul protocol este stufos deoarece are foarte multe elemete de securitate (nu de incriptare). Norocul nostru este ca modulul CAN din PIC face partea grea, pentru noi ramanand partea de transmisie si receptie.2. Comunicatia este pe doua fire si nu este full-duplex ci are o intreaga filozofie de rezolvare a prioritatii. Sper ca dupa -masa sa am timp sa va dau date despre BUS. Oricum va informez ca autorul este R. Bosch si ca protocolul este standardizat si ca a fost realizat pentru transmisia pe automobile a datelor. Relevant este faptul ca se adapteaza la viteza la starea retelei si ca stie sa refaca mesajele pierdute.3. Am gasit la serviciu o scurta prezentare a retelei CAN pe care o atasez.Cu respect,A.P.Duban

[puiu]

1. Asa cum am promis va redau in anexa cateva documentatii de firma. Precizez ca se adreseaza mai mult celor care stiu limbajul C, din pacate eu lucrez in ASM, dar ma mai inspir din C.

2. cer scuze ca revin cu al doilea mesaj, dar suntem cam putini care comunicam.

3. Bazele teoretice ale comunicatiei se gasesc pe http://www.can.bosch.com

4. Sper ca nu sperii cu partea teoretica.

Cu respect

[Vizitator townkat]

4. Sper ca nu sperii cu partea teoretica.

:smt003

 

Inteleg ca accentul in CAN se pune pe partea de securitate, ceea ce este chiar bine, dar nu cumva se complica cam mult jucaria? am vazut acolo ca mai apar niste integrate cand cu rs485 ma legam direct la controller cu busul. Nu stiu, zic si eu , asta totusi nu este un autovechicul in care o eroare poate sa duca la pierderea de vieti.

Intrebari:

1. Pot comunica cu CAN prin hyperterminal cu pot cu rs485?

2. RS485 nu are si el niste algoritmi de corectie?

 

Daca doriti sa ajungeti sa vindeti un modul universal

:(, imi pare rau ca ati inteles ca vreau sa fac bani din vanzarea acestui modul, v-am scris si pe pm ca m-as bucura sa il pot pune pe net cu titlul freeware daca va iesii ceva.

 

Asadar, astept cu nerabdare schema electronica pe care o propuneti, in format eagle.

nu stiu nici acum ce controler sa aleg, si nici ce bus (as face-o cu rs485 ca pare mai simplu).

[puiu]

1. Exista in comert chiar adaptor CAN - RS232, daca vrei. De regula intre microcontroler si bus este un integrat pe post de dreiver. Eu am propus MCP2551 deoarece este produs de MICROCHIP ca si microcontrolerul.2. In una din documentatii, daca nu ma insel AN816, aveti mai multe variante de utilizare a magistralei CAN si aveti si cazul cand nu ai microcontroler cu modul CAN si atunci se utilizeaza MCP2510 pe post de micontroler de comunicatie intre un micontrollerul fara CAN si driver. Foarte multe microntrollere au implementat modulul CAN, asa ca probleme cele grele le preia hardul respectiv.Atasat iti trimit explicatii pe partea de hard si o traducere mai putin pretentiosa a cea ce inseamna protocolul CAN.3. Am avertizat ca partea teoretica a protocolului este stufoasa si ca nu vreau sa sperii pe nimeni cu ea.Traducerea vad ca nu pot sa o trimit, dar am sa vad maine ce s-a intamplatCu stima,

[puiu]

1. Nu stiu de ce nu pot sa postez documentul cu extensia .doc. Are 17 pagini, deci este mult ca sa-l includ aici.2. townkat decide pe ce magistrala se va merge. Daca nu va fi CAN, atunci eu ma opresc cu datele despre aceasta magistrala. Nu este nici o suparare, de aceea suntem pe forum, ca sa schimbam idei si alte cele.Cu stima,

[Blind]

Baga-l intr-o arhiva si apoi vei putea sa atasezi fisierul.

[vsurducan]

1. Nu stiu de ce nu pot sa postez documentul cu extensia .doc. Are 17 pagini, deci este mult ca sa-l includ aici.

2. townkat decide pe ce magistrala se va merge. Daca nu va fi CAN, atunci eu ma opresc cu datele despre aceasta magistrala. Nu este nici o suparare, de aceea suntem pe forum, ca sa schimbam idei si alte cele.

Cu stima,

V-as ruga sa-l trimiteti la [email protected], sunt interesat.

 

Multumesc

[vsurducan]

Fotografia promisa a encoderului analogic, 2K 2% liniaritate.

[puiu]

1. Ce curent maxim admite encodorul analogic? Presupun ca este un encodor potentiometru si l-as cupla pe o intrare analogica a PIC-ului cu o tensiune maxima de referinta 4,096V pentru avea o rezolutie de 4mV pe o diviziune(rezolutie pe 10 biti).Cu respect,