> > > 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 < [email protected]> wrote: > Feb 18, 2021, 23:44 by [email protected]: > > > 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 <> [email protected]> > > 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 <>> > [email protected]>> > wrote: > >> > >>> Hello, > >>> > >>> Feb 18, 2021, 14:32 by >>> [email protected]>>> : > >>> > >>> > 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, > >>> [email protected]>>> > <> >>> > [email protected]>>> > > 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 >> >>> > [email protected]>>> >> 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 >>> >>> > [email protected]>>> <>>>> 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 >>>> >>> > [email protected]>>> <>>>>> 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 >> >>> [email protected] <mailto: > machinekit%[email protected]>>>> >> . > >>> >> 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 > >>> [email protected] <mailto: > machinekit%[email protected]>>>> > . > >>> > 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 >>> [email protected] <mailto: > machinekit%[email protected]>>>> . > >>> 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 > [email protected]> . > > 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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/CA%2BQ02MMdHK7aUd5i0yZ1_PaUDT3dpPr2wvirU-zAd2y0qWFzeA%40mail.gmail.com.
