any info on the spiPRU mentioned

[Doug LaRue]

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

[ce...@tuta.io]

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:

[Doug LaRue]

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. 

[ozzy...@gmail.com]

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.

[Joonas Forsell]

USB itself isn’t realtime capable so it can’t be used for any realtime tasks.

--
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/cc241b97-47bb-48d0-b3b4-e595dc809b55n%40googlegroups.com.

--

Terv,

Joonas Forsell

[Doug LaRue]

I've seen the lower levels of the device stack used but not at the standard HiD level.  I believe this is why the author of isaPRU/Remora used SPI.

[ce...@tuta.io]

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.

>> 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> .

> 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>> .
>

[justin White]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/MTpwssk--3-2%40tuta.io.

[Joonas Forsell]

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.

If you don't care about the smoothness of tour motion or use a buffered approach, usb works fine.

--

Terv,

Joonas Forsell

[Doug LaRue]

For those interested, I've been in comms with the author of Remora and he has this working. He's been using it on a 3D printer but once setup, I would think it's a configuration task to set it up to run a 4 axis CNC, a 2/3 axis laser cutter, etc.

[Doug LaRue]

I don't want to start up a Machinekit vs LinuxCNC argument but the developer of Remora has been using LinuxCNC with the 2.8-rtpreempt kernel which seem way out of date.

I know this group has been doing Machinekit on the BBB SBC for far longer and for a while were using the Xenomai kernel but switched to the rtPreempt and is using Preempt_rt v4.9 and provides pre-built images.

Do any of the developers here see a reason why this SPI implementation can't work with Machinekit and why it might even be better doing it?

I also like the fact that, IIRC, devs here created QtQuickVCP which is a better UI system for these SBC implementations.

I don't see an current docs for Machinekit on rPi4, only and old one for rPi2/3.     It's been quite a while since I built Machinekit from source for the BBB so I've not looked at the current state for doing that on the latest rPiOS.

[Charles Steinkuehler]

On 2/21/2021 11:58 AM, Doug LaRue wrote:
> I don't want to start up a Machinekit vs LinuxCNC argument but the
> developer of Remora has been using LinuxCNC with the 2.8-rtpreempt kernel
> which seem way out of date.
> I know this group has been doing Machinekit on the BBB SBC for far longer
> and for a while were using the Xenomai kernel but switched to the rtPreempt
> and is using Preempt_rt v4.9 and provides pre-built images.
> Do any of the developers here see a reason why this SPI implementation
> can't work with Machinekit and why it might even be better doing it?

I don't see why an SPI interface shouldn't work with Machinekit.

> I also like the fact that, IIRC, devs here created QtQuickVCP which is a
> better UI system for these SBC implementations.
>
> I don't see an current docs for Machinekit on rPi4, only and old one for
> rPi2/3. It's been quite a while since I built Machinekit from source
> for the BBB so I've not looked at the current state for doing that on the
> latest rPiOS.

I haven't been building Machinekit much, but I have been doing a lot of
work recently on the RPi4. I may be able to help if you get stuck on
something.

--
Charles Steinkuehler
cha...@steinkuehler.net

[ce...@tuta.io]

Feb 18, 2021, 23:36 by blaz...@gmail.com:

>> 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.
>

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...

Cern

>
> On Thu, Feb 18, 2021 at 11:23 AM cern via Machinekit <> machi...@googlegroups.com> > wrote:
>

>> >>  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>> .

>>
>
>
>
> --
> 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%2BQ02MNv8G2nL0aRpAdCNPrELLit3t9KyrUhUFqrXG-6xaukDg%40mail.gmail.com <https://groups.google.com/d/msgid/machinekit/CA%2BQ02MNv8G2nL0aRpAdCNPrELLit3t9KyrUhUFqrXG-6xaukDg%40mail.gmail.com?utm_medium=email&utm_source=footer>> .
>

[ce...@tuta.io]

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.

>>> >>  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>> .
>

[justin White]

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"

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.

[Doug LaRue]

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.