Varför tar vissa saker lång tid i Mach3.

[Bobbox]

Problemet är detta:
Jag behöver stanna en spindel i rätt läge för en verktygsväxling (Dynamyte)
Det sitter en givare på spindeln när den är i rätt läge, det finns några grader i rotationen att spela på.
Jag kör spindeln så sakta jag kan, under 10 varv per minut.
Jag läser av givarens input i macrot, den väntar bara på givarens signal och när den får den så sätts bromsen åt och spindeln stannar.
Men Mach3 är så segt så det tar 1sekund innan bromsen slår in och spindeln snurrar för långt.
Då försöker macrot igen och den håller på så en stund, har lagt en liten slinga så att spindeln snurrar på lite och stannar precis innan givaren
så att när den accelerar upp får signalen så att den hinner stanna.
Kan väl nämna att jag har Smoothstepper via nätverk.
Nu funderar jag på att koppla in en arduino till signalen och att den slår till bromsen i två sekunder tills att Mach3 har hunnit reagera.
Finns det något jag kan göra så att Mach3 reagerar fortare?

[Sastrom]

Flytta givaren så signalen går iväg innan spindeln är i rätt läge.

[JimmyAndersson]

Det känns lite konstigt om det skulle bero på Mach3.
Det mesta som det programmet gör måste ju svara snabbt. Annars vore det oanvändbart.

Vad är det för givare? Hinner den få tillräckligt tydlig signal för att trigga när det är dags?
Fungerar det bra med övriga givare?

[Vilhelmsson]

låter som "shoveling shit" vilken pc har du ? kör du bara mach3 ? alt om installera win

[H.O]

Kan väl nämna att jag har Smoothstepper via nätverk.

Jag tror att det är här flaskhalsen ligger. Kommunikationen mellan SS och PC'n är inte "realtid", först skall signalen läsas av Smoothsteppern, sen ska den "förpackas" i ett "datapaket", föras över till datorn, sen ska drivrutinen "packa upp" datapaketet och göra det tillgängligt för Mach3, sen ska ditt macro läsa signalen, behandla den och sen ska allt göras om fast i omvänd ordning. Inget av detta borde ta någon direkt tid om det vore anpassat för det från början, vilket det antagligen inte ÄR.

[Bobbox]

Tro nog att det är som H.O tror, att det är något med kommunikationen.
Homing och E-stop svarar den direkt på men det kanske har lite högre prio.
Sen kör jag en massa annat på datorn så det kan ju vara det med men allt annat fungerar bra.
Men för nu räcker det med att jag vet att det skall gå snabbare och det skall det uppenbarligen.
Jag har en annan dator som skall styra fräsen men jag tänkte flytta över allt när jag klabbat färdigt
men jag kanske skall göra det direkt.

[H.O]

Jag tror inte att byte av dator kommer att hjälpa.
Kan du förklara lite hur du har det uppbyggt? Är det i M6Start.m1s du ligger och väntar på signalen och hur ser koden för det ut?

Homing fungerar för att det, i princip, är SS själv som utför homingen - det är inte Mach3 som övervarkar ingången för ref-switchen utan det görs direkt av hårdvaran. Beroende på hur du har det uppbyggt så kan jag tänka mig att det kan hjälpa att ändra inställningen för controler frequency. Men även om det skulle hjälpa så kommer du ändå uppleva en fördröjning.

[H.O]

Jag testade lite snabbt med följande kod

Kod: Markera allt

DeActivateSignal(OUTPUT1)
While NOT IsActive(INPUT1)
Wend
ActivateSignal(OUTPUT1)

(Risk för häng men funkar för detta test)

Med LPT-porten och 25kHz kernel frequency går utgången till ca 60us efter ingången, självklart skiljer det lite från gång till gång men någon stans mellan två och tre interrupt perioder (50-75us i det här fallet).

Jag har ingen Ethernet Smoothstepper men jag testade med USB-varianten och plugin version 015meg (jättegammal) och controller frequency satt till 2kHz, då är svarstiden med samma kod 250-300ms - jag upplevde ingen direkt skillnad av att ändra controller frequency till 4kHz.

Frågan är om Ethernet-versionen verkligen "bör" vara så mycket långsammare, men som sagt, det vore bra med lite mer info om vad och hur du gör.

[Bobbox]

Ja det är i M6Start.m1s som koden ligger i och det ser ut ungefär som din kod While NOT IsActive(INPUT1)
Wend
Det är ju stor skillnad på på parallellporten direkt och Smoothsteppern.
Man får väl gå in i REGEDIT och disable Nagles algorithm och lite annat för att trimma nätverket.
Jag har redan varit på Controller frequency men märkte ingen skillnad.
Sen kan det ju vara lite virusskydd och annat som slöar till det.
Men det är nog där som man får jobba med finjusteringar.,
Det fungerar som det är nu men det tar tid, spindeln kan få göra tre fyra försök innan den kommer rätt.
Att det tar så lång för den att reagerar förklara en massa andra problem som jag har haft med verktygslåsning och sånt.
Tack för att du tog dig tid att mäta svarstiderna

[arvidb]

Det är inte så att Smoothsteppern buffrar kommandon fråm Mach3 och att det helt enkelt tar ett tag innan stopp-kommandot från Mach3 tar sig igenom buffern?

[H.O]

Jo visst är det så, det var därför jag tänkte att en ändring av controller frequency skulle göra att det "svarar" snabbare, men det varkar ju inte hjälpa i det här fallet. Sen är det så att Mach3 planerar och genererar kod "i förväg" (som sedan buffras i Smoothsteppern) men när den träffar på en M-kod i koden så pausar den "förvägsplaneringen". Dock kan det ju vara så att kommandona ändå måste "spolas genom bufferten" även om den är tom.

Jag testade den senaste versionen av plugin'en också (17f tror jag) men det var ingen skillnad. Däremot finns det där en inställning flör hur många "punkter" i förväg Mach3 ska planerara och generera. Denna är ställd till 1023 by default, kanske det kan hjälpa att ändra denna - med tillhörande nackdelar såklart.

[Bobbox]

Det sitter två givare på spindeln, den ena ligger lite före den som jag läser av.
Det började bli lite ont om inputs men jag beslutade mig för att koppla in port3 och förberedde för det.
Imorgon (Tisdag) skall jag bege mig 164 mil norrut och testa detta.
Hade tänkt att slippa färdas så långt men när jag var där förra rundan så la en Gecko 203V av (en oförstörbar).
Nu kan man väl tro att jag klåpade med kablar eller nåt men den slutade bara att fungera, Murphys lag slog in.
Men det var ganska trevligt däruppe och jag fick en massa jobb att räkna på.

Jag har pillat en del på avdelningen på hur många punkter i förväg Mach3 skulle genera men det blev för mycket för Smoothsteppern, den hängde sig.
Tror man får kolla på nätverksinställningarna istället och ändra lite där.
Jag har med mig både hängslen och livrem så jag fixar det nog.

Men att Smoothsteppern är så långsam måste ju fler har råkat ut för.
Nästa ombyggnad blir nog med en microcontroller eller PLC.

[arvidb]

Titta på LinuxCNC också inför nästa ombyggnad. Det klarar sånt här galant.

Hmm, du säger att den svarar direkt på homing-switchar - du kan inte behandla spindeln som en 4:e axel och använda en homing-signal för detta (som du då kopplar förbi med ett relä eller liknande under vanlig drift)?

Edit: Jag ska kanske säga att jag egentligen inte har någon koll på varken Mach3 eller Smoothstepper, men jag har hyfsad koll på de genvägar man måste ta för att få en sån här sak att funka utan riktigt realtidsstöd (eller egentligen utan riktig realtidskommunikation, i detta fall). Det är på grund av precis de här problemen som LinuxCNC har valt att inte stödja USB- eller (vanlig) Ethernet-anslutning av externa kontrollers.

[Bobbox]

Kör den givaren som Chome-limit redan men det var inte någon skillnad.
Maskinen funkar som den är men den kan göra mellan ett och fyra försök innan den hittar rätt läge.
Det tar lite tid men maskintid är en sak, arbetstid en annan och kunden är nöjd.

[Bobbox]

Nu tänkte jag visa lite goodwill och snabba på verktygsväxlingen en del så jag har en liten fråga.
Givaren är en hallsensor på 5volt så min ide är att tjyva lite på signalen och köra den igenom en optokopplare och sen fortsätta till smoothsteppern.
Funkar det? jag vill att både optokopplaren och smoothsteppern använder samma signal.