Just to update on this, I now have the 2nd instance of Remora controlling a 3D printer. My setup is a 2GB rPi4 connected over SPI and AUX(monitoring) to a MKS Sbase v1.3 controller running Remora and wired to a stock Creality Ender 3. The power, heatbed, hotend and one fan connected easily to the screw terminals, One hotend fan has a 2p JST-XH connector so I made a pigtail with flying leads to connect to the 4th screw terminal on the MKS Sbase board. The Ender end stops are 2p JST-XH connectors and the MKS Sbase has 3p JST-XH connectors so I made cable adapters.
I checked the 3 axis's for proper motion/direction and configured then checked basic movement and used best guess to get decent speed. I then calibrated the 4th axis(Extruder) and printed a test object. Next I want to work on tuning velocity and acceleration on the 3 motion axis's and see how fast it can be pushed. Just a stock hotend with a silicon insulation cover so i hope that ends up being the limitation. I will look for banding and corner oozing and will report back. On Monday, February 22, 2021 at 4:38:56 PM UTC-8 blaz...@gmail.com wrote: > >> There is no secret sauce. Or better said the sauce is not secret. You may >> have an application which requires 10 ms polling of maximum reaction time, >> in that case you are golden as then you will have 8 ms rate (simplified). >> >> You can read this thesis: http://caxapa.ru/thumbs/833386/pomarlan.pdf >> about what one can do about RT on USB2. >> >> And why? Well, because people are people, and they will always try to do >> things which seem superfluous. If somebody wants to use USB, great, let's >> see what he will be able to come up with... > > > That's just contradictory. If I have an application that requires 10ms > reaction time and I'm willing to design within those constraints, THAT'S > FINE, but then I 'm not operating at what's accepted as RT because I don't > need to and that is specifically what you said previously. I can't do > anything faster than this, I can design around it, I can muck about, but if > a 1ms servo thread is the generally accepted RT constraint, then the > conversation is over, because I can't do it. > > >> It's not that simple. USB2 has higher latencies, true, but if you are OK >> with them, then the USB2 interface is as capable of real-time communication >> as any other interface. >> > > Every bus that is accepted as real-time can meet a 1ms servo thread > deadline, When someone implements USB and can meet a 1ms deadline reliably > I will call USB real-time myself, but I wanna see it before I can go > against the grain. @8ms you will be running a 125hz servo thread, which is > lousy. > > All this talk of determinism is completely moot. I can take a guess what > is going to happen 1 week from now, then I can guess what is going to > happen 2 months from now. Not only am I far more likely to be wrong if I > guess 2 months aread, I have to wait 7 weeks longer to find out I was > wrong. It's moot because anything done deterministically can be done better > if you can see results in 1/8th the time, far less unknown factors enter > the equation in 1ms vs 8ms. If I'm trying to read a GPIO pin that may have > an on-time of 2ms, I'm guaranteed to see that it has changed state without > any trickery if I look at it once every 1ms. If I look at it once every > 8ms, I am almost certain to miss it most of the time. There is no > determinism to resolve this, you can write a firmware module to latch state > until it's read, you can lengthen the on-time, you can write some crazy > snapshot type function into the module that tells you how many cycles have > passed since it happend........What you cannot do is read it in 1ms. > > Can you make a 3D printer running on USB........sure, they do it all the > time. You can send commands ahead of time and have the controller execute a > buffered command queue, if that meets the design goals you can do that, but > you can't call it real-time if it does not meet some RT excepted standard, > no matter how you workaround all the things. > > ..........Forgot to "reply all" > > On Mon, Feb 22, 2021 at 5:39 PM cern via Machinekit < > machi...@googlegroups.com> wrote: > >> Feb 18, 2021, 23:44 by joonas....@gmail.com: >> >> > Realtime isn't about latency but determinism and the standard usb >> driver stack is non-deterministic. I believe there are realtime capable >> stacks for usb devices but it needs to be supported by both devices. And I >> don't think most mcus support it. >> > >> Latency is an integral part of determinism. The larger the uncertain >> latency part will be, the bigger the limit until when the information is >> valid will need to be. And real-time in how Machinekit-HAL understands it >> and uses it is all about the top maximum when the information has to be >> processed, not the minimum or absolute gradual, sequential time of each >> step. (You can look at how the HAL modules, both drivers and components, >> are conceptually programmed and compiled, there are no time constant >> execution path, the same amount of jumps or other similar real-time >> concepts.) >> >> Pretty much all it cares about is to start the linked list of functions >> comprising the HAL thread at a given monotonic clock tick. >> >> > >> > If you don't care about the smoothness of tour motion or use a buffered >> approach, usb works fine. >> > >> Yes, buffered approach is one way to use USB. It really depends on for >> what you want to use it, if your application can live with the latency of - >> let's say - 5 ms, because your monotonic clock is ticking at 20 ms, well, >> then you are going to be fine. >> >> Cern. >> >> > >> > On Fri 19. Feb 2021 at 0.36, justin White <> blaz...@gmail.com> > >> wrote: >> > >> >>> It's not that simple. USB2 has higher latencies, true, but if you are >> OK with them, then the USB2 interface is as capable of real-time >> communication as any other interface. There have been attempts to mitigate >> these latencies with various results. (Search research papers online.) USB3 >> should be much better in this regard. >> >>> >> >> >> >> I dont see how that's true when the default USB2 polling rate is 8ms. >> You can change the mouse driver to get 1ms but I don't know that the RT >> patches touch USB. So whats the secret sauce to getting RT USB if the >> polling interval remains at 8ms on a shared bus? >> >> >> >> USB3 isn't really even worth talking about yes its peer to peer with >> much better latency but an rpi4 having a USB3 port doesn't do any good when >> MCUs really do not. Most MCUs bake usb2 hardware right onto the chip while >> usb3 is generally a PCIE lane attached to a PHY which I have yet to see on >> any dev boards. >> >> >> >> So what's the secret sauce to RT USBx? And .......why, when any MCU >> contains fast UARTs, spi and sometimes ethernet. >> >> >> >> On Thu, Feb 18, 2021 at 11:23 AM cern via Machinekit <>> >> machi...@googlegroups.com>> > wrote: >> >> >> >>> Hello, >> >>> >> >>> Feb 18, 2021, 14:32 by >>> joonas....@gmail.com>>> : >> >>> >> >>> > USB itself isn’t realtime capable so it can’t be used for any >> realtime tasks. >> >>> > >> >>> It's not that simple. USB2 has higher latencies, true, but if you >> are OK with them, then the USB2 interface is as capable of real-time >> communication as any other interface. There have been attempts to mitigate >> these latencies with various results. (Search research papers online.) USB3 >> should be much better in this regard. >> >>> >> >>> Cern. >> >>> >> >>> > >> >>> > On Thu 18. Feb 2021 at 11.18, > >>> ozzy...@gmail.com>>> > <> >> >>> ozzy...@gmail.com>>> > > wrote: >> >>> > >> >>> >> Be interesting to see more details on the Linuxcnc\USB\MESA setup. >> >>> >> As far as I was aware there was no RT support for USB. >> >>> >> I'm not even sure if MESA themselves recommend their USB boards >> for use with Linuxcnc. >> >>> >> >> >>> >> On Thursday, February 18, 2021 at 7:32:57 AM UTC+11 >> >>> >> doug....@gmail.com>>> >> wrote: >> >>> >> >> >>> >>> Great, thanks for finding it! >> >>> >>> >> >>> >>> I've seen lots of people purchasing 3DP controller boards to >> upgrade 3DP/Lasers/CNC's(consumer stuff) and many of them also use an rPi >> with OctoPrint or CNCjs, GridBot etc. >> >>> >>> I like this approach in that all of my macines(4 3DPs, 2 laser >> cutters and 1 CNC) all have consumer grade controllers in them running on >> different uCPUs. Some AVR328, STM32, LPC17xx and one a BBB/CRAMPS. >> >>> >>> But would love to be able to have LinuxCNC/Machinekit on an rPi >> doing the control, UI, setup. >> >>> >>> On Wednesday, February 17, 2021 at 11:02:18 AM UTC-8 >>> >>> >> ce...@tuta.io>>> <>>>> wrote: >> >>> >>> >> >>> >>>> Hi, >> >>> >>>> the code is available in >>>> >>> >> https://github.com/scottalford75/Remora>>> >>>> - looks like he though >> that spiPRU is not a great name and changed it to something more flashy. >> >>> >>>> >> >>> >>>> Looks interesting from programming point of view, but I wonder >> how many people would buy Smoothieboard and RPi both to run 3D printer with >> LinuxCNC on it? Most will stay with Smoothie, I think. >> >>> >>>> >> >>> >>>> Cern. >> >>> >>>> >> >>> >>>> Dne úterý 16. února 2021 v 19:18:20 UTC+1 uživatel >>>> >>> >> doug....@gmail.com>>> <>>>>> napsal: >> >>> >>>> >> >>> >>>>> I was about to start on setting up a Xylotex BareBoneCNC with >> a BBB/Machinekit and thought I'd look at what's going on with Raspberry Pi >> in CNC world. I found a video of a guy driving a Mesa board over USB with >> LinuxCNC and it looked impressive(doesn't take much). >> >>> >>>>> >> >>> >>>>> Got to wondering if a standard 3DP controller like SKR, >> Smoothieboard, etc couldn't run firmware similar to the MESA board and only >> found mention of this spiPRU but no details, code, anything. >> >>> >>>>> >> >>> >>>>> >>> https://github.com/scottalford75/LinuxCNC-on-RPi >> >>> >>>>> >> >>> >>>>> I searched for spiPRU here and in general inter-web lands and >> found nothing but the mention of it in the above git repo. If anyone knew >> about it I figured they would be here. >> >>> >>>>> Thx >> >>> >>>>> >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> website: >> >>> http://www.machinekit.io>>> >> blog: >> >>> >> http://blog.machinekit.io>>> >> github: >> >>> >> https://github.com/machinekit >> >>> >> --- >> >>> >> You received this message because you are subscribed to the >> Google Groups "Machinekit" group. >> >>> >> To unsubscribe from this group and stop receiving emails from >> it, send an email to >> >>> machinekit+...@googlegroups.com <mailto: >> machinekit%2bunsu...@googlegroups.com>>>> >> . >> >>> >> To view this discussion on the web visit >> >>> >> https://groups.google.com/d/msgid/machinekit/cc241b97-47bb-48d0-b3b4-e595dc809b55n%40googlegroups.com>>> >> >> <>>> >> https://groups.google.com/d/msgid/machinekit/cc241b97-47bb-48d0-b3b4-e595dc809b55n%40googlegroups.com?utm_medium=email&utm_source=footer>>> >> >> >>> . >> >>> >> >> >>> > -- >> >>> > Terv, >> >>> > Joonas Forsell >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > website: > >>> http://www.machinekit.io>>> > blog: > >>> >> http://blog.machinekit.io>>> > github: > >>> >> https://github.com/machinekit >> >>> > --- >> >>> > You received this message because you are subscribed to the >> Google Groups "Machinekit" group. >> >>> > To unsubscribe from this group and stop receiving emails from it, >> send an email to > >>> machinekit+...@googlegroups.com <mailto: >> machinekit%2bunsu...@googlegroups.com>>>> > . >> >>> > To view this discussion on the web visit > >>> >> https://groups.google.com/d/msgid/machinekit/CA%2B%2BSnhq%3D-rmGD2z8ewbQ9ryBoyWgwymJTbmWp6NKnGPyhmsrbw%40mail.gmail.com>>> >> >> <>>> >> https://groups.google.com/d/msgid/machinekit/CA%2B%2BSnhq%3D-rmGD2z8ewbQ9ryBoyWgwymJTbmWp6NKnGPyhmsrbw%40mail.gmail.com?utm_medium=email&utm_source=footer>>> >> >> >> . >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> website: >>> http://www.machinekit.io>>> blog: >>> >> http://blog.machinekit.io>>> github: >>> https://github.com/machinekit >> >>> --- >> >>> You received this message because you are subscribed to the Google >> Groups "Machinekit" group. >> >>> To unsubscribe from this group and stop receiving emails from it, >> send an email to >>> machinekit+...@googlegroups.com <mailto: >> machinekit%2bunsu...@googlegroups.com>>>> . >> >>> To view this discussion on the web visit >>> >> https://groups.google.com/d/msgid/machinekit/MTpwssk--3-2%40tuta.io>>> . >> >>> >> > -- >> > Terv, >> > Joonas Forsell >> > >> > >> > >> > -- >> > website: > http://www.machinekit.io> blog: > >> http://blog.machinekit.io> github: > https://github.com/machinekit >> > --- >> > You received this message because you are subscribed to the Google >> Groups "Machinekit" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to > machinekit+...@googlegroups.com> . >> > To view this discussion on the web visit > >> https://groups.google.com/d/msgid/machinekit/CA%2B%2BSnhrgbwYbXtseCcC6hZmb%3D1-7HcBJSmS2bzHhEs%2BnSuUbpg%40mail.gmail.com >> >> < >> https://groups.google.com/d/msgid/machinekit/CA%2B%2BSnhrgbwYbXtseCcC6hZmb%3D1-7HcBJSmS2bzHhEs%2BnSuUbpg%40mail.gmail.com?utm_medium=email&utm_source=footer>> >> >> . >> > >> >> -- >> website: http://www.machinekit.io blog: http://blog.machinekit.io >> github: https://github.com/machinekit >> --- >> You received this message because you are subscribed to the Google Groups >> "Machinekit" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> email to machinekit+...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/machinekit/MUAtO_U--3-2%40tuta.io. >> > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/ccf6dc28-94d3-4ba8-9221-80d37b954084n%40googlegroups.com.
