Feltbussens dage er talte
more_vert
close
close

Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og at Mediehuset Ingeniøren og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, tilbud mm via telefon, SMS og email. I nyhedsbreve og mails fra Mediehuset Ingeniøren kan findes markedsføring fra samarbejdspartnere.

Feltbussens dage er talte

Illustration: Flickr-bruger saschaa

Det har været sagt i mange år, men nu skulle dødsklokkernes ringen kunne høres vidt omkring: Feltbussen er på vej ud, og industriel ethernet er den nye konge på bjerget.

Det er situationen, sådan som Morten Jørgensen fra firmaet Elkas ser det. Firmaet, der beskæftiger sig med industriel automation, tæller store danske virksomheder som Novo og Rockwool blandt sine kunder.

I dag eksisterer de to teknologier side om side, men leverandører som Rockwell og Siemens er ved at udfase de serielle snitflader.

Det er ikke prisen, der gør computernetværks-teknologien populær i maskinhallerne. Faktisk kan ethernet-baseret udstyr være mere omkostningstungt end feltbussen. Fordelen med ethernet er, at det kan anvendes i hele stakken af teknologier, så at sige fra top til bund.

For konsulent Anders Mynster fra Force Technology ser stakken således ud:

»Nederst har vi sensorer og aktuatorer, dernæst kommer IO og kontrol-laget, og så kommer Scada og HMI (Human-Machine Interface). Disse tre lag er ‘operational technology’ og det er her at feltbussen historisk set har domineret.«

Det næste lag er MES – Manufactory Execution Systems – og oven på kommer styringssystemer som ERP. Her er vi i it-verdenen, hvor ethernet og IP-teknologi forbinder systemerne.

»Vi ser stadig, at feltbusserne eksisterer på det laveste niveau, som handler om sensorer og aktuatorer. Det er fordi industriel automation er en branche, der ikke bevæger sig så hurtigt,« mener Anders Mynster fra Force Technology. Illustration: Delta

Og ethernet graver sig altså som en anden orm længere og længere ned i stakken.

Ethernet vinder på ensartethed

»For os er ethernet både fysisk og som datalag bare nemmere at integrere med løsningen, elektrisk og datamæssigt, i proceslaget,« forklarer Morten Jørgensen fra Elkas.

Der er en større grad af ensartethed i ethernet-verdenen og det giver færre smerter, når der skal trækkes signalveje.

I feltbussens verden kan der være forskellige protokoller, forskellige typer kabler og længder, som skal forbindes med stjernehubs og termineringer.

»Og du skal være opmærksom på en frygtelig masse forhold, elektronisk og fysisk. Mange er bange for støj, reflektanser og så videre.«

Det er de forhold der gør, at ethernet har vundet konkurrencen. En ethernet-switch er et klart defineret begreb, og man kan fejlrette ligesom på et almindeligt ethernet/IP-netværk, pinge adresser og benytte SNMP-værktøjer.

Industriel automation er langsom branche

Der, hvor ethernet begynder at tage over fra feltbussen, er i IO/kontrol og Scada/HMI (human machine interface), mener Anders Mynster.

»Vi ser stadig, at feltbusserne eksisterer på det laveste niveau, som handler om sensorer og aktuatorer. Det er fordi industriel automation er en branche, der ikke bevæger sig så hurtigt. Det tager lang tid før man laver nye produkter. Man kender noget, sådan har det altid været, det er sikkert at køre med, og det implementerer man bare igen.«

Men ethernet kan godt opfylde den rolle, som feltbussen spiller. Profinet er et eksempel på en udgave af industriel ethernet, som har mange af de samme egenskaber som feltbussen.

»Der er skabt realtidssystemer og synkrone realtidssystemer, hvor vi er nede på 100 til 250 millisekunders ‘latency’ (signalforsinkelse, red.) Det er godt nok til mange systemer, som f.eks. kemisk og medicinsk produktion. Det bliver kritisk, når du har interne kontrolløkker. Hvis du har en åbne-lukke-ventil, som registrerer, hvor langt den er fra at lukke: I det splitsekund, hvor den siger, at nu er den helt lukket, skal du slukke for servostyringen til ventilen, så man ikke prøver at lukke den mere, end den kan. Der vil feltbussen og interne systemer stadig køre videre, tror jeg.«

Ethernet-teknologi betyder ikke nødvendigvis konventionelle RJ45-stik fra it-verdenen, som kan se skrøbelige ud i den industrielle automatiks verden.

»Der findes der tilpassede løsninger,« forklarer Morten Jørgensen.

»Man har fjernet nogle af lederne fra det konventionelle kabel og gjort ledertykkelsen tre gang større og lavet gedigne stik, som samtidig kan gå ind i en almindelig switch.«

Wifi venter i kulissen

I kulissen står trådløse teknologier på spring til at gøre sit indtog. Her er udfordringen, at forbindelsen skal være deterministisk, og det kræver, at man har styr på sine frekvensbånd.

»Der skal jeg passe på, hvad jeg siger, for der bliver min verden væltet om fra uge til uge,« siger Morten Jørgensen, der peger på, at der allerede finde wifi-access points og klienter med specielle lag af protokoller, som sørger for ekstra høj sikkerhed.

»Men jeg tror, at der er længere fremtidsudsigter på det punkt.«

Feltbussen er på vej ud, og industriel ethernet er den nye konge på bjerget.

Nej, feltbussen er ikke på vej ud; men traditionelle feltbusser er ganske rigtigt under pres fra Ethernet.

Faktisk kan ethernet-baseret udstyr være mere omkostningstungt end feltbussen.

Nemlig, og samtidig langt mindre pålidelig, og det er bl.a. problemet.

Ethernet er idag en punkt-til-punkt forbindelse, der kræver store rackskabe med en router/switch-kanal for hver eneste enhed, som derved får antallet af transistorelementer i systemet til at eksplodere, så prisen stiger, og pålideligheden falder, da den stort set er omvendt proportionalt med antallet af transistorelementer og desuden falder til det halve for hver 10 grader C, hvis de varmes op, hvilket de netop gør i en router! Desuden kræves en microcomputer med stømforsyning og protokolstak i hver eneste I/O enhed, og hvis man ikke bruger den relativt dyre PoE (Power over Ethernet), skal der minimum 2 kabler til.

Fremtidens feltbusser som Max-i - se www.max-i.org - vil ved størsteparten af aktuatorer og sensorer kun kræve én billig IC i hver enhed, som strømforsynes direkte (med 20 Vdc ved Max-i) fra kommunikationskablet. Da der desuden benyttes standard installationskabler, kan man ved Max-i trække op til 800 W pr. segment på 4 mm2 kabler, hvilket rækker til adskillige aktuatorer, LED belysning etc. Det bliver en langt billigere og langt mere pålidelig løsning end Ethernet - og så kan den ikke hackes, da kun de mest komplekse enheder indeholder en mikrocomputer.

Der er en større grad af ensartethed i ethernet-verdenen og det giver færre smerter, når der skal trækkes signalveje.

I feltbussens verden kan der være forskellige protokoller, forskellige typer kabler og længder, som skal forbindes med stjernehubs og termineringer.

Vrøvl. Der findes næsten lige så mange indbyrdes inkompatible Ethernetprotokoller, som der er feltbusprotokoller, som f.eks. Ethernet PowerLink, EtherCAD, ProfiNet, Ethernet/IP og Sercos, og tager vi igen Max-i, er der hverken nogen stjernehubs eller kabeltermineringer, og til industribrug benyttes et standard 4-leder installationskabel, der er meget nemmere at montere og giver en langt mere sikker forbindelse end RJ45 konnektorer, som basalt set ikke er skabt til hårdt industrimiljø.

»Og du skal være opmærksom på en frygtelig masse forhold, elektronisk og fysisk. Mange er bange for støj, reflektanser og så videre.«

Vrøvl igen. Som skrevet er der ved Max-i ikke engang nogen termineringsmodstande at holde styr på, og sendeeffekten er op til ca. 5 W, så man behøver normalt heller ikke at bekymre sig om signal/støjforholdet. Det er bare at koble et stort set ubegrænset antal enheder ind på et fælles kabel. Ved Ethernet skal der benyttes talrige routere eller switche, som evt. skal konfigureres.

En ethernet-switch er et klart defineret begreb, og man kan fejlrette ligesom på et almindeligt ethernet/ip-netværk, pinge adresser og benytte SNMP-værktøjer.

Og ved traditionelle feltbusser og Max-i er der slet ingen routere eller switche, hvilket alt andet lige er meget simplere. Der er altså ikke meget at fejlrette på et standard installationskabel! Ved Max-i, som er en multimasterbus baseret på bit-vis busarbitrering, er der heller intet at konfigurere, når enheder tilføjes eller fjernes, og det kan gøres on-the-fly, medens anlægget er i drift. Man kan på den måde tilføje (og fjerne) et vilkårligt antal debugenheder og kan oven i købet manipulere med procesværdierne, så man f.eks. under en idriftsættelse kan teste sit procesanlæg uden materiale!

Den totale Max-i specifikation fylder kun ca. 210 sider; men omkring halvdelen er baggrundsmateriale (annex'er) og ting, som kun IC leverandøren behøver at koncentrere sig om, så standardbrugeren behøver kun at kunne konfigurere nogle ganske få registre, og selv den avancerede bruger, som selv ønsker at skabe en kommunikation til systemet med alle protokollag, behøver ikke at læse mere end omkring 100 sider. Jeg vil påstå, at jeg kan få de fleste igang på ca. 1-2 timer. Til sammenligning er de fleste Ethernet protokoller (og også mange andre feltbusprotokoller) på over 1000 sider, hvor store dele er standarder, som man først skal købe. God fornøjelse med at skrive sin egen stak helt fra bunden til et Ethernetbaseret system!

»Der er (med Ethernet, mig) skabt realtidssystemer og synkrone realtidssystemer, hvor vi er nede på 100 til 250 millisekunders ‘latency’ (signalforsinkelse, red.) Det er godt nok til mange systemer, som f.eks. kemisk og medicinsk produktion.

Det er langsommere, end vi kunne styre for 40 år siden med en 2 MHz 8080. Max-i kan på et 35 m langt kabel (og i visse specialtilfælde en 70 m lukket ring) synkronisere 7 servoakser med 32-bit præcision til en indbyrdes nøjagtighed på 0,1 us og en state-of-the-art opdateringscyklus på 400 us for samtlige akser - og det til en brøkdel af prisen for en Ethernetløsning.

PS. Undskyld at dette indlæg indeholder referencer til Max-i, som kan opfattes som reklame, men ligesom computere og Ethernet har udviklet sig, er det altså også tilfældet for feltbusser, og uden en reference til Max-i, som nok er den nyeste af de traditionelle feltbusser, kan jeg ikke bevise mine påstande og imødegå Morten Jørgensens i mine øjne temmelig unfair, unuancerede og direkte forkerte påstande.

  • 16
  • 4

Som sædvanlig et indlæg fra din hånd fuld af information og argumentation.
Har du mulighed for at tilknytte et par ord til diskussionen ethernet/feldbus vedrørende datasikkerheden og risikoen for at uvedkommende skaffer sig adgang til data enten for at stjæle info, eller for at ødelægge noget?

  • 0
  • 2

Har du mulighed for at tilknytte et par ord til diskussionen ethernet/feldbus vedrørende datasikkerheden og risikoen for at uvedkommende skaffer sig adgang til data enten for at stjæle info, eller for at ødelægge noget?

Ved en traditionel feltbus - også Max-i - vil enhver, der har fysisk adgang til feltbussen, kunne skaffe sig adgang til alle data, da de ikke er krypterede; men hvis man allerede er inde på selve procesanlægget og ønsker at gøre skade, kan det gøres meget enklere rent mekanisk med f.eks. en stor hammer :-)

En traditionel feltbus som Max-i kan køre autonomt, så problemet med datasikkerhed opstår reelt set først det øjeblik, hvor man laver en gateway fra bussen og ud til omverdenen som f.eks. internettet. Her må man selvfølgelig tilføje den nødvendige kryptering i gateway'en; men selv i det tilfælde er sikkerheden meget lettere at styre end ved Ethernet af flere årsager:

1) Protokollen er uhyre simpel; så det er let bare at koble en debugenhed ind på bussen og logge alt, hvad der sendes. Max-i har oven i købet et avanceret acceptance-filter i sit UART interface, som f.eks tillader, at man ekskluderer en hurtig lokal kommunikation i en reguleringssløjfe og kun logger globale data af interesse. Med en routerbaseret Ethernetløsning er det intet sted, hvor man kan koble en debugger/datalogger ind, så man med garanti logger alt, hvad der sendes - uanset hvor smart en hacker måtte være i sit forsøg på at skjule dette, og selv om man kunne logge alt, så god fornøjelse med debugningen.

2) Max-i kan håndtere simple enhedstyper direkte i hardware (ingen microprocessor) som f.eks. 4-bit Boolske I/O værdier, 20- og 36-bit analoge værdier, UART, SPI-interface, meget avanceret LED styring og i fremtiden nok også simpel 3-faset motorstyring med variabel hastighed. Det giver for det første en meget høj pålidelighed, og for det andet er det ikke muligt for en hacker at loade nyt program i enheden, som det f.eks. er tilfældet med talrige IoT dimser med WiFi, hvor man oven i købet er på indersiden af firewall'en, så hvis først én enhed er blevet kompromitteret, kan det sprede sig til andre og ikke mindst de overordnede systemer. Jeg har set en video, hvor Philips Hue blev hacket fra en drone, så man kunne lege med lyset. Alle snakker trådløs kommunikation ved IoT; men det er altså ganske problematisk - både med hensyn til sikkerhed og pålidelighed.

  • 10
  • 4

PS. Undskyld at dette indlæg indeholder referencer til Max-i, som kan opfattes som reklame, men ligesom computere og Ethernet har udviklet sig, er det altså også tilfældet for feltbusser, og uden en reference til Max-i, som nok er den nyeste af de traditionelle feltbusser, kan jeg ikke bevise mine påstande og imødegå Morten Jørgensens i mine øjne temmelig unfair, unuancerede og direkte forkerte påstande.

Helt enig i at det er alt alt for tidligt at skrive nekrologen over den "middelaldrende feltbus". Som Carsten glimrende skriver er der masser af gode grunde til ikke at vælge ethernet.
@Carsten Af nysgerrighed er det lykkedes at få Max-i sparket ud i den virkelige verden eller er den stadigt kun på teststadiet?

  • 6
  • 1

Er det ikke et spørgsmål om at ethernet er billigt nok og godt nok til mange formål? Ikke det billigste eller det bedste. Men så snart vi har det på som netværk kan IT folket være med. De samlede projektomkostninger bliver mindre fordi du får et mere homogent system og åbner op for mindre specialiseret arbejdskraft.

  • 3
  • 0

Det der står her http://www.max-i.org i afsnittet "supplement to ethernet" virker ret fornuftigt.

På hjemmefronten og makerbevægelsen ser jeg dog et marked for ethernet selv helt ned på sensorniveau. Forestil dig en trykknap der skal aktivere et system. Hvis den kommer med ethernet interface kan jeg sætte den til hjemmenetværket og programmere det hele uden at røre en loddekolbe eller se på noget elektronik. Det virker trygt. Måske styringen tilmed er via en app og ude i skyen (gud hjælpe os).

Det er også i den anvendelse at wifi er relevant. Samme knap nu bare med wifi interface. Til anvendelser hos lægmand hvor det er vigtigere at det er nemt end at det er den bedste løsning.

  • 2
  • 0

@Carsten Af nysgerrighed er det lykkedes at få Max-i sparket ud i den virkelige verden eller er den stadigt kun på teststadiet?

I slutningen af Q1 2018 forventes nye moduler, der passer med den højere spænding og det langt større spændingsområde i version 9 af specifikationen. I modsætning til de nuværende evalueringsmoduler, vil de nye blive i en væsentlig mindre størrelse, så de kan indbygges i produkter, men de bliver selvfølgelig ikke så små og billige som den endelige IC-løsning, der først igangsættes efter en meget grundig testfase.

  • 3
  • 2

Jeg sad lige og overvejede max-i til en 3D printer med automatisk tool change. Ideen er at bruge max-i til at kommunikere med den udskiftelige extruder, laser, etc. Max-i til SPI til at styre stepperdriverne etc. Men det er altså ikke klar til det endnu?

  • 1
  • 0

... og åbner op for mindre specialiseret arbejdskraft.

Tror du virkelig?

Stort set alt, hvad der kommer fra IT verdenen, er unødigt kompliceret og klodset opbygget, og ingen kan overskue noget som helst. Vi har aldrig haft så mange fejl, så mange alvorlige sikkerhedshuller og så mange IT skandaler, som efter vi fik lukket IT-nørderne ind i automationsbranchen :-)

Da jeg startede med at lave automatik for næsten 40 år siden, kunne vi styre ca. 80 enheder på f.eks. en foderstoffabrik med én 2 MHz 8080 mikrocomputer med 6 kbyte RAM og 8 kbyte EPROM, og responstiden var typisk mindre end 100 ms. Idag skal Microsoft bruge minimum 250 Mbyte RAM og 1 Gbyte FLASH (Windows 10 IoT) og helst også en lejet virtuel maskine i skyen for at styre en kaffemaskine i hjemmet.

Hvorfor tror du, at Arduino er så populær? Fordi den er simpel og let at overskue, og det samme gælder Max-i. De korteste telegrammer er på kun 5 bytes, som inkluderer en 12 bit identifier, 4 bit data og en 20 bit CRC check, som også indeholder en 7-bit Hamming kode af identifieren og kan indeholde et 7-bit telegramserienummer. Det er til at overse og debugge, og det åbner op for Maker bevægelsen - også for dem, der ikke er eksperter.

  • 8
  • 3

Men det er altså ikke klar til det endnu?

Kun de gamle 12-V evalueringsmoduler med kun 2 indgange og 3 udgange, der dog kan køre alle versioner af SPI som master. De nye 20-V moduler med 6 udgange og formodentlig også 6 indgange må du vente til det nye år med.

Iøvrigt er Max-i godt egnet til CNC styring, da man kan benytte et fælles telegram til mange enheder og så bare specificere et bytedelay i hver enhed som i DMX512. På den måde vil alle akser blive synkroniseret med en indbyrdes tidsforsinkelse, der kun svarer til tidsforsinkelsen på kablet dvs. ca. 5 ns/m. I de flaste andre feltbusser skal man sende meddelelser til X, Y, Z og andre akser som separate telegrammer til de enkelte servomotorer med det resultat, at maskinen kører i zig-zag.

  • 4
  • 2

De samlede projektomkostninger bliver mindre fordi du får et mere homogent system og åbner op for mindre specialiseret arbejdskraft.

Hvad er billigst - En flok højt specialiserede i 3 måneder mens anlægges opbygges og indkøres - Eller et voksende tillæg til IT-afdelingen i 10 år?

Og hvorfor skal IT-folkene være mindre specialiserede? Så snart noget er koblet på "IT" er grænsefladen meget større, hvilket giver langt flere muligheder for (mange flere) at lave noget l**t - Så dem der satser på at det kan laves til ingen penge i Indien - De taber formentlig ret hurtigt til dem der sidder ude i processen og har overblik over hele processen, mens de fejlsøger...

Man kunne også spørge - Nu vi delvist er i IT - Hvorfor bruger vi stadig mainframes - Det er da gammel og besværlig teknologi der kræver en høj grad af specialisering... Eller hvad?

KISS, Occams ragekniv m.fl. vinder altid til sidst - Færre muligheder = færre fejl

  • 4
  • 0

Har prøvet installationer med Ethercat (Ethernet)+100 og med Profibus (RS485)+1000slaver. Det er bare meget nemmere at fejlfinde på en stjerne topologi end på en alm bus topologi.
Jeg vil aldrig igen tilbage til Profibus, for mange små problemer tager for lang tid at løse.
Performance på Ethernet er også væsenligt højere og latency I eks. Ethercat er mig bekendt langt under 1ms. Der laves Ethernet slaver med indbygget switch. :)
I vores produktion anvende vi Ethernet eller rs232.(Enheder der ikke understøtter andet). Vores stegkode læsere er forbundet med Ethernet, det er skønt at man hurtigt kan se og trimme stegkodelæseren.

  • 5
  • 0

Det er bare meget nemmere at fejlfinde på en stjerne topologi end på en alm bus topologi.

Kriteriet for om man let kan fejlfinde er primært, om man bare kan koble en debugenhed på og snakke med alle enheder uden at skulle rekonfigurere noget som helst. Så er det ligegyldigt, om der er tale om en stjerne topologi, en trunk-line eller en lukket ring.

STL-nettet, som jeg lavede til Søren T. Lyngsø's STELLA system for ca. 35 år siden, var ligesom Max-i en multimasterbus baseret på bit-vis busarbitrering, som er det eneste multimasterprincip, som tillader, at man uden nogen rekonfiguration bare kan koble én eller flere debugenheder på bussen. Den slags debugenheder producerede vi på samlebånd i laboratoriet, og de gjorde det muligt ikke bare at snakke med alle STELLA computere på bussen via. en række standardmonterede busudtag, men også at manipulere med alle interne parametre i SLS/PLC fortolkeren, så man f.eks. kunne starte et anlæg, selv om et startkriterie ikke var opfyldt. Der var også et "speedometer", så vi kunne aflæse netbelastningen og dermed garantere, at bussen ikke var overbelastet. Det fungerede helt perfekt, så jeg forstår ikke, hvordan du kan påstå, at en stjerne topologi er lettere at fejlfinde på end en almindelig bus topologi (trunk-line).

Jeg vil aldrig igen tilbage til Profibus, for mange små problemer tager for lang tid at løse.

Hvad problemerne skyldes, ved jeg ikke; men jeg kan ialtfald pege på to muligheder:

1) Hvis man anvender Profibus FMS, som er en multimasterbus baseret på token-passing, skal man omkonfigurere for at kunne tilslutte en debugger, da den jo skal ind i token rækkefølgen for at kunne kommunikere. Alternativt og ved Profibus DP, som er en single-master bus, skal man have et debugudtag på én eller flere enheder og kan så kun kommunikere via dem og dermed med deres evt. begrænsninger.

2) Profibus benytter i modsætning til Ethernet og Max-i et skærmet kabel, hvor skærmen skal forbindes til stel i begge ender, hvilket automatisk sker i enhederne. I et procesanlæg er det bare en særdeles dårlig idé at skabe jordsløjfer på den måde og skabe potentialudligning via et tyndt feltbuskabel - specielt i TN-C anlæg, hvor man har fælles beskyttelsesjord og 0-leder. F.eks. har min gamle ven Jens EMC med et tangamperemeter målt strømme på så vidt jeg husker ca. 40 A i et trappegelænder, han syntes var lidt varmt(!), så det er temmelig indlysende, at en feltbus skal være galvanisk adskilt, hvilket Ethernet er pga. transformatoren og Max-i er, fordi den udnytter den galvaniske adskillelse, der normalt er i simple aktuatorer og sensorer. Ved jordede enheder benytter Max-i en galvanisk adskillelse mellem IC'en og det jordede udstyr (ikke mellem IC og buskabel), og IC'en vil bl.a. til det formål både stille en 5 V og en 3,3 V til rådighed, som tilsammen må belastes med 100 mA (switched-capacitor converter).

Vores stegkode læsere er forbundet med Ethernet, det er skønt at man hurtigt kan se og trimme stegkodelæseren.

Min printer er også forbundet med Ethernet, hvilket virker fint for udskrivning, men det gør den hændelsesstyrede statusvisning for blækniveau, papirfejl etc. derimod ikke, og som det er tilfældet i IT-verdenen, er man bare "lost" og må leve med fejlen, når noget ikke virker :-(

Iøvrigt kan jeg ikke se, hvorfor en stregkodelæser ikke lige så godt kunne være forbundet med Max-i, som er hændelsesstyret og dermed perfekt egnet til den slags formål. Man vil oven i købet kunne koble et vilkårligt antal stregkodelæsere, dankort terminaler, kortlæsere etc. ind på samme bus og kan så samtidig trække den nødvendige strøm til dem fra kablet.

Ethernet er fremragende til overførsel af store datamængder, men til korte telegrammer vil jeg påstå, at en traditionel feltbus er både billigere, langt mere pålidelig og betydelig lettere at debugge.

  • 7
  • 4

100-250 ms er vel latenstiden hvis de to der kommunikerer gør det gennem et datacenter et andet sted i verden - hvilket er en dybt tåbelig måde at gøre det på.

To enheder på et lokalt netværk skal på ingen måde bruge så lang tid.

  • 4
  • 0

100-250 ms er vel latenstiden hvis de to der kommunikerer gør det gennem et datacenter et andet sted i verden - hvilket er en dybt tåbelig måde at gøre det på.

To enheder på et lokalt netværk skal på ingen måde bruge så lang tid.

Latency fra den ene ende af Danmark til den anden er på ethernet ca. 3-4 millisekunder. Inden for samme matrikel er latency langt under et millisekund og afgøres primært af hastigheden på de tilsluttede enheder i hver ende af ethernetkablet.

Ethernet er dog efter best-effort-princippet - der er ingen garanti for at en pakke når frem inden for et bestemt tidsrum, eller om den overhovedet når frem. Men i praksis gør den, og især i et kontrolleret miljø som et LAN må antages at være.

Så mon ikke det er et spørgsmål om tid inden industrien vænner sig til at best-effort for det meste er godt nok, og den økonomisk mest forsvarlige løsning - ligesom telebranchen efterhånden har erkendt?

  • 3
  • 0

ligesom telebranchen efterhånden har erkendt?

I IT-verdenen er vi stadig nogen der savner STYRING og GARANTIER, som der f.eks. var med Token Ring 4Mbit/s.
Tænk dog på, at med Ethernet er der jo INGEN STYRING, og dermed INGEN GARANTIER!

... tankevækkende at såvel netværkstrafik som person- og vareflytning i praksis OFTE fungerer bedst når det er "relativt anarkistisk" i stedet for STYRET og GARANTERET.
I praksis fungerer vejtrafikken såledet OFTE bedre end togtrafik, trods den manglende STYRING af vejtrafikken.

(ironi VAR anvendt om Token Ring - som også jeg engang troede ALTID måtte være bedre end det uforudsigelige, anarkistiske Ethernet, hvor ingen åbenbart kunne garantere noget som helst).

ATH0

  • 3
  • 2

... tankevækkende at såvel netværkstrafik som person- og vareflytning i praksis OFTE fungerer bedst når det er "relativt anarkistisk" i stedet for STYRET og GARANTERET.

Ved mange feltbusser og Ethernet - men ikke Max-i - er det et spørgsmål om pest eller kolera. Gør man systemet deterministisk med f.eks. faste tidsintervaller, sænker man ofte effektiviteten så meget, at der kan komme flere telegrammer igennem pr. sekund ved ren anarki. Alligevel foretrækkes ofte determinisme i industrimiljø, så man kan garantere en vis maksimal responstid, og langt de fleste industrielle Ethernetprotokoller går netop på at gøre Ethernet deterministisk,

Feltbussystemer baseret på bit-vis busarbitrering som Max-i og CAN benytter i princippet den hurtige, anarkistiske metode; men Max-i har så yderligere en speciel "babbling-idiot-protection", der sikrer, at alle enheder, der ønsker adgang, blot komme igennem én efter én, hvis nettet belastes hårdt, så Max-i kører fint selv ved 100% belastning.

  • 2
  • 3

Hej alle
Undskyld mig, men der er virkelig emner der ikke bliver belyst i denne debat.
Max-i ??? hvor er den internationale understøttelse af denne "såkaldte feltbus løsning"?

I forbindelse med nogle af de forskellige indlæg henvises der til Profibus FMS(Fieldbus Message Specification) hvilket var en protokol der blev benyttet for +20 år siden "WAY OFF"" men dette var en løsning som lå meget tæt op af de forskellige PC programmører, men overhovedet ikke i nærheden af hvad Automations folk ønsker og benytter.

Har jeg glemt at snakke om de +56 mill (Skriver: seksoghalvtres millioner !) Profibus noder der benyttes i dag ! og stadigvæk stigende !

Standardisering frem for alt, det er den eneste vej frem, vi kan ikke leve med mindre nationale løsninger
Dette betyder også at alle de "ganske fornuftige løsninger" som Stella mm. aldrig nogensinde har fundet plads internationalt. (og dette vil heller ikke ske for Max-I) som godt kan være en god feltbus løsning.

I øvrigt er Profibus International ved at være ved at definere næste generation af PROFINET du kan se meget mere på:
https://www.profibus.com/newsroom/press-re...

  • 3
  • 1

Max-i ??? hvor er den internationale understøttelse af denne "såkaldte feltbus løsning"?
...
Standardisering frem for alt, det er den eneste vej frem, vi kan ikke leve med mindre nationale løsninger

Der findes ikke én eneste feltbusløsning incl. Profibus, som ikke i starten var en mindre national løsning, så skal vi stoppe udviklingen ved Adam og Eva og aldrig nå videre, og hvad med IO-Link, som netop er en relativ ny udvidelse til bl.a. Profibus, da Profibus ofte er for dyr til den sidste strækning ud til low-cost aktuatorer og sensorer?

I forbindelse med nogle af de forskellige indlæg henvises der til Profibus FMS(Fieldbus Message Specification) hvilket var en protokol der blev benyttet for +20 år siden "WAY OFF"" men dette var en løsning som lå meget tæt op af de forskellige PC programmører, men overhovedet ikke i nærheden af hvad Automations folk ønsker og benytter.

Når jeg henviste til Profibus FMS, som formodentlig stort set ikke bruges mere, var det fordi, den var en multimasterbus, hvad Profibus DP ikke er. At hævde, at automationsfolket ikke er interesseret i multimasterbusser er direkte forkert. Jeg forlod ikke-hændelsesstyrede systemer og busser for 35 år siden, da de efter min mening har alt for lav effektivitet og er alt for svære at debugge, da man ifølge sagens natur ikke bare kan manipulere med værdier og tilkoble en debugenhed!

Dette betyder også at alle de "ganske fornuftige løsninger" som Stella mm. aldrig nogensinde har fundet plads internationalt.

Nej, for Lyngsø gik ned, inden STL-net kunne nå at blive en standard, og STL-net er idag forældet, ligesom mange af de andre feltbusser fra den tid også er det! STL-net var måske verdens første multimasterbus med bit-vis busarbitrering. CAN blev først lanceret nogle måneder senere, men er nok blevet udviklet parallelt. Til gengæld var CAN før mig med den geniale Publisher-subscriber model, hvilket stadig irriterer mig :-) Den model har jeg naturligvis adopterer på Max-i; men stort set alle andre feltbusser adresserer stadig den enkelte enhed og ikke den enkelte procesværdi - incl. Profibus og selv de fleste CAN protokoller, som f.eks. CANOpen.

(og dette vil heller ikke ske for Max-I) som godt kan være en god feltbus løsning.

Hvordan kan du vide det? Der er ialtfald én ting, jeg har lært af alle mine år i automations- og elektronikbranchen, og det er, at det absolut vigtigste kriterie for rigtig mange personer er prisen, og her vil en Max-i løsning i IC version blive stort set lige så billig som en IO-Link device controller; men mindst lige så slagkraftig som Profibus FMS og DP og langt bedre egnet til IoT. Du får f.eks. pokkers svært ved at trække op omkring 1 kW ud af Profibus kommunikationskabler til f.eks. LED belysning, vinduesåbnere og ladning af bærbare PC'er, og IoT markedet med bl.a. intelligente huse er meget større end automationsmarkedet.

Hvad der bliver standard afhænger primært af, hvad pengestærke firmaer eller investorer bakker op om - ikke om der er tale om helt nye løsninger, hvad der f.eks. er tilfældet for de talrige, trådløse løsninger, der til stadighed dukker op.

  • 3
  • 3

Ikke ligefrme en god artikel..... Nærmest forvridende i sine eksempler. +100ms ses kun i store DCS-systemer hvor man behandler data og lige skal comitte det hele i en SQL-base førned næste scan kører. F.eks. ABB XA800 - men det ville man selvsagt ikke bruge til de til ventilen som nævnes.

Carsten> at det absolut vigtigste kriterie for rigtig mange personer er prisen,

Nej det er engineeringstiden! Vi er ikke ligeglade med prisen men det engineering, applicaitons-udvikling, og commisioning som koster suverænt mest! (Og her har jeg Automations-manager-hatten på hos en maskinbygger der høretil på samme adresse som Lyngsø Marine).
Og at sætte et patch-kabel fra en IO-nodes videre til et servo-drev osv. kræve meget mindre engineering, eltegning og installation. Hvem gider står og tylle ledere på en profibus/CAN?

Fieldbus er død - men det har intet med latency og gøre, men alt at gøre med at kablings-infrastrukturen er den samme uagtet om det er EtherCat/ProfiNet/EtherIP/ModbusTCP/OPC-UA osv.

Af samme årsag har Max-I ikke en chance, specielt ikke nu hvor alle partout vil pushe I/O-link.

Til sidst en lille kommentar vedr. tids-synkronisering som blev bragt op:

> I de flaste andre feltbusser skal man sende meddelelser til X, Y, Z og andre akser som separate >telegrammer til de enkelte servomotorer med det resultat, at maskinen kører i zig-zag.

Det citerede er noget totalt vrøvl! Og ja, jeg er uddannet indenfor servo-teknik, var hjælpelærer i det på DTU (på samme tid som Baldur), og har arbejdet som konsulet med det siden 2002.
F.eks. Ethercat synkroniserer lokale realtids-clock med præcision som måles i nanosec. Telegrammerne sendes typisk med 0.5-4ms interval fast konfigureret, og setpunkter aktiveres samtidigt med den synkrone clock.
Ergo er der ikke noget som kører zig-zag!
Clock-algoritmen minder meget om NTP-metoden med målte transmissions-latency (antages symmetrisk i begge retninger).

Den metode som Carsten referer blev f.eks. brugt i SERCOS-II via MST-telegrammet - der snakker vi us i synkroniserings-præcision, altså en hel decade til forskel.

I øvrigt er CAN ligeså dårlig som CSMA/CD-netværk grundet bit-arbitreringen. Der er så tiltag som TT-CAN osv. men reelt er det ikke en bedre bus til formålet - det virker dog stadig hvis blot man laver det rigtige regelsæt for slavernes opførsel som bla. CAN-Open gør.

  • 3
  • 2

Nej det er engineeringstiden!
...
Og at sætte et patch-kabel fra en IO-nodes videre til et servo-drev osv. kræve meget mindre engineering, eltegning og installation. Hvem gider står og tylle ledere på en profibus/CAN?
...
Fieldbus er død - men det har intet med latency og gøre, men alt at gøre med at kablings-infrastrukturen er den samme uagtet om det er EtherCat/ProfiNet/EtherIP/ModbusTCP/OPC-UA osv.

Du finder ikke noget feltbussytem med kortere engineeringtid end Max-i. Brugeren skal bare tilkoble kablet, som ikke engang har en bøvlet skærm, og så stille et par registre med bl.a. identifier. Der er netop ikke behov for gammeldags IO-nodes med tilhørende computer, klemkasser og forskruninger.

Af samme årsag har Max-I ikke en chance, specielt ikke nu hvor alle partout vil pushe I/O-link.

Og hvorfor vil alle pushe IO-Link og have besværet med først at sende data ud til en distribueret IO-node med en gateway og så videre derfra til den enkelte sensor og aktuator? Fordi traditionelle feltbusser er for dyre til at gå det sidste stykke af vejen! Alt andet lige er ét niveau i kommunikationen, som ved Max-i, altså betragtelig nemmere at overskue end to eller flere som ved f.eks, Profibus + IO-Link.

Til sidst en lille kommentar vedr. tids-synkronisering som blev bragt op:

> I de flaste andre feltbusser skal man sende meddelelser til X, Y, Z og andre akser som separate >telegrammer til de enkelte servomotorer med det resultat, at maskinen kører i zig-zag.

Det citerede er noget totalt vrøvl! Og ja, jeg er uddannet indenfor servo-teknik, var hjælpelærer i det på DTU (på samme tid som Baldur), og har arbejdet som konsulet med det siden 2002.

Det er da ikke noget vrøvl. Hvis en maskine ikke skal køre i zig-zag, skal alle servoakser opdaters nøjagtig samtidig. Det sker ikke automatisk, hvis man bare sender telegrammer til de enkelte servomotorer én efter én. I Max-i kan man sende data til mange enheder i samme telegram, og data bruges så nøjagtig samtidig i alle enheder, når CRC check'et er verificeret. Da det oven i købet sker i ren hardware, er tidsforsinkelsen mellem de enkelte enheder kun bestemt af tidsforsinkelsen på linjen, sample tiden for kommunikationen og den evt. tid, det tager at clocke data videre fra Max-i controlleren til servomotoren f.eks. via et SPI interface.

F.eks. Ethercat synkroniserer lokale realtids-clock med præcision som måles i nanosec. Telegrammerne sendes typisk med 0.5-4ms interval fast konfigureret, og setpunkter aktiveres samtidigt med den synkrone clock.

Selv om alle enheder opdateres med f.eks. 400 us interval, skal man stadig sikre sig, at data i de telegrammer, der sendes først, holdes tilbage, indtil alle telegrammer er udsendt. Det kan selvfølgelig gøres med præcis tidssynkronisering - jeg siger ikke, at Max-i's metode er den eneste mulige; men med Max-i er man ikke afhængig af et fast tidsinterval og kan derfor bare sende telegrammerne så hurtigt som muligt, og får man af én eller anden grund for travlt til f.eks. 400 us, sker der ikke det store, hvis et interval udvides til f.eks. 600 us, hvis blot aksedata korrigeres tilsvarende. Det gør der med de faste tidsintervaller, hvilket betyder, at et tidsstyret system ikke kan presses så hårdt som ét, der benytter et fælles telegram.

Den metode som Carsten referer blev f.eks. brugt i SERCOS-II via MST-telegrammet

Nej. Det svarer til DMX512, som bruges til scenelys blot med den forskel, at data ikke benyttes, før den fælles CRC-check er verificeret (DMX512 har ingen datacheck). Der er netop ingen synkroniseringstelegrammer (bortset fra tidstelegrammer, som bruges til at muliggøre nøjagtig tidsstempling af data og synkronisere lampeblink).

I øvrigt er CAN ligeså dårlig som CSMA/CD-netværk grundet bit-arbitreringen.

Nej, ikke helt - man må skelne mellem destruktiv og ikke-destruktiv bus arbitrering; men CAN har i modsætning til Max-i ingen "babbling-idiot-protection", så en højt prioriteret værdi kan lægge hele netværket ned, så CAN er i modsætning til Max-i ikke deterministisk.

Der er så tiltag som TT-CAN ...

TT-CAN er netop et forsøg på at klare dette problem; men det nedsætter effektiviteten drastisk.

Det gamle thick-ethernet, der benyttede CSMA/CD, havde destruktiv busarbitrering, idet kollosionsdetekteringen var baseret på en DC-strøm med tilhørende spændingsmåling. Det betød, at i tilfælde af kollision måtte man rafle om tilgang til bussen, hvilket spildte tid og betød, at thick-ethernet i praksis ikke kunne belastes mere end omkring 10%. Det problem eksisterer ikke med CAN og Max-i, som begge benytter ikke-destruktiv busarbitrering. Der er dog det problem med CAN på lange afstande (ikke i biler, som CAN er skabt til), at hvis mere end to enheder i hver ende af et linjestykke går på linjen samtidig, vil den uundgåelige linjeringning mellem enhederne som følge af naturlovene blive så stor, at signalet ikke kan detekteres korrekt på dette stykke af linjen. Desuden kan et stort spændingsfald på linjen også volde problemer pga. det offset, der skabes ved, at alle CAN transceivere normalt er forbundet til den negative forsyningsledning. I Max-i trækkes det meste overskydende energi ud af linjen vha. de specielle clamp-netværk, der erstatter modstandstermineringerne, hvilket holder linjeringningen på et ubetydeligt niveau, og al kommunikation refererer til et kunstigt midtpunkt mellem forsyningslederne, så hvis bare kablet benytter samme kvadrat for + og - eller der kompenseres for forskelle i DC-modstand, er der intet problem med spændingsfald i kablet.

  • 1
  • 3

Hej Carsten! Jeg er tilbøjelig til at give dig ret i det meste du skriver - men du glemmer en meget vigtig ting: For at nogen bruger en bus, er det vigtigt at den er defacto standard hos de helt store. F.eks. Microsoft, Apple, IBM eller Intel. Og det mangler din Max-i bus! Indenfor industri, findes lidt andre spillere på markedet, f.eks. Simens og Honywell. Så mit råd til dig er at alliere dig med en af dem, men ikke alliere dig bedre, end at bussen stadigt må bruges af andre, end dem/de du samarbejder med. Og, få den gjort til standard i deres systemer. Her i Danmark har vi også flere der laver PLC'er og lignende udstyr, f.eks. Logic IO. De satser dog på trådløs kommunikation.

  • 2
  • 0

Det gamle thick-ethernet, der benyttede CSMA/CD, havde destruktiv busarbitrering, idet kollosionsdetekteringen var baseret på en DC-strøm med tilhørende spændingsmåling. Det betød, at i tilfælde af kollision måtte man rafle om tilgang til bussen, hvilket spildte tid og betød, at thick-ethernet i praksis ikke kunne belastes mere end omkring 10%. Det problem eksisterer ikke med CAN og Max-i, som begge benytter ikke-destruktiv busarbitrering.


Jeg tror vi har været inde på det før, men destruktiv busabitrering betyder ikke nødvendigvis en lavere hastighed på nettet. Det er korrekt, at der går data tabt. Men du bruger også tid på busabitrering, og CAN bussen gør også, da det tager tid for data at udbrede sig over netværket. Det er naturligvis ikke lang tid, men i stedet for at lave en bitvis arbitrering, der beror på 0 eller 1, så kan man også lave en bitvis abitrering, der beror på ikke kollision eller kollision. Dette muliggør, at nettet kan udnyttes effektivt, og der kan ofte sendes mange data på den tid, du bruger til arbitreringen. Med en tilpas protokol, kan du begrænse antallet af kollisioner til at være log2 til antallet af noder, der sender ud samtidigt. Sender således 7 i munden på hinanden, opstår max 3 kollisioner. Og disse sker indenfor ganske kort tid, efter en pakke udsendes - oftest hurtigere, end den tid du bruger, før du detekterer en anden sender samtidigt, med bitvis arbitrering. Dataene udbreder sig med tæt på lysets hastighed, så det går ikke længe, før der opdages en kollision. Og den samlede tid er brøkdele af mikrosekunder, hvis det er et netværk på almindelig størrelse. Er netværket enormt, kan tage længere tid før der kommer en kollision, men så accepteres også en længere tid ved bitvis arbitrering - da det tager længere tid for data at udbrede sig på netværket. Ved kollisionsbaserede systemer, så skal du ikke tænke på konfiguration, da tiden før der kommer en kollision, og dermed netværkets ledningers fysiske længde, automatisk detekteres. Det ideelle system, er derfor det gamle kollisionsbaserede ethernet, men justeret lidt i måden protokollen fungerer. Så kan man opnå, at kollisionerne sker meget hurtigt, når flere forsøger samtidigt adgang, og at kollisionen sker i starten af pakken, så der ikke skal sendes mange data igen. Og, man kan sikre sig, at antallet af kollisioner er max log2 til antallet af computere, der samtidigt forsøger at sende data. Ofte er der kun en der forsøger at sende data, og så er der ingen kollision.

Vi er helt enige om, at binær arbitrering, som sker i din bus, og can bussen, er det bedste. Men, det behøver ikke at ske ved at logisk or'e 1'er og 0'er på et netværk. Det kan også ske, ved at detektere om der er kollision eller ej. Kollisioner fungerer fint som logisk or. Og samtidigt, så opdages netværkets længde, ved at se hvor længe det går før kollisionen opstår - og dermed justeres tiden på at detektere kollisioner til absolut minimum, ud fra kabellængde og hastigheden i kablet (tæt på lysets hastighed).

Ligesom ved binær arbitrering, kan du også bruge kollisioner til at lave prioriteter, og til at få adgang i bestemt rækkefølge, så der opstår en ligelig fordeling - eller programmerbar fordeling - af brugen af netværkets båndbredde. Har du f.eks. en enhed, som kræver stor båndbredde, så er muligt at reservere denne båndbredde. Og har du en enhed, der kræver højere prioritet, f.eks. bremser, interrupts og lign. så er muligt, at give dem højere prioritet, så de kommer på øjeblikkeligt, med højst en kollision (der kan komme en kollision, når de kommer på, da netværket kan være ved at sende data). Er der flere med høj prioritet, kan det naturligvis betyde log2 antal kollisioner, så de kommer på i rækkefølge. Det er kun et spørgsmål om, at bruge logisk or, ved hjælp af kollisioner, sammen med nogle små delays, på en god måde. Så er det ligeså pålideligt, og deterministisk, som CAN busser, og andre hvor der ikke sendes data under den binære arbitrering. Om binær arbitrering sker uden der sendes data (ikke kollisionsbaseret, men hvor det kun trækkes f.eks. høj eller lav), eller om det sker med data (kollisionsbaseret), er stort set ligegyldig for princippet. Men, det væsentlige er, at ved kollisionsbaseret, kan man opnå at netværkets forsinkelse på grund af størrelse, automatisk bliver større/mindre, afhængigt at netværkets størrelse, og derfor bliver hurtigt ved små netværk, og mindre hurtigt ved store, uden at skulle opsættes og opmåles. Og, som nævnt, så kan man sende data, og bruge tiden effektivt, i de tilfælde at der ikke er en kollision. En henvisning til en tåbelig protokol, der var udviklet til at få store netværk til at gå død, er ikke et brugbart bevis for, at kollisionsbaserede netværk er upålidelige. Du vil hurtigt opdage, at nogle kan lave en protokol der er stort set identisk med din, og som beviser at dit er helt ubrugeligt. Den slags har vi set ofte. Ok, det er så måske ikke det samme, og det kan man argumentere for i al evighed. Der er lavet mange dårlige kollisionsbaserede systemer - indrømmet. Men, det er intet bevis imod at de kan være gode. Dem, der har været gode, er bare ikke blevet defacto standard.

  • 3
  • 2

Hej Carsten! Jeg er tilbøjelig til at give dig ret i det meste du skriver - men du glemmer en meget vigtig ting: For at nogen bruger en bus, er det vigtigt at den er defacto standard hos de helt store. F.eks. Microsoft, Apple, IBM eller Intel.

Det er jo netop også det, jeg skriver, så jeg har absolut ikke glemt det:

Hvad der bliver standard afhænger primært af, hvad pengestærke firmaer eller investorer bakker op om ...

Jeg er fuldstændig klar over, at jeg skal have en investor på banen; men ikke før systemet er ordentlig gennemtestet. Den slags folk har ikke meget tålmodighed, så alt skal ligge klar til produktion af IC og infrastruktur i form af f.eks. 20-V stikkontakter og lignende, inden jeg for alvor går den vej :-)

Max-i ville aldrig kunne være udviklet i et stort firma, for der ville være nogle "jakkesæt", der blot ville sætte mange mand på opgaven, forlange at være færdig i går, og absolut ikke har nogen forståelse for, at det kan være nødvendigt at gå helt tilbage og ændre noget grundlæggende, som det er sket med Max-i flere gange, da bl.a. den DMX512 lignende multienhedskommunikation blev indført, og da jeg gik fra 2 til 4 bit for boolske værdier. Max-i udviklingen er endt med at tage rigtig mange år, men er til gengæld endt som mit "masterpiece", som jeg godt vil være bekendt :-)

  • 2
  • 5

men i stedet for at lave en bitvis arbitrering, der beror på 0 eller 1, så kan man også lave en bitvis abitrering, der beror på ikke kollision eller kollision.
...

Alt det her har vi jo været igennem før og diskuteret i én uendelighed; men du har endnu aldrig været i stand til at vise, hvordan du vi realisere det i praksis. Beskriv i det mindste lag 1 af OSI modellen med den bitkodning, som skal gøre det muligt.

  • 1
  • 3

Jeg er fuldstændig klar over, at jeg skal have en investor på banen; men ikke før systemet er ordentlig gennemtestet. Den slags folk har ikke meget tålmodighed, så alt skal ligge klar til produktion af IC og infrastruktur i form af f.eks. 20-V stikkontakter og lignende, inden jeg for alvor går den vej :-)

Max-i ville aldrig kunne være udviklet i et stort firma, for der ville være nogle "jakkesæt", der blot ville sætte mange mand på opgaven, forlange at være færdig i går, og absolut ikke har nogen forståelse for, at det kan være nødvendigt at gå helt tilbage og ændre noget grundlæggende, som det er sket med Max-i flere gange, da bl.a. den DMX512 lignende multienhedskommunikation blev indført, og da jeg gik fra 2 til 4 bit for boolske værdier. Max-i udviklingen er endt med at tage rigtig mange år, men er til gengæld endt som mit "masterpiece", som jeg godt vil være bekendt :-)


Ja, jeg kender dem også disse "jakkesæt" folk, og når man så forklarer dem, at det altså ikke er færdig endnu, så sætter de konsulenter på opgaven, der har fået til opgave, at bevise det er færdigt, selvom ophavsmanden siger nej!!! Næste dag, bliver man truet med fyring, indtil de så besinder sig.

Jeg er dog ikke enig med dig i, at det er sådan det foregår i de helt store virksomheder. De ved godt at tingene skal fungere. Og mange af dem, som sættes af på en opgave, gør meget i at tjekke tingene ordentligt igennem. Jeg tror godt at du vil kunne bruge et stort antal ingeniører, og få produktet hurtigt færdigt, og måske endda mere testet, end du orker at gøre alene. Men det koster. Og så er vi oppe i de helt store virksomheder som f.eks. chip producenter som Intel, Microchip, og de største indenfor industriel elektronik, f.eks. Siemens og Honywell.

  • 1
  • 1

Jeg er dog ikke enig med dig i, at det er sådan det foregår i de helt store virksomheder. De ved godt at tingene skal fungere.

Jeg har selv måttet slås hårdt for at lave ændringer, fordi det efter min mening ikke virkede ordentligt, hvor chefen blot syntes, at det måtte være godt nok, så vi kunne komme videre, så jeg kender godt proceduren med "jakkesættene".

Jeg tror godt at du vil kunne bruge et stort antal ingeniører, og få produktet hurtigt færdigt, og måske endda mere testet, end du orker at gøre alene.

Når man sætter mange folk på en opgave, bliver kvalitetsniveauet laveste fællesnævner, hvilket godt kan give frustrationer, hvis andre i gruppen har højere kvalitetskrav, og det kan være næsten umuligt at gå tilbage og lave grundlæggende ændringer, fordi andres arbejde så skal laves om, hvilket der sjældent er forståelse for. Specielt inden for software kan det være ekstremt frustrerende at have skabt en ordentlig struktur og så få "hjælp" af andre, der på rekordtid smadrer det hele. Den har jeg også prøvet. Derfor vil jeg stadig fastholde, at Max-i aldrig var blevet det, den er, med mange folk på opgaven og en chef, der blot vil have det hele færdigt hurtigst muligt.

Der er meget få, der interessere sig for produkter og løsninger fra små firmaer, så med mindre man gør det 10 gange bedre end alle andre på stort set alle punkter, er der ingen, der gider interessere sig for dine løsninger. Folk vil hellere have en uoptimal løsning fra et stort firma end en perfekt fra et lille, så den eneste chance, et lille firma her, er at lave helt enestående løsninger.

  • 1
  • 5

Jeg køber automations løsninger til fabriksanlæg selvfølgelig i samarbejde med slutkunden. . Trådløse løsninger bliver ofte meget hurtigt taget af bordet pga bekymringer om robusthed. Hvordan klarer de sig i industrielle miljøer med masser af stål, sensorer som sidder gemt bag maskiner, elektromagnetisk støj fra motorer, osv osv. ? Mange tænke på de problemer man har med mobiltelefoner og wifi og der er til dato ingen af mine kunder der har villet trådløs. I særdeles når erfaringerne med kablede løsninger jo er gode og oftest skal der jo alligevel trækkes strøm ud til udstyret så det koster ikke ret meget at tage et signalkabel med rundt samtidig. Der er ingen nævneværdig økonomisk fordel og jeg vil som systemleverandør ikke sætte hverken prestige eller contingency på trådløs automation generelt medmindre slutkunden forlanger det - hvilket ikke er sket endnu.

  • 2
  • 0

Jeg har selv måttet slås hårdt for at lave ændringer, fordi det efter min mening ikke virkede ordentligt, hvor chefen blot syntes, at det måtte være godt nok, så vi kunne komme videre, så jeg kender godt proceduren med "jakkesættene".

Jeg tror godt at du vil kunne bruge et stort antal ingeniører, og få produktet hurtigt færdigt, og måske endda mere testet, end du orker at gøre alene.  

Når man sætter mange folk på en opgave, bliver kvalitetsniveauet laveste fællesnævner,


Chefer bliver ofte utålmodige. Det medfører forkerte beslutninger, som i den sidste ende bliver meget dyrere. Selvom man beviser det, så kan en forkert beslutning normalt ikke gøres om, for den er taget af chefen, og verificeret og godkendt at masser af konsulenter... Når man sætter mange på en opgave, bliver kvalitetsniveauet ikke laveste fællesnævner. Det gør den kun, hvis det er den kvalitet, som chefen ønsker. Vælger chefen den laveste kvalitet, med argumenter som at det er billigst (hvilket som regel er det rene vås, men et godt argument), så bliver det naturligvis laveste kvalitet. Men, går chefen ind for høj kvalitet, så vælges ikke nødvendigvis det dårligste.

I gode virksomheder, har man dygtige chefer, der ikke bliver nervøse og tager forkerte beslutninger, men som formår at få medarbejderne til at arbejde med resultaterne, og arbejde sig til resultaterne. Man skal ikke beslutte. Man skal arbejde sig til resultaterne. Problemet er, at beslutte kan alle, uden kompetancer - alene på baggrund af argumenter, og hvordan de lyder for øjet.

  • 0
  • 2

Folk vil hellere have en uoptimal løsning fra et stort firma end en perfekt fra et lille, så den eneste chance, et lille firma her, er at lave helt enestående løsninger.


Min erfaring er, at ingen ønsker det enestående. Du skal helst lægge fejl ind, så de har noget at rette, og kan sætte deres "fingerpræg" på. Det er æren, som er op spil. Er de oppe imod det perfekte, er de villige til at spendere rigtig mange ressourcer på, at få alle til at sige noget andet.

  • 0
  • 3

Når man sætter mange på en opgave, bliver kvalitetsniveauet ikke laveste fællesnævner. Det gør den kun, hvis det er den kvalitet, som chefen ønsker. Vælger chefen den laveste kvalitet, med argumenter som at det er billigst (hvilket som regel er det rene vås, men et godt argument), så bliver det naturligvis laveste kvalitet. Men, går chefen ind for høj kvalitet, så vælges ikke nødvendigvis det dårligste.

Det har nu ikke noget med hverken chefen eller et bevidst valg af kvalitetsniveau at gøre, men det simple faktum, at ingen kæde er stærkere end det svageste led dvs. den dårligste programmør.

Desuden er det sådan, at hvis ét eller andet er lavet af én person, har vedkommende 100 % ansvar. Ved bare 2 personer har de højest 10% ansvar hver, da det pr. definition altid er den andens fejl :-)

Min erfaring er, at ingen ønsker det enestående. Du skal helst lægge fejl ind, så de har noget at rette, og kan sætte deres "fingerpræg" på.

Jo, ingen ønsker fejl; men der er næsten altid en kværulant, som vil have sit fingeraftryk på enhver sag, så det kan være en god idé at indføre en rimelig synlig, men dog ikke alt for åbenlys fejl, som man allerede har en løsning på (kan være indbygget og frakobles med en switch). Denne kværulant vil så forlange, at det bliver ændret, hvilket man så efter lidt spilfægteri går med til :-) Er der ikke en sådan åbenlys fejl, skal vedkommende nok finde noget, og så kan man komme til at rette på steder, som man ikke ønsker.

  • 1
  • 2

Re: Ikke ligefrme en god artikel.

Når man sætter mange på en opgave, bliver kvalitetsniveauet ikke laveste fællesnævner. Det gør den kun, hvis det er den kvalitet, som chefen ønsker. Vælger chefen den laveste kvalitet, med argumenter som at det er billigst (hvilket som regel er det rene vås, men et godt argument), så bliver det naturligvis laveste kvalitet. Men, går chefen ind for høj kvalitet, så vælges ikke nødvendigvis det dårligste.  

Det har nu ikke noget med hverken chefen eller et bevidst valg af kvalitetsniveau at gøre, men det simple faktum, at ingen kæde er stærkere end det svageste led dvs. den dårligste programmør.

Desuden er det sådan, at hvis ét eller andet er lavet af én person, har vedkommende 100 % ansvar. Ved bare 2 personer har de højest 10% ansvar hver, da det pr. definition altid er den andens fejl :-)

Min erfaring er, at ingen ønsker det enestående. Du skal helst lægge fejl ind, så de har noget at rette, og kan sætte deres "fingerpræg" på.  

Jo, ingen ønsker fejl; men der er næsten altid en kværulant, som vil have sit fingeraftryk på enhver sag, så det kan være en god idé at indføre en rimelig synlig, men dog ikke alt for åbenlys fejl, som man allerede har en løsning på (kan være indbygget og frakobles med en switch). Denne kværulant vil så forlange, at det bliver ændret, hvilket man så efter lidt spilfægteri går med til :-) Er der ikke en sådan åbenlys fejl, skal vedkommende nok finde noget, og så kan man komme til at rette på steder, som man ikke ønsker.

Jeg er helt enig i, at som du beskriver det, fungerer det oftest i praksis. Men, det er altså ingen naturlov! Men, er chefen bare en smule inkompetent, så går det helt galt. Så er det den højtråbende, der ønsker at sætte fingeraftryk, som får indflydelse og sætter dagsorden. Det er meget sjovt, at chefen aldrig vil indrømme, at han ønsker at køre det hele i sænk. Men, har du erfaring med det, så opdager du hurtigt, at det er chefens skjulte plan, som ingen må få at vide. På en eller anden måde, virker det dog som om, at chefen ikke selv kan se det!

  • 0
  • 3