Svenska ElektronikForumet

Tycker det verkar genomtänkt! Jag är inte helt med på var och vad det är som självhåller men det är viktigt att inget kan "gå igång" enbart genom att dra/återställa ut nödstoppsknappen - det skall finnas en separat knapp som kvitterar/återaktiverar systemet. Men det kanske du redan har? Räcker inte med det för att uppfylla maskindirektivet (vilket jag får känslan av att du är medveten om) men det är en bra början och bättre än många hobbymaskiner!

Om gränslägesbrytarna är kopplade i E-Stop-kedjan måste du implementera en bypass på något sätt, så att du kan aktivera systemet och jogga bort från brytaren - om du inte ska göra det för hand.

viktigt att inget kan "gå igång" enbart genom att dra/återställa ut nödstoppsknappen - det skall finnas en separat knapp som kvitterar/återaktiverar systemet.

Ja, om man trycker in "svampen" så stannar allt p.g.a. två saker.
1. E-stop reläet släpper -> spänningen till spindeln och stegmotorerna bryts.
2. ARV drar ned ESTOP_MON, denna läses över modbus in till LinuxCNC som i Ladder bryter ESTOP_IN.
3. Om man återställer "svampen" går ESTOP_IN inte hög p.g.a. att ESTOP_IN inte finns längre. För att få ESTOP_IN hög måste man pulsa estop_req vilket görs när man trycker på estop knappen på skärmen i LinuxCNC.

Om modbus kommunikationen inte skulle fungera bryts kedjan av Modbus_Error istället, med samma resultat.

Så Ja, man måste trycka på en annan knapp, samt återställa "svampen", för att återstarta systemet.
Det räcker inte heller med att hålla inne denna "annan knapp" och få igång systemet genom att släppa "svampen".
Allt måste vara OK när man trycker in denna knapp.

Räcker inte med det för att uppfylla maskindirektivet (vilket jag får känslan av att du är medveten om)

Har faktiskt inte läst maskindiriktivet. Har bara gjort det jag tycker verkar logiskt.
Utöver e-stop finns det även en brytare i luckan. Gissar att det är OK att få ur maskinen ur e-stop fastän luckan är öppen. Men det borde inte vara möjligt att starta körning/spindel med den öppen och att om man öppnar luckan under körning borde körningen och spindeln stanna.
Får den starta automatiskt om man stänger luckan igen?

Om gränslägesbrytarna är kopplade i E-Stop-kedjan måste du implementera en bypass på något sätt, så att du kan aktivera systemet och jogga bort från brytaren - om du inte ska göra det för hand.

Ja det finns redan en "axis override" knapp. Har inte behövt ändra något i elen, i varje fall inte än....
"Bara" gjort ett nytt controller kort. Detta nya kort kör med samma signaler på bakplanet och dess expansionsbuss.

OK, verkar bra. Men om man nu ska leka lite djävulens advokat här.... OM nu mjukvaran felar så du blir tvungen att trycka in svampen, är det då säkert att inget går igång när du drar ut svampen. Äh, som sagt jag tycker det verkar genomtänkt och bra!

Jag är verkligen ingen expert på maskindirektivet men för att uppfylla dess krav (finns dock olika nivåer) på nödstop kan man generellt säga attt det mesta skall vara "dubblerat och övervakat". Dvs, om du har en kontaktor som matar spindelmotorn så måste nödstoppet fungera även om denna kontaktor bränner fast, dvs det räcker inte att "bara" bryta denna kontaktor och/eller dess manöverspänning. I princip behöver du två kontaktorer i serie - på ett eller annat sätt. Sen skall dessa kontaktorer "övervakas" så att nödstoppet inte går att kvitera/återställa om en av dom ÄR fastbrunnen. Själva nödstopssknappen skall vara tvåpolig så att en kan gå sönder utan att nödstoppet slutar fungera osv osv. Inte många hemma-maskiner som uppfyller det....

Har sett massor med videor där man kör maskin och spindel med dörren öppen men kan mycket väl tänka mig att det finns "folk" som skulle ha anmärkningar på det. Axlarna MÅSTE man ju kunna köra med dörren öppen (och således kan dörren inte vara i E-stop kedjan) annars kan man ju inte indikera in ett skruvstycke eller nånting.... Personligen tror jag man skulle bli tokig om man inte kunde köra maskinen fullt ut med dörren öppen.

Lite lurigt om du tillåter axlarna att röra sig men stoppar spindeln när dörren öppnas. Hur blir det om du öppnar dörren mitt i en körning?

Ett tips av erfarenhet, gör det enkelt att kontrollera VAD det är som gör maskinen inte går att ta ur nödstop - och vad det är som triggar ett nödstop. Det är hopplöst när man har en massa vilkor som måste uppfyllas men inget lätt sätt att kolla "hur långt" man kommer. Är det fysiskt fel på slingan, AVR'en som inte funkar, komminikationskabeln som är avsliten, MODBUS-mastern som inte snurrar, laddern som inte går etc etc.

Än en gång, bra jobbat!

> Har sett massor med videor där man kör maskin och spindel med dörren öppen...
En nyköpt maskinen hinner väl knappt landa på golvet innan det skyddet är
bortplockat/kringgånget (i en verkstad för fåstyckstillverkning). Finns också maskiner
som har nyckelbrytare där man kan köra med dörren öppen men då med lägre
maxhastighet i rörelserna.

Trevlig storlek på maskinen och roligt att du använder Linux CNC!

Blir riktigt coolt detta bygge.

Som föregående talar så vill jag ej klanka ner på dina ideer.

Men som H.O skriver så blanda inte in Maskindirektivet.
Jag har jobbat x antal år med den och andra standarder och skall man nu göra det så skall man börja med en risk analys.
Vad man än kommer fram till så måste man ha ett externt säkerhetsrelä som sköter hela nödstopps slingan och även luckorna / dörrarna för att det skall bli godkänt. Sen vad risk analysen kommer fram till så kommer man hamna i olika performace level "PL b till e" och utifrån den nivån designar man sin säkerhetslösning så den uppfyller den nivån.



Jag själv hade aldrig lagt en nödstopps funktion via en mjukvara så här, beror nog mycket på att man vet vad som kan hända.
Jag hade låtit nödstoppsknapparna gå till ett externt säkerhetsrelä av något känt fabrikat, sen från det reläet kan du plocka in en signal till linux systemet som stoppar mjukvaran.
Men från detta reläet skall du sen styra 2 kontaktorer som bryter kraften till drivstegen.
Har man sen luckor så kopplar du dessa till ett annat säkerhetsrelä som i sin tur bryter kraften till spindel motor enbart.


Sen angående att köra med öppna dörrar.
Jag har sett detta på x antal maskiner ute när man har gjort risk analyser åt kunder och det tråkiga är att folk vet ej vad som händer om olyckan är framme.
Reducerad hastighet eller som vi kallar det "Safe speed" blir mer och mer vanligt men det kräver speciell hårdvara och kostar mycket kulor.
Men en regel om dörrarna är öpnna så skall kraften till spindel motorn vara borta, annars hade jag aldrig litat på systemet och vågat vara inne i maskinen.

Lycka till

Jag själv hade aldrig lagt en nödstopps funktion via en mjukvara så här, beror nog mycket på att man vet vad som kan hända.
Jag hade låtit nödstoppsknapparna gå till ett externt säkerhetsrelä av något känt fabrikat, sen från det reläet kan du plocka in en signal till linux systemet som stoppar mjukvaran.

Jag tror det är exakt det han gör. Nödstoppslingan är i hårdvara (dock utan reglerätt säkerhetsrelä). Mjukvaran (PLC ladder i LinuxCNC) och MODBUS kommunikationen är "endast" för att tala om för LinuxCNC att externt nödstop är "triggat". Det enda jag personligen är lite tveksam i det här fallet är att det nödstoppet och systemet "aktiveras" via mjukvaran, om jag nu förstått det hela rätt.

Jag har gjort det så att nödstoppet återställs med hjälp av en tvåpolig tryckknapp. Den ena polen går till en ingång på styrningen (Mach3) som då "går ur" nödstopp och via chargepump-funktionen aktiverar ett relä vars kontakter sitter i sitter i serie med den andra polen på sagda tryckknapp som är vad som återställer säkerhetsreläet. På detta sätt kan jag återställa/aktivera hela systemet (hård- och mjukvara) med en fysisk knapp, jag kan återställa enbart mjukvaran genom dess interface men den hårdvarumässiga nödstoppskretsen går inte att återställa genom enbart mjukvara.

Hade funderingar vilket var nästa steg. Att se till att IO fungerar eller se om man kan få något att röra på sig.
Bestämde mig för att det var dax för rörelse.

Sagt och gjort, börja med läsa dokumentationen om stegmotor drivarna för att ha koll på timings.
Visst oftast kan man få det att "fungera" ändå, men om man inte sätter upp tider rätt kan det bli lite konstigt.
t.ex. om man inte har rätt inställningar på när riktningssignalen får ändras kan det bli så att det "tappas"
ett steg ibland när den byter riktning på en axel. Det kan då t.ex. bli så att LinuxCNC lägger ut en riktningsförändring medan drivern gör ett steg. Vilket håll blev då steget? Anledningen att det kanske bara blir ibland är p.g.a. latency. Att LinuxCNC drivaren inte fick tid exakt när den ville utan lite senare.
Med andra ord får man mycket svårfunna fel. Att kärningar blir mer och mer "fel" ju längre de är.
Det som man också måste kontrollera är om drivaren gör steget vid stigande eller fallande flank på step signalen.

Min drivare är att den gör steget vid fallande signal.
Optokopplaren mellan parallellporten och drivaren inverterar signalen, så på parallellkabeln så görs steget på stigande flank.
LinuxCNC stepgen tycker den skall gå vid stigande, så jag skall inte invertera signalen i parallellports drivern.

Min data ser ut såhär
1. Stegmotor drivare, pulslängd på steg signal 10us
2. Ändring av dir signal. Ej inom 0.5-5us efter steg (fallande flank).
3. max freq. 20kHz
4. Max latency 7.4uS

I "normal" mode så kan LinuxCNC ändra 1 gång per heartbeat (BASE_PERIOD). I mitt fall ger detta att en heartbeat på 10us+7.4us+safety time => 20us.
För att generera 1 steg behövs 2 heartbeat => max step freq 25kHz
25kHz stegfrekvens, 200steg/mm => 125mm/sec

Om denna hastighet inte skulle räcka så ha LinuxCNC möjlighet att köra ett helt steg i ett heartbeat, men det hanteras då delvis av parallellports drivern. Inget jag behöver i denna maskin.

Maskindokumentationen för min maskin specificerar 1500mm/min (25mm/sec). Vilket är antagligen vad stegmotorerna klarar.
Så för att vara på den mycket säkra sidan satte jag BASE_PERIOD till 50us.
Detta ger då max 100us / steg => 10kHz => 50mm/sec => 3000mm/min.
Detta ger möjlighet till dubbelt så snabbt som det gamla. Antagligen går det inte att köra så snabbt.
Anledningen till att välja 50us och inte 20us är flera. Bra marginal på max latency. Även att det lastar datorn mindre, mer tid till annat t.ex. UI. Finns ingen anledning att köra snabbare än man behöver.

Detta är de viktigaste bitarna i min nuvarande konfiguration för att köra med stegmotorer.
ini fil Hal fil Visar bara X-Axis, de andra två är i stort sett lika.

Testkörning visar att det fungerar! Alla axlar rör sig, men x-axeln bara i en riktning.
Första reaktionen. Vad har jag nu gjort för fel i x-axelns dir signal.
Kollar igenom schema och layout. Inga fel så långt.
Fel i dokumentation? Tar ur stegmotor korten och mäter bakplanet mellan controller kortet och stegmotor kortet.
Inga problem, kontakt mellan på rätt sätt. Ingen kortslutning mot jord eller matning heller.
Vad nu då!
Tar och bär ut skåpet och mäter på step och dir. Inga problem.
Tittar noggrannare på stegmotordrivarna. Ett är en SD13, två SD12 d.v.s 3A respektive 2A drivare.
Varför sitter det olika kort i? Det är samma stegmotorer på alla axlar.

Tar en chanstagning och bytar x och y axel korten. Nu fungerar X som det skall, Y går bara åt ett håll.
Fel på kortet alltså.
Såhär ser kortet ut. Detta med min temporära lagning på. Lite fusk att visa vad som var fel.

Felsökningen gick till såhär.
1. Koppla in kortet på labbänken
2. Koppla signalgeneratorn på step signalen
3. Mät på motorutgångarna

Lite konstigt såg det ut. Alla lindningarna har ena sidan alltid drivna.
Mäter vidare på gaten på utgångstransistorerna. Vissa är alltid drivna.
Följer ledarna bakåt, kommer till en MC1488. En RS232 driver?!?!
Denna används tydligen som nivåskiftare, detta tillsammans med några externa transistorer.
MC1488 utgångarna verkar inte följa ingångarna. Aha, trasig!
Hittar faktiskt en på ett skrotkort man har i sin samling.
Inga förbättringar!
Mäter runt lite till. Hittar då att den saknar den negativa spänningsmatningen.
Varför drog man så förhastade slutsatser att den skulle vara trasig?
Varför kontrollerade jag inte det första man skall kontrollera på ett trasigt kort.
Finns matningspänningarna? Alla?
Efter det var det enkelt att hitta, kortslutning i en elektrolytkondensator.
Inte svullen! Kanske lite för gammal för att ha det problemet. Kortet gjort 1992.

I med kortet igen och nu går alla axlar på båda hållen!


Det måste varit problem med denna maskin tidigare. Sitter som sagt 3st stegmotor kort i den.
Alla tre är olika!
Här är bilder på de andra två Kort 2 är nästan samma som kort 3, men på bara två amp. istället för 3. Lite färre utgångstransistorer bara.
Kort 3 är lite annorlunda. Den har t.ex. inte den kondensator som var problemet.
Lite annorlunda layout i vissa delar t.ex. det som sitter under de stora kondensatorerna.

Finns etiketter på baksidan av korten när de är testade och av vem.
Kort 1 10/9/92
Kort 2 2/4/93
Kort 3 15/4/93

Mitt felaktiga kort lite äldre än de andra, men inte mycket.

De två första korten har samma siffror på de båda kretsarna, det tredje har andra på det ena.

Versioner av PCB
Kort 1 1408.102.02
Kort 2 1408.102.03
Kort 3 1408.102.06

Tyder på Kort 3 är senare version, Kort 1 (det söndriga) det äldsta.
Ändå intressant att det tydligen skett så mycket förändringar på dessa kort under så pass begränsad tid.

Ändå trevligt att ha igång det så här långt. Är alltid en skön känsla när något rör sig för första gången!
Måste nu bara finna ut vad max acceleration och max hastighet kan bli på min maskin.
Helt enkelt testa sig fram och se var det slutar fungera. Börjar med låg acceleration för att finna ut max hastighet. Sedan justera upp accelerationen.
När man funnit max, justera ned mycket så det finns god marginal när man bearbetar också.
Kanske t.o.m. fästa något tungt på bordet när man testar.

Litet steg framåt.
Testat all home brytare och ställt in positioner.

Home brytarna måste finnas på en snabb IO utan fördröjningar, därför har jag dessa på parallellporten.
Konfiugurering i HAL filen kopplar ihop ingångarna med respektive axel.
Resten av konfigurationen ligger i ini filen Här har jag ställt att AXIS_S, Z axeln, har HOME_SEQUENCE=0, medan de andra har HOME_SEQUENCE=1.
Detta gör att den först kör hem på Z. När denna är hemma så körs x och y samtidigt hem.

Det finns sedan två inställningar som lätt förväxlas med varandra, det är HOME och HOME_OFFSET.
HOME_OFFSET är den maskinposition som home brytaren sitter på
HOME är positionen maskinen skall gå till när den gjort gjort home sekvensen.

Hur den gör home sekvensen beror på tecken på HOME_SEARCH_VEL och HOME_LATCH_VEL.
Om maskinen skall köra mot brytaren, tillbaka tills den släpper och är då hemma.
Eller om den kör mot brytaren, backar tillbaka och mot brytaren igen för att vara hemma.

Sedan finns det också möjlighet, om man har en givare även på skruven/motorn, att ha en index också.
Detta skulle då ge bättre repeterbarhet eftersom denna oftast rör sig mer än bordet.

Om man har ont om ingångar så finns det möjlighet att alla home brytare sitter på samma ingång.
Man sätter då HOME_IS_SHARED till 1.
Nackdelen med detta är att man kan inte köra hem två eller flera axlar samtidigt. LinuxCNC vet inte vilken axel som nådde home brytaren.
En annan inte helt uppenbar nackdel är att LinuxCNC vägrar köra hem om någon brytare är triggad. Detta för att LinuxCNC vet inte vilken axel som måste köras för att släppa.

Ligger lite efter med uppdateringar...
Men tar det det i "rätt" ordning.

Efter att ha rörelserna fungerande så var nästa steg IO.
Det är inte många IO signaler som var in till original kontroller kortet.
8 in och 8 ut utöver e-stop, stepper drivers, etc.

Signalerna är
IN-0 ARM IN (ATC armen är helt ute mot spindeln)
IN-1 ARM OUT
IN-2 ARM UP
IN-3 ARM DOWN
IN-4 Carousel Ref Sensor, Inte verktygs position utan motor position. Motorn skall gå två varv för att snurra en verktygsposition.
IN-5 LUBE FLOAT SWITCH
IN-6 GUARD SWITCH, är luckan stängd
IN-7 SPINDLE SPEED SENSOR, inte inkopplad på min maskin.

OUT-0 SGR, Spindle Go Relay
OUT-1 SRR, Spindle Reverse Relay
OUT-2 COR, Coolant On Relay
OUT-3 CIR, Carousel In Relay
OUT-4 CDR, Carousel Down Relay
OUT-5 DBR, DrawBar Relay
OUT-6 CPR, Carousel Power Relay
OUT-7 CCR, Carousel Counter clockwise Relay

Dessa signaler är kopplade mot AVR processorn genom en ULN2803 (utgång) och en vanligt 74ls245 buffer (ingång). Detta är samma som används på original controllern.

Utgångarna mappades bara mot 8 coil register i modbus, ingångarna mot 8 discrete.
I LinuxCNC valde jag att konfigurera att Coils och Discretes skulle läsas in till Ladder bit memory (%B).
Alternativet hade varit %Q, %I, att de mappas direkt mot HAL signaler.
Jag valde %B för att det ger mest flexibilitet. Tyvärr ger det samtidigt att man måste ibland göra några extra "onödiga" steg i de fall man har signaler i HAL som direkt skall ut på modbus. Se t.ex. coolant lösningen nedan. Enkel test för att se att allt fungerar.
Ta upp VARS fönstret. Här kan man se status på alla signalerna och ändra utgångarna (om de inte är kontrollerade av HAL eller ladder. Ingen override med andra ord).
Klicka bara på checkboxen för att toggla status på en %B utgång så skickas den ut genom modbus.
Reläerna drog som förväntat. Också om man öppnade/stängde luckan så uppdaterades %Bx.
Så långt allt väl.

Kvar att koppla ihop HAL signaler med utgångar. Eftersom jag valde %B så måste man gå "omvägen" genom ladder.
Exempel Coolant
I HAL finns det en signal i IO control komponenten som är 1 om coolant skall vara på, 0 annars.
Denna signal kopplar jag ihop med classicladder in (%I)
net flood iocontrol.0.coolant-flood => classicladder.0.in-23
I ladder måste jag då koppla ihop %I23 med %B18 Under körning kan man se status direkt i ladder. I Coolant fallet är den ej aktiv, e-stop i första är aktiv.
För att sedan testa skicka M8 och M9 i MDI fönstret.
Om man nu i LinuxCNC modbus konfiguration hade valt att mappa coil till %I hade man inte behövt göra något i ladder. Samtidigt måste man då göra all logik i HAL eller i Modbus devicen.

Lite svårt att komma ihåg vad nu %B18 är för något. Man kan därför sätta namn på signalerna. Detta görs i Symbols. Här kan man även se om det är kopplad nägon HAL signal till denna variabel.

Spindeln är på samma sätt
net spindle-on motion.spindle-on => classicladder.0.in-08
net spindle-fwd motion.spindle-forward => classicladder.0.in-09
net spindle-rev motion.spindle-reverse => classicladder.0.in-10
Jag har inte gjort spindelhastighetstyrningen än så kan inte testa om den fungerar. Men det klickar i reläerna när man skickar M3, M4 och M5.

Originalkontrollern hade möjlighet att styra verktygsväxlaren med M-koder. Att manuellt köra in, ner, upp, ut den samt släppa verktyget. Hur gör man då detta?
Valde att göra det med "ngc" scripts
I ini filen Detta gör att om man skickar M20 så kommer LinuxCNC att starta atc_m20 scriptet. Den viktiga biten är här att den kör M64 P1
Valde att inte lägga in "1" direkt här utan gå igenom INI filen för att ha en översikt.
Vad gör då M64 P1, den sätter helt enkelt en HAL signal, i detta fall motion.digital-out-01

För att få ut denna till Modbus måste man i HAL filen koppla den mot en ladder ingång och sedan i Ladder koppla ihop %I17 med %B19.

Vad gör då M66 i ngsc scriptet?
Den väntar på en HAL signal en viss tid. Det den skall vänta på är ARM_IN.
Här måste man då först i ladder koppla ihop ARM_IN descrete %B0 med %Q11
Q är här signaler från Ladder in til HAL.
Koppla ihop Q11 med motion signal in 0 Ini file PINS I scriptet har jag också om armen inte gick helt ut innom 10sek så försöker den dra tillbaka armen igen och returnera FAIL från scriptet.

Om allt gick bra, skicka M2, klara med scriptet.

Det intressanta här är att M-code ngc script är samma sak som ett g-code sub program. Det kan göra allt som ett g-code program kan göra, varken mer eller mindre.

När jag kommit såhär långt så provade jag med att koppla in tryckluften för att se att det verkligen fungerade också. Det var början på en hel del mer jobb men mer om detta nästa gång....
Det positiva var att det var inga problem i det elektriska eller i mjukvaran.

Mycket intressant detta! Det är inte så ofta man får följa någon som använder de lite mer avancerade funktionerna i LinuxCNC (modbus, ladder).

Fönstret som har rubriken "Section Display of custom.clp" i ena bilden i senaste inlägget, är det en ladder-editor från LinuxCNC?

Ja och Nej.
Just den bilden är det i runtime läget.
För att komma till Edit läget, klickar man på "Editor" knappen.
Man får du upp ett fönster till med vertygen.
Det är en lite jobbig editor, man jobbar bara i en bit i taget.
Man ser i kanterna vilket bit som är "aktiv", d.v.s vilken bit som man kommer att ändra när man trycker på
"Modify" knappen. Man kan heller inte flytta ner en "rail", men man kan föra in ett "block" istället.
Det är också möjligt att dela upp sitt program i flera "Sections". En section är det man ser i "Section <name> of" fönstret.

daer: Vad skulle du rekommendera vid ett nytt bygge. Lägga all logiken I Linux cnc eller lägga det I en extern plc och prata Modbus imellan?
Är det svårt att prata Modbus mellan en extern enhet och Linux cnc?
Får man in signalerna I ladder editor eller var knyter man annars sina funktioner från Modbus till olika saker I Linux cnc som start av program med mera..

Ps. Ser riktigt grymt ut I övrigt ditt bygge, snart dags att starta?

MVH

Om jag hade haft en PLC som paratar modbus och inte bara ett IO-kort som pratar modbus hade jag haft logiken i PLC'n. Hoppat över Ladder i linuxCNC helt och hållet.

I konfigurationen av Modbus mappar man då Coils/Holding etc mot %Qx och %Ix istället för %B och %W.
%Q och %I är kopplingen mot HAL, %Q Ugång från HAL, %I ingång mot HAL.
%B och %W är variabler till Ladder, B är bit (boolean) och W är Word. Spelar ingen roll om de sätts eller bara är ingångar i Ladder, det är samma.

Om man använder sig av %B och %W så måste man i Ladder koppla sig mot %B och %W.
%I och %Q kopplingen går rätt ut på modbus.

I mitt fall så är min config av modbus och hantering av spindeln såhär I min HAL fil d.v.s. jag kopplar ihop LinuxCNC interna spindle-on signal med %I8 och i Ladder skickar ut den på modbus med %B16. %B var mappat mot Write Colis, och under Modbus I/O registers så har jag konfigurerat att Variabel 16 går mot modbus Write_coils element #1. Eftersom då Coil är en boolean blir det då %B16.
Som sagt många steg blir det men är inte så komplicerat när man väl kommer in i det.

Men nu frågade du om man inte ville ha med Ladder, i config mappa modbus mot %Q och %I istället.
Vet tyvärr inte vilka signaler som sedan exporteras mot HAL eftersom jag inte kört så.
Men det är enkelt att ta reda på. Bara konfigurera upp det och starta LinuxCNC.
Ta sedan upp "HAL configuration" exempelvis från Axis UI, Machine menyn, "Show HAL configuration".
Där kan man se alla HAL signaler och hur de är kopplade.
Koppla då bara ihop den interna signalen med den som går ut genom Modbus i HAL liknande det som jag hade ovan.
Om man vill ha t.ex. en start knapp så finns det en HAL signal som heter "halui.program.run", koppla bara ihop den i HAL filen med en signalen från modbus, vad den nu kan heta.

Så om man kör logiken i PLC'n så räcker det med en rad i HAL för att få ut en given signal över modbus.

Hmmm måste verkligen ta ner den gamla datorn från vinden och dra in Linux cnc på den och börja labba.
Vad för typ av Modbus pratar Linux? Är det bade RS-232 och RS-485?

Enda jag behöver köpa är ett seriekort på typ kjell & company om inte datorn redan har ett?

Dum fråga men I windows vet jag hur man installerar ett seriekort men hur gör man I Linux?
Är det nåt man måste göra ute I själva Linux eller man kan göra det inne I cnc delen?


Tack för bra information.

MVH
Oscar

RS-232 och RS-485 är båda samma seriella protokol, bara det elektriska gränsnittet skiljer.
Finns omvandlare mellan RS-232 och RS-485. Om du kör med en sådan så kan man behöva köra med RTS handskakning. Detta för att omvandlaren skall veta om man skall skicka data eller ta emot data.

För att köra modbus behöver du inte något intern serieport, det går bra med en USB-RS232 (RS485) omvandlare också.

Inga problem att installera dessa i Linux. De flesta har drivrutinera inbyggda i kärnan.
Normalt presenterar de sig i /dev/ttyX där X är USB0 för första USB-RS232 omvandlaren.
Om du har ett internt kort eller på modekortet så är det normalt /dev/ttyS0.