Svenska ElektronikForumet

Har suttit och labbat en del nu och försökt förstå dataformatet med hjälp av din förklaring, det som är totalt förvirrande är att den sniffade trafiken fungerar men stämmer inte med manualen.

Kör jag detta så går den igång.
#01
0901001C00000002 < powerstage enable
0901002600000001 < electronic gear enable
0901002400000400 < vel + (rpm på slutet)
Svaret från servon blir 0101002400000400
09010024FFFFFE14 < vel -

#01
0901001C00000000 < powerstage disable
0901002600000000 < electronic gear disable

Det verkar inte som att jag behöver växla några bitar mellan gångerna utan samma kommando fungerar varje gång troligen för att jag använder short transmit command?

sid 21 i protokoll manualen:
Short transmit command
The contents of the value readdata can also be requested via the short
control command <CR> (0Dh).
The slave sends the current status information to the master as an acknowledgement. Bits sf and rf for the acknowledgement mechanism do not change

Sen med 84 i början händer inte något.
Det är inte svaren som börjar med 09 utan det jag skickar och även vad CT programmet skickar, ser tydligt på vad som skickas och läses i sniffern (2 olika fönster)
CT programmet skickar dock en hel del kommandon som börjar på 02, mest status koll tror jag på spänning och sånt.

Har även testat att köra med mach3, ändrat baud osv i servon så att den skall kunna prata med mach3s inställnigar.
Dock får jag inget svar alls när jag skickar iväg med script editorn, det kommer upp i serie snifferns write fönster men inget svar som jag fått tidigare med putty.
Troligen är detta väll för att mach3 serie modulen är 1 vägs?
Såg på din sida att man kunde ladda in en annan driver, tror du det skulle fungera bättre?

Putty fungerar med samma settings som jag satt i servon men inte mach3.

Hej,
OK, jag förstår inte heller varför det skall vara 09 som första byte, det betyder att bit 0 och bit 3 är satta och de har ju ingen betydelse enligt manualen - eller missar jag något? Att CT programmet ibland skickar 02 som första byte köper jag för då är ju bit 1 satt ("write command") men inte bit 7, om bit 7 också vore satt skulle det vara 84h.

Det är riktigt att du i Mach3 inte kan ta emot svaret från motorn men den skall ju fortfarande skicka ett svar (det är bara det att det inte finns någon rutin i Mach3 för att läsa det). Om du verkligen vill ta emot svaret så måste du använda en extern api för serieporten, t.ex den jag presenterar på min sida. Men, i princip så ska ju inte det behövas.

När du sniffar trafiken och skickar från Mach3, får du exakt samma resultat på "utgående" trafik då (men ändå inget svar från motorn) eller ser det annorlunda ut? Har du startat om Mach3 efter att du ändrat Port och Baudrate? Du säger att du ändrat baudrate i motorn, är du säker på att den inställningen "fastnat", har du provat den baudraten från putty?

En sista grej, det står att varje kommando skall avslutas med <CR>, exakt hur ser det i sniffern när du skickar något som fungerar - med putty eller CT? Är det en vagnretur i slutet på varje rad?

Tänk på att du inte ser svaret från servo-drivaren om inte mach3 försöker läsa det när du kör med en sniffer i windows.
Skulle du däremot lyssna på dom fysiska portarna så ska det synas.

Jag säger inte emot men...say what?
Menar du att sniffern normalt "interceptar" anropet från applikationen till operativsystemet att LÄSA bufferten istället för att "plocka upp" vad som faktiskt kommer in TILL bufferten? Om så är fallet så kan det ju förklara varför det inte verkar komma något svar över huvud taget, good point!

Min begränsade erfarenhet av "port-sniffar-applikationer" är att de plockar upp den faktiska trafiken på porten - inte den mellan operativsystsmets buffert och applikationen som accessar den.

Nu fungerar det i mach3 med!
det var det mycket ologiska förklaring av servons comports settings som blev fel
Satte detta till 4 igår för att mach 3 skulle kunna prata med den vilket borde enligt mig bli.
8-N-1
Men arbetar inte bit 0 och 1 ihopa?
bit 0 slår på eller av paritet och bit 1 sätter even eller odd?

Satte jag den till 5 så fungerar det i mach3 av någon anledning...
Det borde då bli Parity on,
fattar inte något av hur de tänker där.
Eller läser jag bitarna fel?

RS485.serFormat 22:3 (16:03h)

Data format
Assignment of bits:
Bit 0: 0 = no parity, 1 = parity on
Bit 1: 0 = parity even, 1 = parity odd
Bit 2: 0 = 7 data bits, 1 = 8 data bits
Bit 3: 0 = 1 stop bit, 1 = 2 stop bits
Default is 0 = 7-E-1


vb koden aktiverar drivsteget och drar igång electronic gear!
SendSerial( "#01" & Chr(13) )
SendSerial( "0901001C00000002" & Chr(13) )
SendSerial( "0901002600000001" & Chr(13) )

Nu har jag grunden för att kunna testa servona på fräsen som idag kör stegare.
Hoppas de orkar, annars får jag dreva dem kanske, problemet är att servona spinner upp till 6-7k rpm....

Ja, dokumentionen verkar lite märklig....
22.3=0 borde vara 7-N-1
22.3=4 borde vara 8-N-1
22.3=5 borde vara 8-E-1
Sen står det att default är 0=7-E-1, det stämmer ju inte alls.... och det där med att första byte'n är 09 istället för 84 eller 2 förstår jag fortfarande inte.

Men strunt samma, nu fungerar det ju! Lycka till med fortsättningen!

Tackar så väldans för att du tog dig tid!
har underlättar massor.
Kanske kommer någon mer fråga när jag kommer vidare och monterat servona osv.

Hittade detta i en äldre manual för servona (bergher larh som de var tidigare)

Data format
Bit0: 1=no parity, 0=parity on
Bit1: 1=parity odd, 0=parity even
Bit2: 1=8 data bits, 0=7 data bits
Bit3: 1=2 stop bits, 0=1 stop bit
Default is 0 = 7-E-1

Där stämmer det.

Står det något annorlunda om första byte'n - den som är 09h nu?

Inte vad jag kunde hitta, sökte på de olika och hittade fortfarande de jobbiga ref till 84h och 80h.
Kan vara firmware ändring eller dyl, får lura på det.