Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On Fri, Apr 26, 2013 at 5:15 PM, Michael Haberler mai...@mah.priv.atwrote: Mark, I was thinking more of hardware resources, such as interrupts. What happens when both instances require the same interrupt at the same time? Any instance usually will have a HAL driver to talk to the outside world exactly like the single instance which we have now, and that driver will attach to a hardware device and will be responsible to allocate all required resources during startup or bark if isnt possible - there is no difference at all from a single instance which loads several drivers talking to different devices this would include an interrupt if there were one - you probably wont find any in LinuxCNC Isn't that presuming that all the hardware devices will be relegated to that singular instance? That would be okay if there were multiples of each hardware device, but in cases where there aren't is where my concern lies. Unlike shared memory, interrupts are a bit harder to share, or have concurrent use. Can the separate instances somehow share the IO bus? no, separation is at the HAL driver level as it always was, no new concepts here an example: assume you have 2 parports in a PC: it is exactly the same I/O usage if you do this in a single instance: loadrt hal_parport cfg=0x278 0x378 or do this in instance #1 loadrt hal_parport cfg=0x278 and this in instance #2: loadrt hal_parport cfg=0x378 Remember: instances are ships in the night _except_ if there are cross-linked signals, in which case they can share signal values you're thinking too complicated ;) - Michael I probably am overthinking it, and making it too complicated, but my degree is computer science, and I've always been intrigued by RTOS systems. Now that folks are looking into multiple instances of RTOS running on the same machine, I'm very curious how they get around resources that can't be shared, or how they schedule them so that a lock on the resource by one instance affects the other instance which might need that resource at the same time. Mark -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Mark, Am 27.04.2013 um 13:06 schrieb Mark Wendt wendt.m...@gmail.com: On Fri, Apr 26, 2013 at 5:15 PM, Michael Haberler mai...@mah.priv.atwrote: Mark, I was thinking more of hardware resources, such as interrupts. What happens when both instances require the same interrupt at the same time? Any instance usually will have a HAL driver to talk to the outside world exactly like the single instance which we have now, and that driver will attach to a hardware device and will be responsible to allocate all required resources during startup or bark if isnt possible - there is no difference at all from a single instance which loads several drivers talking to different devices this would include an interrupt if there were one - you probably wont find any in LinuxCNC Isn't that presuming that all the hardware devices will be relegated to that singular instance? No. That would be okay if there were multiples of each hardware device, but in cases where there aren't is where my concern lies. In this case what you would do is have the HAL driver in just _one_ instance and cross-link those pins you need into the other instance - problem solved. - Michael Unlike shared memory, interrupts are a bit harder to share, or have concurrent use. Can the separate instances somehow share the IO bus? no, separation is at the HAL driver level as it always was, no new concepts here an example: assume you have 2 parports in a PC: it is exactly the same I/O usage if you do this in a single instance: loadrt hal_parport cfg=0x278 0x378 or do this in instance #1 loadrt hal_parport cfg=0x278 and this in instance #2: loadrt hal_parport cfg=0x378 Remember: instances are ships in the night _except_ if there are cross-linked signals, in which case they can share signal values you're thinking too complicated ;) - Michael I probably am overthinking it, and making it too complicated, but my degree is computer science, and I've always been intrigued by RTOS systems. Now that folks are looking into multiple instances of RTOS running on the same machine, I'm very curious how they get around resources that can't be shared, or how they schedule them so that a lock on the resource by one instance affects the other instance which might need that resource at the same time. Mark -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On Fri, Apr 26, 2013 at 1:47 AM, Michael Haberler mai...@mah.priv.atwrote: Ken, Am 25.04.2013 um 01:11 schrieb Kenneth Lerman kenneth.ler...@se-ltd.com: I'm only addressing this question here: Just noting that the work on RTAPI/HAL has brought with it two capabilities which relate to the theme; most of this has been discussed and done off-list, but since the them comes up I respond to it even if it isnt completely done yet: first, RTAPI is now multi-instance capable (several RTAPI instances on _one_ machine); instances being identified by an integer id (NB this doesnt make NML multi-instance but I hope NML will be history this year in this branch so I dont bother anymore) Michael, Just being curious, how does the multi-instance RTAI keep from banging heads with each other? Lets say we have two instances of RTAI running, how does RTAI keep itself from requiring the same resource as another RTAI instance at the same time, and still maintain the real-time domain of having the resource NOW, when it's needed? Mark -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Mark, Am 26.04.2013 um 11:38 schrieb Mark Wendt wendt.m...@gmail.com: On Fri, Apr 26, 2013 at 1:47 AM, Michael Haberler mai...@mah.priv.atwrote: Ken, Am 25.04.2013 um 01:11 schrieb Kenneth Lerman kenneth.ler...@se-ltd.com: I'm only addressing this question here: Just noting that the work on RTAPI/HAL has brought with it two capabilities which relate to the theme; most of this has been discussed and done off-list, but since the them comes up I respond to it even if it isnt completely done yet: first, RTAPI is now multi-instance capable (several RTAPI instances on _one_ machine); instances being identified by an integer id (NB this doesnt make NML multi-instance but I hope NML will be history this year in this branch so I dont bother anymore) Michael, Just being curious, how does the multi-instance RTAI keep from banging heads with each other? Lets say we have two instances of RTAI running, how does RTAI keep itself from requiring the same resource as another RTAI This multi-instance capability is independent of any specific RTOS and works with all flavors (RTAI, Xenomai any style, RT-PREEMPT) even across flavors; you can have a Xenomai kernel, a few Xenomai user RT instances and a few Posix instances running simultaneously without things going haywire. Not that that makes any sense, I just mention this works too. instance at the same time, resources really translates into threads and shared memory shared memory is an easy case because all shm is allocated at setup time; there is no runtime memory allocation in RTAPI land even if it might be supported as per API description, and it is fact an unnecessary use of a non-portable OS API, which is why I have removed this and replaced by standard Posix shm and a single helper driver for kernel threads just fine, with lots of RTOS-dependent code becoming history in one go. all that was needed to coordinate shared memory is clean up the hodge-podge allocation of shared memory keys here and there, and make an instance id part of the key as for threads, that is quite easy to disambiguate as well and still maintain the real-time domain of having the resource NOW, when it's needed? there is no 'NOW' allocation in allow of LinuxCNC, provided you mean 'NOW' to mean either task or shm allocation 'within a time critical thread'. It is all preallocated before the game starts, and _outside_ of any RT threads, so any fears for collision may be safely put to rest. That case simply doesnt exist, and I cant conceive one were it suddenly might be needed. - Michael Mark -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
This is fantastic, Michael! I am eager to work with this new scheme this summer. It opens up many new avenues that are going to take some time to explore. I don't quite follow your semi-OT statement at the end, but I do think this new code will enable a lot of solutions to long-standing complaints and wishes. Thanks for your hard work. -- Ralph From: Michael Haberler [mai...@mah.priv.at] Sent: Thursday, April 25, 2013 10:47 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] LinuxCNC would be very nice on the UDOO board. Ken, Am 25.04.2013 um 01:11 schrieb Kenneth Lerman kenneth.ler...@se-ltd.com: I'm only addressing this question here: -- How can we distribute HAL (and should we) among multiple components? Just noting that the work on RTAPI/HAL has brought with it two capabilities which relate to the theme; most of this has been discussed and done off-list, but since the them comes up I respond to it even if it isnt completely done yet: first, RTAPI is now multi-instance capable (several RTAPI instances on _one_ machine); instances being identified by an integer id (NB this doesnt make NML multi-instance but I hope NML will be history this year in this branch so I dont bother anymore) this suggested to enable cross-linking of pins between instances, and that is something very close to working; as an example, it will work like so: Assume there is HAL instance #1 (eg started with 'INSTANCE=1 linuxcnc config.ini') Also assume it has signal foo of type bit, so say 'newsig foo bit' executed in #1 in another HAL instance (say #3) you can do this (halcmd script): attach other 1 # make instance #1 accessible under prefix 'other' loadrt or2 net other:foo or2.0.in0 # cross-link signal foo/instance #1 to pin or2.0.in0/instance #3 this will enable instance coordination at the HAL pin level - providing the instances are on the same CPU (shared memory assumption here). Linking will be possible for pins linked to remote signals, and named ring buffers (=queues) between instances. --- second, there will be a new variation of HAL components, called remote components, which address the remote (=non-shared-memory case). This is based on a long discussion I had with JMK and others off-list under the working title 'HAL pipe' to enable linking separate HAL instances over a network link; obvious use cases include multi-spindle setups and remote UI's: A 'remote component' is basically a proxy for another component in a different HAL instance; meaning it has a name, pins with a type etc. It also has additional state - it can be 'bound' (network link up) or unbound (no network link). You can actually define a remote component in halcmd like so (this is from an actual example): # declare a new remote component newcomp gladevcp newpin gladevcp gladevcp.hal_button1 bit in newpin gladevcp gladevcp.hal_label1 float out ready gladevcp # at this stage, the component and its pins exist # and can be linked to net toggle gladevcp.hal_button1 net range gladevcp.hal_label1 # wait until remote is connected, for instance 'reown gladevcp' # is run from a separate window waitbound gladevcp What is not shown here is: a proxy process needs to be started; it will attach to this predefined component, investigate pin names and types, connect to its remote peer, and start exchanging update messages. it will also change the comp state to 'bound' once connection is sucessfully established and pins are linked remotely with proper type checking. --- as I said, this is in an early state so please be patient a bit, but comments welcome anyway. With respect to the original question, I think that both concepts could be helpful; one way the first concept (cross-linking of HAL pins and queues) could come in is to enable complete HAL/RTAPI subsystems which are glued together on the pin+queue level. An example could be say a Soc/FPGA combination like the one Altera is coming out with; assuming the ARM core(s) on-chip are taught to speak HAL to the outside world, such a subsystem can then be integrated at the cross-linking level. It could very well have its own threads, modules etc. We KNOW we will lose the parallel port. We know that PCs will become semi-OT: I am absolutely baffled by the inertia in this community dealing with such issues - the vanishing parport being just one of the more glaring ones. Nothing happening on this front, you'd be able to run LinuxCNC on hardware salvaged from dustbins and yardsales some time down the road, while hoping the RT operating system - an academic one-man show with no community worth speaking of and no tangent to become mainline ever - didnt keel over meanwhile instigated by change of research interests or funding cuts. I simply dont get it - sorry guys, this is reckless driving at the software architecture level. Nevermind how 'ready' the product seems to be. - Michael
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Ralph, Am 26.04.2013 um 15:43 schrieb Ralph Stirling ralph.stirl...@wallawalla.edu: This is fantastic, Michael! I am eager to work with this new scheme this summer. let me manage expectations a bit here. What is currently winding through the buildbot at least partially, and sucessfully has been built and used are the rtos-integration-preview3 (v2.5_branch based) and rtos-integration-preview3-merged-into-master (master based). This is +/- some minor cleanups the codebase as we have it since late November, and provides the capability to build and run on all of the RT Linux variants; one build per variant, and stable. based on that John and me have worked on the unified binary branch, which is feature complete but not ready for downloading and building since some build work remains to be done. This code base will run unchanged on several RT Linux variants, and adapt as needed by investigating the environment. It has - basically as a side effect of going over the code - the multi-instance capability. However, it does not have the instance cross-linking capability I outlined; that I am still working on. The remote HAL components support code is ready and benign in nature, so I will likely include that once that branch matures; the crosslinking feature required some new RTAPI functionality, including a unified approach to managing shared memory, which is new. I therefore look at having this unified branch ready for test say end of May; however, it will bring few new features per se. It should, however, eventually simplify build and upgrade logistics significantly. There will be a set of features at the HAL/RTAPI level in a sequel branch which includes all the support for doing the 'realtime split' - separating the backend from any UI, interp, task etc blobs. I am looking at fall for this; I would think it has some NML-to-zeroMQ/Protobuf migration started but likely not complete; this is a lot of work. Plus, the namespace crosslinking feature requires some heavy lifting and careful sequencing of operation, so I wont rush that until I am sure it is reasonably bullet-proof. In summary, one could expect the HAL plumbing for HAL pipes (remote components) in place early this summer, including an example HAL pipe; I wont commit anything further out yet until it's safe ground. Meaning: realistically one could play with remote HAL links between machines this summer, provided it's a sufficiently rainy summer ;) - Michael It opens up many new avenues that are going to take some time to explore. I don't quite follow your semi-OT statement at the end, but I do think this new code will enable a lot of solutions to long-standing complaints and wishes. Thanks for your hard work. -- Ralph From: Michael Haberler [mai...@mah.priv.at] Sent: Thursday, April 25, 2013 10:47 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] LinuxCNC would be very nice on the UDOO board. Ken, Am 25.04.2013 um 01:11 schrieb Kenneth Lerman kenneth.ler...@se-ltd.com: I'm only addressing this question here: -- How can we distribute HAL (and should we) among multiple components? Just noting that the work on RTAPI/HAL has brought with it two capabilities which relate to the theme; most of this has been discussed and done off-list, but since the them comes up I respond to it even if it isnt completely done yet: first, RTAPI is now multi-instance capable (several RTAPI instances on _one_ machine); instances being identified by an integer id (NB this doesnt make NML multi-instance but I hope NML will be history this year in this branch so I dont bother anymore) this suggested to enable cross-linking of pins between instances, and that is something very close to working; as an example, it will work like so: Assume there is HAL instance #1 (eg started with 'INSTANCE=1 linuxcnc config.ini') Also assume it has signal foo of type bit, so say 'newsig foo bit' executed in #1 in another HAL instance (say #3) you can do this (halcmd script): attach other 1 # make instance #1 accessible under prefix 'other' loadrt or2 net other:foo or2.0.in0 # cross-link signal foo/instance #1 to pin or2.0.in0/instance #3 this will enable instance coordination at the HAL pin level - providing the instances are on the same CPU (shared memory assumption here). Linking will be possible for pins linked to remote signals, and named ring buffers (=queues) between instances. --- second, there will be a new variation of HAL components, called remote components, which address the remote (=non-shared-memory case). This is based on a long discussion I had with JMK and others off-list under the working title 'HAL pipe' to enable linking separate HAL instances over a network link; obvious use cases include multi-spindle setups and remote UI's: A 'remote component' is basically a proxy for another
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On Fri, Apr 26, 2013 at 9:03 AM, Michael Haberler mai...@mah.priv.atwrote: Mark, Just being curious, how does the multi-instance RTAI keep from banging heads with each other? Lets say we have two instances of RTAI running, how does RTAI keep itself from requiring the same resource as another RTAI This multi-instance capability is independent of any specific RTOS and works with all flavors (RTAI, Xenomai any style, RT-PREEMPT) even across flavors; you can have a Xenomai kernel, a few Xenomai user RT instances and a few Posix instances running simultaneously without things going haywire. Not that that makes any sense, I just mention this works too. instance at the same time, resources really translates into threads and shared memory shared memory is an easy case because all shm is allocated at setup time; there is no runtime memory allocation in RTAPI land even if it might be supported as per API description, and it is fact an unnecessary use of a non-portable OS API, which is why I have removed this and replaced by standard Posix shm and a single helper driver for kernel threads just fine, with lots of RTOS-dependent code becoming history in one go. all that was needed to coordinate shared memory is clean up the hodge-podge allocation of shared memory keys here and there, and make an instance id part of the key as for threads, that is quite easy to disambiguate as well and still maintain the real-time domain of having the resource NOW, when it's needed? there is no 'NOW' allocation in allow of LinuxCNC, provided you mean 'NOW' to mean either task or shm allocation 'within a time critical thread'. It is all preallocated before the game starts, and _outside_ of any RT threads, so any fears for collision may be safely put to rest. That case simply doesnt exist, and I cant conceive one were it suddenly might be needed. - Michael Michael, I was thinking more of hardware resources, such as interrupts. What happens when both instances require the same interrupt at the same time? Unlike shared memory, interrupts are a bit harder to share, or have concurrent use. Can the separate instances somehow share the IO bus? Or is there some kind of real time scheduler that looks ahead for all possible conflicts, and works it out? Mark -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Mark Wendt wrote: I was thinking more of hardware resources, such as interrupts. What happens when both instances require the same interrupt at the same time? Unlike shared memory, interrupts are a bit harder to share, or have concurrent use. Can the separate instances somehow share the IO bus? Or is there some kind of real time scheduler that looks ahead for all possible conflicts, and works it out? This has always been a big problem on the PC platform, ie. the extreme shortage of interrupt vectors. This is mostly due to an interrupt architecture that assigns specific bus wires for a single interrupt. Some other platforms, such as the ARM, have interrupt requests that provide a bit field to specify the vector address (like the PDP-11) where hundreds of vectors can be available. Just another annoyance on the PC platform. At least on RTAI, there were some problems in having regularly scheduled threads running from interrupt lines instead of the timer. I hope Xenomai or prempt can be more flexible. On my interface boards, they can sample encoder position and then request an interrupt through the parallel port, which would reduce the effect of task latency on position sampling to zero, as long as the thread completed before the next interrupt. Jon -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
--- On Fri, 4/26/13, Mark Wendt wendt.m...@gmail.com wrote: Michael, I was thinking more of hardware resources, such as interrupts. What happens when both instances require the same interrupt at the same time? Unlike shared memory, interrupts are a bit harder to share, or have concurrent use. Can the separate instances somehow share the IO bus? Or is there some kind of real time scheduler that looks ahead for all possible conflicts, and works it out? There would have to be a scheduler or process manager or some way for processes to communicate with one another. Just letting things roll along independently leads to disasters like the Therac 25. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Mark, I was thinking more of hardware resources, such as interrupts. What happens when both instances require the same interrupt at the same time? Any instance usually will have a HAL driver to talk to the outside world exactly like the single instance which we have now, and that driver will attach to a hardware device and will be responsible to allocate all required resources during startup or bark if isnt possible - there is no difference at all from a single instance which loads several drivers talking to different devices this would include an interrupt if there were one - you probably wont find any in LinuxCNC Unlike shared memory, interrupts are a bit harder to share, or have concurrent use. Can the separate instances somehow share the IO bus? no, separation is at the HAL driver level as it always was, no new concepts here an example: assume you have 2 parports in a PC: it is exactly the same I/O usage if you do this in a single instance: loadrt hal_parport cfg=0x278 0x378 or do this in instance #1 loadrt hal_parport cfg=0x278 and this in instance #2: loadrt hal_parport cfg=0x378 Remember: instances are ships in the night _except_ if there are cross-linked signals, in which case they can share signal values you're thinking too complicated ;) - Michael Or is there some kind of real time scheduler that looks ahead for all possible conflicts, and works it out? Mark -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Greg - Am 26.04.2013 um 22:47 schrieb Gregg Eshelman g_ala...@yahoo.com: --- On Fri, 4/26/13, Mark Wendt wendt.m...@gmail.com wrote: Michael, I was thinking more of hardware resources, such as interrupts. What happens when both instances require the same interrupt at the same time? Unlike shared memory, interrupts are a bit harder to share, or have concurrent use. Can the separate instances somehow share the IO bus? Or is there some kind of real time scheduler that looks ahead for all possible conflicts, and works it out? There would have to be a scheduler or process manager or some way for processes to communicate with one another. Just letting things roll along independently leads to disasters like the Therac 25. since instances do not share devices and their respective HAL drivers, there is no need for any such scheme - Michael -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On Fri, 2013-04-26 at 11:53 -0500, Jon Elson wrote: Mark Wendt wrote: I was thinking more of hardware resources, such as interrupts. What happens when both instances require the same interrupt at the same time? Unlike shared memory, interrupts are a bit harder to share, or have concurrent use. Can the separate instances somehow share the IO bus? Or is there some kind of real time scheduler that looks ahead for all possible conflicts, and works it out? This has always been a big problem on the PC platform, ie. the extreme shortage of interrupt vectors. This is mostly due to an interrupt architecture that assigns specific bus wires for a single interrupt. Some other platforms, such as the ARM, have interrupt requests that provide a bit field to specify the vector address (like the PDP-11) where hundreds of vectors can be available. Just another annoyance on the PC platform. At least on RTAI, there were some problems in having regularly scheduled threads running from interrupt lines instead of the timer. I hope Xenomai or prempt can be more flexible. On my interface boards, they can sample encoder position and then request an interrupt through the parallel port, which would reduce the effect of task latency on position sampling to zero, as long as the thread completed before the next interrupt. Jon Indeed the pdp-11 did handle interrupts nicely including a cute but rigid priority structure. (daisy-chained down the buss) so you put your highest priority device closest to the cpu. Too bad Intel didn't have better foresight. D -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On Wed, 24 Apr 2013 15:14:51 +0100 andy pugh bodge...@gmail.com wrote: Personally I don't see any real incentive to stop using generic PCs. The incentives are: 1. Cost cutting - $25-$45 total for the host computer. Compare this to a MiniITX board + RAM +CPU (if not soldered on) + power supply + case. When the Beagle Board was $150, this was not an issue, but the low cost of these new boards is revolutionary. 2. Size reduction - This ripples through the control design and allows for smaller enclosures. From my perspective, this is a big deal :) 3. Power reduction - This is not so big a deal as the wattage reduction over an energy efficient PC isn't that big compared to the total power input to the typical machine, but it does allow for a cost and size reduction of the power supply (ATX style can be replaced by a single voltage supply which is smaller, and avoids the cost of using a PicoPSU). Thanks, Matt -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Exactly! I have an application which will be using eight 3 or 4 axis pick and place heads in a one square meter area, which will require eight LinuxCNC controllers. Beagle Board Black's would make this vastly cheaper and more space efficient. -- Ralph From: Matt Shaver [m...@mattshaver.com] Sent: Thursday, April 25, 2013 9:12 AM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] LinuxCNC would be very nice on the UDOO board. On Wed, 24 Apr 2013 15:14:51 +0100 andy pugh bodge...@gmail.com wrote: Personally I don't see any real incentive to stop using generic PCs. The incentives are: 1. Cost cutting - $25-$45 total for the host computer. Compare this to a MiniITX board + RAM +CPU (if not soldered on) + power supply + case. When the Beagle Board was $150, this was not an issue, but the low cost of these new boards is revolutionary. 2. Size reduction - This ripples through the control design and allows for smaller enclosures. From my perspective, this is a big deal :) 3. Power reduction - This is not so big a deal as the wattage reduction over an energy efficient PC isn't that big compared to the total power input to the typical machine, but it does allow for a cost and size reduction of the power supply (ATX style can be replaced by a single voltage supply which is smaller, and avoids the cost of using a PicoPSU). Thanks, Matt -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Ken, Am 25.04.2013 um 01:11 schrieb Kenneth Lerman kenneth.ler...@se-ltd.com: I'm only addressing this question here: -- How can we distribute HAL (and should we) among multiple components? Just noting that the work on RTAPI/HAL has brought with it two capabilities which relate to the theme; most of this has been discussed and done off-list, but since the them comes up I respond to it even if it isnt completely done yet: first, RTAPI is now multi-instance capable (several RTAPI instances on _one_ machine); instances being identified by an integer id (NB this doesnt make NML multi-instance but I hope NML will be history this year in this branch so I dont bother anymore) this suggested to enable cross-linking of pins between instances, and that is something very close to working; as an example, it will work like so: Assume there is HAL instance #1 (eg started with 'INSTANCE=1 linuxcnc config.ini') Also assume it has signal foo of type bit, so say 'newsig foo bit' executed in #1 in another HAL instance (say #3) you can do this (halcmd script): attach other 1 # make instance #1 accessible under prefix 'other' loadrt or2 net other:foo or2.0.in0 # cross-link signal foo/instance #1 to pin or2.0.in0/instance #3 this will enable instance coordination at the HAL pin level - providing the instances are on the same CPU (shared memory assumption here). Linking will be possible for pins linked to remote signals, and named ring buffers (=queues) between instances. --- second, there will be a new variation of HAL components, called remote components, which address the remote (=non-shared-memory case). This is based on a long discussion I had with JMK and others off-list under the working title 'HAL pipe' to enable linking separate HAL instances over a network link; obvious use cases include multi-spindle setups and remote UI's: A 'remote component' is basically a proxy for another component in a different HAL instance; meaning it has a name, pins with a type etc. It also has additional state - it can be 'bound' (network link up) or unbound (no network link). You can actually define a remote component in halcmd like so (this is from an actual example): # declare a new remote component newcomp gladevcp newpin gladevcp gladevcp.hal_button1 bit in newpin gladevcp gladevcp.hal_label1 float out ready gladevcp # at this stage, the component and its pins exist # and can be linked to net toggle gladevcp.hal_button1 net range gladevcp.hal_label1 # wait until remote is connected, for instance 'reown gladevcp' # is run from a separate window waitbound gladevcp What is not shown here is: a proxy process needs to be started; it will attach to this predefined component, investigate pin names and types, connect to its remote peer, and start exchanging update messages. it will also change the comp state to 'bound' once connection is sucessfully established and pins are linked remotely with proper type checking. --- as I said, this is in an early state so please be patient a bit, but comments welcome anyway. With respect to the original question, I think that both concepts could be helpful; one way the first concept (cross-linking of HAL pins and queues) could come in is to enable complete HAL/RTAPI subsystems which are glued together on the pin+queue level. An example could be say a Soc/FPGA combination like the one Altera is coming out with; assuming the ARM core(s) on-chip are taught to speak HAL to the outside world, such a subsystem can then be integrated at the cross-linking level. It could very well have its own threads, modules etc. We KNOW we will lose the parallel port. We know that PCs will become semi-OT: I am absolutely baffled by the inertia in this community dealing with such issues - the vanishing parport being just one of the more glaring ones. Nothing happening on this front, you'd be able to run LinuxCNC on hardware salvaged from dustbins and yardsales some time down the road, while hoping the RT operating system - an academic one-man show with no community worth speaking of and no tangent to become mainline ever - didnt keel over meanwhile instigated by change of research interests or funding cuts. I simply dont get it - sorry guys, this is reckless driving at the software architecture level. Nevermind how 'ready' the product seems to be. - Michael less deterministic when it comes to real-time operation. (Modern office machines MUST play games with their clock speed to use power efficiently.) -- Does our future architecture include a PC? Ken On 4/23/2013 11:03 AM, Charles Steinkuehler wrote: On 4/22/2013 11:40 AM, Matt Shaver wrote: On Sun, 21 Apr 2013 19:30:23 +0200 Michael Haberler mai...@mah.priv.at wrote: We'll have a ready-to-go SD card image with xenomai, all prerequisite packages and linuxcnc installed in a week or two; that will include Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
BeBoPr board comments in-line below. -Original Message- From: Charles Steinkuehler [mailto:char...@steinkuehler.net] Sent: Tuesday, April 23, 2013 11:04 AM To: Enhanced Machine Controller (EMC) Cc: Matt Shaver Subject: Re: [Emc-users] LinuxCNC would be very nice on the UDOO board. On 4/22/2013 11:40 AM, Matt Shaver wrote: On Sun, 21 Apr 2013 19:30:23 +0200 Michael Haberler mai...@mah.priv.at wrote: We'll have a ready-to-go SD card image with xenomai, all prerequisite packages and linuxcnc installed in a week or two; that will include Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should reduce the guru requirements to get things going So, I'm ordering a new Beagle Bone Black this morning I was wondering what you guys are doing for a field I/O interface for this computer. Is there a cape I should get? Or are we at the perfboard and wire-wrap wire stage? :) The BeBoPr board is available now and has support for both the Pololu drivers common in the 3D printer world and a header to drive out-board stepper drivers with a more oomph. From the BeBoPr maunal: J5 - all stepper signals are present on this connector. It connects directly to the 15 pin sub-D connector of a TB6560-4V5 3A stepper driver board sold on e-Bay. The BeBoPr board looks interesting, but it seems like it is not currently possible to purchase one. The following claim to sell it but have no stock: element14/Newark/Farnel Mouser Digikey BoardZoo Digikey states that their stocking order is overdue for delivery. Also I wonder about pinout usage and other documentation. Where is the BeBoPr manual that Charles mentioned? I could not find any info about their assignments of the Beaglebone pins. Perhaps one has to read the code to figure that out. There's also the Replicape, but AFAIK it's on-board stepper driver only (Pololu class, but using TI driver chips). There's nothing I'm aware of yet that works for analog servos, but it should be possible, at least for a few channels (the CPU has 3 hardware encoder inputs, and the PRU could support more in software at lower pulse rates). -- Charles Steinkuehler char...@steinkuehler.net -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On 4/24/2013 8:19 AM, Steve Stallings wrote: BeBoPr board comments in-line below. -Original Message- From: Charles Steinkuehler [mailto:char...@steinkuehler.net] Sent: Tuesday, April 23, 2013 11:04 AM snip The BeBoPr board is available now and has support for both the Pololu drivers common in the 3D printer world and a header to drive out-board stepper drivers with a more oomph. From the BeBoPr maunal: J5 - all stepper signals are present on this connector. It connects directly to the 15 pin sub-D connector of a TB6560-4V5 3A stepper driver board sold on e-Bay. The BeBoPr board looks interesting, but it seems like it is not currently possible to purchase one. The following claim to sell it but have no stock: element14/Newark/Farnel Mouser Digikey BoardZoo Digikey states that their stocking order is overdue for delivery. I got mine directly from Bas Laarhoven b...@laarhoven.org, you might contact him directly and see if he has any on-hand, or if he knows of a good place to buy one. Also I wonder about pinout usage and other documentation. Where is the BeBoPr manual that Charles mentioned? I could not find any info about their assignments of the Beaglebone pins. Perhaps one has to read the code to figure that out. The manual came with the board. I'm not sure I'm allowed to share it, since it's not online anywhere I can find. I have, however, pieced together most of the I/O assignments from a combination of the manual, tracing signals on the board, and examining the software in the git repository. Give me a bit and I'll commit my changes to Michael's repo. ...OK, changes are in the arm335x-hal-pru-module branch, as comments at the bottom of the stepgen.p file: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=configs/pru-examples/stepgen.p;h=d6292075abca1cd687dbb4b47cd1ad748b1521d6;hb=fde5606226ba14d0b033ba6b2310d2c58a296284#l506 This is still a work in-progress, but most of the main pins are there. -- Charles Steinkuehler char...@steinkuehler.net -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On 19 April 2013 10:17, Michael Haberler mai...@mah.priv.at wrote: - Xenomai: you drew a lucky punch: the i.MX6 by Freescale is supported by Xenomai I wonder if this one is which I just found looking for something else? http://www.adafruit.com/products/278 Claims to have a lot of GPIO + quadrature counters. Personally I don't see any real incentive to stop using generic PCs. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On Wed, 24 Apr 2013 09:19:20 -0400 Steve Stallings steve...@newsguy.com wrote: The BeBoPr board looks interesting, but it seems like it is not currently possible to purchase one. This is what it looks like to me. I didn't do an exhaustive search, but I couldn't buy one to take to Wichita. Also I wonder about pinout usage and other documentation. Where is the BeBoPr manual that Charles mentioned? Near as I can tell, the available data is here: https://github.com/modmaker/BeBoPr/wiki and http://circuitco.com/support/index.php?title=BeBoPr_Cape I could not find any info about their assignments of the Beaglebone pins. Perhaps one has to read the code Which is here: https://github.com/modmaker/BeBoPr Thanks, Matt -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
The Beagle Bones are so cheap, that we shouldn't be worrying about how many pins we can drive. Just connect a few together using etherCAT or real time ethernet, or whatever the thing supported by the hardware is called. As far as I'm concerned, the problem of no parallel port has been solved with these devices and an ethernet. Sure we need a driver, but that isn't rocket science. We do have some significant open questions for the next few decades though. -- How will are functionality be divided among hardware units? -- How many (and what) platforms will we support? -- How can we distribute HAL (and should we) among multiple components? We KNOW we will lose the parallel port. We know that PCs will become less deterministic when it comes to real-time operation. (Modern office machines MUST play games with their clock speed to use power efficiently.) -- Does our future architecture include a PC? Ken On 4/23/2013 11:03 AM, Charles Steinkuehler wrote: On 4/22/2013 11:40 AM, Matt Shaver wrote: On Sun, 21 Apr 2013 19:30:23 +0200 Michael Haberler mai...@mah.priv.at wrote: We'll have a ready-to-go SD card image with xenomai, all prerequisite packages and linuxcnc installed in a week or two; that will include Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should reduce the guru requirements to get things going So, I'm ordering a new Beagle Bone Black this morning I was wondering what you guys are doing for a field I/O interface for this computer. Is there a cape I should get? Or are we at the perfboard and wire-wrap wire stage? :) The BeBoPr board is available now and has support for both the Pololu drivers common in the 3D printer world and a header to drive out-board stepper drivers with a more oomph. From the BeBoPr maunal: J5 – all stepper signals are present on this connector. It connects directly to the 15 pin sub-D connector of a TB6560-4V5 3A stepper driver board sold on e-Bay. There's also the Replicape, but AFAIK it's on-board stepper driver only (Pololu class, but using TI driver chips). There's nothing I'm aware of yet that works for analog servos, but it should be possible, at least for a few channels (the CPU has 3 hardware encoder inputs, and the PRU could support more in software at lower pulse rates). -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Am 24.04.2013 um 16:14 schrieb andy pugh bodge...@gmail.com: Personally I don't see any real incentive to stop using generic PCs. Then the intent of this effort wasnt to entice you to stop using generic PC's it was to end being forced to use generic PC's - and an operating system with some question marks on its future - _exclusively_ -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On 4/22/2013 11:40 AM, Matt Shaver wrote: On Sun, 21 Apr 2013 19:30:23 +0200 Michael Haberler mai...@mah.priv.at wrote: We'll have a ready-to-go SD card image with xenomai, all prerequisite packages and linuxcnc installed in a week or two; that will include Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should reduce the guru requirements to get things going So, I'm ordering a new Beagle Bone Black this morning I was wondering what you guys are doing for a field I/O interface for this computer. Is there a cape I should get? Or are we at the perfboard and wire-wrap wire stage? :) The BeBoPr board is available now and has support for both the Pololu drivers common in the 3D printer world and a header to drive out-board stepper drivers with a more oomph. From the BeBoPr maunal: J5 – all stepper signals are present on this connector. It connects directly to the 15 pin sub-D connector of a TB6560-4V5 3A stepper driver board sold on e-Bay. There's also the Replicape, but AFAIK it's on-board stepper driver only (Pololu class, but using TI driver chips). There's nothing I'm aware of yet that works for analog servos, but it should be possible, at least for a few channels (the CPU has 3 hardware encoder inputs, and the PRU could support more in software at lower pulse rates). -- Charles Steinkuehler char...@steinkuehler.net -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Matt Shaver wrote: On Mon, 22 Apr 2013 21:19:19 -0500 Jon Elson el...@pico-systems.com wrote: I sent one of these EPP emulator/converters to Dale Grover, I think it ended up with Matt Shaver. Nope, I think Dale's still got it. I was discouraged by the lack of RTAI for ARM, but that seems to be a non-issue with Xenomai available, plus all the breakthroughs in running things in user space. Well, if anyone wants one of these, I could make some more. But, it is Beagle Board (not Bone) only. I'm getting fairly serious about getting either a Pi or a Bone Black, but am waiting to see which way people go with this. Jon -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On Sun, 21 Apr 2013 19:30:23 +0200 Michael Haberler mai...@mah.priv.at wrote: We'll have a ready-to-go SD card image with xenomai, all prerequisite packages and linuxcnc installed in a week or two; that will include Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should reduce the guru requirements to get things going So, I'm ordering a new Beagle Bone Black this morning I was wondering what you guys are doing for a field I/O interface for this computer. Is there a cape I should get? Or are we at the perfboard and wire-wrap wire stage? :) Thanks, Matt -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Am 22.04.2013 um 18:40 schrieb Matt Shaver m...@mattshaver.com: On Sun, 21 Apr 2013 19:30:23 +0200 Michael Haberler mai...@mah.priv.at wrote: We'll have a ready-to-go SD card image with xenomai, all prerequisite packages and linuxcnc installed in a week or two; that will include Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should reduce the guru requirements to get things going So, I'm ordering a new Beagle Bone Black this morning I was wondering what you guys are doing for a field I/O interface for this computer. Is there a cape I should get? Or are we at the perfboard and wire-wrap wire stage? :) yikes.. sore spot. Peter! get that layout editor fired up and get us a decent cape for the bone, not that toy stuff from Adafruit ;) For steppers maybe Bas' https://github.com/modmaker/BeBoPr/wiki/The-BeBoPr-Cape - Michael Thanks, Matt -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
--- On Mon, 4/22/13, Matt Shaver m...@mattshaver.com wrote: So, I'm ordering a new Beagle Bone Black this morning I was wondering what you guys are doing for a field I/O interface for this computer. Is there a cape I should get? Or are we at the perfboard and wire-wrap wire stage? :) Just sit right back and wait for a BOB to plug the BBB (BeagleBone Black) into... Combined with a ready to go bootable LinuxCNC SD card image and CNC would be (should be) much easier to put together. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Haven't heard from Jon Elson here as to his progress with the Beagle. He's had a solution for a parallel port worked out in anticipation of a real time kernel. +++ Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist. -Kenneth Boulding, economist “How unfortunate that the Earth’s first intelligent social animal is a tribal carnivore” -E.O. Wilson, sociobiologist From: Matt Shaver m...@mattshaver.com To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Monday, April 22, 2013 11:40 AM Subject: Re: [Emc-users] LinuxCNC would be very nice on the UDOO board. On Sun, 21 Apr 2013 19:30:23 +0200 Michael Haberler mai...@mah.priv.at wrote: We'll have a ready-to-go SD card image with xenomai, all prerequisite packages and linuxcnc installed in a week or two; that will include Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should reduce the guru requirements to get things going So, I'm ordering a new Beagle Bone Black this morning I was wondering what you guys are doing for a field I/O interface for this computer. Is there a cape I should get? Or are we at the perfboard and wire-wrap wire stage? :) Thanks, Matt -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On Monday 22 April 2013 22:15:54 Michael Haberler did opine: Am 22.04.2013 um 18:40 schrieb Matt Shaver m...@mattshaver.com: On Sun, 21 Apr 2013 19:30:23 +0200 Michael Haberler mai...@mah.priv.at wrote: We'll have a ready-to-go SD card image with xenomai, all prerequisite packages and linuxcnc installed in a week or two; that will include Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should reduce the guru requirements to get things going So, I'm ordering a new Beagle Bone Black this morning I was wondering what you guys are doing for a field I/O interface for this computer. Is there a cape I should get? Or are we at the perfboard and wire-wrap wire stage? :) yikes.. sore spot. Peter! get that layout editor fired up and get us a decent cape for the bone, not that toy stuff from Adafruit ;) For steppers maybe Bas' https://github.com/modmaker/BeBoPr/wiki/The-BeBoPr-Cape - Michael I'm glad you said maybe. As a breakout/i/o board, it looks great, but those polulu stepper stamps aren't big enough to run anything I have at usable speeds. Has anyone seen a price quote? Its not on the site. More, obviously, than the BeBo itself, but compact enough to make one overlook some of that. Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) My web page: http://coyoteden.dyndns-free.com:85/gene is up! My views http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml Windows 2000: Designed for the Internet. The Internet: Designed for UNIX. -- From a Slashdot.org post A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Greg Bernard wrote: Haven't heard from Jon Elson here as to his progress with the Beagle. He's had a solution for a parallel port worked out in anticipation of a real time kernel. I prototyped an EPP parallel port emulator and got it running far enough to run simple test programs to one of my EPP-interfaced controller boards. That was in 2009. I sent a Beagle Board at my expense to Torsten Koschorrek of RTAI, and he has been picking at it, but as far as I know there is STILL not a fully-functional RTAI patch for the Beagle's CPU family. I sent one of these EPP emulator/converters to Dale Grover, I think it ended up with Matt Shaver. I have a couple more I could make up, but it is for the original Beagle Board, not the Bone. Jon -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On Mon, 22 Apr 2013 21:19:19 -0500 Jon Elson el...@pico-systems.com wrote: I sent one of these EPP emulator/converters to Dale Grover, I think it ended up with Matt Shaver. Nope, I think Dale's still got it. I was discouraged by the lack of RTAI for ARM, but that seems to be a non-issue with Xenomai available, plus all the breakthroughs in running things in user space. Thanks, Matt -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Michael, Kent, thanks for your help! It's a pity that I'm not quite a Linux guy. But when the black BeagleBone appears I'll hopefully try to figure it out. I'd use it for Yaskawa servo drives with both step/dir and analog control. I suppose it's easier to get step/dir control, that would be enough for starters. But further, there must be some DAC modules to use with BeagleBone for analog control? Andrew -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Am 21.04.2013 um 17:19 schrieb Andrew parallel.kinemat...@gmail.com: Michael, Kent, thanks for your help! It's a pity that I'm not quite a Linux guy. But when the black BeagleBone appears I'll hopefully try to figure it out. We'll have a ready-to-go SD card image with xenomai, all prerequisite packages and linuxcnc installed in a week or two; that will include Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should reduce the guru requirements to get things going I'd use it for Yaskawa servo drives with both step/dir and analog control. I suppose it's easier to get step/dir control, that would be enough for starters. most of the work on that platform concentrated on steppers so far because being on the low end this looked like the likely use case But further, there must be some DAC modules to use with BeagleBone for analog control? DAC really boils down to PWM output again the linuxcnc stock components like pwmgen are included, and for servo their speed should be sufficient we already discussed quadrature encoders - that might need a bit of work to get polished for high ppr rates; the hardware is included, it 'just needs to be talked to' ;) - Michael Andrew -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
2013/4/21 Michael Haberler mai...@mah.priv.at Am 21.04.2013 um 17:19 schrieb Andrew parallel.kinemat...@gmail.com: Michael, Kent, thanks for your help! It's a pity that I'm not quite a Linux guy. But when the black BeagleBone appears I'll hopefully try to figure it out. We'll have a ready-to-go SD card image with xenomai, all prerequisite packages and linuxcnc installed in a week or two; that will include Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should reduce the guru requirements to get things going That is absolutely great! most of the work on that platform concentrated on steppers so far because being on the low end this looked like the likely use case Sure, this is one point. And another point is low latency (you say 200kHz step rate) could help increase servo frequency to say 10KHz. Or ARM CPU is not enough for that servo frequency? Though, 4-core 2GHz ARMs already released... DAC really boils down to PWM output Sure, PWM output just needs a simple +-10V converter. again the linuxcnc stock components like pwmgen are included, and for servo their speed should be sufficient Again, how do you estimate max servo frequency for ARM platform, precisely BeagleBone? And what if some weird kinematics like Stewart platform should be computed? Andrew -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Am 21.04.2013 um 20:04 schrieb Andrew parallel.kinemat...@gmail.com: 2013/4/21 Michael Haberler mai...@mah.priv.at Am 21.04.2013 um 17:19 schrieb Andrew parallel.kinemat...@gmail.com: Michael, Kent, thanks for your help! It's a pity that I'm not quite a Linux guy. But when the black BeagleBone appears I'll hopefully try to figure it out. We'll have a ready-to-go SD card image with xenomai, all prerequisite packages and linuxcnc installed in a week or two; that will include Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should reduce the guru requirements to get things going That is absolutely great! most of the work on that platform concentrated on steppers so far because being on the low end this looked like the likely use case Sure, this is one point. And another point is low latency yes (you say 200kHz step rate) yes, but that has nothing to do with each other in case of the PRU: latency is the jitter introduced by the host operating system - xenomai in that case the step rate is determined by the clock frequency of the PRU (200Mhz) and the code path execution time between 'stepgen cycles' _in the PRU_; the PRU stepper jitter is likely negligible because the PRU lacks a cache or other bells and whistles like virtual memory which make timing less deterministic. The techref manual actually says 'Cache: none (intentionally)' meaning: low jitter was more important than more MIPS during design. conceptually that is exactly the same as say a Mesanet card clock and its jitter (not relevant) has anything to do with Linux thread jitter (relevant) could help increase servo frequency to say 10KHz. You can try, but these are unrelated concepts. What will be limiting here is the code path execution time of all the components executed in a servo cycle. Halcmd gives you timings for those - go measure ;) Actually publishing results on the wiki would be a great idea. Or ARM CPU is not enough for that servo frequency? Though, 4-core 2GHz ARMs already released... This could help with floating point 'umph', but not necessarily with Linux thread jitter. We'll see. DAC really boils down to PWM output Sure, PWM output just needs a simple +-10V converter. again the linuxcnc stock components like pwmgen are included, and for servo their speed should be sufficient Again, how do you estimate max servo frequency for ARM platform, precisely BeagleBone? And what if some weird kinematics like Stewart platform should be computed? As above: go measure, everthing else is sorta-kinda and conjecture. It's all there - set it up, read the halcmd manual, take timings, make sense of them. Then you'll know if the platform is good enough for the purpose or not. That in fact could be determined without actually driving any hardware with a sim-like config; that wont give you timings for the hardware I/O times but I'm fairly sure those dont break the camel's back. Motion, Pid maybe; a high-rate base thread causes overhead; eg when using software encoders. - Michael -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
2013/4/21 Michael Haberler mai...@mah.priv.athttps://mail.google.com/mail/u/0/?view=cmfs=1tf=1to=mai...@mah.priv.at Sure, this is one point. And another point is low latency yes (you say 200kHz step rate) yes, but that has nothing to do with each other in case of the PRU: latency is the jitter introduced by the host operating system - xenomai in that case the step rate is determined by the clock frequency of the PRU (200Mhz) and the code path execution time between 'stepgen cycles' _in the PRU_; the PRU stepper jitter is likely negligible because the PRU lacks a cache or other bells and whistles like virtual memory which make timing less deterministic. The techref manual actually says 'Cache: none (intentionally)' meaning: low jitter was more important than more MIPS during design. conceptually that is exactly the same as say a Mesanet card clock and its jitter (not relevant) has anything to do with Linux thread jitter (relevant) could help increase servo frequency to say 10KHz. You can try, but these are unrelated concepts. What will be limiting here is the code path execution time of all the components executed in a servo cycle. That's exactly what I meant. A lot of calculations for CPU during a servo cycle: trajectory, kinematics, PID etc. But I did not figure out that it also has PRU so it's just like PC and MESA card on one board. And I thought that ARM Linux jitter is negligible, but it's proved not. Negligible is RPU's jitter. Or ARM CPU is not enough for that servo frequency? Though, 4-core 2GHz ARMs already released... This could help with floating point 'umph', but not necessarily with Linux thread jitter. Absolutely. Could rather make it worse with powersaving features. Again, how do you estimate max servo frequency for ARM platform, precisely BeagleBone? And what if some weird kinematics like Stewart platform should be computed? As above: go measure, everthing else is sorta-kinda and conjecture. It's all there - set it up, read the halcmd manual, take timings, make sense of them. Then you'll know if the platform is good enough for the purpose or not. That in fact could be determined without actually driving any hardware with a sim-like config; that wont give you timings for the hardware I/O times but I'm fairly sure those dont break the camel's back. Motion, Pid maybe; a high-rate base thread causes overhead; eg when using software encoders. I'll definitely try that when I get hold of the board and install LinuxCNC. Andrew -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Andrew, Am 19.04.2013 um 07:10 schrieb Andrew parallel.kinemat...@gmail.com: 2013/4/19 Przemek Klosowski przemek.klosow...@gmail.com On Fri, Apr 19, 2013 at 12:26 AM, Gregg Eshelman g_ala...@yahoo.com wrote: The UDOO is a single board computer with a 1ghz quad core CPU plus an Arduino DUE. Same CPU as the Raspberry Pi but with 4 cores. Runs Linux and Android. http://www.kickstarter.com/projects/435742530/udoo-android-linux-arduino-in-a-tiny-single-board Cool design, thanks for pointing it out---but LinuxCNC currently requires a modified kernel with RTAI-style realtime functionality. People, including some on this list, are interested in porting RTAI to ARM; the most often mentioned target board is the Beagleboard (maybe even Beaglebone), but AFAIK nobody succeeded yet. I recently run into http://www.youtube.com/watch?v=YSnNtgZrfyU LCNC 2.5 is ported to ARM with Xenomai The capability to run on ARM boards has been in a linuxcnc.org development branch since late last year, among them Raspberry Pi and the Beaglebone, both in a v2.5_branch based and master-based branch please see the emc-developers archive for details the link you give above was a one-off effort which never made it back into linuxcnc and is not a recommended base to start on - Michael -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Gregg - Am 19.04.2013 um 06:26 schrieb Gregg Eshelman g_ala...@yahoo.com: The UDOO is a single board computer with a 1ghz quad core CPU plus an Arduino DUE. Same CPU as the Raspberry Pi but with 4 cores. Runs Linux and Android. http://www.kickstarter.com/projects/435742530/udoo-android-linux-arduino-in-a-tiny-single-board Note the much saner port arrangement than what's on the RasPi with its ports on all sides and sticking out at apparently random distances. Except for power input and Micro SD slot, UDOO's ports are all on one side and flush with each other, which will make case design much easier. Port LinuxCNC to the ARM i.MX6 Freescale CPU and have it communicate to/through the Arduino and use a motor controller plugged into the Arduino pin header sockets. there is nothing to 'port' - this capability is stock in the rtos-integration-preview3 and rtos-integration-preview3-merged-into-master branches since several months the relevant task with these new boards is finding a suitable realtime kernel - RTAI - probably not going to happen in a relevant timespan - Xenomai: you drew a lucky punch: the i.MX6 by Freescale is supported by Xenomai - RT-PREEMPT: good luck to find one; no advantage over xenomai in porting effort but worse results see the Xenomai wiki and http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16270 - Michael At 4.33 inch x 3.35 inch (11 cm x 8.5 cm) this would make a very compact control system for CNC. The motor drivers and power supply would dwarf it. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Am 19.04.2013 um 06:26 schrieb Gregg Eshelman g_ala...@yahoo.com: The UDOO is a single board computer with a 1ghz quad core CPU plus an Arduino DUE. Same CPU as the Raspberry Pi but with 4 cores. ... Port LinuxCNC to the ARM i.MX6 Freescale CPU and have it communicate to/through the Arduino and use a motor controller plugged into the Arduino pin header sockets. The Arduino is all fine and popular, but compared to what is already available stock for the Beaglebone any such solution - which will be a lot of work too - will be a complete dog in terms of stepper speed and phase noise the Beaglebone port of LinuxCNC can use the builtin coprocessor of the TI3335 chipset and bang stepper lines at 200kHz if you can find a powerstage and motor to sustain that again: this is _stock_, done, ready to go, not blue skye - build from here: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/arm335x-hal-pru-module no reason to reinvent the wheel in square form ;) - Michael At 4.33 inch x 3.35 inch (11 cm x 8.5 cm) this would make a very compact control system for CNC. The motor drivers and power supply would dwarf it. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
2013/4/19 Michael Haberler mai...@mah.priv.athttps://mail.google.com/mail/u/0/?view=cmfs=1tf=1to=mai...@mah.priv.at Andrew, I recently run into http://www.youtube.com/watch?v=YSnNtgZrfyU LCNC 2.5 is ported to ARM with Xenomai The capability to run on ARM boards has been in a linuxcnc.orgdevelopment branch since late last year, among them Raspberry Pi and the Beaglebone, both in a v2.5_branch based and master-based branch please see the emc-developers archive for details the link you give above was a one-off effort which never made it back into linuxcnc and is not a recommended base to start on Thanks for pointing that out, Michael! 2013/4/19 Michael Haberler mai...@mah.priv.at again: this is _stock_, done, ready to go, not blue skye - build from here: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/arm335x-hal-pru-module no reason to reinvent the wheel in square form ;) Great! Where should I start to get LCNC working on ARM device? What is recommended board to play with? Any FAQ or Wiki available? Andrew -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Am 19.04.2013 um 11:30 schrieb Andrew parallel.kinemat...@gmail.com: 2013/4/19 Michael Haberler mai...@mah.priv.athttps://mail.google.com/mail/u/0/?view=cmfs=1tf=1to=mai...@mah.priv.at Andrew, I recently run into http://www.youtube.com/watch?v=YSnNtgZrfyU LCNC 2.5 is ported to ARM with Xenomai The capability to run on ARM boards has been in a linuxcnc.orgdevelopment branch since late last year, among them Raspberry Pi and the Beaglebone, both in a v2.5_branch based and master-based branch please see the emc-developers archive for details the link you give above was a one-off effort which never made it back into linuxcnc and is not a recommended base to start on Thanks for pointing that out, Michael! 2013/4/19 Michael Haberler mai...@mah.priv.at again: this is _stock_, done, ready to go, not blue skye - build from here: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/arm335x-hal-pru-module no reason to reinvent the wheel in square form ;) Great! Where should I start to get LCNC working on ARM device? The information on ARM ports is atm bit littered over the emc-developers mailing list, which I suggest to read back to last fall, and several Wiki entries: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?BeagleboneDevsetup http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NewRTInstall http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RaspbianXenomaiBuild What is recommended board to play with? my personal recommendation would be the new 'black' Beaglebone board about to come out - umph and I/O capabilities leave the Raspberry in the dust (which I think is a totally overhyped platform; it does have a decent package stream but thats about all of the upside I could think of relative to the BB for LinuxCNC purposes) the advantage of the black BB over the current one is - it has on-board HDMI and more memory I had no chance to build on the black BB since it isnt out yet but I dont expect any surprises except maybe for OpenGL support being a bit bumpy to start with the concept of glueing an Arduino to an ARM core is basically shmoozing up to the popularity of the Arduino and trying to get some marketing uplift from there; in terms of architectural wisdom and usefulneess I think it's obtuse BS that wont get any traction. -- As for other boards - the tough part is finding a realtime kernel that works and for the ARM boards Xenomai is the only realistic option atm - so before you jump make sure that the board, or at least the processor chip, are supported by Xenomai - see www.xenomai.org you miss out on this step - you have a board which will run the 'simulator mode' only (non-realtime threads) which isnt useful for real work; or face nontrivial kernel work to get the board supported and debugged with Xenomai. So the 'great deal' on the board of the week might serve well to enrich your assortment of doorstops ;) - Michael Any FAQ or Wiki available? Andrew -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
2013/4/19 Michael Haberler mai...@mah.priv.at The information on ARM ports is atm bit littered over the emc-developers mailing list, which I suggest to read back to last fall, and several Wiki entries: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?BeagleboneDevsetup http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NewRTInstall http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RaspbianXenomaiBuild Thanks! I started reading, and run into boot from NFS server. Not that I can't do that, but looks inconvenient. Any other options for boot drive? Faster SD card, USB HDD or flash drive? What is recommended board to play with? my personal recommendation would be the new 'black' Beaglebone board about to come out - umph and I/O capabilities leave the Raspberry in the dust (which I think is a totally overhyped platform; it does have a decent package stream but thats about all of the upside I could think of relative to the BB for LinuxCNC purposes) the advantage of the black BB over the current one is - it has on-board HDMI and more memory I had no chance to build on the black BB since it isnt out yet but I dont expect any surprises except maybe for OpenGL support being a bit bumpy to start with the concept of glueing an Arduino to an ARM core is basically shmoozing up to the popularity of the Arduino and trying to get some marketing uplift from there; in terms of architectural wisdom and usefulneess I think it's obtuse BS that wont get any traction. Black Beaglebone is scheduled for May, I hope to acquire it this summer. Though with TFT touchscreen it's not that cheap, but with 200kHz step rate I hope to skip MESA board. Is it possible to connect encoders directly to BB? Andrew -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
Am 19.04.2013 um 18:46 schrieb Andrew parallel.kinemat...@gmail.com: 2013/4/19 Michael Haberler mai...@mah.priv.at The information on ARM ports is atm bit littered over the emc-developers mailing list, which I suggest to read back to last fall, and several Wiki entries: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?BeagleboneDevsetup http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NewRTInstall http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RaspbianXenomaiBuild Thanks! I started reading, and run into boot from NFS server. Not that I can't do that, but looks inconvenient. Any other options for boot drive? Faster SD card, USB HDD or flash drive? Well actually the setup described there is a developer setup because compiling on the standard SD card is very slow; in a production setting you'd rather want to have the standard SD card setup anyway depending if you want to run a GUI on it or for instance emcweb you might either pick the Ubuntu quantal or debian wheezy root image from here: http://www.eewiki.net/display/linuxonarm/BeagleBoard#BeagleBoard-DebianWheezy%28snapshot%29%28armhfbased%29RootFileSystem (forget the Angstrom distro which comes with it and buy a few SD cards) once that works, install the xenomai kernel too and make it boot then follow the outline, install packages as needed and build linuxcnc and when you're done and it works - please describe it on the wiki and post an SD card image ;) note we have a very nice description of the steps for the Raspberry SD card install; we're lacking the same for the beaglebone What is recommended board to play with? my personal recommendation would be the new 'black' Beaglebone board about to come out - umph and I/O capabilities leave the Raspberry in the dust (which I think is a totally overhyped platform; it does have a decent package stream but thats about all of the upside I could think of relative to the BB for LinuxCNC purposes) the advantage of the black BB over the current one is - it has on-board HDMI and more memory I had no chance to build on the black BB since it isnt out yet but I dont expect any surprises except maybe for OpenGL support being a bit bumpy to start with the concept of glueing an Arduino to an ARM core is basically shmoozing up to the popularity of the Arduino and trying to get some marketing uplift from there; in terms of architectural wisdom and usefulneess I think it's obtuse BS that wont get any traction. Black Beaglebone is scheduled for May, I hope to acquire it this summer. Though with TFT touchscreen it's not that cheap, but with 200kHz step rate I hope to skip MESA board. Is it possible to connect encoders directly to BB? the HAL encoder module is stock, so no surprises here, but note that you'll be pushing the envelope with a 40-50uS base thread there are better options which are 'a simple matter of programming': - you can build a fast PRU encode module along the lines of what Charles did in the arm335x-hal-pru-module - the TI3335 cpu supports hardware quadrature encoders - I have no experience with them but the data sheet looks great ;) - while you are at, a multi-channel hardware PWM would be great ;) My suggestion would be to get it right first (use HAL encoder) and get it fast once needed - Michael Andrew -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On 4/19/2013 1:24 PM, Michael Haberler wrote: Am 19.04.2013 um 18:46 schrieb Andrewparallel.kinemat...@gmail.com: 2013/4/19 Michael Haberlermai...@mah.priv.at The information on ARM ports is atm bit littered over the emc-developers mailing list, which I suggest to read back to last fall, and several Wiki entries: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?BeagleboneDevsetup http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NewRTInstall http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RaspbianXenomaiBuild Thanks! I started reading, and run into boot from NFS server. Not that I can't do that, but looks inconvenient. Any other options for boot drive? Faster SD card, USB HDD or flash drive? Well actually the setup described there is a developer setup because compiling on the standard SD card is very slow; in a production setting you'd rather want to have the standard SD card setup anyway Andrew. The Beaglebone and many of its brethren (but not the Raspberry Pi) depend on an open-source program named Das U-Boot (nice choice of name, I thought!). The Beaglebone firmware expects to find suitably packaged Das U-Boot code on the uSD card.(you can find more explanation on Beagleboard.org). By default, the multi-stage Beaglebone booting process ends up loading the Linux kernel from the uSD card and points the kernel to the file system also on the uSD card. Fortunately, a hook is provided that can be exploited to break out of the default booting sequence and do interesting things. Michael's use of remote servers is a good example. Last fall, I worked on uSD cards which allow me to break the booting process and, from the command line, choose to continue with the kernel and the file system each drawn from either the uSD card or from remote servers. It wasn't as pretty nor as automated as I would like, but it was doable. I wasn't interested in booting from a USB device so I didn't look into the resources necessary to do that. I started to document what I'd done on my Google site (sites.google.com/site/manisbutareed) but my wife's declining health drew me away before I published my scripts. I may get back to it mañana. I decided, by the way, to stick to scripts (well, environmental variables on steroids, actually) and not modify Das U-Boot sources because 1) I didn't want to turn this into yet-another-project and 2) if at all successful, I'd immediately be in the position of supporting potentially many others outside the LinuxCNC community. Das U-Boot lives at www.denx.de/wiki/U-Boot in case you want to look at the sources (the U stands for universal which means you should be prepared to do some careful study to figure out what parts apply to the Beaglebone). Regards, Kent -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On 4/19/2013 5:55 AM, Michael Haberler wrote: So the 'great deal' on the board of the week might serve well to enrich your assortment of doorstops;) - Michael Well said! :-) Dave -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] LinuxCNC would be very nice on the UDOO board.
The UDOO is a single board computer with a 1ghz quad core CPU plus an Arduino DUE. Same CPU as the Raspberry Pi but with 4 cores. Runs Linux and Android. http://www.kickstarter.com/projects/435742530/udoo-android-linux-arduino-in-a-tiny-single-board Note the much saner port arrangement than what's on the RasPi with its ports on all sides and sticking out at apparently random distances. Except for power input and Micro SD slot, UDOO's ports are all on one side and flush with each other, which will make case design much easier. Port LinuxCNC to the ARM i.MX6 Freescale CPU and have it communicate to/through the Arduino and use a motor controller plugged into the Arduino pin header sockets. At 4.33 inch x 3.35 inch (11 cm x 8.5 cm) this would make a very compact control system for CNC. The motor drivers and power supply would dwarf it. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
On Fri, Apr 19, 2013 at 12:26 AM, Gregg Eshelman g_ala...@yahoo.com wrote: The UDOO is a single board computer with a 1ghz quad core CPU plus an Arduino DUE. Same CPU as the Raspberry Pi but with 4 cores. Runs Linux and Android. http://www.kickstarter.com/projects/435742530/udoo-android-linux-arduino-in-a-tiny-single-board Cool design, thanks for pointing it out---but LinuxCNC currently requires a modified kernel with RTAI-style realtime functionality. People, including some on this list, are interested in porting RTAI to ARM; the most often mentioned target board is the Beagleboard (maybe even Beaglebone), but AFAIK nobody succeeded yet. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.
2013/4/19 Przemek Klosowski przemek.klosow...@gmail.com On Fri, Apr 19, 2013 at 12:26 AM, Gregg Eshelman g_ala...@yahoo.com wrote: The UDOO is a single board computer with a 1ghz quad core CPU plus an Arduino DUE. Same CPU as the Raspberry Pi but with 4 cores. Runs Linux and Android. http://www.kickstarter.com/projects/435742530/udoo-android-linux-arduino-in-a-tiny-single-board Cool design, thanks for pointing it out---but LinuxCNC currently requires a modified kernel with RTAI-style realtime functionality. People, including some on this list, are interested in porting RTAI to ARM; the most often mentioned target board is the Beagleboard (maybe even Beaglebone), but AFAIK nobody succeeded yet. I recently run into http://www.youtube.com/watch?v=YSnNtgZrfyU LCNC 2.5 is ported to ARM with Xenomai -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
