@rob
Ik zie nog een veel belangrijker voordeel: de prijs.
In de 3d printerwereld is men continue bezig om met zulke goedkoop mogelijke onderdeeltjes een zo goed mogelijke printer te bouwen.
Om een 3d printer fiks afgezet te krijgen (miljoenen exemplaren verkopen) zal hij in de buurt moeten komen van de 200 dollar grens. Hoe verder je daarvandaan zit, des te lastiger.
Elk lineair component is dan stinkend duur ineens. Vooral de Z as goed oplossen is een MEGAPROBLEEM.
Ik ben hier al paar maanden aan klooien met trapeziumdraad (van pietrzak). Echt kapot ben ik er niet van. Het loopt niet zo heel soepel simpelweg. Fiks wat lithium erop (wd40 - nee niet de standaard wd40 want die werkt juist averechts hier - maar dus kogellager versie ervan) liep het wat soepeler maar nog steeds gewoon NIET LEKKER.
Dat trekken nema17 motortjes gewoon niet hoor.
Oplossing is dan simpel nietwaar?
Ja tuurlijk: nema23 motoren. Die heb ik net binnen :)
Maar zo iets kun je niet goedkoop verkopen ooit. Dit principe wel, dus ik snap dat men er naar aan het kijken is.
Het nadeel. Ja da's nogal simpel he. Het nadeel in 1 korte zin samengevat: het is EXPERIMENTEEL.
CoreXY of CoreXZ
Moderator: Moderators
Re: CoreXY of CoreXZ
@rob
En vooral dan de timingsverschillen, want uiteindelijk gaat alles natuurlijk sequentieel op de processoren.
De snelheid waarop ramps communiceert is overigens 250k baud hier. Dat gaat dan echter gelayered via een USB kabel, die an sich geen problemen heeft in versie 1.0 al om de 10 mbit te halen. Dat is 1 MB/s (1 megabyte).
Een byte is weliswaar 8 bits, maar er is altijd communicatieoverhead waardoor meestal 10 bits dus 1 byte vormt.
Vandaar dat ik dus ook die limitatie naar 250k baud niet zo snap eerlijk gezegd voor de 3d printers over usb. Dat is bandbreedte en dus latency voor niks weggooien.
Latere USB versies, usb3 zelfs boven de 500 mbit. Ik vermoed dat hier geen sprake is van een usb3 connectie echter.
USB2 is meest gebruikt tegenwoordig die is dus 480 mbit of te 48 MB/s. Die claim van 60MB/s online is MET protocoloverhead natuurlijk. Dat is niet interessant.
De usb latency is wel heel snel. Veel minder dan een microseconde.
De parallelle port, althans de EPP editie die haalt dus maximaal 2MB/s. Dat is zonder protocoloverhead. Zo'n protocol pen je zelf natuurlijk. Dat is dus takketraag vergeleken met usb2, maar wel sneller dan usb1 en heel veel sneller dan de 250k baud naar de arduino's.
Om het met professionele (supercomputer)netwerken te vergelijken die ik hier heb:
ik heb hier een iets oudere mellanox netwerkje liggen. Die haalt dus 40 gigabit per seconde.
Je zou zeggen dat is dan 4 GB/s, maar dat trekt je computer dus niet. De betere moederborden kunnen rond de 3.2GB/s wel verwerken overigens.
Veel relevanter dan dit alles voor aansturing van motoren is de LATENCY. Bovenstaande getallen zeggen wel iets over de BANDBREEDTE (hoe breed de pijp is) maar niets over hoe SNEL je bericht nu, gemeten in tijd aankomt.
Dan zien we pas echt grote verschillen.
Om met de snelste te beginnen dat is natuurlijk dat infiniband. De nieuwste versie zit daar op 0.7 us.
Die is unbeatable en ook zeer prijzig.
Daarmee stuur je echter geen motoren aan.
De 137 miljoen messages per seconde die kun je vergeten - dat is bij aansturen motoren natuurlijk niet relevant.
Bij aansturing van motoren telt dan ook de snelheid van de processor mee natuurlijk. De kloksnelheid van de arduino's is namelijk niet erg hoog. Rond de 16Mhz als ik het goed las voor wat ik hier heb.
In sommige software ben je vaak instructies verder voor je een motor een opdracht geeft.
Wat hier dus interessant is, in de marlin firmware is hoeveel clockticks er zitten tussen het commando naar motor A en vervolgens motor B, die toch 1 beweging moeten coordineren. Dat is bij de repraps net zozeer het geval als XY aansturing.
We praten dan dus over aantal CPU clockticks, namelijk de efficiency van de firmware, die dan naar het motorboard aan een motordriver een opdracht geeft.
Als we praten over linuxCNC, dan veegt de klokfrequentie van de PC natuurlijk de kloksnelheid van die marlin weg. We hoeven dus de CPU verwerkingssnelheid niet meer te rekenen. Een k7 van 2Ghz is loeisnel namelijk.
We zitten daar echter met een variabele die Marlin niet kent. Namelijk de latency van de parallelle port.
Ik zie daar getallen gepost waar ik wel van schrik bij linuxcnc. Ze zijn al tevreden met enige millisecondes latency, terwijl ze helemaal tevreden zijn met 25 us latency.
25 us in mijn wereld is "go home" :)
Als je op de beurs maar liefst 25 us nodig hebt om een koop of verkoop order van wat futures te plaatsen, dan kun je net zo goed dat bericht niet meer sturen, want dan ben je toch te laat :)
Ja inderdaad als je met flowtraders oid werkt, die helemaal niet op de beurs zitten maaro p eigen platform dan is je minimumlatency al in de tientallen millisecondes (dus factor 10k trager dan de computers in beursgebouw zelf). Derivaten beleggen op platformen die niet IN de beurs zitten, dan heb je natuurlijk gaatje in je hoofd (derivaten anders dan aandelen afdekken met put-opties) - maar dat is hele andere discussie.
Echter daar is men bij linuxCNC enorm tevreden mee met iets dat tussen de 25 us en 10k us zit zo lijkt het.
Kortom de parallelle port aansturing is heel veel trager dan als je 't via een usb2 zou versturen.
Dienen we bij op te merken dat je dan wel een kaartje moet hebben dat zo'n usb2 ook op de snelheid van usb2 aanstuurt. Dus iets wat werkt op 250k baud is niet zo handig dan natuurlijk :).
Maar ook dat valt ruim binnen de snelheden waar men bij de linuxcnc bench al ruim tevreden mee is, zo lijkt het.
Vooralsnog is het goed mogelijk dat direct aansturen vanaf de arduino, een snellere latency richting de motoren heeft dan linuxcnc. Als er namelijk maar een paar dozijn clockticks zit tussen elk commando dan is dat minder dan 25 us, terwijl de latency waaronder je dient te zitten voor de motoren onder de zoveel millisecondes ligt.
Dit vind ik uitermate boeiend onderwerp. Hoe verhoudt zich dit tot linuxCNC?"Een ander nadeel is de manier waarop de Marlin software (als je die gebruikt) de stappenmotoren aanstuurt: eerst worden 1..4 pulsjes naar de X-motor gestuurd, dan 1..4 naar de Y-motor en dan 1..4 naar de Extruder motor."
En vooral dan de timingsverschillen, want uiteindelijk gaat alles natuurlijk sequentieel op de processoren.
De snelheid waarop ramps communiceert is overigens 250k baud hier. Dat gaat dan echter gelayered via een USB kabel, die an sich geen problemen heeft in versie 1.0 al om de 10 mbit te halen. Dat is 1 MB/s (1 megabyte).
Een byte is weliswaar 8 bits, maar er is altijd communicatieoverhead waardoor meestal 10 bits dus 1 byte vormt.
Vandaar dat ik dus ook die limitatie naar 250k baud niet zo snap eerlijk gezegd voor de 3d printers over usb. Dat is bandbreedte en dus latency voor niks weggooien.
Latere USB versies, usb3 zelfs boven de 500 mbit. Ik vermoed dat hier geen sprake is van een usb3 connectie echter.
USB2 is meest gebruikt tegenwoordig die is dus 480 mbit of te 48 MB/s. Die claim van 60MB/s online is MET protocoloverhead natuurlijk. Dat is niet interessant.
De usb latency is wel heel snel. Veel minder dan een microseconde.
De parallelle port, althans de EPP editie die haalt dus maximaal 2MB/s. Dat is zonder protocoloverhead. Zo'n protocol pen je zelf natuurlijk. Dat is dus takketraag vergeleken met usb2, maar wel sneller dan usb1 en heel veel sneller dan de 250k baud naar de arduino's.
Om het met professionele (supercomputer)netwerken te vergelijken die ik hier heb:
ik heb hier een iets oudere mellanox netwerkje liggen. Die haalt dus 40 gigabit per seconde.
Je zou zeggen dat is dan 4 GB/s, maar dat trekt je computer dus niet. De betere moederborden kunnen rond de 3.2GB/s wel verwerken overigens.
Veel relevanter dan dit alles voor aansturing van motoren is de LATENCY. Bovenstaande getallen zeggen wel iets over de BANDBREEDTE (hoe breed de pijp is) maar niets over hoe SNEL je bericht nu, gemeten in tijd aankomt.
Dan zien we pas echt grote verschillen.
Om met de snelste te beginnen dat is natuurlijk dat infiniband. De nieuwste versie zit daar op 0.7 us.
Die is unbeatable en ook zeer prijzig.
Daarmee stuur je echter geen motoren aan.
De 137 miljoen messages per seconde die kun je vergeten - dat is bij aansturen motoren natuurlijk niet relevant.
Bij aansturing van motoren telt dan ook de snelheid van de processor mee natuurlijk. De kloksnelheid van de arduino's is namelijk niet erg hoog. Rond de 16Mhz als ik het goed las voor wat ik hier heb.
In sommige software ben je vaak instructies verder voor je een motor een opdracht geeft.
Wat hier dus interessant is, in de marlin firmware is hoeveel clockticks er zitten tussen het commando naar motor A en vervolgens motor B, die toch 1 beweging moeten coordineren. Dat is bij de repraps net zozeer het geval als XY aansturing.
We praten dan dus over aantal CPU clockticks, namelijk de efficiency van de firmware, die dan naar het motorboard aan een motordriver een opdracht geeft.
Als we praten over linuxCNC, dan veegt de klokfrequentie van de PC natuurlijk de kloksnelheid van die marlin weg. We hoeven dus de CPU verwerkingssnelheid niet meer te rekenen. Een k7 van 2Ghz is loeisnel namelijk.
We zitten daar echter met een variabele die Marlin niet kent. Namelijk de latency van de parallelle port.
Ik zie daar getallen gepost waar ik wel van schrik bij linuxcnc. Ze zijn al tevreden met enige millisecondes latency, terwijl ze helemaal tevreden zijn met 25 us latency.
25 us in mijn wereld is "go home" :)
Als je op de beurs maar liefst 25 us nodig hebt om een koop of verkoop order van wat futures te plaatsen, dan kun je net zo goed dat bericht niet meer sturen, want dan ben je toch te laat :)
Ja inderdaad als je met flowtraders oid werkt, die helemaal niet op de beurs zitten maaro p eigen platform dan is je minimumlatency al in de tientallen millisecondes (dus factor 10k trager dan de computers in beursgebouw zelf). Derivaten beleggen op platformen die niet IN de beurs zitten, dan heb je natuurlijk gaatje in je hoofd (derivaten anders dan aandelen afdekken met put-opties) - maar dat is hele andere discussie.
Echter daar is men bij linuxCNC enorm tevreden mee met iets dat tussen de 25 us en 10k us zit zo lijkt het.
Kortom de parallelle port aansturing is heel veel trager dan als je 't via een usb2 zou versturen.
Dienen we bij op te merken dat je dan wel een kaartje moet hebben dat zo'n usb2 ook op de snelheid van usb2 aanstuurt. Dus iets wat werkt op 250k baud is niet zo handig dan natuurlijk :).
Maar ook dat valt ruim binnen de snelheden waar men bij de linuxcnc bench al ruim tevreden mee is, zo lijkt het.
Vooralsnog is het goed mogelijk dat direct aansturen vanaf de arduino, een snellere latency richting de motoren heeft dan linuxcnc. Als er namelijk maar een paar dozijn clockticks zit tussen elk commando dan is dat minder dan 25 us, terwijl de latency waaronder je dient te zitten voor de motoren onder de zoveel millisecondes ligt.
Re: CoreXY of CoreXZ
Als ik het goed begrijp zo dan beukt smoothieboard dus iedereen weg qua latency als het gaat om steppers aan te sturen voor CNC besturing.
De motordrivers zitten direct op smoothieboard en die draait op fiks wat megaherzjes, terwijl er geen draadje tussenzit.
Nu kan ik me ook voorstellen dat voor 3d printing deze discussie relevanter is dan een cnc freesmachine/draaibank, want een 3d printer beweegt veel frequenter dan een cnc freesmachine.
De motordrivers zitten direct op smoothieboard en die draait op fiks wat megaherzjes, terwijl er geen draadje tussenzit.
Nu kan ik me ook voorstellen dat voor 3d printing deze discussie relevanter is dan een cnc freesmachine/draaibank, want een 3d printer beweegt veel frequenter dan een cnc freesmachine.
Re: CoreXY of CoreXZ
Tuurlijk hoor.diepchess schreef: Vandaar dat ik dus ook die limitatie naar 250k baud niet zo snap eerlijk gezegd voor de 3d printers over usb. Dat is bandbreedte en dus latency voor niks weggooien.
Sure..De usb latency is wel heel snel. Veel minder dan een microseconde.
Blijkbaar heb je er geen flauw benul van hoe USB werkt, dus hoe je aan dit soort uitspraken komt?
kreun...Veel relevanter dan dit alles voor aansturing van motoren is de LATENCY. Bovenstaande getallen zeggen wel iets over de BANDBREEDTE (hoe breed de pijp is) maar niets over hoe SNEL je bericht nu, gemeten in tijd aankomt.
steun...We zitten daar echter met een variabele die Marlin niet kent. Namelijk de latency van de parallelle port.
Ik zie daar getallen gepost waar ik wel van schrik bij linuxcnc. Ze zijn al tevreden met enige millisecondes latency, terwijl ze helemaal tevreden zijn met 25 us latency.
25 us in mijn wereld is "go home" :)
zucht...Kortom de parallelle port aansturing is heel veel trager dan als je 't via een usb2 zou versturen.
flierp...Dienen we bij op te merken dat je dan wel een kaartje moet hebben dat zo'n usb2 ook op de snelheid van usb2 aanstuurt. Dus iets wat werkt op 250k baud is niet zo handig dan natuurlijk :).
Maar ook dat valt ruim binnen de snelheden waar men bij de linuxcnc bench al ruim tevreden mee is, zo lijkt het.
flubber....Vooralsnog is het goed mogelijk dat direct aansturen vanaf de arduino, een snellere latency richting de motoren heeft dan linuxcnc.
Lees eens wat, zoek uit hoe dingen werken, en probeer het ook nog eens te begrijpen voordat je dit soort lappen text pent...
De belangrijkste wet in de wetenschap: 'hoe minder efficient en hoe meer herrie, hoe leuker het is'
Re: CoreXY of CoreXZ
Ik ben 1 van die gasten die dus zelf benchmarks geproduceerd heeft in verleden.
Daarmee kun je dus latencies meten. Wij gebruikten al jaren geleden usb sticks voor fast latency access.
De patenthouder van veel van die usb flash media is overigens ook een computerschakerd :)
In 2005 heeft dat figuur nog een rechtszaakje aangespannen hierover overigens (zie wallstreet journal: 500 miljoen dollar claim).
Er zijn enorme verschillen in USB hardware.
De latency van bepaalde sticks ligt rond de 100 microsecondes.
Het heeft wel even geduurd voor SSD's daar aan konden tippen (intel ging er met hun SSD onder op gegeven moment).
Er zijn tegenwoordig speciale filesystemen ook voor dit soort hardware overigens die latency gebaseerd zijn.
Het betreft bij de latencies hier overigens om blocked reads.
USB is dus helemaal niet een belemmering qua snelheid (wel vaak de drivers). Het haalt simpelweg in versie 2 die al wijd en zijd verspreid is dus die 480 mbit.
Bij linuxcnc is de belemmering dus de beperkte doorvoorsnelheid van de parallelle port. Die haalt maar 2MB/s.
Dat is een bandbreedte - geen latency.
dat smoothieboard zit direct op de motordrivers. je schijnt op smoothieboard ook de motordrivers die veel meer amperes leveren, direct te kunnen koppelen aan smoothieboard. Er is dan dus helemaal geen latencyverlies door een parallelle port.
Dan is enige interessant feitje dus hoeveel clockticks het kost om een gcode command om te zetten naar een commando richting de driver.
Indruk die ik krijg is dat de CNC besturing bijna niks nodig heeft realtime.
De vereisten zijn zo laag dat enkel een realtime kernel genoeg is.
Daarmee kun je dus latencies meten. Wij gebruikten al jaren geleden usb sticks voor fast latency access.
De patenthouder van veel van die usb flash media is overigens ook een computerschakerd :)
In 2005 heeft dat figuur nog een rechtszaakje aangespannen hierover overigens (zie wallstreet journal: 500 miljoen dollar claim).
Er zijn enorme verschillen in USB hardware.
De latency van bepaalde sticks ligt rond de 100 microsecondes.
Het heeft wel even geduurd voor SSD's daar aan konden tippen (intel ging er met hun SSD onder op gegeven moment).
Er zijn tegenwoordig speciale filesystemen ook voor dit soort hardware overigens die latency gebaseerd zijn.
Het betreft bij de latencies hier overigens om blocked reads.
USB is dus helemaal niet een belemmering qua snelheid (wel vaak de drivers). Het haalt simpelweg in versie 2 die al wijd en zijd verspreid is dus die 480 mbit.
Bij linuxcnc is de belemmering dus de beperkte doorvoorsnelheid van de parallelle port. Die haalt maar 2MB/s.
Dat is een bandbreedte - geen latency.
dat smoothieboard zit direct op de motordrivers. je schijnt op smoothieboard ook de motordrivers die veel meer amperes leveren, direct te kunnen koppelen aan smoothieboard. Er is dan dus helemaal geen latencyverlies door een parallelle port.
Dan is enige interessant feitje dus hoeveel clockticks het kost om een gcode command om te zetten naar een commando richting de driver.
Indruk die ik krijg is dat de CNC besturing bijna niks nodig heeft realtime.
De vereisten zijn zo laag dat enkel een realtime kernel genoeg is.
Re: CoreXY of CoreXZ
Uiteraard. Vertrouw nooit statistiek waar je niet zelf aan gemorreld hebt.diepchess schreef:Ik ben 1 van die gasten die dus zelf benchmarks geproduceerd heeft in verleden.
Ja, en waarom niet minder voor een read-access? Lees de USB-spec....De latency van bepaalde sticks ligt rond de 100 microsecondes.
Ja, dat klopt. Als je bulktransfers doet met grote blokken data dan kom je een aardig eind in de buurt.USB is dus helemaal niet een belemmering qua snelheid (wel vaak de drivers). Het haalt simpelweg in versie 2 die al wijd en zijd verspreid is dus die 480 mbit.
En wat precies heeft een 'G0 X0Y0Z0' over USB te maken met het sturen van pulsen via de parallelle poort?Bij linuxcnc is de belemmering dus de beperkte doorvoorsnelheid van de parallelle port. Die haalt maar 2MB/s.
Dat is een bandbreedte - geen latency.
Tipje van de sluier: latency tussen de pinnen van de poort (en dus de motoren onderling) zit in het enkele-nanoseconden gebied. De jitter op de timing van de stap-pulsen zit voor de meeste PC-hardware met parallelle poort op 10-20usec. Meer dan dat en ik zou het systeem niet gebruiken met parallelle poort.Er is dan dus helemaal geen latencyverlies door een parallelle port.
Ik laat de rekenexercitie of dat wel of geen probleem is aan jou over; da's goed voor het algemene begrip. Neem de interne werking van LinuxCNC's software-stepgen, inertie van de belasting op 'het magneetveld van de motor', het koppel van de motor bij de hoekafwijkingen en de werkingsprincipes van de stepperdrives mee in je evaluatie.
De belangrijkste wet in de wetenschap: 'hoe minder efficient en hoe meer herrie, hoe leuker het is'
Re: CoreXY of CoreXZ
LinuxCNC is niet te vergelijken met Marlin software. LinuxCNC heeft een totaal andere motorcontroller en een andere manier van aansturen. Om te beginnen wordt in LinuxCNC alles via een realtime process naar buiten gestuurd en worden de step signalen voor alle motoren in één bewerking naar buiten gestuurd en LinuxCNC maakt geen gebruik van het soort 'overclocking' die in Marlin zit (Ik had bij LinuxCNC trouwens een aparte FPGA kaart die alle signalen genereert, daarmee legt LinuxCNC een deel van het genereren van de pulsen in de FPGA waardoor de boel beter getimed is en er veel hogere puls-snelheden mogelijk zijn).diepchess schreef:@robDit vind ik uitermate boeiend onderwerp. Hoe verhoudt zich dit tot linuxCNC?"Een ander nadeel is de manier waarop de Marlin software (als je die gebruikt) de stappenmotoren aanstuurt: eerst worden 1..4 pulsjes naar de X-motor gestuurd, dan 1..4 naar de Y-motor en dan 1..4 naar de Extruder motor."
En vooral dan de timingsverschillen, want uiteindelijk gaat alles natuurlijk sequentieel op de processoren.
Is toch gewoon van de zotte: als je processor de interrupts niet snel genoeg kan genereren geef je gewoon 4 pulsen per interrupt. Dan kan je net zo goed je stepperdriver op een factor 4 minder instellen.
en waarom ze in Marlin de pulsen voor XYZ en E na elkaar produceren is mij een compleet raadsel.
Natuurlijk gaat alles sequentieel. Maar de poort waar de motorsignalen op gegenereerd worden is parallel dus je kan rustig 3 pulsen op 3 verschillende lijnen tegelijk genereren.
Huh?diepchess schreef: De snelheid waarop ramps communiceert is overigens 250k baud hier. Dat gaat dan echter gelayered via een USB kabel, die an sich geen problemen heeft in versie 1.0 al om de 10 mbit te halen. Dat is 1 MB/s (1 megabyte).
Een byte is weliswaar 8 bits, maar er is altijd communicatieoverhead waardoor meestal 10 bits dus 1 byte vormt.
Iets met klokken en klepels ...
Je snapt duidelijk niet hoe de boel in elkaar steekt. RAMPS communiceert niet op wat voor Bauds dan ook, RAMPS zit aan de I/O lijnen van de Arduino processor en er zit een USB-serieel omzetter tussen de PC en de Arduino processor (dat is de 2e processor op het Mega 2560 bord).
Die 250kBaud is dus alleen van de PC naar de Arduino processor en het is de software op de Arduino die de pulsen voor de motor genereert. De Arduino ontvangt gewoon de G-code van de PC en maakt daar zelf dus pulsen van en daar heb je bij lange na geen 250 kBaud voor nodig.
Dat verhaal over latency ... Hoe groter de klok ...
In de code van de Arduino zit een buffer die een aantal regels G-code buffert. Op die manier zorgt de Arduino ervoor dat je geen problemen met de USB latency krijgt.
Latency van USB memory sticks heeft niets met dit alles te maken. Maakt niet uit hoeveel benchmarks je in het verleden geproduceert hebt. Ik ben software engineer en programmeer bijna dagelijks real time systemen, ook die waarbij de precisie zich in het microseconde domein bevindt. Ook heb ik voor een aantal verschillende microcontrollers USB protocol software geschreven en met USB analyzers problemen aangetoond bij verschillende (commerciële) producten.
Ik stel voor dat we deze hele software discussie hier maar laten rusten - het wordt behoorlijk off topic en daar heeft Hans niets aan. Waar het mij om ging is dat Marlin een vreemde manier heeft om de motoren aan te sturen en dat geeft met een CoreXZ systeem mogelijk vreemde bewegingen in de Z-as die je niet wilt zien.
Hans is bij mij geweest en we hebben uitgebreid zitten praten over zijn idee en de mogelijkheden.
Zoals ik eerder al schreef:
Hans gaat het dus gewoon proberen. Mocht het niet het gewenste resultaat geven dan kan hij het ontwerp altijd nog aanpassen.Rob65 schreef: Maar laat je dat zeker niet weerhouden hier naar hartelust mee te experimenteren.
Snaarwieltjes kosten geen drol en die gevlochten visdraad zal je ook de kop niet kosten.
-- Kunnen wij het maken? Nou en of!
Re: CoreXY of CoreXZ
@dabit,
Flashmedia via USB is juist heel erg slecht in grote bandbreedte, terwijl het steengoed is in het doen van kleine reads en writes. Mijn benchmarks zijn met name gefocussed op versturen van een paar bytes per message.
Dat loopt dus op bijna dezelfde snelheid als de snelste SSD's aldaar qua access. Gezien de reactietijden van de motoren geen enkel probleem.
Het aantal messages per seconde ligt veel hoger dan de parallelle port.
Wel is het zo dat alle besturingssystemen vrij knullige vorm van centrale locking hebben voor elk packet dat verstuurd wordt. Dit is echter redelijk bugvrije vorm van communicatie. Die krijg je dus op die hoge snelheid kado erbij.
LinuxCNC omzeilt weliswaar die centrale locking, maar mag verder alles zelf doen natuurlijk. Erg compatible is dat allemaal niet. Het is over 20 jaar natuurlijk nog precies hetzelfde als het nu is :)
Flashmedia via USB is juist heel erg slecht in grote bandbreedte, terwijl het steengoed is in het doen van kleine reads en writes. Mijn benchmarks zijn met name gefocussed op versturen van een paar bytes per message.
Dat loopt dus op bijna dezelfde snelheid als de snelste SSD's aldaar qua access. Gezien de reactietijden van de motoren geen enkel probleem.
Het aantal messages per seconde ligt veel hoger dan de parallelle port.
Wel is het zo dat alle besturingssystemen vrij knullige vorm van centrale locking hebben voor elk packet dat verstuurd wordt. Dit is echter redelijk bugvrije vorm van communicatie. Die krijg je dus op die hoge snelheid kado erbij.
LinuxCNC omzeilt weliswaar die centrale locking, maar mag verder alles zelf doen natuurlijk. Erg compatible is dat allemaal niet. Het is over 20 jaar natuurlijk nog precies hetzelfde als het nu is :)
Re: CoreXY of CoreXZ
@rob65 ik geloof dat je niet goed begrijpt wat ik bedoel.
Hetzelfde kaartje wat je gebruikt bij linuxCNC dat aan de parallelle port hangt.
Veel GOEDKOPER en simpeler is om er een usb connector op te prikken ipv parallelle port.
Al enige jaren geleden heeft men in alle besturingssystemen besloten om de parallelle port af te schermen.
Kortom met normale functiecalls kun jij niet meer de parallelle port benaderen voor custom hardware.
Vandaar dat LinuxCNC aan kernelhacking moet doen, terwijl dit compleet onnodig zou moeten zijn.
Zodra je dat via een usb kabeltje doet, dan werkt die software zowel op windows als linux ineens natuurlijk en ook op android.
Dus je stuurt je CNC machine aan vanaf je mobiele telefoon dan als je wilt.
Hetzelfde kaartje wat je gebruikt bij linuxCNC dat aan de parallelle port hangt.
Veel GOEDKOPER en simpeler is om er een usb connector op te prikken ipv parallelle port.
Al enige jaren geleden heeft men in alle besturingssystemen besloten om de parallelle port af te schermen.
Kortom met normale functiecalls kun jij niet meer de parallelle port benaderen voor custom hardware.
Vandaar dat LinuxCNC aan kernelhacking moet doen, terwijl dit compleet onnodig zou moeten zijn.
Zodra je dat via een usb kabeltje doet, dan werkt die software zowel op windows als linux ineens natuurlijk en ook op android.
Dus je stuurt je CNC machine aan vanaf je mobiele telefoon dan als je wilt.
Re: CoreXY of CoreXZ
Zoals ik al schreef: laten we deze (zinloze) discussie hier maar stoppen. Het begint nu wel heel ververvelend te wordendiepchess schreef:@rob65 ik geloof dat je niet goed begrijpt wat ik bedoel.
.
-- Kunnen wij het maken? Nou en of!
Re: CoreXY of CoreXZ
Zullen we de discussie terugbrengen naar CoreXY? Als ik 't even samenvat:
In prusa-achtige modellen beweegt de tafel (zeg Y) en de gantry met kop (X en Z). Op de kop zit een extruder met motor, of alleen extruder (bowden). In het laatste geval is het gewicht van de kop het laagste, in het eerste geval beweegt de extruder motor in zowel in de X als de Z richting.
Bij Ultimaker-achtige modellen beweegt alleen de kop met bowden in X en Y, en de tafel in Z.
Dit is qua bewegend gewicht vergelijkbaar met CoreXY. De motoren zijn allemaal stationair.
CoreXY heeft ook stationaire motoren die de X-Y beweging verzorgen, en de tafel is Z.
De vraag is welk systeem welke voor en nadelen heeft, riem vs snaar, waar backlash in zit, etc.
De motorcontroller/drivers die het zwikkie aansturen zijn voor die mechanische constructie niet zo relevant, dus open maar een nieuwe thread voor USB vs printerpoort. Daar is alle ruimte voor discussies over waar de gcode geprocessed wordt (Marlin/GRBL/LinuxCNC), en op welke plek in de keten de latency en jitter een rol spelen.
Ik ben, net als HansLeeuw, benieuwd wie al een HBOT/CoreXY achtige constructie gebouwd heeft en wat zijn of haar bevindingen zijn.
In prusa-achtige modellen beweegt de tafel (zeg Y) en de gantry met kop (X en Z). Op de kop zit een extruder met motor, of alleen extruder (bowden). In het laatste geval is het gewicht van de kop het laagste, in het eerste geval beweegt de extruder motor in zowel in de X als de Z richting.
Bij Ultimaker-achtige modellen beweegt alleen de kop met bowden in X en Y, en de tafel in Z.
Dit is qua bewegend gewicht vergelijkbaar met CoreXY. De motoren zijn allemaal stationair.
CoreXY heeft ook stationaire motoren die de X-Y beweging verzorgen, en de tafel is Z.
De vraag is welk systeem welke voor en nadelen heeft, riem vs snaar, waar backlash in zit, etc.
De motorcontroller/drivers die het zwikkie aansturen zijn voor die mechanische constructie niet zo relevant, dus open maar een nieuwe thread voor USB vs printerpoort. Daar is alle ruimte voor discussies over waar de gcode geprocessed wordt (Marlin/GRBL/LinuxCNC), en op welke plek in de keten de latency en jitter een rol spelen.
Ik ben, net als HansLeeuw, benieuwd wie al een HBOT/CoreXY achtige constructie gebouwd heeft en wat zijn of haar bevindingen zijn.
Re: CoreXY of CoreXZ
In mijn ontwerp ga ik er van uit dat alleen de extruder motor beweegt op de X-as. De Z en X bewegingen worden gerealiseerd met 2 stationaire motoren. Die kunnen onder in het frame een plaats krijgen.
Het zal een beetje pielen zijn met de snaren maar door de dubbele katrollen een beetje schuin te zetten lijkt me dat op te lossen.
Andere overwegingen (mits ze slaan op het onderwerp) zijn welkom.
Het zal een beetje pielen zijn met de snaren maar door de dubbele katrollen een beetje schuin te zetten lijkt me dat op te lossen.
Andere overwegingen (mits ze slaan op het onderwerp) zijn welkom.
Re: CoreXY of CoreXZ
@diepchess: als je erover door wilt discussieren, start dan een nieuw topic. Maar je aannames blijven gewoon niet kloppen.
De belangrijkste wet in de wetenschap: 'hoe minder efficient en hoe meer herrie, hoe leuker het is'
Re: CoreXY of CoreXZ
Ik kwam deze tegen, en volgens mij is het hetzelfde principe.
https://www.youmagine.com/designs/sli3d ... 3d-printer
https://www.youmagine.com/designs/sli3d ... 3d-printer
universeel is gemaakt om nergens op te passen...
