Weird idea?

[Berkdan Kara]

Hi All.

I have an idea but it may sound weird at the first place. Since I am not a tech guy I don't know if it's stupid or not, could you please criticize the idea.

I would like to use raspberry pi3 with machinekit. This is not the weird? idea.

The idea; can pi be used as an FPGA?

I want to use a laptop or PC as the main machine with machinekit and want to connect raspberry pi with ethernet or spi or something else. Raspberry pi will be machinekit installed as well without any gui. What I would like to do is: the main computer will send the commands to the pi as if it is a FPGA board (or not) then pi will get the command and execute it( generate steps follow the error messages from NML etc.) Then will send feedback to main machinekit computer.

You could think that why pi is needed between computer and step drivers. I did some resourcing and find out with parallel port computers can generate 25 khz steps. With the GUI it's about the same for pi. But I read a discussion on linuxcnc forum that without GUI someone could achieve 500 khz step generating on Pi3.

I know it's been very long to explain what I would like to do but please forgive me since I am not a native English speaker.

Thank you all in advance if you read this till here.

Have a good day/night.
Berkdan

[Bas de Bruijn]

Hi Berkdan,

Failing to understand why you need what you think you need...

IMO a better setup would be a PC with a mesanet PCI card. This is in fact a FPGA. Perhaps you could do a thing like you propose, but i think this is a setup involving a lot of components where i fail to see the merit.

What does the machine need to do, why do you need a 500 kHz step rate? I wonder which driver/motor would be able to handle that.

You can run Machinekit directly on a raspberry pi, or a beaglebone for that matter.

Bas

> --
> 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/148c4e87-3d8a-4785-b435-e091a3f3cd67%40googlegroups.com.

[justin White]

He obviously wants to use something small so a pc with a PCIe FPGA probably isn’t his goal. But I agree, it’s not really a good idea, the raspberry pi can’t be used “like an FPGA” because it’s not an FPGA. Generating steps in software on a RPI and sending them out over GPIO while remotely communicating with the RPI is not a good machine setup.

Mesa has FPGA cards for the raspberry pi. The 7c80 apparently isnt ready yet due to drivers but the 7c81 is. I would wait for the 7c80 personally because the I/O is machine ready all on one board. Using this setup you don’t need the Remote PC, the RPI is the PC, and it can handle commanding the FPGA to generate steps in hardware fine.

If you really want to do this remotely with a laptop or whatever, that should be fine with the setup mentioned above, isn’t that what machinetalk is for? A better setup is to use a de10 nano, which is a FPGA with processors on chip, so it can run machinekit headless ( or with GUI) and it can be controlled the same way you would if you were controlling a RPI really. You would still need hardware to make the DE10-Nano I/O useable for a machine, but it’s a simpler affair. I’m not sure what’s all out there for these boards, I’ve designed my own daughter card for the DE10, but I think there is other direct hardware out there.

Sent from my iPhone

> To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/01D310F6-8DE1-4BCC-B66B-604D3EBEC95E%40basdebruijn.com.

[Berkdan Kara]

Thank you Justin and Bas for quick response.

I know about Mesa cards, but it takes too long to have it in my country. Legal procedures etc. or I need to spend a lot for quick cargo and custom taxes.. Besides I have two analog and one digital servo motor and drive thus I need at least two Mesa daughter card and one anything card like the one for pi or pcie etc. Which is very confusing for me. So I am trying to find a solution for that. I am good at python programming and I know that using NML with machinekit is possible to control motors. I already have a pi3b+ and a pc :) so I just wanted to know if it's a good idea to spend some time on it or not.

I have no idea about pic programming nor electronics so I wanted to do something with what I already have.

About step frequency I have tested linuxcnc with parallel port and I have got 1500 mm/min speed rate if just two axis runs at the same time. I do relief machining a lot and when z axis runs with X and y, speed drastically reduce to 600 mm/min. This is because of the latency issues. Not to have latency issues I thought it would be good idea if I seperate the GUI and the step generator.

Since forums is here for brainstorming I just got the idea and shared with you to learn if it's a good idea or not.

Thank you again for your interest.

Berkdan

[justin White]

What do you need to control the 3 servo drives? Are they step/direction with encoder feedback to the controller or the driver?

Sent from my iPhone

> --
> 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/4ed6c762-8e48-4a3a-a90b-6e01abcbe967%40googlegroups.com.

[Berkdan Kara]

Those are analog servo motors and i have their drivers. 1 is step dir servo. So I need either step/dir to analog converter for the 2 of them or one Mesa analog servo daughter card and one regular step dir daughter card. And one anything to do card like 5i25 if we talk about Mesa cards.

The thing is, is the idea good enough to chase or just needless or stupid.

[ce...@tuta.io]

Sep 18, 2019, 16:26 by ber...@gmail.com:

Hello,
I can feel your pain. The distribution part of Mesa business is very bad. It is a little bit better that it was but still they could learn a lot from Chinese sellers.

However, Raspberry Pi with default GPIO configuration for step-gen is not good solution. I have heard some interesting news about the GPIO toggling on Raspberry Pi: https://evlproject.org/pipermail/evl/2019-May/000019.html <https://evlproject.org/pipermail/evl/2019-May/000019.html> but fo far I didn't play with it.

About distributed system, to have proper distinction between RT tasks specific hardware and non-RT tasks specific hardware is the way forward, I think. It is clutch from LinuxCNC days to have everything on one PC, from times when electronics, PCs and whatnots were very expensive. Today, there is no need to not have one physical system running the RT kernel and tasks and other taking care of the planning and another taking care of UI. Video frame buffer will always cause unnecessary latencies on RT systems.

However, Machinetalk in the current form is not going to take us there. Unfortunately.

If you want Raspberry Pi with something like Mesa FPGA firmware, try the BeagleBone Black.

And, if you are up to challenge, you can try to implement simple core on some $10 FPGA developer board from Alibaba. The HostMot2 is nice, but it is universal and so overcomplicated. Look for example at the Pluto code or internet tutorials. Or the LAN9252 + ARM or XMC4800 for Mesa card DYI alternatives.

Cern.

[justin White]

@cern

Curious, what is the state of machinetalk?

I am at some point planning on running a remote GUI, pretty much as you described with a de10 nano as the RT pc/FPGA and some ARM or small X86 running the interface. I didn’t get too far in depth of what I need to do with remotely controlling it, too busy with hardware but I thought the remote concept of machinekit was solid.

@berkdan, can you use PWM to control the analog servos


Sent from my iPhone

> --
> 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/Lp4RDSK--3-1%40tuta.io.

[Bas de Bruijn]

> On 18 Sep 2019, at 19:34, <ce...@tuta.io> <ce...@tuta.io> wrote:
>
> Sep 18, 2019, 16:26 by ber...@gmail.com:
>
>> Thank you Justin and Bas for quick response.
>>
>> I know about Mesa cards, but it takes too long to have it in my country. Legal procedures etc. or I need to spend a lot for quick cargo and custom taxes.. Besides I have two analog and one digital servo motor and drive thus I need at least two Mesa daughter card and one anything card like the one for pi or pcie etc. Which is very confusing for me. So I am trying to find a solution for that. I am good at python programming and I know that using NML with machinekit is possible to control motors. I already have a pi3b+ and a pc :) so I just wanted to know if it's a good idea to spend some time on it or not.
>>
>> I have no idea about pic programming nor electronics so I wanted to do something with what I already have.
>>
>> About step frequency I have tested linuxcnc with parallel port and I have got 1500 mm/min speed rate if just two axis runs at the same time. I do relief machining a lot and when z axis runs with X and y, speed drastically reduce to 600 mm/min. This is because of the latency issues. Not to have latency issues I thought it would be good idea if I seperate the GUI and the step generator.
>>
>> Since forums is here for brainstorming I just got the idea and shared with you to learn if it's a good idea or not.
>>
>> Thank you again for your interest.
>>
>> Berkdan
>>
> Hello,
> I can feel your pain. The distribution part of Mesa business is very bad. It is a little bit better that it was but still they could learn a lot from Chinese sellers.
>
> However, Raspberry Pi with default GPIO configuration for step-gen is not good solution. I have heard some interesting news about the GPIO toggling on Raspberry Pi: https://evlproject.org/pipermail/evl/2019-May/000019.html <https://evlproject.org/pipermail/evl/2019-May/000019.html> but fo far I didn't play with it.
>
> About distributed system, to have proper distinction between RT tasks specific hardware and non-RT tasks specific hardware is the way forward, I think. It is clutch from LinuxCNC days to have everything on one PC, from times when electronics, PCs and whatnots were very expensive. Today, there is no need to not have one physical system running the RT kernel and tasks and other taking care of the planning and another taking care of UI. Video frame buffer will always cause unnecessary latencies on RT systems.
>
> However, Machinetalk in the current form is not going to take us there. Unfortunately.

I’ve used remote UI’s with HAL remote components for a few projects, I was happy using the UI on an Android device, while machinekit ran on a PC with mesa hardware. What’s wrong with Machinetalk?

>
> If you want Raspberry Pi with something like Mesa FPGA firmware, try the BeagleBone Black.
>
> And, if you are up to challenge, you can try to implement simple core on some $10 FPGA developer board from Alibaba. The HostMot2 is nice, but it is universal and so overcomplicated. Look for example at the Pluto code or internet tutorials. Or the LAN9252 + ARM or XMC4800 for Mesa card DYI alternatives.
>
> Cern.
>

> --
> 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/Lp4RDSK--3-1%40tuta.io.

[Berkdan Kara]

Cern, thank you very much for the infos. I have had lots of informations from your message.

After writing on the forum I took a look at picnc project on GitHub. It was promising for me to see it's possible to make a board that can generate step pulses and communicate over spi with pi. There is even a pull up which uses more powerful CPU but unfortunately I cannot get these CPU's in Turkey.

So I have checked what else I can reach easily in my country and found out that stm32f4 discovery and STM nucleo are cheap and available here. I may go in that way if your suggestions does not work for me. But I am surely going to check beaglebone out.

And Justin, unfortunately own output does not work for me.

I am going to use step to analog converter to control the servos. Thus I will control motors with a stepgen card.

Thanks again. I am going to check the other possibilities that Cern suggested.

[Berkdan Kara]

Cern,

I have checked Beaglebone out and it fits my needs. Thank you for your guidance.

[ce...@tuta.io]

Sep 18, 2019, 20:19 by blaz...@gmail.com:

> @cern
>
> Curious, what is the state of machinetalk?
>
> I am at some point planning on running a remote GUI, pretty much as you described with a de10 nano as the RT pc/FPGA and some ARM or small X86 running the interface. I didn’t get too far in depth of what I need to do with remotely controlling it, too busy with hardware but I thought the remote concept of machinekit was solid.
>

This is only my view at the situation and as such there is going to be a difference of opinions. Mainly what Machinetalk is and what it should do.

The Machinetalk and HALtalk is a joint baby of Michael Haberler and Alexander Rössler (for whom I think it was a diploma work). By post-mortem investigation, there were a quite big plans for what Machinetalk should be able to do. It was intended as a replacement of the NML and also shift from current position, when NML sits on top of (for example) motion component, nearer the HALayer core. That way it would enable node structure of machine system setup. (As a example, imagine two RTAPI instances (msgd and rtapi_app daemons) running infinite real-time loop tasks like now, but getting the instruction from one separate planner, which it itself is controlled from numerous terminals [GUIs].) Instances of Machinekit should be also able to communicate with each other, not only with current clien-server. As there was intention for direct control of rtapi_app created HAL.

But then Michael Haberler performed his exit stage left without finishing his work (he even wanted to write documentation) and Alexander Rössler was always (and by his online activity still is) interested more in GUI and HMI work and replacing AXIS with something remote/running on Android/written in modern language.

So, the current situation is that the Machinetalk (and affiliated technologies) is deeply ingrained into Machinekit, but not deeply enough as too much LinuxCNC ways is still visible. And then it's development stalled. And that is the root of my frustration.

So, to @Bas, if you want to use only the UI components, you are fine as it works. (But is still only a clutch, as the messages are translated to NML to communicate with Machinekit-CNC side.) However, look for example at the NOTYET portion of code in rtapi_app and then how HALCMD communicates with  rtapi_app. It uses the Machinetalk. But then not. It uses the ZeroMQ layer and Protobuf serialization. And then it registers itself as a HAL module, which I consider a braindead move (OK, I get it why it does that, but it's bad architectural design and means that the process needs to run on the same system as a rtapi_app). Saner approach would be to enforce the rtapi_app only place where access to the HAL shared memory space happen. CMDLINE would message rtapi_app socket with command, rtapi_app would execute it and send back a status. That way you can milk the great feature of ZeroMQ and use HALCMD from everywhere, even Windows Machines. (Typical machine programmer monkey cannot use Linux.)

I think the best approach would be to implement what I described here: https://github.com/machinekit/machinekit-hal/issues/230 <https://github.com/machinekit/machinekit-hal/issues/230> with Linux based permissions on file access, onto this connect new process which would do the Machitalk access (machinetalk_app), which would do all what is done now plus manage permissions (which current implementation of Machinetalk does not even take into account) based on certificates, protocols and interfaces (you can have an interface you consider implicitly safe which is direct connection to other parts of the machine and then another which is LAN) onto which would be connected the HALCMD and other similar applications or remote/nonRT connected rtapi_app (Machinekit-HAL) instances. But, as I said, it is only my opinion.

Also, part of Machinekit is the router message pipe (currently not used, I think) which is intended for direct messaging between two HAL modules. Imagine module which has a ring buffer. This ring buffer is filled from one side by (for example) RT HAL module, then on other end emptied  by this router, send over ZeroMQ to other machine and there the dealer puts this message back into receiving ring buffer of some local HAL module. Problem with this is that the HAL module works with structures, but the router has to serialize this to Protobuf format and remote router has to deserialize it. For this, something with same-on-wire-same-in-memory format would be better. Like Flat buffers (pending consideration on memory alignment).

Machinetalk is also big on multipart messaging concept. Which is considered by parental ZeroMQ community as an obsolete (or starting to be obsolete) and is no longer supported with new messaging patterns and sockets - like the UDP, which for direct communication between two Machinekit/Machinetalk instances would be the best.

(BTW, Machinetalk with DNS-SD will have a big problem with non-Ethernet network, for example were you implement the ZeroMQ pattern over RS-232 serial, for which there already was interest.)

It would be also great to use the current HAL-REMOTE component pattern for PIN creation before the actual HAL component is instantiated. I see the use for going away with the postgui.hal hack and streamlining the HAL configuration setup and tear down for non-realtime capable components.

Sorry for the rant, but that is what I see is problematic with Machinetalk. I want independent islands of functionality which don't care about where they run and are able to dynamically change each other.

But it needs people interested in it. And so far, nobody (with big enough means) really is.

Cern.

[ce...@tuta.io]

Sep 18, 2019, 21:05 by ber...@gmail.com:

> Cern, thank you very much for the infos. I have had lots of informations from your message.
>
> After writing on the forum I took a look at picnc project on GitHub. It was promising for me to see it's possible to make a board that can generate step pulses and communicate over spi with pi. There is even a pull up which uses more powerful CPU but unfortunately I cannot get these CPU's in Turkey.
>

You may find interesting to follow local auctions/bazaars with lookout for Ethercat Beckhoff hardware. I was able to score some off (German) Ebay in an interesting price range.

>
> So I have checked what else I can reach easily in my country and found out that stm32f4 discovery and STM nucleo are cheap and available here. I may go in that way if your suggestions does not work for me. But I am surely going to check beaglebone out.
>

It would be great to get some new OSH in the Machinekit community. But I imagine it is a lot of work. I had some hopes for the DieBie Slave ( https://github.com/DieBieEngineering/DieBieSlave ), <https://github.com/DieBieEngineering/DieBieSlave> but he had to use a 6 layer board, which is death sentence for any DYI/OSH project.

Hope the BBB will work out for you.

>
> And Justin, unfortunately own output does not work for me.
>
> I am going to use step to analog converter to control the servos. Thus I will control motors with a stepgen card.
>
> Thanks again. I am going to check the other possibilities that Cern suggested.
>

> --
> 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/52dfc271-98c4-4ba0-8df7-54956e570451%40googlegroups.com.
>

[Berkdan Kara]

Hi Cern,

You are the guy. You helped me a lot.

And,

Isn't the following veeery long and also great explanation about what I (kind of) have asked for in the first place?

Berkdan

[ce...@tuta.io]

Sep 19, 2019, 19:41 by ber...@gmail.com:

> Hi Cern,
>
> You are the guy. You helped me a lot.
>
> And,
>
> Isn't the following veeery long and also great explanation about what I (kind of) have asked for in the first place?
>

I don't know about great, but in a way it is. And you can use it today if you are able to meet the limitations (AXIS like GUI, remote HAL components, MKWrapper, Launcher and so on). The problem with the latency and what is one capable with reaching is the video Frame Buffer. You are never going to get the best when you run the graphics on the same system. (Plus you should always use processor isolation, you can even let different tasks (threads) run on different wholly isolated cores.)

BTW, in many cases you don't even need FPGA. It became a kind of magic bullet in LinuxCNC community, because the solution around HostMot2 works, it has support from Peter Wallace, is universal and people like repetition. There are many (commercial) solutions based on microcontrollers which work as good.

But if you want something like CS-LAB CSMIO (real-time tasks with additional hardware for encoder counting, PWM and step/dir generation and some real-time processed GPIO commanded by some higher system), then you are out of luck with current system. Even if @SnowWhite's SoC solutions could be excellent for this, you would still need to slash the Motion component.

(That's another legacy from LinuxCNC, they historically had a problem with letting go of the all-in-one system.)

Cern.

> --
> 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/f58e7235-a387-482b-bd51-061e87e711a7%40googlegroups.com.
>

[Berkdan Kara]

Thank you Cern.

I know I am kinda pain in the head :)

I have searched about BBB and I always found bbb+machinekit+some Cape like CNC Cape. I couldn't find any information about connecting motor driver directly to the BBB. A friend of mine need to drive step motor with leadshine ma860 driver. In this case is it possible to connect the BBB and the driver?

A big thank you again.

[Simon S]

Hi!

I use this cape to connect similar drivers and all my Endstops etc to a BBB:

https://www.necitec.de/index.php/en/cnc-cape

Simon

[Bas de Bruijn]

> On 19 Sep 2019, at 17:50, <ce...@tuta.io> <ce...@tuta.io> wrote:
>
> Sep 18, 2019, 20:19 by blaz...@gmail.com:
>
>> @cern
>>
>> Curious, what is the state of machinetalk?
>>
>> I am at some point planning on running a remote GUI, pretty much as you described with a de10 nano as the RT pc/FPGA and some ARM or small X86 running the interface. I didn’t get too far in depth of what I need to do with remotely controlling it, too busy with hardware but I thought the remote concept of machinekit was solid.
>>
> This is only my view at the situation and as such there is going to be a difference of opinions. Mainly what Machinetalk is and what it should do.
>
> The Machinetalk and HALtalk is a joint baby of Michael Haberler and Alexander Rössler (for whom I think it was a diploma work). By post-mortem investigation, there were a quite big plans for what Machinetalk should be able to do. It was intended as a replacement of the NML and also shift from current position, when NML sits on top of (for example) motion component, nearer the HALayer core. That way it would enable node structure of machine system setup. (As a example, imagine two RTAPI instances (msgd and rtapi_app daemons) running infinite real-time loop tasks like now, but getting the instruction from one separate planner, which it itself is controlled from numerous terminals [GUIs].) Instances of Machinekit should be also able to communicate with each other, not only with current clien-server. As there was intention for direct control of rtapi_app created HAL.
>
> But then Michael Haberler performed his exit stage left without finishing his work (he even wanted to write documentation) and Alexander Rössler was always (and by his online activity still is) interested more in GUI and HMI work and replacing AXIS with something remote/running on Android/written in modern language.
>
> So, the current situation is that the Machinetalk (and affiliated technologies) is deeply ingrained into Machinekit, but not deeply enough as too much LinuxCNC ways is still visible. And then it's development stalled. And that is the root of my frustration.
>
> So, to @Bas, if you want to use only the UI components, you are fine as it works. (But is still only a clutch, as the messages are translated to NML to communicate with Machinekit-CNC side.)

I’m afraid you misunderstand. I do not use the CNC stuff. Just the HAL layer. Pins, No NML.

The entire “let’s replace nml” has halted because 1: this is hard work and 2: it is a lot of work and 3: there’s nobody who wants to do that.

> However, look for example at the NOTYET portion of code in rtapi_app and then how HALCMD communicates with rtapi_app. It uses the Machinetalk. But then not. It uses the ZeroMQ layer and Protobuf serialization. And then it registers itself as a HAL module, which I consider a braindead move (OK, I get it why it does that, but it's bad architectural design and means that the process needs to run on the same system as a rtapi_app). Saner approach would be to enforce the rtapi_app only place where access to the HAL shared memory space happen. CMDLINE would message rtapi_app socket with command, rtapi_app would execute it and send back a status. That way you can milk the great feature of ZeroMQ and use HALCMD from everywhere, even Windows Machines. (Typical machine programmer monkey cannot use Linux.)
>
> I think the best approach would be to implement what I described here: https://github.com/machinekit/machinekit-hal/issues/230 <https://github.com/machinekit/machinekit-hal/issues/230> with Linux based permissions on file access, onto this connect new process which would do the Machitalk access (machinetalk_app), which would do all what is done now plus manage permissions (which current implementation of Machinetalk does not even take into account) based on certificates, protocols and interfaces (you can have an interface you consider implicitly safe which is direct connection to other parts of the machine and then another which is LAN) onto which would be connected the HALCMD and other similar applications or remote/nonRT connected rtapi_app (Machinekit-HAL) instances. But, as I said, it is only my opinion.
>
> Also, part of Machinekit is the router message pipe (currently not used, I think) which is intended for direct messaging between two HAL modules. Imagine module which has a ring buffer. This ring buffer is filled from one side by (for example) RT HAL module, then on other end emptied by this router, send over ZeroMQ to other machine and there the dealer puts this message back into receiving ring buffer of some local HAL module. Problem with this is that the HAL module works with structures, but the router has to serialize this to Protobuf format and remote router has to deserialize it. For this, something with same-on-wire-same-in-memory format would be better. Like Flat buffers (pending consideration on memory alignment).
>
> Machinetalk is also big on multipart messaging concept. Which is considered by parental ZeroMQ community as an obsolete (or starting to be obsolete) and is no longer supported with new messaging patterns and sockets - like the UDP, which for direct communication between two Machinekit/Machinetalk instances would be the best.
>
> (BTW, Machinetalk with DNS-SD will have a big problem with non-Ethernet network, for example were you implement the ZeroMQ pattern over RS-232 serial, for which there already was interest.)
>
> It would be also great to use the current HAL-REMOTE component pattern for PIN creation before the actual HAL component is instantiated. I see the use for going away with the postgui.hal hack and streamlining the HAL configuration setup and tear down for non-realtime capable components.
>
> Sorry for the rant, but that is what I see is problematic with Machinetalk. I want independent islands of functionality which don't care about where they run and are able to dynamically change each other.
>
> But it needs people interested in it. And so far, nobody (with big enough means) really is.
>
> Cern.
>
>
>

> --
> 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/Lp9CwT---3-1%40tuta.io.

[justin White]

The bbb I/o is 3.3v so you’ll want to take a look at the manual for the driver and see if it can accept 3.3v or it must be 5v. The if it must be 5v you would need a level shift solution which is what most cape hardware does for you.

If bbb gpio is sourcing and your motor driver has both plus and minus inputs for step and direction then you connect the minus of each to common and stick the bbb outputs into the plus of each.

Sent from my iPhone

> --
> 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/0275f51b-7c2c-4577-970f-200de9e37c8f%40googlegroups.com.

[Berkdan Kara]

Thank you all for your help.

[justin White]

The FPGA is LinuxCNC's magic bullet because FPGA's in general are magic bullets. IMHO, mksocfpga could also be Machinekit's magic bullet in a way that is even more potent that off the shelf Mesa hardware. This is what LinuxCNC is missing, and Machinekit is not quite exploiting enough. The means exist for you to design your own field tolerant hardware and configure the hm2 firmware however it suits using an socfpga dev board of your choosing as long as Charles/Michael have gotten their hands on it.

Not to knock MK, I understand it's mission statement... I just don't have real faith in Beaglebone or Raspberry Pi hardware. I'm sure they are great for 3D printers and such but running a machinetool on them makes me cringe. I think the DE10 Nano is good hardware with an FPGA that is more than large enough. Could use a bit more CPU and a GPU though. CPU performance seems good enough with a FB that I think it can get away with quite a bit. I have yet to explore the headless-remote setup but I'd think there would be very little left to desire if it's well sorted.

I would not say microcontrollers are not plenty capable but I would not bother with the availability of very capable FPGA hardware that is relatively easily configured. Micros are better sorted for something specialized like the STM32 used in STMBL drives. I can understand the desire for low cost machine control for a 3D printer, but trying to spend less for the control solution than the cost of 1 motor and step driver is a bit silly. The fact that you can control a machine with reasonable hardware for a couple hundred bucks these days all in is amazing in and of itself. 

> To unsubscribe from this group and stop receiving emails from it, send an email to machi...@googlegroups.com.

[Bas de Bruijn]

On 21 Sep 2019, at 03:10, justin White <blaz...@gmail.com> wrote:

The FPGA is LinuxCNC's magic bullet because FPGA's in general are magic bullets. IMHO, mksocfpga could also be Machinekit's magic bullet in a way that is even more potent that off the shelf Mesa hardware. This is what LinuxCNC is missing, and Machinekit is not quite exploiting enough. The means exist for you to design your own field tolerant hardware and configure the hm2 firmware however it suits using an socfpga dev board of your choosing as long as Charles/Michael have gotten their hands on it.

Not to knock MK, I understand it's mission statement... I just don't have real faith in Beaglebone or Raspberry Pi hardware. I'm sure they are great for 3D printers and such but running a machinetool on them makes me cringe. I think the DE10 Nano is good hardware with an FPGA that is more than large enough. Could use a bit more CPU and a GPU though. CPU performance seems good enough with a FB that I think it can get away with quite a bit. I have yet to explore the headless-remote setup but I'd think there would be very little left to desire if it's well sorted.

I would not say microcontrollers are not plenty capable but I would not bother with the availability of very capable FPGA hardware that is relatively easily configured. Micros are better sorted for something specialized like the STM32 used in STMBL drives. I can understand the desire for low cost machine control for a 3D printer, but trying to spend less for the control solution than the cost of 1 motor and step driver is a bit silly. The fact that you can control a machine with reasonable hardware for a couple hundred bucks these days all in is amazing in and of itself. 

You hit the nail right on the head (Although I’d like to nuance about the Beaglebone).

The FPGA solution is very powerful. At the same time it’s the Achilles heel. To get an FPGA running with mksocfpga is a lot of work and not many people can do that.

When you want to apply this in an industrial environment then you need hardware that’s around for longer than the developers SoC boards are around. Say 10 year. And are available.

There are some boards with long life supports. Like these: http://www.exorembedded.net/webpage?ReadForm&wPageName=products&t=Product&p=microSOM%20uS02 Even if you can buy these for example in small quantities (I’ve enquired and you can only buy them at 500 pcs, silly) you still need to develop additional hardware.

So for a small form factor with RT capabilities, ready to use proper OS (not some gobbled up Linux image that loses support the moment you buy the board), availability and longevity there are not a lot alternatives for a Beaglebone... and then again you need additional hardware ;)

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/4eb48782-49fc-40ec-b7e0-a52d1d8e8f8d%40googlegroups.com.

[justin White]

The length of availability is something that was concerning me as well, that does seem to possibly be the unfortunate downside. Getting the FPGA running is only hard for the mksocfpga guys I'm sure, modifying the firmware for hardware on users end is actually very easy because of how it's implemented. While I wouldn't take anything away from the mksocfpga guys, IMO hm2 firmware is like a masterpiece that makes this quite a bit more portable and settles alot of the prior work.

 Again one of the frustrating things in MK is figuring out what is going on and minor things when the major work to make it easily usable is already done. Current state seems to be like a few missing pieces to a documentation puzzle that is otherwise complete. Modifying a pinfile on the user's end is super easy, it's those missing pieces that make it a bit more difficult.

You can buy the boards you mentioned individually from Arrow https://www.arrow.com/en/products/us02-0001/exor-embedded-srl. Problem with those is that they're about double the price of a DE10 and stuff like hdmi and ethernet would have to be routed through daughtercard as well since the connectors are not onboard, which adds more to the cost of the external hardware. 

The BBB requires additional HW as well, it's not field ready in any way without a cape. I'm not fully upto snuff on BBB but I was originally intending to make a hybrid board to use either the DE10 or BBB but the BBB was starting to erk me with all the conditional pin states....adding this disables that, you can do this but not if you do that, use this PRU don't use that one, you don't really need the PRUs....just a headache when the DE10 has 72 I/O pins from the FPGA.......do whatever you want with any one of them. Routing a PCB is greatly simplified when the only thing you really care about is tracking close to the pin when the pin can do whatever you want it to.

The state of ARM itself in the Linux world is likely to improve, hopefully sometime during the 5.x kernel lifespan will make ARM socs less dependent on vendor kernels so cobbled up images may see less use and the ARM world will get a little closer to the x86 world. Intel owns Alterra so even though they say they won't be putting x86 inside an socfpga, well we'll see. Smaller nodes make that easily possible. ARM is like MK in a way so they're perfect for each other. People think ARM is for cell phones and don't realize how powerful it really can be if the support and infrastructure exists......instead, cobbled up images relying on vendor patched Linux Kernels.

[ce...@tuta.io]

Sep 20, 2019, 16:16 by b...@basdebruijn.com:

>
>
>> On 19 Sep 2019, at 17:50, <ce...@tuta.io> <ce...@tuta.io> wrote:
>>

>> Sep 18, 2019, 20:19 by blaz...@gmail.com:
>>
>>> @cern
>>>
>>> Curious, what is the state of machinetalk?
>>>
>>> I am at some point planning on running a remote GUI, pretty much as you described with a de10 nano as the RT pc/FPGA and some ARM or small X86 running the interface. I didn’t get too far in depth of what I need to do with remotely controlling it, too busy with hardware but I thought the remote concept of machinekit was solid.
>>>
>> This is only my view at the situation and as such there is going to be a difference of opinions. Mainly what Machinetalk is and what it should do.
>>
>> The Machinetalk and HALtalk is a joint baby of Michael Haberler and Alexander Rössler (for whom I think it was a diploma work). By post-mortem investigation, there were a quite big plans for what Machinetalk should be able to do. It was intended as a replacement of the NML and also shift from current position, when NML sits on top of (for example) motion component, nearer the HALayer core. That way it would enable node structure of machine system setup. (As a example, imagine two RTAPI instances (msgd and rtapi_app daemons) running infinite real-time loop tasks like now, but getting the instruction from one separate planner, which it itself is controlled from numerous terminals [GUIs].) Instances of Machinekit should be also able to communicate with each other, not only with current clien-server. As there was intention for direct control of rtapi_app created HAL.
>>
>> But then Michael Haberler performed his exit stage left without finishing his work (he even wanted to write documentation) and Alexander Rössler was always (and by his online activity still is) interested more in GUI and HMI work and replacing AXIS with something remote/running on Android/written in modern language.
>>
>> So, the current situation is that the Machinetalk (and affiliated technologies) is deeply ingrained into Machinekit, but not deeply enough as too much LinuxCNC ways is still visible. And then it's development stalled. And that is the root of my frustration.
>>
>> So, to @Bas, if you want to use only the UI components, you are fine as it works. (But is still only a clutch, as the messages are translated to NML to communicate with Machinekit-CNC side.)
>>
>

> I’m afraid you misunderstand. I do not use the CNC stuff. Just the HAL layer. Pins, No NML.
>

Ah yes, I did. HALtalk works. But then I always thought that HALtalk is only a subset of Machinetalk.

BTW, given that you use it in - probably - professional manner, do you think that the HAL_REMOTE_COMPONENT idea would be usable for creating orphaned pins inside HAL for real-time components if my realtime character device communication idea was possible?

>
> The entire “let’s replace nml” has halted because 1: this is hard work and 2: it is a lot of work and 3: there’s nobody who wants to do that.
>

I can relate to that. It's just that it seems  that replacing the NML was the main motivation behind Machinetalk. Given the fact, that NML is layered upon the CNC side, it is not that interesting to me at the moment.

Cern.

>> However, look for example at the NOTYET portion of code in rtapi_app and then how HALCMD communicates with rtapi_app. It uses the Machinetalk. But then not. It uses the ZeroMQ layer and Protobuf serialization. And then it registers itself as a HAL module, which I consider a braindead move (OK, I get it why it does that, but it's bad architectural design and means that the process needs to run on the same system as a rtapi_app). Saner approach would be to enforce the rtapi_app only place where access to the HAL shared memory space happen. CMDLINE would message rtapi_app socket with command, rtapi_app would execute it and send back a status. That way you can milk the great feature of ZeroMQ and use HALCMD from everywhere, even Windows Machines. (Typical machine programmer monkey cannot use Linux.)
>>
>> I think the best approach would be to implement what I described here: https://github.com/machinekit/machinekit-hal/issues/230 <https://github.com/machinekit/machinekit-hal/issues/230> with Linux based permissions on file access, onto this connect new process which would do the Machitalk access (machinetalk_app), which would do all what is done now plus manage permissions (which current implementation of Machinetalk does not even take into account) based on certificates, protocols and interfaces (you can have an interface you consider implicitly safe which is direct connection to other parts of the machine and then another which is LAN) onto which would be connected the HALCMD and other similar applications or remote/nonRT connected rtapi_app (Machinekit-HAL) instances. But, as I said, it is only my opinion.
>>
>> Also, part of Machinekit is the router message pipe (currently not used, I think) which is intended for direct messaging between two HAL modules. Imagine module which has a ring buffer. This ring buffer is filled from one side by (for example) RT HAL module, then on other end emptied by this router, send over ZeroMQ to other machine and there the dealer puts this message back into receiving ring buffer of some local HAL module. Problem with this is that the HAL module works with structures, but the router has to serialize this to Protobuf format and remote router has to deserialize it. For this, something with same-on-wire-same-in-memory format would be better. Like Flat buffers (pending consideration on memory alignment).
>>
>> Machinetalk is also big on multipart messaging concept. Which is considered by parental ZeroMQ community as an obsolete (or starting to be obsolete) and is no longer supported with new messaging patterns and sockets - like the UDP, which for direct communication between two Machinekit/Machinetalk instances would be the best.
>>
>> (BTW, Machinetalk with DNS-SD will have a big problem with non-Ethernet network, for example were you implement the ZeroMQ pattern over RS-232 serial, for which there already was interest.)
>>
>> It would be also great to use the current HAL-REMOTE component pattern for PIN creation before the actual HAL component is instantiated. I see the use for going away with the postgui.hal hack and streamlining the HAL configuration setup and tear down for non-realtime capable components.
>>
>> Sorry for the rant, but that is what I see is problematic with Machinetalk. I want independent islands of functionality which don't care about where they run and are able to dynamically change each other.
>>
>> But it needs people interested in it. And so far, nobody (with big enough means) really is.
>>
>> Cern.
>>
>>
>>

>> --
>> 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/Lp9CwT---3-1%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/CD19E8B0-DD42-4756-8114-F5A62D63CA7B%40basdebruijn.com.
>