Re: [Emc-developers] Announcing the LinuxCNC 2.6 branch
Great, so no unified build ... this means rt-preemt is also not in emc 2.6 progress Please say I'm to pessimistic ? :-D / Lars Segerlund. 2014-04-02 8:50 GMT+02:00 Sebastian Kuzminsky s...@highlab.com: I am pleased to announce the creation of a branch for stabilizing and releasing LinuxCNC 2.6. This marks the beginning of the 2.6 release process. Look for a 2.6.0~pre1 pre-release in the near future. The 2.6 branch does not contain either of the two big, hotly anticipated merge candidates, joints-axes and unified-build-candidate. It is my (unpopular) opinion that both of these branches require additional work to be release-ready, and i don't want to hold up the 2.6 release any longer. It's been two years since 2.5.0 and that's way too long. There are good features that are ready to release today, so I want to get those out to users while we finish up the next round of features for the next release. Both branches are candidates for a future 2.7 release (as is Robert Ellenberg's new trajectory planner). I intend for the 2.7 release cycle to be much shorter than 2.6 was, and i intend to keep working with everyone's help to make ready the features in the pipeline for 2.7. But for now I ask for everyone's help in getting 2.6 out. Breaking with tradition, the 2.6 branch is called, simply, 2.6. Bug fixes are welcome in 2.6 (or in v2.5_branch if appropriate), as are new components and drivers, but commits that potentially destabilize existing functionality should be reviewed before being pushed to the release branch. The 2.6 release is targeting the following platforms: Realtime (RTAI): Ubuntu Lucid (32-bit, Linux 2.6.32) Ubuntu Precise (32-bit, Linux 3.4) Debian Wheezy (32-bit, Linux 3.4) Simulation: Ubuntu Lucid Ubuntu Precise Debian Wheezy Ubuntu Hardy (RTAI and simulation) is not currently supported because of a build dependency of the new xhc-hb04 driver. If there is user desire for 2.6 on Hardy we can disable that driver on Hardy (while still shipping that driver on the newer platforms). Work remaining/request for help: Testing - especially be on the lookout for any needed config changes Squashing of bugs (https://sf.net/p/emc/bugs/milestone/2.6/) Building of new Live CDs (for both Precise and Wheezy) Proof-reading the docs -- Sebastian Kuzminsky -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Announcing the LinuxCNC 2.6 branch
Just give it up, I followed rt-preempt developement for 4 years or so, and even measurement doesn't affect these guys, a good system can do rt-preempt and less than 10 us , under load, infact less jitter under heavy load than RTAI or xenomai, ( perhaps not less jitter, but smaller worst cases ). I don't get it, there is a realtime kernel in debian, and ubuntu and so on now that we have a sane build with the realtime dependent parts in libraries which can be loaded at runtime this happens. Abandon all hope ! 2014-04-02 22:13 GMT+02:00 EBo e...@sandien.com: Oh good god... Is there any way this could be brought in some how? On Apr 2 2014 2:09 PM, Lars Segerlund wrote: Great, so no unified build ... this means rt-preemt is also not in emc 2.6 progress Please say I'm to pessimistic ? :-D / Lars Segerlund. 2014-04-02 8:50 GMT+02:00 Sebastian Kuzminsky s...@highlab.com: I am pleased to announce the creation of a branch for stabilizing and releasing LinuxCNC 2.6. This marks the beginning of the 2.6 release process. Look for a 2.6.0~pre1 pre-release in the near future. The 2.6 branch does not contain either of the two big, hotly anticipated merge candidates, joints-axes and unified-build-candidate. It is my (unpopular) opinion that both of these branches require additional work to be release-ready, and i don't want to hold up the 2.6 release any longer. It's been two years since 2.5.0 and that's way too long. There are good features that are ready to release today, so I want to get those out to users while we finish up the next round of features for the next release. Both branches are candidates for a future 2.7 release (as is Robert Ellenberg's new trajectory planner). I intend for the 2.7 release cycle to be much shorter than 2.6 was, and i intend to keep working with everyone's help to make ready the features in the pipeline for 2.7. But for now I ask for everyone's help in getting 2.6 out. Breaking with tradition, the 2.6 branch is called, simply, 2.6. Bug fixes are welcome in 2.6 (or in v2.5_branch if appropriate), as are new components and drivers, but commits that potentially destabilize existing functionality should be reviewed before being pushed to the release branch. The 2.6 release is targeting the following platforms: Realtime (RTAI): Ubuntu Lucid (32-bit, Linux 2.6.32) Ubuntu Precise (32-bit, Linux 3.4) Debian Wheezy (32-bit, Linux 3.4) Simulation: Ubuntu Lucid Ubuntu Precise Debian Wheezy Ubuntu Hardy (RTAI and simulation) is not currently supported because of a build dependency of the new xhc-hb04 driver. If there is user desire for 2.6 on Hardy we can disable that driver on Hardy (while still shipping that driver on the newer platforms). Work remaining/request for help: Testing - especially be on the lookout for any needed config changes Squashing of bugs (https://sf.net/p/emc/bugs/milestone/2.6/) Building of new Live CDs (for both Precise and Wheezy) Proof-reading the docs -- Sebastian Kuzminsky -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Announcing the LinuxCNC 2.6 branch
What I am saying is this is the same talk as for the 2.4 release, a couple of years ago. Now there is nothing of importance in the 2.6 release described above, and it will take a couple of years for interesting stuff to make it to mainline. That puts it ouside my interest, I have been waiting for this stuff for 3 years and now it's the same talk as last time, so for me this makes EMC irrelevant, all the effort so many people have put in the good features. The new motion planner would be a really neat option to BE ABLE to enable and test, now it will die a slow death on the develbranch. / Lars Segerlund 2014-04-02 23:06 GMT+02:00 sam sokolik sa...@empirescreen.com: Just because it didn't make it into 2.6 doesn't mean it isn't going to happen. This isn't the end of the world. Have you seen the todo list? There have been a few calls for help http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Todo-2.6 As far as rt_preempt - I have tested it using the unified build - michael debs. (playing with the 7i80) All the hardware I have tested it on - I have never seen anything better than 50us latency. Just fine for servo loop systems. (where as the same hardware runs rtai/xeomai 10us or there abouts..) I see things moving forward.. Anyone can test/use any of the linuxcnc advancements. (be it the ub, new trajectory planner, whatever) I wish I could do more than just test... (not enough hours in the day) sam On 04/02/2014 03:20 PM, Lars Segerlund wrote: Just give it up, I followed rt-preempt developement for 4 years or so, and even measurement doesn't affect these guys, a good system can do rt-preempt and less than 10 us , under load, infact less jitter under heavy load than RTAI or xenomai, ( perhaps not less jitter, but smaller worst cases ). I don't get it, there is a realtime kernel in debian, and ubuntu and so on now that we have a sane build with the realtime dependent parts in libraries which can be loaded at runtime this happens. Abandon all hope ! 2014-04-02 22:13 GMT+02:00 EBo e...@sandien.com: Oh good god... Is there any way this could be brought in some how? On Apr 2 2014 2:09 PM, Lars Segerlund wrote: Great, so no unified build ... this means rt-preemt is also not in emc 2.6 progress Please say I'm to pessimistic ? :-D / Lars Segerlund. 2014-04-02 8:50 GMT+02:00 Sebastian Kuzminsky s...@highlab.com: I am pleased to announce the creation of a branch for stabilizing and releasing LinuxCNC 2.6. This marks the beginning of the 2.6 release process. Look for a 2.6.0~pre1 pre-release in the near future. The 2.6 branch does not contain either of the two big, hotly anticipated merge candidates, joints-axes and unified-build-candidate. It is my (unpopular) opinion that both of these branches require additional work to be release-ready, and i don't want to hold up the 2.6 release any longer. It's been two years since 2.5.0 and that's way too long. There are good features that are ready to release today, so I want to get those out to users while we finish up the next round of features for the next release. Both branches are candidates for a future 2.7 release (as is Robert Ellenberg's new trajectory planner). I intend for the 2.7 release cycle to be much shorter than 2.6 was, and i intend to keep working with everyone's help to make ready the features in the pipeline for 2.7. But for now I ask for everyone's help in getting 2.6 out. Breaking with tradition, the 2.6 branch is called, simply, 2.6. Bug fixes are welcome in 2.6 (or in v2.5_branch if appropriate), as are new components and drivers, but commits that potentially destabilize existing functionality should be reviewed before being pushed to the release branch. The 2.6 release is targeting the following platforms: Realtime (RTAI): Ubuntu Lucid (32-bit, Linux 2.6.32) Ubuntu Precise (32-bit, Linux 3.4) Debian Wheezy (32-bit, Linux 3.4) Simulation: Ubuntu Lucid Ubuntu Precise Debian Wheezy Ubuntu Hardy (RTAI and simulation) is not currently supported because of a build dependency of the new xhc-hb04 driver. If there is user desire for 2.6 on Hardy we can disable that driver on Hardy (while still shipping that driver on the newer platforms). Work remaining/request for help: Testing - especially be on the lookout for any needed config changes Squashing of bugs (https://sf.net/p/emc/bugs/milestone/2.6/) Building of new Live CDs (for both Precise and Wheezy) Proof-reading the docs -- Sebastian Kuzminsky -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] ubc: inconsistent behavior in posix flavor vs others
+1 ! non-blocking datastructures are indispensible ! 2014-03-04 16:15 GMT+01:00 Charles Steinkuehler char...@steinkuehler.net: On 3/3/2014 5:16 PM, John Kasunich wrote: massive in-line snippage Can we agree that on a single core system, slow threads should never steal the CPU from fast threads, and web browsers should never steal the CPU from any real-time threads? Even if you are only doing simulated real-time? Even on a single core system, there are more ways to implement thread scheduling than you can shake a stick at. The important issue is the code operates correctly under the implemented scheduling scheme. The right scheduler is the one that works for your application. That said, I don't have an issue with your proposal, although terms like fast, slow, and real-time should probably be rephrased in terms of relative thread priorities. It would be foolish to try to implement a ringbuffer or other fairly heavy-weight protocol in an FPGA. Instead, you define a register map by which the slow task controls the fast hardware. Ideally every register is independent and the FPGA does the right thing regardless of what order you write them in. In some cases, there may be groups of registers that need to be atomic. It isn't uncommon to have double-buffers with a strobe or similar signal that tells the FPGA to transfer from the first set to the second set in parallel. I totally disagree. I work with FPGA systems on a daily basis, and would be completely crippled if you remove ringbuffers (and their identical twins: FIFOs and queues) from my bag of tricks. These constructs are used extensively in my designs for the exact same reasons we need them in the new real-time layers: Communicating chunks of data atomically across clock domains (or threads / scheduling contexts in software). These constructs are non-blocking, and serve to isolate various timing domains from each other while providing for highly efficient transfers of data/messages/whatever. -- Charles Steinkuehler char...@steinkuehler.net -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable
It depends on the driver implementation, ie. if the kernel code is using preempt disable or disable interrupts. ALL preempt-rt performance is to a large extent dependent on the quality of the device drivers. If you look at osadl.org there is an effort on realtime device drivers ... / Lars 2014-01-30 Michael Haberler mai...@mah.priv.at: Michal is trying hard to get the 7i80/hm2_eth.c driver working for RT-PREEMPT using normal socket I/O from an RT thread. The hopes with RT-PREEMPT are obviously pegged on the assumption: 'the kernel is hardened, so I'm free to use any system calls from an RT thread and still get decent latency, so we can leverage of the stock linux driver universe'. This might not be a valid assumption. I just had a long offline discussion with Nicholas Mc Guire from the rt-preempt effort on a related issue (signaling a non-RT thread from an RT thread; the method I proposed uses a write(2) system call on an eventfd(2) file descriptor; one of the most efficient ways to signal a poll(2) compatible event between threads). Nicholas pointed me to the fact that almost all system system calls might be spoilers for RT threads; _including write(2)_ , hardened kernel or not. While I didnt fully understand every detail he said, the message was clear: the above assumption might not hold. He also pointed at that hoping for low latency when using the kernel IP stack may be a lost cause to start with. He hinted towards a UIO-based userland stack being worked on for exactly this purpose. I am still searching for details on this. My recommendation is: peer-review your assumptions to avoid a time waster here. Get in touch with linux-rt-us...@vger.kernel.org, describe what you intend, get advice straight from the people who make it happen. - Michael -- ps: IMV the search for a low-latency network I/O method is still on. Note that we already have a userland PCI framework thanks to Charles, which might be a startng point. See also: http://static.mah.priv.at/public/rtlws-proceedings/rtlws-2012/proc/Yang.pdf http://os.inf.tu-dresden.de/ddekit/dde_rtlws11.pdf. semi-related: anyone looking into RT-PREEMPT on ARM CPU's should read: http://lwn.net/images/conf/rtlws11/papers/proc/p11.pdf -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable
2014-01-30 Michael Haberler mai...@mah.priv.at: Am 30.01.2014 um 11:42 schrieb Lars Segerlund lars.segerl...@gmail.com: It depends on the driver implementation, ie. if the kernel code is using preempt disable or disable interrupts. The kernel execution path is _much_ longer than just the driver, and depending on the system call all sorts of issues happen well before a driver is invoked. Priority inversion, memory allocation which might block, the whole nine yards. The gist of what Nicolas said was: it's the kernel execution path of a particular syscall - meaning: no matter how bright your driver is you might well be hosed before you get there. ALL preempt-rt performance is to a large extent dependent on the quality of the device drivers. This is a general observation from running preempt-rt, I did not contest your statements, I simply added that if you have bad device drivers you are out of luck with preempt-rt. It's one of the things you have to make sure of when using it, but it's getting better, thanks to multiprocessing large parts of the kernen are undergoing efforts to use lockless datatypes or mechanisms. If you have a set of different computers and run some tests on preempt-rt you will soon find that some perform much worse due to poor drivers, and networking is one are where there are some 'known bad' cards and drivers. Or in engineering english, some systems suck and some don't ... / regarrds, Lars Can you back up that assertion with facts? the case at hand was the 7i80 UDP I/O effort. That means the whole kernel IP stack gets traversed. There obviously is a reason why Xenomai employs the RTnet stack for such jobs. For instance, it might make sense to ask Jan Kiska, the author. If you look at osadl.org there is an effort on realtime device drivers ... What I am suggesting against: trying such approaches in isolation and hope for results based on some homegrown theory. What I am suggesting: talk to the relevant community, test your theory, listen to alternative suggestions. That has paid off hugely in the Xenomai case already. In the RT-PRREMPT case the gist I took away so far was: the UIO framework might be a solution to bypass kernel execution paths in RT - resullting in: lower latency, card dependency, no sharing with kernel stack, userland UDP handling, likely extra kernel modules, and out-of-tree support modules like uio_dma . - Michael / Lars 2014-01-30 Michael Haberler mai...@mah.priv.at: Michal is trying hard to get the 7i80/hm2_eth.c driver working for RT-PREEMPT using normal socket I/O from an RT thread. The hopes with RT-PREEMPT are obviously pegged on the assumption: 'the kernel is hardened, so I'm free to use any system calls from an RT thread and still get decent latency, so we can leverage of the stock linux driver universe'. This might not be a valid assumption. I just had a long offline discussion with Nicholas Mc Guire from the rt-preempt effort on a related issue (signaling a non-RT thread from an RT thread; the method I proposed uses a write(2) system call on an eventfd(2) file descriptor; one of the most efficient ways to signal a poll(2) compatible event between threads). Nicholas pointed me to the fact that almost all system system calls might be spoilers for RT threads; _including write(2)_ , hardened kernel or not. While I didnt fully understand every detail he said, the message was clear: the above assumption might not hold. He also pointed at that hoping for low latency when using the kernel IP stack may be a lost cause to start with. He hinted towards a UIO-based userland stack being worked on for exactly this purpose. I am still searching for details on this. My recommendation is: peer-review your assumptions to avoid a time waster here. Get in touch with linux-rt-us...@vger.kernel.org, describe what you intend, get advice straight from the people who make it happen. - Michael -- ps: IMV the search for a low-latency network I/O method is still on. Note that we already have a userland PCI framework thanks to Charles, which might be a startng point. See also: http://static.mah.priv.at/public/rtlws-proceedings/rtlws-2012/proc/Yang.pdf http://os.inf.tu-dresden.de/ddekit/dde_rtlws11.pdf. semi-related: anyone looking into RT-PREEMPT on ARM CPU's should read: http://lwn.net/images/conf/rtlws11/papers/proc/p11.pdf -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers
Re: [Emc-developers] OSADL Project: Real Time Linux Workshops - conference paper on RTAPI/unified build
Thanks ! And it's really super that EMC shows up on OSADL, hopefullly it's on the radar for the rt-preempt folks. The paper was really good, especially about the PRU ... nice implementation. / regards, Lars Segerlund. 2013/10/8 Michael Haberler mai...@mah.priv.at: this year's OSADL conference: https://www.osadl.org/RTLWS-2013.rtlws-2013.0.html has an entry from LinuxCNC: https://www.osadl.org/?id=1752 the final paper is here: http://static.mah.priv.at/public/paper.pdf program: https://www.osadl.org/RTLWS-Submitted-Papers.rtlws15-submitted-papers.0.html - Michael -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] NURBS, jerk minimization, and other stuff
The nice part is that if the motion is in a continous NURBS form, you only have one continous motion, and NURBS can be patched togeter, so a big part can be done in the motion planning stage, ie. precalculated. think of two straight lines represented by NURBS, the corner can be patched to a radii consistent with the tolerance settings specified, also the speed along the NURB can be included i the representation, so you don't have a separate velocity component. For stuff like trochoidal machining this is NICE ! For a longer run if you want realtime calculations, you can patch together NURBS of different degrees , as long as your motion NURB is atleast of the highest degree of the component NURBS, I am not 100% on this one but I do think so. Also you get consistent handling of lines/arcs/circles/conics and so on in an analytical form. It does however get complicated :-D / Lars Segerlund. 2013/7/8 Anders Wallin anders.e.e.wal...@gmail.com: It is fairly straightforward to plan a trajectory for a *single* segment (line, arc, nurbs-curve) with limited acceleration/jerk/double-jerk etc. It is much harder to come up with an algorithm that blends together *many* lines/arcs/nurbs-curves and plans a smooth trajectory. Note that it is always necessary to deviate from the programmed path at the corners between segments (unless your CAM-program produces c2/c3/c4 continuous toolpaths!). So there is always a tolerance to be specified for blending. Better trajectory control for linuxcnc is a fairly hard problem to tackle. It's especially hard if we want to support arbitrary kinematics and feed-override settings. I think it would be wise to start with only trivial kinematics and no 100% feed-override allowed. Are there software tests for the trajectory controller? If so, has anyone run them on the araisrobo nurbs-branch (github)? Good tests would make it easier to develop something new and increase the confidence in new code before starting to move heavy metal. Anders On Mon, Jul 8, 2013 at 12:11 PM, EBo e...@users.sourceforge.net wrote: I never ment to imply that NURBS were necessary -- I like them for other reasons (like exact representation of conics, splaying the control polygon gives you a helix in closed form (read threading in any arbitrary axis), is a natural representation produced from 3D models and CAD systems, and of course the ability to smooth and analyze them. I will take a look at the TinyG firmware for reference, and I am aware that there are a number of ways to get to achieve jerk minimization. Thanks for the TinyG pointer BTW, EBo -- On Jul 8 2013 12:51 AM, Alexey Starikovskiy wrote: There is an quite simple algorithm, which is used in TinyG firmware. There is a link to the paper from their github. No NURBS involved. On Mon, Jul 8, 2013 at 1:23 AM, EBo e...@users.sourceforge.net wrote: Since I do not have my references handy I thought I would review some of the properties necessary to geometrically minimize jerk. I found a couple of references online that might make for a good read: Smooth trajectory generation for five-axis machine tools: http://academia.edu/3862221/Smooth_trajectory_generation_for_ve-axis_machine_tools So it looks like they are requiring C3 continuity, and uses NURBS. This might comtinue the interesting debate... EBo -- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Open Development
Hmmm, I think you are better at words than I am, I generally come out a bit rough :-D ... when I was running 15 ns latency, I was running on the NMI and had disabled half the cache for the microcontroller, this one made it possible to disable and memory map it, so I had plenty of space to stuff the 'fun part' in , about 8 or 16 k which made the time for the interupt deterministic so we prescheduled a bit, end result we always came out with the same latency. Is it possible to do something similar on the Arduino ? I might check if adm64 permitts something similar, I will be back on that. It would be nice to use the arduino as backend, stepgenerator or so, and linuxcnc as frontend for heavy stuff Floating point is nice but people tend to trust it :-D so I have actualy had more problems getting things running in fixed point code, but more problems getting stuff 'safe' or bugfree in floatingpoint, it's so easy to loose precision. / regards, Lars Segerlund. 2013/7/6 EBo e...@sandien.com: I agree. If you can stuff your entire calculation into fixed point then you can do some wicked cool stuff -- I worked on a project where we embedded a 4-level wavelet decomposition and filter into an FPGA that processed ultrasonic scans of train rail tracks at 35MPH in real-time (we were scanning for cracks). I do not consider this a pissing match (yet), but I agree with the sentiment. Adding to my prior points (of rt-preempt, jerk, and real NURBS instead of bi-arcs), I would also ask in the redesign if we can break things out enough so that we could actually use other parts of LinuxCNC in embedded systems (like path planning, tool compensation, etc.) As Lars said, if we can get 15ns latencies out of them then for certain applications they are the right kind of thing. EBo -- On Jul 5 2013 2:41 PM, Lars Segerlund wrote: Hi guys, Floating point is moot, if you use fixed point in machine coordinates and add a 2^x bits to that, and you can do a lot of things on simple hardware :-D Linuxcnc flaunts a lot of hardware, but I think a microcontroller can beat it any day, I did 14.7 ns jitter on one once :-D ... go figure that out will ya, ( interrupt jitter, scheduled timer ) all that said I work on linuxcnc and rt-preempt . So if both sides in this debate state what they would like out of this perhaps some progress can be made instead of pissing contest ? I think linuxcnc could do wonders for 3d printing, and I think the 3d printing folks can teach us a bit about hardware and software, and I think the linuxcnc folks knows a bit about motion controll they can share :-D / Lars Segerlund -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Open Development
Hi guys, Floating point is moot, if you use fixed point in machine coordinates and add a 2^x bits to that, and you can do a lot of things on simple hardware :-D Linuxcnc flaunts a lot of hardware, but I think a microcontroller can beat it any day, I did 14.7 ns jitter on one once :-D ... go figure that out will ya, ( interrupt jitter, scheduled timer ) all that said I work on linuxcnc and rt-preempt . So if both sides in this debate state what they would like out of this perhaps some progress can be made instead of pissing contest ? I think linuxcnc could do wonders for 3d printing, and I think the 3d printing folks can teach us a bit about hardware and software, and I think the linuxcnc folks knows a bit about motion controll they can share :-D / Lars Segerlund -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Open Development
He can hire a programmer and pay him to fix it ... as long as it's nice enough to go in the distribution. It's more likely that there is a problem that crap is not accepted look at the linux kernel ... Even google is trying to play nice with main line after the brain dead crap they produced in the android kernels, and everyone is playing nice now. I think they will learn ... thats the way it's been with the kernel and stuff like eclipse ... ( IBM finally learned ... ). The real problem is that they hire a programmer to scratch that itch, and they also scratches everyone elses some companies wont rewrite code since that's already payed for ! ( even if it's buggy or doesn't work ). / my two cents, Lars Segerlund. 2013/7/3 andy pugh bodge...@gmail.com: On 3 July 2013 01:03, Charles Steinkuehler char...@steinkuehler.net wrote: The main point I am trying to make is the hackerspace folk have a different perspective on the world than the industrial machine control market where LinuxCNC is typically used, and if you want to engage these people (which I think is a good idea) the LinuxCNC community needs to be prepared for the differing perspectives of the two communities. FWIW I feel that the LinuxCNC developers tend to be closer to the Open-Source movement than to the Industrial Controls market, and this has probably been an obstacle to industrial adoption in the past. (I suspect that it would worry an industrial adopter that he needs to enthuse a developer to get a change made, rather than just pay him) -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Vote Seb for 2.6 Release Manager!
Hi Matt, I think the big thing is running on any of these systems without rebuilding linuxcnc, in other words one binary to rule tham all ... with with the rt parts as libs. This should also make it easier for windriver to support it, the porting work is smaller ( should be ... ). I am trying to fixup preemtp-rt since we have som nasty bug with pagefaults ( in the older preempt-rt also, I confirmed yesterday ), but which should be fixable. The big plus with this is we would be able to ship prebuilt .deb packages in standard debian, since they include a preempt-rt kernel now, and also has xenomai packages. / regards, Lars Segerlund. 2013/6/25 Matt Shaver m...@mattshaver.com: On Mon, 24 Jun 2013 21:16:23 -0600 EBo e...@sandien.com wrote: I just hope the processes does not burn you to a crisp. This is a worry, but Seb seems to handle stress in a healthy way so I think he'll be OK. One of the few things I would like to see kept in and taken seriously is preempt-rt. Im'm just sayin... John Morris tried to educate me on this, and what I think he said is that their universal binary idea provides for use of either the POSIX (the best you can do without changing the kernel), RTAI, Xenomai, or PREEMPT_RT real time systems. EBo: You know the FSM Labs folks right? Once the above changes are integrated, I would think that making RTLinux work again would be possible. I've just spent two minutes looking this up and have discovered that RTLinux was acquired by Wind River Systems and then discontinued, but that FSM Labs has a (possibly) related product called TimeKeeper. I guess what I'm saying is that the next time you talk to these folks you might describe the changes that are being made to linuxcnc and let them know that an opportunity exists for them to integrate support for their product if that would help them. The existence of RTLinux made possible the first Linux based version of EMC, so they have some good will on deposit with the linuxcnc project if they need it. Best of luck to you Seb! Ditto. Thanks, Matt -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAPI is broken
Nope sys V is fine but mmap is not, some On Jun 14, 2013 5:12 p.m., Eric Keller eekel...@psu.edu wrote: On Thu, Jun 13, 2013 at 7:15 AM, Lars Segerlund lars.segerl...@gmail.com wrote: A short note, i... is this because we are using shared memory? Been a while since I looked under the hood. -- This SF.net email is... -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAPI is broken
Nope sys V is fine, it takes mmap, clone or memory allocation to cause fauls . IF we have prefaulted the memory stacks. I will try to get some time to look at it, and a way to trace pagefaults for out app. I got the tip to use trace_print in handle_ page_fault ... but would like to have a better way to look at it. / Lars Segerlund On Jun 14, 2013 5:12 p.m., Eric Keller eekel...@psu.edu wrote: On Thu, Jun 13, 2013 at 7:15 AM, Lars Segerlund lars.segerl...@gmail.com wrote: A short note, i... is this because we are using shared memory? Been a while since I looked under the hood. -- This SF.net email is... -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAPI is broken
A short note, it seems we get pagefaults in rt context, latency-test says so. I will build latest and run some tests. The intriguing thing is all other rt programs run fine, just linuxcnc that overshoots. / regards, Lars Segerlund. 2013/6/13 Alec Ari neotheu...@ymail.com: Hello everyone! I just talked to Lars Segerlund over the course of a few private emails, we've narrowed down the Missed scheduling deadline problem for LinuxCNC with PREEMPT_RT to an issue within RTAPI. A lot of people (if not everyone) has this problem. I have used debian kernels, I have compiled nearly 100 different kernels, changing settings in regards to ACPI, the RCU, every option that has a direct impact on latency, whether positive or negative, has been changing, with absolutely no change in latency. Several kernel versions have been tried, such as the official debian PREEMPT_RT kernel, and several custom kernels that I configured completely from scratch (all options by default disabled, allowing me to turn on only the ones I need to boot my system) and no change what-so-ever in regards to pagefaults and latency. This is no time to say don't use gentoo don't compile your own kernel your kernel config is broken etc, this is an issue that relies within the LinuxCNC tree. I have been hacking away at RTAI and PREEMPT_RT for a few years now to know how they both work, inside and out. I am not however, experienced with LinuxCNC itself, but I can guarantee that this issue is not relevant to Linux distributions, kernel releases, kernel configs, tool chain issues, and so on and so fourth. After running cyclictest for hours tonight (12 threads) while in the background compiling kernels, GMP, GCC, GNU Mpc, all with 50 parallel compiling jobs, on top of all that, running a CPU burn-in utility doing excessive number crunching with the use of exactly 1,000 threads, with integers in the billions. Latency with cyclictest reached no higher than 110 microseconds, and that's with using the standard POSIX interval timer, and not even a fully tweaked kernel. The latency-test program in LinuxCNC almost instantly shoots up to over 200,000 nanoseconds upon interacting with the system at all (idling it can last a bit longer.) Launching LinuxCNC itself throws several errors as well, unexpected real-time delay, check dmesg for details (which for the record doesn't mention anything..) and basically says the same thing in the terminal window, just worded a bit differently. Lars Segerlund and I are going to be tackling this issue the best we can, but any changes to do with LinuxCNC are going to have to be by people besides myself. Changes that have to do with the kernel side of things, that part I can do. Any additional help is greatly appreciated! Alec Ari -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] on the subject of governance
The problem with governance is that talented people tend to say Fuck yuo .. and go elsewgere. I am familiar with this since that's what I do in situations like that, in my proffession it's common if your're good enough then they are left with shit trying to do miracles and management seldom make great deeds on their own :) . I prefer unguided miracle workers , which seem's to fit the emc developement model so far. No offence, I want to do miracles not shit and miracles tend to one engineer against god the laws of nature so far it doesn't look good for god the laws of nature. / Just my two cent's ... :) ... Lars Segerlund On May 18, 2013 4:25 p.m., Kenneth Lerman kenneth.ler...@se-ltd.com wrote: On 5/18/2013 9:20 AM, Kent A. Reed wrote: A modest suggestion: There are lots of governance mo... My take is that our governance and communications models should depend on our goals (or to use business speak, our mission). My goals are quite modest. I'd like something that I can use on my mill, and someday, my lathe. The lathe will probably be outfitted with gang tooling. I don't much are about using the system for commercial production. I do, however, care about complete and elegant solutions. (Although you might not guess that from my quick and dirty implementation of interpreter control statements -- O words -- and named parameters.) [A few things that I'd like to see are: higher order control (jerk limited), unlimited (or limited only by memory) look ahead, a better interactive interface. The first two are for elegance (I have no real need for them), the last for my own use in making prototypes]. I also care about people like Stuart who have used our work product to control machines with five axes. People who are willing to pay their dues always get my respect. I don't really care if other products have twice (or ten times) the rate of growth. I don't view this as a competition. And while it's great to have talented developers like Michael who seem to have almost unlimited time and energy, any developer who is willing to take on a sub-project and carry it to completion has my respect. On the matter of not having enough time to do a job, I'll say what I've been saying to the members of a volunteer ambulance corps of which I'm a former chief. We all have the same amount of time -- there are twenty-four hours in a day. How you spend that time is a matter of your priorities. I won't tell anyone how to set their priorities. I suggest, however, that before you take on a job that requires a specific time commitment, you examine your priorities. (Yes, I recognize that priorities change.) In my own case, my LinuxCNC priority has decreased from former years. I have a full time job working for someone else these days. I haven't fired up my milling machine in over a year. Unfortunately, I have a prior commitment (cooking lobster for forty people) the weekend at the end of our get together. I'm contemplating joining those of you who can make it to Wichita perhaps from Tuesday to Friday, though. Regards, Ken -- AlienVault Uni... -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] on the subject of governance
This gets my +1 , the nazi governance talk does not .. it's more people should scratch my itch This is stuff that's generally 'good' and 'cool' :-D .. Well spoken ! I share the belief of a out of the box solution that 'just works' , and I share the belief that the 3D printing/manufacturing stuff has more potential than cutting metal. I am looking for a cheap 3D printer to prototype, and make molds for wax ( investement casting models ) ... A nice package for 3D printers might get an instant user base, especially since fx. debian is including preemt-rt kernels now ... ie. the possibility of out of the box. / regards, Lars Segerlund. 2013/5/18 Charles Steinkuehler char...@steinkuehler.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/18/2013 12:41 PM, Michael Haberler wrote: Am 18.05.2013 um 19:02 schrieb Peter C. Wallace p...@mesanet.com: On Sat, 18 May 2013, Kent A. Reed wrote: ... Number of LinuxCNC installations (the ballot on the website): something on the order of 10**3 Pretty sure the # of installations is closer to 10**4 where do you assume the difference to hide? and why dont they fork over gobs of hay so we can affort a decent server ;) Well, as a newbie here, my take is: The typical LinuxCNC / Mach user wants a working tool, and is less interested in the guts of the control box. That's one reason I want to try and get LinuxCNC (easily) usable by the maker community...these are the folks who are more likely to be contributing code, configuration, and documentation improvements. I was drawn to LinuxCNC via the 3D maker movement, when I reviewed the AVR based control code and typical hardware platforms and realized the general GRBL/Marlin on Arduino solution has limited upside moving forwards. That said, the 3D and maker folks are *RAPIDLY* evolving the control firmware, and combined with running bare-metal on some of the lower-end ARM chips they are poised to rapidly out-pace LinuxCNC in fairly short order. I still think there is a window of opportunity to get LinuxCNC, and specifically HAL in big with the maker crowd. These are folks who re-compile their firmware to change things like steps per distance for a given axis. The ability to easily manipulate PID control loops, run halscope, and all the other goodness that comes with LinuxCNC is so beyond what can be done today with the conventional control software most folks don't even know enough to miss it. So...I'm working on trying to make a fairly simple off-the-shelf system out of the BeagleBone that can run LinuxCNC with enough performance to beat out the AVR and low-end ARM based controllers, with the hope that as the maker folk start using this solution other bits and pieces will fall into place (like attractive and intuitive control screens, sample machine setup files with good feed-forward PID temperature control, etc). I realize this may not align well (or at all) with the existing LinuxCNC community's view of it's future, but I'm OK with that. I'm new here and don't know all the things I'm not supposed to do or say. :) - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGXw/cACgkQLywbqEHdNFweWACg3Dxmu13GjZK9dWps25d/h/E/ F50AnAy+SK3wfzCrQG8r0jQuIbJhHjzI =UCZO -END PGP SIGNATURE- -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?
check the data on osadl.org ... with RT-Preempt you should be able to get worstcase jitters of less than 50 us ... or you have a 'bad' system / bad drivers. With a 'good' RT-Preempt system you get 20 us as worstcase. osadl is good since they are really hammering the systems while measuring. / regards, Lars Segerlund. 2013/5/6 Kent A. Reed kentallanr...@gmail.com: On 5/6/2013 8:13 AM, Charles Steinkuehler wrote: Yes, but if you've got a Mesa card, you don't gain that much on an x86 platform. Unless you're really pushing your servo rate, rtai and xenomai are IMHO really only necessary on x86 if you're trying to do software stepgen. But make sure you test your board, latency numbers for rt_preempt can vary a*LOT* based on BIOS settings and your particular hardware (since for rt_preempt to work well, the driver code needs to be written to work well under SMP). and, just prior, Ebo wrote: There are people poking at RT-PREEMPT, and depending on your exact setup getting very good results. Like others have said, RTAI and Xenomai get better latencies and will probably always do so because of technical reasons of their implementation. That being said, if the rt-preempt latencies is good enough for your application I personally go for that -- rt-preempt is now part of the stock kernel and there is a variant which is now supposed to provide hard real-time. Anyway, them's my thoughts on the matter. and, just prior to that, Michael wrote: Yes, RTAI and Xenomai have significantly better latency behaviour than RT-PREEMPT. I think this is relevant mostly for software stepgen setups The question of what is good enough has intrigued me since I first started reading LinuxCNC nee EMC2 documentation. For many years we have had essentially only one quantitative criterion. IIRC correctly it shows up several places but this particular quote comes from the Latency-Test page on the Wiki: If the numbers are 100 uS or more (100,000 nanoseconds), then the PC is not a good candidate for software stepping. Numbers over 1 millisecond (1,000,000 nanoseconds) mean the PC is not a good candidate for LinuxCNC, regardless of whether you use software stepping or not. Is this still the best we can do for guidance to prospective users? I realize that details matter so it's difficult to get very specific about what is good enough for your application but I keep hoping we could say more. For that matter, we could say more about the impact of high jitter. Currently, we say only : ...your maximum step rate might be a bit disappointing If I thought I had the knowledge I would write more about the impact myself, but I don't and I haven't. MIchael and I briefly discussed the subject a year ago in the context of stepper drives and I realized after considerable Internet searching that little useful information is available (one limited calculation by Proctor et al and some postings by Mariss) so maybe it's just too hard a subject? As a practical matter, we haven't collected much latency/jitter data for the Xenomai and RT-PREEMPT kernels on different CPU-motherboard-BIOS combinations. It feels like it is time to start gathering such data in new tables on the Latency-test page on the Wiki. If I get time later today (and if the Wiki is more responsive than it was yesterday), I'll copy in my Xenomai results for several systems and Charles' RT-PREEMPT results for several other systems which have been posted elsewhere. Maybe the presence of new tables will embolden others to contribute their results. Regards, Kent PS - if new material on this subject already has been added to the LCNC documentation please point it out. My blind spots are widening with age. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?
+1 one that ! It's really hard to pick good hardware unless you buy try ! Cheers ! / Lars 2013/5/6 Kent A. Reed kentallanr...@gmail.com: On 5/6/2013 9:16 AM, Lars Segerlund wrote: check the data on osadl.org ... with RT-Preempt you should be able to get worstcase jitters of less than 50 us ... or you have a 'bad' system / bad drivers. With a 'good' RT-Preempt system you get 20 us as worstcase. osadl is good since they are really hammering the systems while measuring. / regards, Lars Segerlund. Lars: I'm not looking to open a discussion about the definition of jitter and the appropriate methodology for measuring it (we've had some of those in the past on this list, and some of us are quite familiar with OSADL). What I'm looking for is better guidance to our CNC users, most of whom find the details about latency as understandable as details about the fuel-injection algorithm used in their car's computer. What we have seen in the time I've been reading the emc2- lists amounts to constant schoolyard taunting, my latency is better than your latency. Look how excited we get when the latest Atom board yields 1us lower or higher jitter results than another. If the better guidance includes pointing to the OSADL as another source of data (along with suggestions on how to interpret those data) so much the better for the folks who wish to use RT-PREEMPT enabled kernels (and my thanks to those on this list who have been making it possible for the average user to even consider using them). Regards, Kent -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 12.04, xenomai, rtai buffering/blocking question
On the a somewhat related note, debian wheezy have RT kernels included, just for information I haven't tried it out yet. But it's nice to have prebuilt. 2013/2/20 Michael Haberler mai...@mah.priv.at: Am 20.02.2013 um 22:07 schrieb Tom Easterday: Let me re-ask the question, for which I gave too much prior information. Apologies for that. Are there pre-built packages for RTAI on Ubuntu 12.04 Precise? -Tom no, which was part of the reason for the Xenomai/RT-PREEMPT effort but you will very likely be able to run precise with the existing RTAI kernel just fine by manual installation with dpkg - Michael On Feb 20, 2013, at 3:52 PM, Michael Haberler mai...@mah.priv.at wrote: Tom, Am 20.02.2013 um 20:29 schrieb Tom Easterday: I have a problem that looks like either process scheduling, or buffering, some sort of blocking on a linuxcnc host running 12.04/Xenomai and 2.6.0pre. It does not display this problem on 10.04/RTAI and 2.6.0pre (same base hardware, an intel atom board). The symptom is that when continuously jogging, a DRO showing position on a remote device changes smoothly when talking to 10.04/rtai. On 12.04/xenomai we get a distinct pattern of three updates and a pause, three updates and a pause. The pause is some number of milliseconds long (1/4 second maybe) and distinctly visible. The remote connection is through our web server (Rockhopper) over tcp (websocket) on wired ethernet. We first thought it was packet buffering or network latency and played with TCP parameters and system buffers but that had no effect. We put timing statements in the web server code at the point were we write the data out and it appears that the whole web server process is being blocked or something. We tried re-nicing the web server but it didn't help. If we run Axis locally while doing this it doesn't display this pause, it moves along smoothly as one would expect. For debugging I thought I might try 12.04 and rtai to see if it was just with the xenomai kernel or if rtai on 12 does it as well. Are there rtai packages available for 12.04 yet? I was going through the email list archive on the new RT stuff but don't see any pointer to packages on rtai specifically... Any thoughts on what we might look at to narrow it down further? From the above I can tell: - you are running some of your own code because you cite some 'web server' which is not part of a released or working branch. Where is the code, the configuration you are using, and the exact sequence of commands leading up to it? - you say you are running '2.6.0pre', whatever that is, that tag isnt a unique identifier. Please state repository, branch name, commit, and which changes you did. - you do not say anything about hardware, exact lan setup including any intermediate hardware, the board, kernel version - how are we supposed to guess? With that level of information, my thought is that you will get zero help in narrowing down things further, simply because it is impossible. -- that said, what I suggest you do is: triage the problem into a) network driver and hardware b) tcp kernel stack and throughput c) application. a) Find throughput tests which measure at the packet loss level with the least kernel intervention, that is - raw throughput tests at the ethernet or UDP level. Find out if there are significant differences between operating systems on the same hardware. Change hubs/switches or whatever have in between. Try a crossover cable. b) do the same including the TCP stack which measures end-to-end throughput at the TCP level. Observe the TCP retransmission numbers in netstat which should give a clue. c) as for application level issues, install wireshark and pcap, and trace the flow between the programs which show the the issue - we dont know which they are since you do not tell. The packet capture will include timestamps and TCP retransmissions which hint at network problems. If you see any retransmissions, try alternate hardware and drivers - this zoo has many animals. Try with everyting on one machine to exclude network issues. And: read this: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html -- One reason why I suggest you produce a more thorough report, and not some ephemeral problem narrative: I spent several hours recently in a off-list debugging session on a 'reported Xenomai problem'. The problem was finally resolved by me demanding to 'yank that ethernet hub *now* and throw it in the wastebin' in no uncertain words. No more Xenomai issues since. Btw that was a device 'which always used to work so far'. So much for perceived causality. - Micahel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb
Re: [Emc-developers] Latency and preempt rt
For some more often than others :-D ! / Lars 2012/10/16 EBo e...@sandien.com: Lars, No bother. We all have those headlapping moments. Actually I had not even noticed... Thanks for the follow up though! EBo -- On Tue, 16 Oct 2012 14:49:44 +0200, Lars Segerlund wrote: I made a bit of a fool of myself asking about the best way to implement preempton disabled detection in the kernel, since it's already there I got he name for tracefs and googled, if you have a 'bad' system you can enable detection as per below: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_MRG/2/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-Realtime_Specific_Tuning-Using_the_ftrace_Utility_for_Tracing_Latencies.html http://lwn.net/images/conf/rtlws11/papers/proc/p02.pdf Together with running hwlat this should give a good indication where the preemption latency is coming from, BIOS/hardware or kernel. You can also have tracefs trigger on latencies larger than a preset value. / regards, Lars Segerlund. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] future base kernel version
There is the hwlat program in rt-tools and debugfs/tracing which will give max latencies. Note that the OSADL values are not from userspace ! Atleast the way I read ther documentation on the testing, so from userspace there will be a 'little' more jitter/latency . Here is some on the latency tracer, it's a beauty ! :-D http://lwn.net/Articles/97811/ Often you end up in drivers for specific hardware , but for tuning of the platform it's the same for all systems, ( RTAI/xenomai/rt-preempt ) ie. black-magick ! Search on linux kernel latency tracer and you will find a lot. My short list is disable power save, set rational swappiness, be sure to set rt-priorities ! / regards, Lars Segerlund. 2012/10/15 Kent A. Reed kentallanr...@gmail.com: On 10/11/2012 2:12 AM, Lars Segerlund wrote: Me thinks latest preempt-rt is preferable fx. there is a patch that shaves 100 uS of the arm worstcase ... ( in the tty driver of all places ) ... The biggest problem with preempt-rt is the tuning, to get good results we should do a little eality check ... ( ie. disable all power save , and so ) Before I went on holiday I had followed in Charles' footsteps to build preempt-rt kernels and test them on several Intel and AMD boards. The latencies I got weren't very good (although not wildly out of line with oasdl postings) and certainly not as good as Charles got with his particular boards. So far, I have been utterly unable to make any substantial difference tuning. Does a systematic tuning process exist? So far all I have is the usual laundry list of try this... suggestions. Regards, Kent -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] future base kernel version (was: Re: xenomai-integration: papers on Xenomai vs RT_PREEMPT perfromance, Xenomai overview)
Me thinks latest preempt-rt is preferable fx. there is a patch that shaves 100 uS of the arm worstcase ... ( in the tty driver of all places ) ... The biggest problem with preempt-rt is the tuning, to get good results we should do a little eality check ... ( ie. disable all power save , and so ) 2012/10/11 Michael Haberler mai...@mah.priv.at: Lars brings up a good question, namely: which kernel base version to use - the rt-preempt-integration and xenomai-integration branches are underway that needs to be decided, it would be unfair have developers out there dabbling with these ports and no path recommendation from this group. my take is: - for the reason Lars noted it would be better to use a 3.x base version - for a similar reason (getting in the latest adeos patch) xenomai-integration better be used on more recent kernels than 2.6 - I have yet to discover a problem running a 3.x kernel with an Ubuntu 10.04 userland environment in case anybody dies to have that combination - the lock-in to 10.04 came with the 2.6.* RTAI lock-in (or at least so I understand it) - a newer kernel opens the option of moving beyond 10.04lts from what I collected so far, Linux 3.2.21 seems the latest 3.x series supported by xenomai, which maps fine onto the Ubuntu LTS/kernel version list: http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html (precise LTS being the target platform) for RT_PREEMPT I'm open to suggestions - please share; by default I'd go for the same base version as the xenomai kernel RTAI: let's hope and pray for Paolo's health and time - any news on 3.x RTAI ? -Michael ps: an atom/3.2.21/xenomai setup guide: https://code.google.com/p/atrias/wiki/XenomaiSetup Am 11.10.2012 um 07:24 schrieb Lars Segerlund: One note though, on preempt-rt, this is a 2.6.33 kernel, which have the BKL ... rt-preempt later than 3.1 or 3.2 should do a lot better for the worst case, ( not saying that they do :-D ... ). / Lars Segerlund. 2012/10/11 Michael Haberler mai...@mah.priv.at: Amit (aka automata on IRC), who has taken the initiative on xenomai integration, kindly sent me these links which I found very interesting: https://www.osadl.org/fileadmin/dam/rtlws/12/Brown.pdf - comparing rt_prempt v/s xenomai performance retis.sssup.it/~lipari/courses/str07/xenomai-handout.pdf - good introductory overview of Xenomai - Michael -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] future base kernel version (was: Re: xenomai-integration: papers on Xenomai vs RT_PREEMPT perfromance, Xenomai overview)
HI folks, I dont think it matters much for the RT-PREEMPT kernels, since they are at 3.4+ at this moment I don't know if it's 3.5 or 3.6 that's the latest. But at the moment I don't think it matters, since it's using the POSIX API. Atleast for debian, I used to compile the latest kernels to run on production machines, I see no or little added value from distro patches, RH is a bad example ... So I would say go with latest that the distro supports, and if considering something else I would consider the kernels marked for 'long time support' by Linus Friends ... RTAI Xenomai are more dependent on the version and thus can decide, as long as it's as new one as possible. 2012/10/11 EBo e...@sandien.com: Michael, Quite right, and I am sorry for jumping in without noting that the last time I poked around the kernel folks were focusing on the 3.2.14 for integration (so it was not just me). At that time I had been bouncing ideas back and forth with someone (Lars?) and that seemed to be the most stable sources. I do believe that this is all based off of the vanilla kernel sources. If I were not so busy at the moment I would dig through my notes and see if I could outline the various groups we were tracking for RT patches and make sure we were all talking about the same folks. So, please accept my apologies for the knee jerk comment and not detailing it a bit more thoroughly. EBo -- On Thu, 11 Oct 2012 21:05:54 +0200, Michael Haberler wrote: Ebo, I would think this requirement is driven more from the availability and performance side of RT patches than from what certain distros do, and me must make a priority decision here between 'tracking a given distro' and 'having a recent kernel' - note we are just pulling our leg out of a version trap (although that came with a kernel version, not a distro) of course it would be nice if we found a matching kernel in some distro, and that doesnt exclude such matching kernels are built - I'm discussing with Seb how we can set up a buildbot scheme for kernels - (NB: plural) so if somebody comes around and supplies patches that should find its way there so such a matching kernel for say Xenomai is automatically built assuming Lars is right - which I dont doubt - then the RT_PREEMPT kernel will have to be pretty much bleeding edge and generic, like this: http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/ -- What I am completely unclear about, and what I would appreciate being educated about - what are the compatibility issues of running a non-distro kernel on say Ubuntu 10.04 or 12.04 - I do that all the time, and still have to fund a problem, so I'm a bit unsure what the actual value-add of distro-specific kernel patches is - Michael Am 11.10.2012 um 19:52 schrieb EBo: On Thu, 11 Oct 2012 08:02:14 +0200, Michael Haberler wrote: ... from what I collected so far, Linux 3.2.21 seems the latest 3.x series supported by xenomai, which maps fine onto the Ubuntu LTS/kernel version list: http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html (precise LTS being the target platform) for RT_PREEMPT I'm open to suggestions - please share; by default I'd go for the same base version as the xenomai kernel ... my 2c would be to pick 3.2.14 for one of the kernel numbers as that is the newest version that has been integrated into a couple of distributions. If Ubuntu has a different one they are throwing resources into, then that might not be a bad choice after all. Just to throw it out there, we could look at a TinyCoreLinux version. That would run bootable off of a small USB drive, and can be installed on a machine. Jut thinking out loud... EBo -- -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Don't let slow site
Re: [Emc-developers] xenomai-integration: papers on Xenomai vs RT_PREEMPT perfromance, Xenomai overview
One note though, on preempt-rt, this is a 2.6.33 kernel, which have the BKL ... rt-preempt later than 3.1 or 3.2 should do a lot better for the worst case, ( not saying that they do :-D ... ). / Lars Segerlund. 2012/10/11 Michael Haberler mai...@mah.priv.at: Amit (aka automata on IRC), who has taken the initiative on xenomai integration, kindly sent me these links which I found very interesting: https://www.osadl.org/fileadmin/dam/rtlws/12/Brown.pdf - comparing rt_prempt v/s xenomai performance retis.sssup.it/~lipari/courses/str07/xenomai-handout.pdf - good introductory overview of Xenomai - Michael -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Q: do HAL signals exist independently of components yes/no?
If were looking at protocol buffers , I think upb , https://github.com/haberman/upb/wiki would be nice to look at. / Lars 2012/9/22 Michael Haberler mai...@mah.priv.at: Am 21.09.2012 um 20:55 schrieb Kent A. Reed: On 9/21/2012 1:53 PM, Michael Haberler wrote: Am 21.09.2012 um 18:22 schrieb Kent A. Reed: On 9/19/2012 6:30 PM, Michael Haberler wrote: -- when the time has come to send a status update message, go through the member list, pull current values, and create a status message (this would have to call upon the serialisation method employed in the future, for instance Google protocol buffers, or JSON, or whatever we decide on) ... I only know JSON, and that not so well. Is there some simple but relevant benchmark that could be cobbled up to explore it vs the rest of the contenders? There are some, but I'm unsure whether they are terribly relevant for us, e.g. http://stackoverflow.com/questions/2000933/protocol-buffers-versus-json-or-bson http://www.4feets.com/2009/08/serializing-data-json-vs-protocol-buffers/ the overall criteria I'm looking at are (roughly in descending importance): - degree of, and options for type checking (iow: IDL-based versus loose typing; I'm very lukewarm about loosely typed approaches here even if they are 'convenient') - bindings for 'our languages' available without resorting to low-level API's - support for introspection (e.g. inspecting variant messages), again without low-level API's - support for optional, 1-n-repeated fields, and reuse of existing 'submessages' (compound structures) - versioning support without need for recompilation - language independence (for instance, cuts out Python pickle - no decent C support) - size and fit of user base, and developer community - avoid one-man shows - quality of documentation and examples - maturity of packaging - community fit - the technology must be easily understandable and 'close' - no esoterics please - conversion to/from textual external representation automatic (iow: you can write a stream of motion commands with the editor, and play it; or record one) - encoding/decoding speed - only one aspect - transport-mechanism independence - no integrated serialisation plus RPC thingies - one function only - external dependencies (e.g. malloc required or not? if yes: here comes your memory leak;) - suitability for in-kernel use - not sure if thats really needed This is a great list, Michael. Not that it matters, but I'm not sure I'd order it in quite the same way. Language independence and high-level bindings for our languages seem to me equal in importance and almost a meta-must. Auto-conversion to/from external text representation is a big winner for me. It's a godsend for developers, bug chasers, those learning the system, talented hackers. As well, it's a nice reflection of the Tao of Unix. Type checking is an interesting subject. I went from one extreme with CORBA and IDL to the other extreme with a pub/sub infrastructure that cared only that the XML messages being passed around were well-formed. I assume you see a middle ground. I used to think IDL's are just another dependency which create a clunker of auto-generated code which nobody cares to read and is hell to find a bug in; and there's something to that but there's one aspect which makes an IDL like protobuf extremely convenient - namely if it autogenerates a high-level binding for a message format; for example the following is hard to beat by manual coding: 1. define a message format like here: http://git.mah.priv.at/gitweb/emc2-dev.git/blob/93d0baf050f68989b07ac71b60b976f982c7ee70:/src/hal/halnotify/report.proto 2. compile it into Python bindings like so: hal/halnotify/report_pb2.py: hal/halnotify/report.proto protoc $(PROTOC_FLAGS) --proto_path=hal/halnotify/ \ --python_out=hal/halnotify/ hal/halnotify/report.proto 3. write a real complex application for said message format like so: http://git.mah.priv.at/gitweb/emc2-dev.git/blob/93d0baf050f68989b07ac71b60b976f982c7ee70:/src/hal/halnotify/sub.py 4. and get the thing into Python fully automatic, with external representation (and back too - not shown here): http://git.mah.priv.at/gitweb/emc2-dev.git/blob/93d0baf050f68989b07ac71b60b976f982c7ee70:/src/hal/halnotify/sub.log - Michael My current ordered short list is protobufs, and with some distance followed by BSON and then Json; I have most experience with protobufs and after a while found it very easy going; the learning curve is OK and documentation support fine. wrt benchmarking, I guess what I'll do is record a motion and status stream for a few sample programs to arrive a 'typical' message type distribution, and build a strawman encoder/decoder for the say top 80% and see how that fares; note the current use is heavily tilted towards emcstat retrieval which need not be if change- or event driven updates were
Re: [Emc-developers] question re RT PREEMPT linux on ASUS Atom board
I did not do it for emc I hinted that we should look at doing it. I have used exactly the code you linked for my rt-code ( not EMC ) ... basicly you mlockall() and then fault all pages you are going to use, after tuning glibc to never trim the heap. So basicly lock all rt parts in memory fault all pages and then run. / Lars. 2012/9/14 Michael Haberler mai...@mah.priv.at: Am 14.09.2012 um 06:30 schrieb Kent A. Reed: With the RT PREEMPT system, this board gives lousy results even running headless. Using latency-test, for some minutes I see the base (25us) thread showing a max latency of anywhere from 25us to 40us and the servo (1000us) thread 40us to 50us. Then, the servo thread pops a bit and the base thread pops a lot, to about 110us. At the same time, the kernel throws three lines to the console ERROR: Missed scheduling deadline for task 0 [ times] Now is x.xxx, deadline is x.xxx Absolute number of pagefaults in realtime context: 1030 I guess this could be mitigated by pre-page faulting all RT code into memory this example deals with the issue: https://rt.wiki.kernel.org/index.php/Threaded_RT-application_with_memory_locking_and_stack_handling_example Lars: you also hinted at that - how did you do it? -m -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] question re RT PREEMPT linux on ASUS Atom board
Which still doesn't affect the pagefaults ... tricky this I will have a look when I get home today, I don't have systems running the code here . / Lars 2012/9/14 Steve Stallings steve...@newsguy.com: Hi Kent, I have NO experience with doing this sort of build, but have to wonder if it is significant that your target is an Atom D510 cpu, yet you list a kernel for amd64. Regards, Steve Stallings -Original Message- From: Kent A. Reed [mailto:kentallanr...@gmail.com] Sent: Thursday, September 13, 2012 11:31 PM To: EMC developers Subject: [Emc-developers] question re RT PREEMPT linux on ASUS Atom board Gentle persons: First, a statement. On my ASUS AT5NM10-I board (Intel Atom D510 CPU, 2GB RAM, yada yada yada) I followed in Charles Steinkeuhler's footsteps (http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Debian_Wheezy_Linux- Rt_Compile_LinuxCNC) to build a 64-bit Debian Wheezy RT PREEMPT Linux system running the 3.2.0-3-rt-amd64 kernel and Linuxcnc 2.6.0~pre. Such a build has given Charles some decent albeit not (yet) great latency numbers on several non-Atom boards. My ASUS board has given me excellent latency results with what I'll call classic Ubuntu 10.04LTS LinuxCNC running the 2.6.32-122-rtai kernel: sub 10us for both threads with Hyperthreading disabled in the BIOS and one cpu isolated during the boot process. big snip Has anyone with a different Atom board, preferably an Intel-branded board, loaded and tested Wheezy with Linux-RT and LinuxCNC? If so, what's your experience? Regards, Kent -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] question re RT PREEMPT linux on ASUS Atom board
Unfortunately trye for x86 hardware ... and even then , sometimes you have bad luck with the hardware :-( Hmm, I am missing a rttop progrram, like powertop , but different . :-) ... Lars 2012/9/14 Kent A. Reed kentallanr...@gmail.com: Thanks, Jan, Lars, Michael, Charles, Ken, and Steve for your thoughts. I'll have to cogitate a bit on what to do next, but I can answer Steve off the top of my head. Two pre-built realtime kernels are available from the Debian Wheezy repository. The amd64 build is for 64-bit amd and intel processors; there is also a 32-bit 3.2.0-3-rt-686-pae build. That's what I alluded to in my third agenda item to try. muttered aside Yes, I know I could custom-build my own kernel, but there comes a point where I say enough, this isn't just tweaking any more. It took LinuxCNC (well, ok, EMC2) a while to get to the point where a LiveCD distribution just works for most folk. I'm hoping it doesn't take as long for our use of these alternative realtime platforms to stabilize in the same way, especially since I believe they are necessary alternatives. If using RT PREEMPT or Xenomi approaches requires more than a straightforward tuning-your-system checklist, then I don't know how we'll make the alternatives attractive to our user base let alone attract new classes of users. That would be unfortunate. /muttered aside It's clear to me from your responses that if I want to run with the big dogs I have to learn how to instrument a realtime environment :-) Regards, Kent On 9/14/2012 8:05 AM, Steve Stallings wrote: Hi Kent, I have NO experience with doing this sort of build, but have to wonder if it is significant that your target is an Atom D510 cpu, yet you list a kernel for amd64. Regards, Steve Stallings -Original Message- From: Kent A. Reed [mailto:kentallanr...@gmail.com] Sent: Thursday, September 13, 2012 11:31 PM To: EMC developers Subject: [Emc-developers] question re RT PREEMPT linux on ASUS Atom board blah blah blah -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] question re RT PREEMPT linux on ASUS Atom board
That graph looks a bit funky Perhaps you should try to run hwlat ? ( module ) ... to see if there are some SMI or similar, you can also use latency tracing in the kernel to see where the offender is Can you see what rt-priority the system is running with ? 110 looks like a bit over the top. How about asking on the rt-preempt mailing list ? linux-rt-us...@vger.kernel.org 2012/9/14 Jan de Kruyf jan.de.kr...@gmail.com: Hallo, this is the plot from this board with a slightly different cpu, under reasonable load: https://www.osadl.org/Latency-plot-of-system-in-rack-4-slot.qa-latencyplot-r4s7.0.html You might look up there also exactly how they do their tests. The Pagefault message says that the LCNC memory is not properly locked in place (i.e. the kernel needs to page, it should not) So I would say, speak to your friendly software developer, or if you really want to try, throw lots of memory at it and hope the kernel stops paging after a while. By the way you can also look up the kernel compile switches here: https://www.osadl.org/Profile-of-system-in-rack-4-slot-7.qa-profile-r4s7.0.html and try to build a new kernel. At first I thought the problem might be there, but the pagefault message convinced me otherwise. cheers, j. On Fri, Sep 14, 2012 at 6:30 AM, Kent A. Reed kentallanr...@gmail.comwrote: Gentle persons: First, a statement. On my ASUS AT5NM10-I board (Intel Atom D510 CPU, 2GB RAM, yada yada yada) I followed in Charles Steinkeuhler's footsteps ( http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Debian_Wheezy_Linux-Rt_Compile_LinuxCNC ) to build a 64-bit Debian Wheezy RT PREEMPT Linux system running the 3.2.0-3-rt-amd64 kernel and Linuxcnc 2.6.0~pre. Such a build has given Charles some decent albeit not (yet) great latency numbers on several non-Atom boards. My ASUS board has given me excellent latency results with what I'll call classic Ubuntu 10.04LTS LinuxCNC running the 2.6.32-122-rtai kernel: sub 10us for both threads with Hyperthreading disabled in the BIOS and one cpu isolated during the boot process. With the RT PREEMPT system, this board gives lousy results even running headless. Using latency-test, for some minutes I see the base (25us) thread showing a max latency of anywhere from 25us to 40us and the servo (1000us) thread 40us to 50us. Then, the servo thread pops a bit and the base thread pops a lot, to about 110us. At the same time, the kernel throws three lines to the console ERROR: Missed scheduling deadline for task 0 [ times] Now is x.xxx, deadline is x.xxx Absolute number of pagefaults in realtime context: 1030 This process repeats but not at regular intervals. Using latencyplot, I can see that, with nothing else running, both threads mostly show good latency numbers, typically 10us, once we've settled down after invoking latencyplot. If I run a copy of glxgears, the servo thread latency gets jumpy but stays below about 40us. Running several copies of glxgears doesn't seem to cause any more damage, nor does invoking du or some other disk access-intensive command. Sooner or later, though, the above big-time event happens. Repeat ad nauseum. I've done everything I can think of. I've diddled all available BIOS settings (this is not an enthusiast board; it has only a limited number of settings); stopped the kernel from loading just about any non-essential module; preventing many services from starting. No gdm, no X, no Intel i915 driver, no acpid, no alsa, no pulseaudio, yada yada yada. About the only things I haven't tried are (1) trying Charles' suggestion of playing with cpusets, mostly because I don't understand them well enough yet to trust myself, (2) ripping out some more modules that relate to sound (with names snd*; alsa and pulseaudio stuff is already gone), mostly because I'm not sure who's loading them, and (3) redoing all this with a 32-bit Debian Wheezy, mostly because getting Debian Wheezy systems into this machine is a bore (the Wheezy installer is broken somewhere in the disk partitioning process and why should I be the one to fix it when others have been complaining forever). Now, my question. I'm wondering if my results are intrinsic to the Atom architecture or specific to the ASUS BIOS. Has anyone with a different Atom board, preferably an Intel-branded board, loaded and tested Wheezy with Linux-RT and LinuxCNC? If so, what's your experience? Regards, Kent -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Raspberry Pi running EMC ???
A quick question, youre running preempt-rt on a raspberry pi, I might be wrong on this, but I think there is a patch for the linux kernel lowering the latency for context switching by running in a single virtual adress space ( ie. the arm doesn't have to copy the caches when it context switches ). If the patch is appliable to your cpu it would lower latency MUCH. If not I am barking up a tree .. :-D I don't remember much but it was similar to this, worth checking out http://www.denx.de/en/pub/News/Xum2009AbstractsAndPresentations/The_ARM_Fast_Context_Switch_Extension_for_Linux.pdf Were talking ARM 5 here / regards, Lars Segerlund. 2012/9/8 Michael Haberler mai...@mah.priv.at: I've done some bit-bang timing measurements for the Raspberry GPIO pins see http://linuxcnc.org/index.php/english/component/kunena/?func=viewcatid=18id=20514limit=6start=48#24062 I'm not saying the Pi has many cycles left at 220nS transition spacing, but the 'slow ARM IO myth' seems to be just that, memory mapped IO is roughly an order of magnitude faster than I ever got with a PC parport driven from a user process; interrupt latency is another issue but GPIO in this style doesnt use it - Michael Am 20.07.2012 um 16:30 schrieb Charles Steinkuehler: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/20/2012 9:11 AM, Kent A. Reed wrote: On a more serious note, as has been discussed on the two emc mail lists, the road to ARM is littered with ideas but so far we have little result. The nicely done miniEMC2 project by Sergey Kaydalov is the most complete effort I know of. It employed the higher-latency Xenomi code rather than RTAI. Inquiring minds want to know more about the possibility of porting this code or something like it to boards like the RPi or BB and about the resulting performance attainable. I wish I could have tackled this already but I've got too many family issues at the moment. I'm planning on trying to use the PREEMPT_RT version of LinuxCNC with my Pi when it comes in, but I'm not sure what sort of latencies to expect. On conventional PC hardware, I've gotten decent latency jitter with modern systems, but not yet down to the RTAI levels. On older hardware latency with PREEMPT_RT is much worse, particularly on single-core systems (although I don't yet know if this is due to not having two cores to schedule between or because all my single-core systems are pretty ancient). I'm also hoping on the Arm it might be possible to use the fast IRQ and read/write the I/O pins in an ISR which may allow the servo thread to run with much higher jitter. Then there's the problem of gluing these boards to our CNC hardware about which I yield to Jon. My current plan is to bit-bang GPIO pins based on code from the parallel port driver, but adding a bit of electronics would probably make things much easier. I'll evaluate that option once I see where I get with software stepgen. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAJa6IACgkQLywbqEHdNFyNjwCfTVchMrwrcmA2RZ78hoYM0OEa zn0AoOyTZa74B1MnFaDOL2HqUxG5LwOH =Dmby -END PGP SIGNATURE- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https
Re: [Emc-developers] build system [was: master sim+rip build on 64-bit 12.04LTS]
I have experience with it, it's just another case of let's reiinvent the build system, I do not wish to air my opinion of it publicly, since I would be sued for defamation What's wrong with autoconf friends ? They are cross platform, have few dependencies and can do everything Anyhow, everytime one uses a new build system, time goes on and five or ten years later the archives are unbuildable . I prefer to keep it simple and take the pain ... rather now than later. Just my 5 cents / regards, Lars Segerlund. 2012/9/6 EBo e...@sandien.com: On Thu, 6 Sep 2012 08:34:38 +0200, Michael Haberler wrote: ... LinuxCNC isnt the only project in this situation; some are developing cmake build instructions in parallel while leaving the existing autoconf stuff in place until the new way stabilizes. I've had a lot of problems in the past with cmake. Has anyone taken a look at other multi-platform solutions like Jam? It has been a number of years since I have used both Perforce's Jam and its derivative Boost Jam and Boost Build. And before getting all medieval on this post about C++ dependencies, Boost's Jam and Build at least were maintained independently so that they could be easily used for other projects without requiring Boost libraries. While drafting this email I came across references for SCons. Since we have been talking about general python support, this might also be a decent option, but I have no personal experience with it. I found the following link informative http://www.scons.org/wiki/SconsVsOtherBuildTools EBo -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] zombie hal configuration on preempt_rt system
Hi again, no problem here it was more of a pun on 'no forking way' :-D ..
/ Lars
2012/9/4 Kent A. Reed kentallanr...@gmail.com:
On 9/4/2012 1:54 AM, Lars Segerlund wrote:
The standard way to demonize a process is to do a double fork and
close the file handles so I just speculated that this was a case
of unintentionally doing that, as soon as you 'loose the parent' or
don't have any resources to it, the process will be attached to init's
PID , so check the parent of the 'zombies' parent PID.
As for my contorted use of the english language, 'No forking way !' .
( Sorry for my bad english ... )
/ regards, Lars Segerlund.
Lars:
It was late; I was tired; I was looking for a snarky comeback to two
forks involved. The first thing that came to mind was Yogi's remark. No
way was I critiquing anyone's use of English. I've had 68 years of
experience with it and still make mistakes (even *cough* on this list
*cough*).
I could just as well have responded that my dad used to complain that I
was a two-fisted eater, so of course two forks are involved.
To get serious for a moment, I expect my problem lies in the changes
made to scripts/realtime as part of the preempt_rt work ('owner' changed
to root, s-bit set, 'group' has r/x permissions, 'other' has no
permissions) but I haven't walked the code to see why those changes are
needed and what the consequences are. Too busy today at doctors and such.
Regards,
Kent
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] zombie hal configuration on preempt_rt system
Is there by any chance two forks involved ? :-D / Lars. 2012/9/3 Kent A. Reed kentallanr...@gmail.com: Gentle persons: I've been experimenting with the results of the hard work of Charles Steinkuehler, John Morris (and others whose names I confess I've forgotten at the moment) to get LinuxCNC running over the preempt_rt kernel. I seem to be able to create a zombie hal configuration. System: ASUS AT5NM10-I motherboard, 2-cpu Atom, 2 GB ram, Debian Wheezy, 3.2.0-3-rt-686-pae kernel, LinuxCNC 2.6.0~pae, gdm (and X-server) killed, running headless to a remote X-server. Symptom: Start up latency-test; kill it rudely 1) by a ctrl-c at an some inopportune moment, after which it may die gracefully or it may become a zombie or 2) by closing the terminal window I invoked it from, after which it seems reliably to become a zombie What do I mean zombie? Well, a halcmd show shows that the hal configuration didn't get cleaned up. All the components are still loaded and wired up and the two threads still exist. Trying to invoke latency-test a second time gets me a string of error messages all to the point that I'm trying to duplicate stuff already loaded and also introducing a new message that comes from the preempt_rt work: could not find cpusetfs mount point. I can't seem to kill this hal configuration by the usual methods as an ordinary user even though I started latency-test as myself. The only method I got to work was to invoke halrun as root: sudo scripts/halrun -U. Any comments Regards, Kent -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] zombie hal configuration on preempt_rt system
The standard way to demonize a process is to do a double fork and close the file handles so I just speculated that this was a case of unintentionally doing that, as soon as you 'loose the parent' or don't have any resources to it, the process will be attached to init's PID , so check the parent of the 'zombies' parent PID. As for my contorted use of the english language, 'No forking way !' . ( Sorry for my bad english ... ) / regards, Lars Segerlund. 2012/9/4 Kent A. Reed kentallanr...@gmail.com: On 9/3/2012 4:31 PM, Lars Segerlund wrote: Is there by any chance two forks involved ? :-D / Lars. Undoubtedly, but why do I feel like Yogi Berra just walked in? (Widely quoted because of his tortured use of the English language, while giving directions this American baseballer once advised a friend when you come to a fork in the road, take it.) Regards, Kent 2012/9/3 Kent A. Reed kentallanr...@gmail.com: Gentle persons: I've been experimenting with the results of the hard work of Charles Steinkuehler, John Morris (and others whose names I confess I've forgotten at the moment) to get LinuxCNC running over the preempt_rt kernel. I seem to be able to create a zombie hal configuration. ... -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] found a really god pdf on rt-preempt programming ...
Thanks ! :-D 2012/8/31 Jon Elson el...@pico-systems.com: Lars Segerlund wrote: Ok, I will check how the latency in device drivers are, perhaps they are not so bad, atleast for x86 , I was thinking arm someone was mentioning they had to do some copying on interrupts ( ie, context switches ... ). Lets investigate, it's no worse than a scope to the parport and setting one pin with outb and another with a driver. I've already done this in user mode on the Beagle Board. You can't change the state of a GPIO pin faster than 240 ns. Apparently the GPIO hardware is multiplexed, and the hardware scans each GPIO bank every 240 ns. It appears the CPU goes into a wait state until the GPIO performs the action requested. Somebody on the Beagle list claims a device driver is much faster, but I have doubts he measured it right. On x86 hardware, motherboard parports are pretty slow, so you can't flip a parport bit much faster than 500 ns or so. But, it would be fine for testing interrupt latency and jitter. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] found a really god pdf on rt-preempt programming ...
Thank you, I will go RTFM this was the pointers I needed. / Lars 2012/8/30 Jon Elson el...@pico-systems.com: Lars Segerlund wrote: Nicely presented, and I liked the clarity of it, enjoy. http://free-electrons.com/doc/posix-api.pdf The killer might be to talk to hardware through device drivers . There are methods to access hardware from user mode, but it requires super-user privileges set on that executable. The RT system or rtapi may take care of that for you, I don't know preempt. But, once you have the privilege, iopl() will open access to a range of I/O ports for x-86 style hardware. there is an mmap function to access memory-mapped hardware on the ARM CPUs, and I have worked out how to do that on the Beagle Board. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Parallel Port Expansion via I2C/SPI
Why do you not hang them on USB ? Something like a FTDI breakout and then SPI if you can find working examples it's a nice solution, you dont gett the speed of the parport BUT for temperature there usually is some lag. You could also run an 8 bit micro on a serial line :-D . it has AD's and DA's just a thought. / regards, Lars Segerlund. 2012/8/30 Charles Steinkuehler char...@steinkuehler.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Now I've got LinuxCNC (both RTAI and PREEMPT_RT) connected to my 3D printer and moving around the X/Y/Z/A(E) axis, I need to get some temperature control wired up. I would like to just hang a few ADCs off of some parallel port pins programmed to function as an I2C bus. So...has anyone implemented a serial expansion protocol such as I2C or SPI via the parallel port for LinuxCNC? It's pretty easy to bit-bang these protocols, but the code would have to gracefully co-exist with software stepgen. Throughput wouldn't really matter much, as the thermal time constants are pretty long so even a few samples/s would probably enable a working PID loop. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA+kxoACgkQLywbqEHdNFzE2ACfZjANxZ9pu3CalFbmqKxV6Den 81cAoLsZCGf6JGn8PvVyzSyPwnOoEWsh =oKWH -END PGP SIGNATURE- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] found a really god pdf on rt-preempt programming ...
As for now, we can run as root, and get around the problem :-D / Lars 2012/8/30 John Kasunich jmkasun...@fastmail.fm: On Thu, Aug 30, 2012, at 08:48 AM, andy pugh wrote: On 30 August 2012 05:16, Jon Elson el...@pico-systems.com wrote: There are methods to access hardware from user mode, but it requires super-user privileges set on that executable. The RT system or rtapi may take care of that for you, I think rtapi already includes rtapi_inb() and rtapi_outb() which presumably (hopefully?) could be abstracted. A lot of the drivers don't actually use them, but could presumably be made to. rtapi_inb() and rtapi_outb() alone won't be able to do the job. It looks like some separate preparatory work needs to be done, such as requesting access to the ports. That is a one-time thing that needs to be done as part of component initialization, rather than at each port access. So another function would be needed to wrap that. It could be a do-nothing function for kernel module based code, and do whatever is actually needed for rt-preempt based code. -- John Kasunich jmkasun...@fastmail.fm -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] found a really god pdf on rt-preempt programming ...
Ok, I will check how the latency in device drivers are, perhaps they are not so bad, atleast for x86 , I was thinking arm someone was mentioning they had to do some copying on interrupts ( ie, context switches ... ). Lets investigate, it's no worse than a scope to the parport and setting one pin with outb and another with a driver. / Lars 2012/8/31 Jon Elson el...@pico-systems.com: andy pugh wrote: On 30 August 2012 05:16, Jon Elson el...@pico-systems.com wrote: There are methods to access hardware from user mode, but it requires super-user privileges set on that executable. The RT system or rtapi may take care of that for you, I think rtapi already includes rtapi_inb() and rtapi_outb() which presumably (hopefully?) could be abstracted. A lot of the drivers don't actually use them, but could presumably be made to. Well, this would be fine for X-86 architecture, but not on memory-mapped ones like ARM. But, if their versions of inb() and outb() are different from the ones we use now, that would require some work in rtapi, I guess. It would be nice if we don't have to call a wrapper routine that calls a wrapper routine to do these functions, too. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] heads up: redis integration into master imminent
Well , to get a ubuntu packet, generally if you make a debian one youre pretty much done I want to add my 2 cents also, it would be really nice to have a setup for the fabbing guys for repraps, mendels and such ... that they can run straight out of the box .. I think that would get a bit of userbase, and there should be a tinkerer or two in there. So if we can keep the core simple, and add complexity as needed ? RIght now we have to dive into the middle of it to get off the ground. Compared to Mach3 and such , linuxcnc is a bit intimidating .. / regards, Lars Segerlund. 2012/8/29 Kent A. Reed kentallanr...@gmail.com: On 8/29/2012 8:16 AM, Michael Haberler wrote: However, I think creating a LinuxCNC*simulator* package and pushing this into some repo stream whould be a great way to improve LinuxCNC visibility - the CD requirement is a bit of a turnoff for a casual evaluator. http://askubuntu.com/questions/16446/how-to-get-my-software-into-ubuntu, while one step removed from the official statements, has a useful overview of the process; it touches on both Debian and Ubuntu. Having a simulator in a package repository is a nice touch but I don't consider the CD requirement to be a spoiler. As a LiveCD (more likely used as a live memory stick these days) it allows one to assess LinuxCNC without messing with a working system no matter the O/S or its dialect. As well, I believe even casual evaluators come to CNC software via developers' websites and not via a search of their system's package repository. I'll grant there are potential users lacking adequate Internet access who don't like downloading a CD image, but the whole install/update/upgrade philosophy of many Linux distributions is predicated on Internet access so I consider this issue a wash. Just my 2 cents worth. Regards, Kent -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] found a really god pdf on rt-preempt programming ...
Nicely presented, and I liked the clarity of it, enjoy. http://free-electrons.com/doc/posix-api.pdf The killer might be to talk to hardware through device drivers . -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] AVR Chips
What I was thinking is do the kinematics on the PC and just dump positions per axis on the avr . point in time and space so to speak it should work to stream to it ... I mean it's an open loop system ? / Lars 2012/8/29 EBo e...@sandien.com: Actually I do not mind. If it is going to move off list, please include me... On Wed, 29 Aug 2012 11:32:21 -0500, Charles Steinkuehler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry for the noise...I didn't notice reply was set to go to the list and not the original sender. :( - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA+RBUACgkQLywbqEHdNFzQugCcDy/YHcKTlLs8kCXLCAL0g2vR jpgAn1glw42e6LKA5ezfTpbRYlOTVDhZ =F+rA -END PGP SIGNATURE- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC RT OS underpinnings
2012/8/28 John Kasunich jmkasun...@fastmail.fm: On Tue, Aug 28, 2012, at 01:50 AM, EBo wrote: Well, I am a strong proponent of eXtreme Programming (XP) and similar Test Driven Development (TDD) methodologies. They can be overdone though... The nice thing about these discussions is that we could use them to start to develop an automated test suite and work away on various parts until the tests succeed (the XP approach). Even if you tare the code base down and start over again the test suite provides its own resource. In addition, when you move from one platform to another you can use this as a base level test to verify that it is working as expected. So I would agree lets blue sky this puppy, but lets start small... I want to raise a red flag about XP and other test driven development methods. They work fine for deterministic situations, but you can't use testing to prove the absence of race conditions and other rare bugs that can occur when doing realtime programming. It is very easy to write code that will work fine until one instance of the program happens to interrupt another during that single line of code that isn't properly re-entrant. Said interrupt may happen once a year, or less, and testing will never find it. Realtime stuff needs to be designed like hardware, not software. Hardware engineers have long and expensive prototyping cycles, so they do their absolute best to get it right and know it is right. I've been following this thread with some interest. RTAPI was designed with the goal of making it relatively simple to add new RTOS's as they became available, and I would hope that is still true. In theory, no code other than rtapi itself should need to be changed. However, the build system is another thing all together, and I'm sure adding the option to build for RT-PREEMPT instead of RTAI or user-space sim mode will be a major task. Yes it is :-D . but it's been deno before, so lets check the old patches out ? Any chance to give the makefiles a rework ? :-D If any significant work is going to be done in RTAPI, the first step should be to read rtapi.h, then go grepping through the codebase and see what subset of rtapi.h is actually used. I'm 99.94% sure that LCNC does not use RTAPI FIFOs, so they should be dropped. (When I defined RTAPI, I was young and foolish and didn't know about http://c2.com/cgi/wiki?YouArentGonnaNeedIt). RTAPI was nice looking at ! ... no biggie there ... -- John Kasunich jmkasun...@fastmail.fm -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC RT OS underpinnings
A bit of both, but a man can dream and laugh at the same time . I have been trying to drive a laser diode ( pointer ), modulated at several frequencies to get absolute measurements, they have a feedback diode built in so it's possible, just filter out the multiple modulation frequencies, get the phase shifts, and viola ! the absolute distance, but not much precition, hard to get less than a micrometer. Its just for fun, and not working to well, if you try it, be sure to buy the diodes in bulk the feedback loop must be stable with the 250 - 500 MHz high frequency of the modulation signal :-D It seemed like a good idea at the time :-D , the diodes were around $300 a piece at that time never got it right . It's hard to build phase detectors at these frequencies with discrete components. VARIAX used time of flight as I understand it. So a failed dream and a bit of pun for all the 'steppers are no good' folks ... :-D It was soo much easier n paper :-D What I'd really like is some netzler linear capacitive absoulte scales :-D ... simpler and available, but too expensive. I don't think linear drives are used except in EDM and ECM but I could be wrong, not enough holding tourque. / regards, Lars. 2012/8/29 EBo e...@sandien.com: On Wed, 29 Aug 2012 00:10:08 +0200, Lars Segerlund wrote: ... When it comes to hardware, no one can deny servos and encoders, but that's not necessary or the reality for many, for serious work only linear servos and absolute sensing lasers with interferrometric enhancement will do. Huh... are you serious with the linear servos and LDM? Or were you just joking? EBo -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC RT OS underpinnings
Was there anything about mutexes ? :-D ( joke ok ? ) 2012/8/29 Kent A. Reed kentallanr...@gmail.com: On 8/28/2012 6:30 PM, Sebastian Kuzminsky wrote: (after a nice synopsis of what the Coverity analysis does Here's the full documentation, you might need a Scan account to read it (i'll be happy to make a scan account for any linuxcnc developer who wants it): http://scan5.coverity.com:8080/docs/en/webhelp/content/bk04ch01s04s03.html Sebastian set up an account for me earlier this afternoon. Thanks. I've downloaded a .csv summary of the 350+ bugs Coverity* identified in some version of 2.5 as it stood in February, brought the .csv file into OpenOffice, deleted a number of columns that have no meaning for us since we haven't set up the project management scheme they reflect, and sorted the resulting table on the fully qualified source file name. Give a few minutes to get these files up to a public server and I'll tell you where it is. This can be compared to the 56 bugs reported by Clang on the current v2.5_branch (sorry, things are a bit out of sync because of the time displacement, but it will be instructive anyway). The Clang bugs can be seen referenced to the actual offending lines in the source code on the buildbot site. A Coverity/Scan account will be needed to see the Coverity-identified bugs referenced to the actual offending lines in the source code. Make sure you have an extra large cup of coffee at hand before you start. Regards, Kent *They seem to be calling this online site the Coverity Integrity Manager now, although it has a scan5.coverity.com URL, and make reference to the Coverity Analysis Tools. Maybe I'm just confused by the nomenclature. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] anybody running LinuxCNC with the RT_PREEMPT patch?
I am ... what do you want to know ? / Lars 2012/8/27 Michael Haberler mai...@mah.priv.at: please get in touch with me thanks -Michael -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] anybody running LinuxCNC with the RT_PREEMPT patch?
Check out www.osadl.org they have a test rack with timings, for arm, mips, x86 amd64 and some. There should be a page to the wiki there to. Usually if you have bad hardware or a bad driver it will be a no go, but if you have good hardware it should work fine, when checking the numbers remember these systems are under heavy load. Also if testing, don't forget to set RT priority ! ( btw. there is a debian rt-preempt kernel , try it So an decent hardware you will not get below 10 us jitter, but whitout stretching it you should get somewhere between 20-40 depending on system. In general, worse jitter than RT-Linux or RTAI , BUT better worst cases . ie. worst cases are not very frequent, and not as big. Try a greater than 3.0 kernel, and I think there are virtualisation issues . please report back ! / regards, Lars Segerlund. 2012/8/27 Michael Haberler mai...@mah.priv.at: Am 27.08.2012 um 18:45 schrieb Lars Segerlund: I am ... what do you want to know ? First I would like to understand what the major differences and restrictions are; at first glance this looks very similar to a SIM setup to me Also I'd like to figure how mature this is and if it could be a merge candidate for LinuxCNC a README.rt-preempt like we did this and that would be stunning ;) I managed to compile git://gitorious.org/emc-rt-preempt/emc-rt-preempt.git branch linuxcnc-buesch-rt on a 2.6.31-11-rt kernel (virtualbox) but runtests fails on me; I'll retry on a real machine background: I want a non-RTAI HAL environment to try on smaller devices like ARM - Michael / Lars 2012/8/27 Michael Haberler mai...@mah.priv.at: please get in touch with me thanks -Michael -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] anybody running LinuxCNC with the RT_PREEMPT patch?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Emc2HardwareDesign#No_buffering Havent looked into it, but it's stupid for some purposes . you could stream to a buffer, and have limitations on how often it would get updated . Doesn't seem to hold entirely true either, some people seem to have implemented buffered drivers. / Lars 2012/8/27 Michael Haberler mai...@mah.priv.at: Am 27.08.2012 um 20:09 schrieb Lars Segerlund: As for virtualisation issues, you said you tested on virtualIbox ?? I get the same hangs in halcmd waiting for a mutex both on a real machine and VB on 2.6.33.7.2-rt30-1-686-bigmem ; havent debugged yet I run a 2.2 something which is hacked from old patches, the makefiles are the worst to get building, I set rt priorities separately ( post launch ), to tune. The 2.4 patched kernel had some issues if I don't remember wrong, however I am quite busy and time goes to new hardware at the moment. For the rtapi the changes are a couple of files, I just dropped in the old patches, looked them over a bit and ran. The other Michael, ( of bitmunster ), had newer patches which I ended up picking up. The rtapi is trivial to implement, since rt-preempt runs in userspace and implements POSIX. One this is that perhaps a more well thought approach than a quick hack would be nice, since then one could incorporate all the 'best practices' for rt-preempt. hm, I'd be looking for basic build and 'works within rt-preempt limitations' diffs for the RTAPI layer with an eye towards merging - I want to avoid importing experimental or undocumented HAL changes I guess I'll need to find out who owns these diffs these days, Michael says he doesnt Run some test programs, and tune the system well before starting ! As for hal ... no problem .. but Michael changed it a bit. ( btw. hal's lack of buffering is stupid IMHO, that is something that should be adressed in any linuxcnc3, otherwise great. ). What do you mean by HAL buffering - please explain? -Michael btw. I would port it to rt-preempt by myself if it wasn't done, it's so much easier to work with than RT-Linux / RTAI just a regular program on a regular computer ... This is my perspective. Watch out for some platforms, sometimes certain versions gets regressions for specific platforms. But all in all , very undramatic. 2012/8/27 Michael Haberler mai...@mah.priv.at: Lars, thanks for the general RT observations (what exactly is a 'viritualisation issue' provided I dont use virtualisation?) can you say anything about the *LinuxCNC* source level changes which happened, in particular to rtapi and hal? - Michael Am 27.08.2012 um 19:29 schrieb Lars Segerlund: Check out www.osadl.org they have a test rack with timings, for arm, mips, x86 amd64 and some. There should be a page to the wiki there to. Usually if you have bad hardware or a bad driver it will be a no go, but if you have good hardware it should work fine, when checking the numbers remember these systems are under heavy load. Also if testing, don't forget to set RT priority ! ( btw. there is a debian rt-preempt kernel , try it So an decent hardware you will not get below 10 us jitter, but whitout stretching it you should get somewhere between 20-40 depending on system. In general, worse jitter than RT-Linux or RTAI , BUT better worst cases . ie. worst cases are not very frequent, and not as big. Try a greater than 3.0 kernel, and I think there are virtualisation issues . please report back ! / regards, Lars Segerlund. 2012/8/27 Michael Haberler mai...@mah.priv.at: Am 27.08.2012 um 18:45 schrieb Lars Segerlund: I am ... what do you want to know ? First I would like to understand what the major differences and restrictions are; at first glance this looks very similar to a SIM setup to me Also I'd like to figure how mature this is and if it could be a merge candidate for LinuxCNC a README.rt-preempt like we did this and that would be stunning ;) I managed to compile git://gitorious.org/emc-rt-preempt/emc-rt-preempt.git branch linuxcnc-buesch-rt on a 2.6.31-11-rt kernel (virtualbox) but runtests fails on me; I'll retry on a real machine background: I want a non-RTAI HAL environment to try on smaller devices like ARM - Michael / Lars 2012/8/27 Michael Haberler mai...@mah.priv.at: please get in touch with me thanks -Michael -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https
Re: [Emc-developers] anybody running LinuxCNC with the RT_PREEMPT patch?
I think this is the original patches from Michael Bursch if my memory is not too bad. http://bu3sch.de/patches/emc-linux-rt/LATEST/ These patches worked pretty well, about 9 months ago. I did not try them recently, though. Unfortunately the link doesn't seem to be valid anymore. perhaps compare to recent rt-preempt ? As for the mutex lock, how about a look at debugfs ? Which is great pinpointing latency ? I think debugfs can trace on a given condition, like a mutex hang. Or a core of the process and a gdb session ? it should be possible to look at what all threads are doing ? The amazing thing is how small the patches are, / regards, Lars. 2012/8/27 Michael Haberler mai...@mah.priv.at: Am 27.08.2012 um 20:09 schrieb Lars Segerlund: As for virtualisation issues, you said you tested on virtualIbox ?? I get the same hangs in halcmd waiting for a mutex both on a real machine and VB on 2.6.33.7.2-rt30-1-686-bigmem ; havent debugged yet I run a 2.2 something which is hacked from old patches, the makefiles are the worst to get building, I set rt priorities separately ( post launch ), to tune. The 2.4 patched kernel had some issues if I don't remember wrong, however I am quite busy and time goes to new hardware at the moment. For the rtapi the changes are a couple of files, I just dropped in the old patches, looked them over a bit and ran. The other Michael, ( of bitmunster ), had newer patches which I ended up picking up. The rtapi is trivial to implement, since rt-preempt runs in userspace and implements POSIX. One this is that perhaps a more well thought approach than a quick hack would be nice, since then one could incorporate all the 'best practices' for rt-preempt. hm, I'd be looking for basic build and 'works within rt-preempt limitations' diffs for the RTAPI layer with an eye towards merging - I want to avoid importing experimental or undocumented HAL changes I guess I'll need to find out who owns these diffs these days, Michael says he doesnt Run some test programs, and tune the system well before starting ! As for hal ... no problem .. but Michael changed it a bit. ( btw. hal's lack of buffering is stupid IMHO, that is something that should be adressed in any linuxcnc3, otherwise great. ). What do you mean by HAL buffering - please explain? -Michael btw. I would port it to rt-preempt by myself if it wasn't done, it's so much easier to work with than RT-Linux / RTAI just a regular program on a regular computer ... This is my perspective. Watch out for some platforms, sometimes certain versions gets regressions for specific platforms. But all in all , very undramatic. 2012/8/27 Michael Haberler mai...@mah.priv.at: Lars, thanks for the general RT observations (what exactly is a 'viritualisation issue' provided I dont use virtualisation?) can you say anything about the *LinuxCNC* source level changes which happened, in particular to rtapi and hal? - Michael Am 27.08.2012 um 19:29 schrieb Lars Segerlund: Check out www.osadl.org they have a test rack with timings, for arm, mips, x86 amd64 and some. There should be a page to the wiki there to. Usually if you have bad hardware or a bad driver it will be a no go, but if you have good hardware it should work fine, when checking the numbers remember these systems are under heavy load. Also if testing, don't forget to set RT priority ! ( btw. there is a debian rt-preempt kernel , try it So an decent hardware you will not get below 10 us jitter, but whitout stretching it you should get somewhere between 20-40 depending on system. In general, worse jitter than RT-Linux or RTAI , BUT better worst cases . ie. worst cases are not very frequent, and not as big. Try a greater than 3.0 kernel, and I think there are virtualisation issues . please report back ! / regards, Lars Segerlund. 2012/8/27 Michael Haberler mai...@mah.priv.at: Am 27.08.2012 um 18:45 schrieb Lars Segerlund: I am ... what do you want to know ? First I would like to understand what the major differences and restrictions are; at first glance this looks very similar to a SIM setup to me Also I'd like to figure how mature this is and if it could be a merge candidate for LinuxCNC a README.rt-preempt like we did this and that would be stunning ;) I managed to compile git://gitorious.org/emc-rt-preempt/emc-rt-preempt.git branch linuxcnc-buesch-rt on a 2.6.31-11-rt kernel (virtualbox) but runtests fails on me; I'll retry on a real machine background: I want a non-RTAI HAL environment to try on smaller devices like ARM - Michael / Lars 2012/8/27 Michael Haberler mai...@mah.priv.at: please get in touch with me thanks -Michael -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how
Re: [Emc-developers] LinuxCNC RT OS underpinnings
I have done work with RTLinux professionally and had to rewrite some of the rt-fifo's . it was a time of hangs, inconsistencies and black magic. Oh, and lousy support ! ... I have also used RTAI , but loading kernel modules and unloading get's old fast. Now, three times there have been rt-preempt patches for emc, and for the most part the main argument is that it's not worth doing :-D , LoL , I have been running on it, and on the right machine you get less than 10 us worst case. With microstepping you can run a stepper at 20 us between pulses, and it sings :-D ... provided that the motor is up to it. So I would say that in general the consensus is that everything that's not RTAI or RTLinux is not worth doing or something like that. I got MIchels hacks, they run nicely, and I am satisfied , but I must say that the biggest thing keeping emc from gaining userbase is all the fiddling and magic that has to be done to set it up. The Sherline systems are nice, preinstalled, it has to be, no one of the fabbers for example will use something where you have to rebuild your kernel and so on, if it's not a prebuilt package it's not much use. And while I am complaining, why not have a build with dynamic loading of which rt to use ? Instead of building for a single strategy ? Sorry for whining, I would be nowhere without EMC and its capabilities, so it's a perl, ( when you look closely :D ). And please forget me my mindless rambling .. / regards, Lars Segerlund 2012/8/27 Michael Haberler mai...@mah.priv.at: I am late to get the gist on options for RT with Linux, but what I found leaves me a bit speechless. My understanding is the following: LinuxCNC supports two RT linux kernels, RTLinux and RTAI. RTLinux is dead in the water. Website doesnt even respond. Product abandoned by last owner, Wind River Systems. RTAI is a mostly one-man-show project locked into a single platform. The hope for RTAI on non-PC platform is just that - somebody seems to have noticed a dead end here. RT_PREEMPT is where the Linux mainstream is heading, as is Xenomai stated direction. There is no coordinated attempt on getting LinuxCNC to run out of the box on RT_PREEMPT or Xenomai, or any other alternative, despite some work as at least a starting point being available. --- Please tell me where I'm wrong: is this really it - Paolo walks into the wrong car, and the LinuxCNC project has no viable and believably maintained kernel alternative at hand? If I'm right: this must be changed ASAP, and this is a LinuxCNC2 issue. At the risk of hurting some feelings: if LinuxCNC were my company, and my chief tech told me this is our strategy, I would have this fellow empty his desk the very same day. - Michael ps: I am leaving software stepgen type performance issues out of the picture for now, and on purpose - I dont think this is a terribly important property going forward given the hardware on the market at a reasonable price point and with good integration into LinuxCNC. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC, RTAI, and Ubuntu long term support releases
A quick question, I would like to ask what speed you 'guess' / estimate the stepper lovers need ? ... and with speed I mean max allowable latency. Perhaps I could also ask about the speed for the loop ? On a well tuned x86 system, a 100kHz loop speed for the steppers should be easily obtainable, and 250+ possible, if I'm not totally wrong. / regards, Lars Segerlund. 2012/5/16 Jan de Kruyf jan.de.kr...@gmail.com: Hallo, Back from a week bundu-bashing. I would say from my side that I see a fair amount of work in the PREEMPT_RT patches still needs doing. Besides the point that the stepper lovers will allways want the speed of RTAI / XENOMAI. The ARM problem (besides what you mention below) leads me to believe that some serious work needs doing on the Xenomai patch to bring it up to scratch. But for my own reasons I am devoting what little time I have at the moment to PREEMPT_RT. Hope this helps the discussion. j. On Fri, May 11, 2012 at 6:10 PM, Kent A. Reed kentallanr...@gmail.comwrote: Gentle persons: The recent email discussions about ARM-based cpus on the one hand and about progress with the PREEMPT_RT patch on the other got me to wondering about RTAI and where it is going. I see that two test versions of rtai-3.9 were posted in quick succession in January/February of this year. As best I can interpret the Changelog, version 3.9 is supposed to support Linux kernels up to 2.6.38 although the second test release appears due in part to some failure of the first test release to achieve this goal fully. (The only mention of ARM in the Changelog dates from 2009 so I won't say any more in this message about ARM.) The last Ubuntu long-term-support release was Ubuntu 10.04.3LTS, aka Lucid Lynx, based on kernel 2.6.32. It reaches its official end of life in 11 months. As of a few weeks ago, the current Ubuntu long-term support release is Ubuntu 12.04LTS, aka Precise Pangolin, based on kernel 3.2.14. I feel no pressure to rush to new Linux distributions since I keep my desktop usage separate from my machine-control usage. Even if I did, I'm personally comfortable with mixing-and-matching kernels and distributions. However, it would appear from other email traffic that a number of LinuxCNC users want their latest and greatest hardware supported by the latest and greatest distribution releases so they can do everything on one computer. Given the stated commitment of the LinuxCNC developers to LTS releases of Ubuntu, the age of 10.04LTS, and the apparent lack of any RTAI roadmap indicating when kernel 3.+ will be supported, has a 'position' been formulated on the disconnect that exists today and likely will exist for some time to come? It would be great if other work---PREEMPT_RT, Xenomai, etc---end up making this a moot point but I was taught (my first employer paid for it and I have a yellowing certificate suitable for hanging to prove it!) that good project management does not include praying for a miracle :-) I'm just saying Regards, Kent -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] S-curve: my summary
Buy some on sparkfun or similar, with the righte G force range, thera are a lot of them, and hooking one up on SPI or i2c is not complicated. The sensors for airbags are probably not right ... The DIY robotics guys use them a lot as far as I can understand. It will be a bugger to read though since you have machine vibration, tool acceleration and the stiffness of the machine ( resonance ? ) ... Check out Variax solution laser measurement in realtime of the lenght and deformations in the frame :-D . Col .. I was thinking that hooking up a LIM or similar to a reference outside the machine might give better readings ? and simpler signal handling, since it gives absolute position ... It's not uncommon to have a LIM system with amplifiers lying around a machine shop . / regards, Lars Segerlund. 2012/5/3 EBo e...@sandien.com: On Thu, 3 May 2012 12:39:15 +0300, Anders Wallin wrote: The spectrum is so full of noise all the way up and beyond the range of the chart, that it has to be measured on some kind of machine. Jon I found the source of this pictures: http://www.mmrc.iss.ac.cn/~xgao/papernc/jounce2022.pdf And I am not sure what was measured. From this motion profile (0.1 to 0.2 s time to reach max. velocity) I do not expect frequency components in the 800 to 1200 Hz range. Another point is that the spectrum does not look alike sinc. But I may be totally wrong. The authors of that paper are not very clear on what exactly was measured, but I am sure it is not just an fft of the velocity-profile. Rather is a vibration measurement from somewhere on the machine. As such it might have components from the spindle, servo-drive, etc. If someone really wanted to get into this on a hobby level there might be acceleration-sensors (made for e.g. airbag-triggers on cars) which could be used? Simply HAL-scoping commanded/actual position and maybe looking at their spectra might be a good start too. Actually a high end smart phone with the new fancy nano gyros + accelerometers might just do the trick. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] S-curve: my summary
I meant LVDT ! ... sorry ! / Lars 2012/5/3 Lars Segerlund lars.segerl...@gmail.com: Buy some on sparkfun or similar, with the righte G force range, thera are a lot of them, and hooking one up on SPI or i2c is not complicated. The sensors for airbags are probably not right ... The DIY robotics guys use them a lot as far as I can understand. It will be a bugger to read though since you have machine vibration, tool acceleration and the stiffness of the machine ( resonance ? ) ... Check out Variax solution laser measurement in realtime of the lenght and deformations in the frame :-D . Col .. I was thinking that hooking up a LIM or similar to a reference outside the machine might give better readings ? and simpler signal handling, since it gives absolute position ... It's not uncommon to have a LIM system with amplifiers lying around a machine shop . / regards, Lars Segerlund. 2012/5/3 EBo e...@sandien.com: On Thu, 3 May 2012 12:39:15 +0300, Anders Wallin wrote: The spectrum is so full of noise all the way up and beyond the range of the chart, that it has to be measured on some kind of machine. Jon I found the source of this pictures: http://www.mmrc.iss.ac.cn/~xgao/papernc/jounce2022.pdf And I am not sure what was measured. From this motion profile (0.1 to 0.2 s time to reach max. velocity) I do not expect frequency components in the 800 to 1200 Hz range. Another point is that the spectrum does not look alike sinc. But I may be totally wrong. The authors of that paper are not very clear on what exactly was measured, but I am sure it is not just an fft of the velocity-profile. Rather is a vibration measurement from somewhere on the machine. As such it might have components from the spindle, servo-drive, etc. If someone really wanted to get into this on a hobby level there might be acceleration-sensors (made for e.g. airbag-triggers on cars) which could be used? Simply HAL-scoping commanded/actual position and maybe looking at their spectra might be a good start too. Actually a high end smart phone with the new fancy nano gyros + accelerometers might just do the trick. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] S-curve: my summary
Me thinks LVDT .. / Lars Segerlund. 2012/5/3 Andrew parallel.kinemat...@gmail.com: 2012/5/3 andy pugh bodge...@gmail.com On 3 May 2012 11:25, Lars Segerlund lars.segerl...@gmail.com wrote: It will be a bugger to read though It's a whole career. In fact it used to be all of my job, and is now part of my job. I am an NVH specialist. Some guys are trying to get exact 6D position (or exact displacement) of a body (say, machine tool end effector) using accelerometers, gyro and magnitometers. I think the accuracy is very limited here, even 0.1mm is hard to obtain. Acceleration data is noisy, and integrating it twice will give a large error. What do you think about it? Andrew -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port
I can confirm that the pagefaults I encountered occured when I had some problems with thee system leading to slower cycle times ( larger than 'normal latencies ). I haven't seen them since I got most of the trouble with the system sorted, ( BIOS ). Haven't had time to oogle the code yet ... / regards, Lars Segerlund. 2012/5/2 Michael Abel michael.a...@isw.uni-stuttgart.de: Hi Jan, On 05/01/2012 01:55 PM, Jan de Kruyf wrote: Ein Zimmermann am Straßenrand vergnügt die Zuschauer. they say in Holland. but also: Die Axt im Haus erspart den Zimmermann. [Friedrich Schiller: Wilhelm Tell] In other words: feel most welcome to the party. Thanks :) The problem seems in the porting to the present HEAD. And since you are much more knowledgable then we are on the subject: On and off the people report some funny hangups, so I would like to ask: 1. Could it be a case of priority inversion in the mutexes? Did you take care of that? Or does the system do that automatically? I haven't managed to look at the code yet, but when I remember right rt-mutexes should have build-in priority inheritance (http://www.mjmwired.net/kernel/Documentation/rt-mutex.txt). This should be the best option. 2. I think I have identified at least one area where a new shared memory resource has been introduced since your port, which I think needs protection. Yes, I have used that feature to talk to other real-time processes. That's also why I've updated semaphore support. Maybe we also need other additional protection. 3. Did you, at the time, check that all RT memory was locked in place? since there are some funny paging faults at times. Not really :) . I've also seen these pagefaults, maybe in combination with missed deadlines. Do the pagefaults also occur when you run with slower cycle times? Other than that your offer of serverspace is most welcome. And I might want to ask you some technical questions at odd times if I may. Feel free :) I can read linux C much better lately, but some of the fine details evade me at times. And I am on a steep learning curve regarding RT. The tool cyclictest is not only a good test tool but also a good reference for a simple real-time program. Maybe it helps to understand rt-preempt ... See: git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git Thanks again, j. Greetings Michael On Tue, May 1, 2012 at 12:09 PM, Abel Michael michael.a...@isw.uni-stuttgart.de wrote: Hi there, I just saw that you have resurrected the rt-preempt patches. Very very cool! I'd like to reproduce your results and help bug-fixing, but I'm not exactly sure how to patch everything together. If I've understood right this procedure might do it: 1) Follow these instructions: http://www.zultron.com/static/2012/04/linuxcnc-bitmuster-bisect.tgz 2) Apply this patch: linuxcnc-bitops-fix.patch 3) Apply the patch Charles send two posts ago to fix the rtapi message levels (Please correct me if I'm wrong). If somebody is in the mood for using git format-patch and send a patch, I would be also very happy. I'd like to push a branch to my repository at http://gitorious.org/emc-rt-preempt afterwards. So that everybody is able to pull. The repository is intended to toy around with rt-preempt and for a later merge upstream when it is running stable. Thanks in advance With best regards Michael Abel Aka the bitmuster guy On 04/30/2012 05:11 AM, Charles Steinkuehler wrote: On 4/29/2012 11:53 AM, John Morris wrote: Hi Charles, The AMAZING thing is I can now sudo scripts/latency-test and IT WORKS!!! So wait, by 'IT WORKS!!!' you mean 'IT WORKS!!!'? I can't believe it! It's our kid's first Mother's Day, so no testing until late for me. I have verified that the fix works not just immediately after the 8868436313c34eaf60a14f5c930f0f2035b9ee48 commit, but also on HEAD with the bitopts-fix patch. Interestingly, even when I send all rtapi output to stdout, I am *STILL* not seeing any of the expected rtapi_msg_handler messages on the console. I _really_ think this is the core issue, and moving messages from stderr to stdout just avoids the crash (or more likely delays it until much later). I was advised by Andy Pugh to echo 5 /proc/rtapi/debug, however there *IS* no /proc/rtapi/anything as I am building using --with-realtime=linux and there are no kernel modules getting loaded. I am unsure what the equivalent setting would be for the linux preempt_rt patch set, but AFAIK with either setting (rtapi_msg_handler data being sent to stderr or stdout) *SOMETHING* should be showing up on the console, and I'm still not seeing _any_ of these messages. This makes me think there is something wacky going on in the rtapi debugging output that is trashing memory when running using preempt_rt instead of the expected kernel module. I have looked around a bit, but still do not understand the code enough to know what might
Re: [Emc-developers] NURBS a la Yi-shin
Vendor specific extensions, check this out. http://books.google.se/books?id=c_-3TxZlnpMCpg=PA61lpg=PA61dq=fanuc+G-code+NURBSsource=blots=PWeZbXOOqAsig=NAPRDGrYpXRngHEfTqISbdkGmrchl=ensa=Xei=Kg6gT6PNIaXe4QSO28GNAwredir_esc=y#v=onepageq=fanuc%20G-code%20NURBSf=false Fanuc ... is 'fairly standard' .. / regards, Lars Segerlund. 2012/5/1 Spiderdab 77...@tiscali.it: Il giorno lun, 30/04/2012 alle 19.55 -0500, sam sokolik ha scritto: http://linuxcnc.org/docs/2.5/html/gcode/gcode.html#_g5_2_g5_3_nurbs_block_a_id_sec_g5_2_g5_3_nurbs_a Sounds like testing would be good No, Yi-shin was talking about three-dimensional nurbs. I'm interested too in trying that branch, but sincerely i don't understand how to pass nurbs to G-Code. If anyone knows, please suggest! Davide. On 04/30/2012 04:40 PM, dave wrote: Hi all, Lots of questions. a. what is the status of NURBS, i.e. has it made it into 2.5? b. what format input format does it expect? c. is it stable enough for a plain old user to run. and of course, if the answer to the above questions is yes are there instructions on the wiki or elsewhere for me to build? I'm about to dump my aging 1200 MHz Duron for something a bit newer and hopefully more rugged and would like to make a significant leap in capabilities. TIA Dave -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port
preempt-rt uses debugfs mount debugfs on /sys/kernel/debug on a kernel with debugging enabled, and the there is a whole set of triggers and instrumentation to play with. http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-Realtime_Specific_Tuning-Using_the_ftrace_Utility_for_Tracing_Latencies.html / Lars 2012/4/30 Charles Steinkuehler char...@steinkuehler.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/29/2012 11:53 AM, John Morris wrote: Hi Charles, The AMAZING thing is I can now sudo scripts/latency-test and IT WORKS!!! So wait, by 'IT WORKS!!!' you mean 'IT WORKS!!!'? I can't believe it! It's our kid's first Mother's Day, so no testing until late for me. I have verified that the fix works not just immediately after the 8868436313c34eaf60a14f5c930f0f2035b9ee48 commit, but also on HEAD with the bitopts-fix patch. Interestingly, even when I send all rtapi output to stdout, I am *STILL* not seeing any of the expected rtapi_msg_handler messages on the console. I _really_ think this is the core issue, and moving messages from stderr to stdout just avoids the crash (or more likely delays it until much later). I was advised by Andy Pugh to echo 5 /proc/rtapi/debug, however there *IS* no /proc/rtapi/anything as I am building using - --with-realtime=linux and there are no kernel modules getting loaded. I am unsure what the equivalent setting would be for the linux preempt_rt patch set, but AFAIK with either setting (rtapi_msg_handler data being sent to stderr or stdout) *SOMETHING* should be showing up on the console, and I'm still not seeing _any_ of these messages. This makes me think there is something wacky going on in the rtapi debugging output that is trashing memory when running using preempt_rt instead of the expected kernel module. I have looked around a bit, but still do not understand the code enough to know what might need to be fixed in the linux-* files to avoid trashing memory and to be able to properly output rtapi debugging information. It seems like this may have been a bug in the linux-preempt_rt patches for some time, but for whatever reason didn't cause serious problems until the changes to the rtapi output scheme. Congrats, Charles. If you fix it by tonight, I'll paypal you a beer. ;) Well, as a rule I never turn down free beer, but I'm not sure it's deserved in this case. Instead of a programmer or engineer, I feel more like a nuclear physicist playing with genetic algorithms: blowing things up and trying to figure out what happened based on the resulting pieces...then if it doesn't make sense I randomly change something and blow it up again. :) Also, I hesitate to consider the issue fixed, even though the latency-test from HEAD is now running for me under stock Debian Wheezy with a 3.2.0-rt kernel. It feels like there's something that needs to be fixed properly by someone who understands the code better than I do before this will be stable long-term. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+eAu0ACgkQLywbqEHdNFy3AwCfciNIyMCENEEXUcGnwnx35cb0 SJUAoJPDd14IcYbPvAzOww57wbUCsvuh =szYC -END PGP SIGNATURE- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port (Was: Re: One-liner patch)
Hi , I was going to try 2.5 but I am getting this error, after downloading and patching. Compiling realtime hal/drivers/hal_ax5214h.c hal/drivers/hal_ax5214h.c:104:20: error: asm/io.h: Filen eller katalogen finns inte can't find the file or catalog ... what I am interested in is that I applied the patches, but I saw something about disabling drivers in the makefile ... SO is this familiar or do I have a small problem with my include files ? Patches applied clean I'll look at the source in the meantime / regards, Lars. 2012/4/25 John Morris j...@zultron.com: Here's a link to the latest patches: http://www.zultron.com/static/2012/04/linuxcnc-buesch-rt-patches-forward-port-2012-04-25.tgz The README explains how to compile them on FC16. A few changes from the last version: - Now three patches 001-003 that parallel Michael's original patches. I thought that may be useful at some point. - I missed a line in the last version's Makefile which caused the drivers not to be built. It is present in these patches. - Patch 100 are simple changes that help a few drivers to compile, and disable a few drivers that won't compile (probably easy fixes). - Sebastian Kuzminsky helped put a couple of little fixes into the master branch today (thank you!!!), so the whole set feels pretty clean. I still haven't even gotten a chance to run these yet! Tomorrow. Must sleep. John On 04/24/2012 04:01 AM, Lars Segerlund wrote: Any git repo I can pull from and give it a spin ? / regards, Lars Segerlund. 2012/4/23 John Morrisj...@zultron.com: Hi Jon, If the rt-preempt route doesn't work, I'll try applying RTAI to a kernel RPM. It would be neat to get LinuxCNC working with linux-rt, of course, but from what I've found on the list and the irc logs, there's only a small amount of interest ATM, though that might increase because of OSADL. One significant aspect of this would be that it could make LinuxCNC run on the Beagle Board, for which there is no RTAI patch yet, and we've been waiting a LONG time. I would LOVE to do some performance tests on the Beagle to see how well LinuxCNC runs on it. I think that means no RTAI patch for ARM? Have you seen this project, which is similar to what I'm doing? http://www.bitmuster.org/projects/emc.html http://gitorious.org/emc-rt-preempt This effort seems to have stalled, and the patch applies to v2.4.4. However, it compiled easily using the cookbook in the first link. Maybe it would get you to where you could run those performance tests. That project was where I initially started from, but there were some messy things in the patch that I didn't feel like cleaning up, so I went back to Michael Buesch's original, very clean patches. (The mess was nothing that would stop you from compiling the project, but things like ripped out .gitignore files, a committed .rej file, other stuff. At some point I may go back to check for any useful additions, but I'll leave out the SHM bit.) Anyway, good news is Michael's patches forward-ported to git HEAD compiled last night with minor twiddling. I'll be running tests over the next few days to see if the beast actually runs. ;) John -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event
Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port (Was: Re: One-liner patch)
Okie, I will have a look, it might be mu include files or links One thing, I have a version that is 2.6~pre so I might have messed up my pull from git . I believe I should have a 2.5 The patches applied though ... / regards ... and thanks ... 2012/4/28 andy pugh bodge...@gmail.com: On 28 April 2012 18:16, Lars Segerlund lars.segerl...@gmail.com wrote: hal/drivers/hal_ax5214h.c:104:20: error: asm/io.h: Filen eller katalogen finns inte The comment in the code is: /* If FASTIO is defined, uses outb() and inb() from asm.io, instead of rtapi_outb() and rtapi_inb() - the asm.io ones are inlined, and save a microsecond or two (on my 233MHz box) */ However, asm/io.h is included in a number of other realtime drivers. -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port (Was: Re: One-liner patch)
I wonder if this might be related to our problem. Deadlocking mutexes .. perhaps we should ask on the rt-linux mailing list ? Right now I am a bit undsure about userspace mutexes but I'll look at the code when I get home, it just sounds familiar, but might be out of context. http://www.mjmwired.net/kernel/Documentation/rt-mutex-design.txt / regards, Lars Segerlund. 2012/4/26 John Morris j...@zultron.com: Well, no solution yet, and only narrowed things a little bit: Continuing Charles's work, I merged the bitmuster-patched v2.4.4 forward. Whatever changes are causing the problem Charles describes were introduced between v2.4.7 and v2.5.0, and also between v2.5.0-pre0 and v2.5.0-pre1. That sounds encouraging until you look at git and see that span between v2.5.0-pre0 and -pre1 is over a year, 833 files and 120k+ insertions, and that v2.5.0-pre0 is more closely related to v2.4.0 than v2.4.4. For the first time, I'm actually *sad* to report that it seems not to be my error at the root of the problem! John On 04/26/2012 12:39 AM, John Morris wrote: Hi Charles and Jan, This is just a stab in the dark, but Debian uses EGLIBC while I think Fedora is still on normal GLIBC. And there were some mutex priority issues in eglibc, quite a long time ago though. John can you repeat Charles' problem in your setup? Fedora uses glibc, yes, and I've replicated what Charles has done exactly. :) What I'm seeing in the debugger is while going through hal_init the hal_data-mutex bit is getting set and is visible in the memory display window after rtapi_mutex_get is called. However after calling rtapi_mutex_give, the mutex bit is *STILL SET* in my debugger memory display. Yep, same here. I don't know if this is a fundamental problem with the rtapi code or something to do with running from the debugger with breakpoints and whatnot. It does seem odd that this would be due to system libraries, as the relevant code seems to be entirely within the linuxcnc rtapi tree. There could be some other issue with the memory mapping or something system related, I suppose. I do, however, get identical results when running the code normally from the command line and then attaching to it with the debugger (the code is looping waiting to acquire the hal_data-mutex that will never become available). Also, the 2.4.4 patched version from bitmuster compiles and runs fine on this same system, so if there is a library issue, it's likely related to the changes from 2.4 to 2.5. Same here with 2.4.4, I think. I'm unsure because the first compile was behaving like my forward-ported patches, but it started working after I recompiled with -g. Hrm. Did anything major change in the hal shared-memory usage between 2.4 and 2.5? Wonder how hard to start bisecting ;) Anyway, up to now I've only managed to reproduce your results. I'll get back if I learn anything new. John -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port (Was: Re: One-liner patch)
check out the RT wiki ... there are some examples, usually you prefault the stacks, for threads and then do a mlock on all of the memory for the process. 2012/4/26 Jan de Kruyf jan.de.kr...@gmail.com: By the way: there is somewhere a note in the software about some pagefaults at startup that probably dont need fixing! I forget at the moment where I saw it. Keep your eyes popped for that. It also explains Lars' experience. j. On Thu, Apr 26, 2012 at 9:32 PM, Jan de Kruyf jan.de.kr...@gmail.comwrote: I was going to bring that issue up as well, that is indeed my understanding of preempt_rt, from reading the docs. I am not sure though that this has caused the mutex drama. That can only be if there is an unbalanced mutex or if the inheritance mechanism has not worked properly, or perhaps if some process had the lock and pagefaulted, and was not cleaned up properly, so the mutex still exists until reboot time. I do not think there is an unbalanced mutex cause it works with rtai. That leaves the last 2 options. And caused by the new rtapi interface no doubt. So on my side some more understanding is needed now and I need to read up on the rtai interface again. The rest of the weekend is more or less available but it is a lot of work for me. But I think you got a long way already. Not half as bad as the prognosis this morning. j. On Thu, Apr 26, 2012 at 9:10 PM, Charles Steinkuehler char...@steinkuehler.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm still working on figuring those out as well. :) Near as I can tell, since there's no kernel space vs. user space with the preempt-rt patch (everything runs in user-space), the realtime and user-mode functions can be the same so the functions were merged into linux_common.h. I can't vouch for how correct this is for linuxcnc v2.5, but pretty much the code seems to work for the 2.4.4. On 4/26/2012 12:24 PM, Jan de Kruyf wrote: I dont seem to get 'rtapi_shmem_new()' and friends in ./rtapi/linux_rtapi.c which presumably is the rtapi interface in the case of rt_preempt. j. On Thu, Apr 26, 2012 at 6:47 PM, Charles Steinkuehler char...@steinkuehler.net wrote: On 4/26/2012 2:49 AM, John Morris wrote: Well, no solution yet, and only narrowed things a little bit: Continuing Charles's work, I merged the bitmuster-patched v2.4.4 forward. Whatever changes are causing the problem Charles describes were introduced between v2.4.7 and v2.5.0, and also between v2.5.0-pre0 and v2.5.0-pre1. Thanks for digging into this! Looking at diffs between the versions above, I think the problem may be related to the changes in the handling of mem_id, lib_mem_id, and comp-mem_id in hal_init and elsewhere. No smoking gun yet, but I had previously ignored these changes, as it looked to me like the comp-mem_id was something added by bitmuster for their shared memory area tests since it didn't exist in the linuxcnc 2.5 codebase. Looking at the linuxcnc diff from 2.5.0-pre0 to 2.5.0-pre1, however, I see that this is a linuxcnc change and did not come from bitmuster. I suspect something in the preempt-rt patches needs to be updated or tweaked to account for this change, but I still don't understand the code well enough to pinpoint what might need fixing. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ZnbsACgkQLywbqEHdNFyqOACgsSMgV/G1Pt/OEB9Qi6sTu7/Z gj0AniuH9GMgsJlQGtWL9RN2yrH30UZe =lcb4 -END PGP SIGNATURE- -- Live Security Virtual Conference Exclusive
[Emc-developers] pagefaults ...
I am getting a set of pagefaults in rt context when running linuxcnc 2.4.4 with rt-preemmpt patches, which is not the question. However, is it normal to hit pagefaults in RT ? ( usually you lock the pages and preallocate the stack and some other init ... then you have no pagefaults ... there are some stuff doing that in the rt patches, but I haven't pinpointed the source of the pagefaults yet, I suspect some other part. I am not veryknowlegeable about emc's code only the parts I have needed to look at. ) I haven't had a look at the specific situation, but will give the system a thorough look asap. since I hit most of them during startup I figured that I should check on the list first. / regards, Lars Segerlund. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] pagefaults ...
Yes I looked at it, and the rtapi part of emc, has something similar, preallocation and prefaulting the stack But I will give it another look, also a bit busy I will try to find the cause of the pagefault, which should be easy with the debugging framework in the linux rt-preempt kernel, it can trigger on latency and I'll get a 'call trace' ... let's hope I have debugging enabled. / regards, Lars. 2012/4/25 Jan de Kruyf jan.de.kr...@gmail.com: Lars I am extremely interested in your graft. Just a bit busy at the moment trying to get back to normal after my europ trip. in any case did you look here?: https://rt.wiki.kernel.org/articles/b/u/i/HOWTO~_Build_an_RT-application_6066.html specifically the Latencies caused by Page-faultssection. j. On Wed, Apr 25, 2012 at 12:28 PM, Lars Segerlund lars.segerl...@gmail.comwrote: I am getting a set of pagefaults in rt context when running linuxcnc 2.4.4 with rt-preemmpt patches, which is not the question. However, is it normal to hit pagefaults in RT ? ( usually you lock the pages and preallocate the stack and some other init ... then you have no pagefaults ... there are some stuff doing that in the rt patches, but I haven't pinpointed the source of the pagefaults yet, I suspect some other part. I am not veryknowlegeable about emc's code only the parts I have needed to look at. ) I haven't had a look at the specific situation, but will give the system a thorough look asap. since I hit most of them during startup I figured that I should check on the list first. / regards, Lars Segerlund. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] pagefaults ...
Debian squeeze with 3.2 rt kernel from backports. However I am investigating the machine now since it's a laptop and it is giving some strange latencies . So hold on, but it's not normal getting a pagefault I suppose ? I'll use debugfs cyclictest to look at the latencies , and then debug emc and the pagefaults. Just need to get it done. / regards, Lars Segerlund On Apr 25, 2012 5:38 p.m., Jan de Kruyf jan.de.kr...@gmail.com wrote: Lars, hi What distribution are you using? Ubuntu? j. On Wed, Apr 25, 2012 at 12:47 PM, Lars Segerlund lars.segerl...@gmail.comwrote: Yes I looked at it, and the rtapi part of emc, has something si... -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] pagefaults ...
And I have run emc on a debian squeeze just fine before. Same codebase and everything, but about a half year ago, its 2.4 I'm running. BUT since my other rt tests also are funky I don't want to jump to conclusions ... could be the kernel. / regards, Lars Segerlund. On Apr 25, 2012 8:53 p.m., Jan de Kruyf jan.de.kr...@gmail.com wrote: I get that but we now have 2 debian installations giving crap and a fedora installation looking vaguely right. (scratch scratch. . . . .) j. On Wed, Apr 25, 2012 at 8:13 PM, Lars Segerlund lars.segerl...@gmail.com wrote: I should point out that I haven't tun RT on this specific machine before, and it can be machin... -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port (Was: Re: One-liner patch)
Any git repo I can pull from and give it a spin ? / regards, Lars Segerlund. 2012/4/23 John Morris j...@zultron.com: Hi Jon, If the rt-preempt route doesn't work, I'll try applying RTAI to a kernel RPM. It would be neat to get LinuxCNC working with linux-rt, of course, but from what I've found on the list and the irc logs, there's only a small amount of interest ATM, though that might increase because of OSADL. One significant aspect of this would be that it could make LinuxCNC run on the Beagle Board, for which there is no RTAI patch yet, and we've been waiting a LONG time. I would LOVE to do some performance tests on the Beagle to see how well LinuxCNC runs on it. I think that means no RTAI patch for ARM? Have you seen this project, which is similar to what I'm doing? http://www.bitmuster.org/projects/emc.html http://gitorious.org/emc-rt-preempt This effort seems to have stalled, and the patch applies to v2.4.4. However, it compiled easily using the cookbook in the first link. Maybe it would get you to where you could run those performance tests. That project was where I initially started from, but there were some messy things in the patch that I didn't feel like cleaning up, so I went back to Michael Buesch's original, very clean patches. (The mess was nothing that would stop you from compiling the project, but things like ripped out .gitignore files, a committed .rej file, other stuff. At some point I may go back to check for any useful additions, but I'll leave out the SHM bit.) Anyway, good news is Michael's patches forward-ported to git HEAD compiled last night with minor twiddling. I'll be running tests over the next few days to see if the beast actually runs. ;) John -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Hard real time in user space with preempt_rt patch
This is not based on facts, rt-preempt does provide hard realtime and strive to provide hard realtime, where have you come up with the notion that it does not ? Please, don't spread misinformation, this is pure FUD ... Check osadl.org and their test rack, it will perhaps shed some light on the quality assurance they try to do. It is hard to argue with numbers, also check a recent kernel and a 'good' system. Some system have latency problems, but most are fine, atleast a worstcase of 50 usor so under hard load and normal times in the low 10 to 20 us range. / regards, Lars Segerlund. 2012/4/24 Mark Hounschell dma...@cfl.rr.com: On 04/24/2012 01:46 AM, Anisha Kaul wrote: From: https://rt.wiki.kernel.org/articles/f/r/e/Frequently_Asked_Questions_7407.html Real-time only has impact on the kernel; Userspace does not notice the difference except for better real time behavior. Does it mean that if we write the applications in user space, they won't get the hard real time effect? The threads running in the userspace won't get the hard real time effect? You use the term hard real time. The RT patch set does not even come close to providing a hard real time environment, and isn't even attempting to. It does however provide user land applications a much better chance for a soft real time environment. The phrase you quot above just means the patches are applied to the kernel and there are no patches required for user land glibc or your application. Regards Mark -- To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Hard real time in user space with preempt_rt patch
Until is so there cant be YY, this is a fact, that is not a fact, that is a statement. If you have numbers or such to base your STATEMENTS on , please do so, but don't present your opinion as a fact. Also lala-land and similar name calling doesn't add to your credibility. Hard realtime is as you state not fast or slow, but in a deterministic time frame, total agreement there. Perhaps you should have a look at the preempt-Rt patches since you don't seem knowledgeable about things like the 'threaded interrupt handler' and such, On a MP machine preempt-RT actually outperforms most other RT systems :-D ... So I think perhaps you should speak a bit softly since there is a lot of people working on making preempt-rt exactly that, a general hard realtime system, and some of them are rather acomplished. If you think a lot of smart people are stupid, then the odds are not in the favour of your opinion . / regards, Lars Segerlund. 2012/4/24 Mark Hounschell dma...@cfl.rr.com: On 04/24/2012 05:08 AM, Lars Segerlund wrote: This is not based on facts, rt-preempt does provide hard realtime and strive to provide hard realtime, where have you come up with the notion that it does not ? Please, don't spread misinformation, this is pure FUD ... Check osadl.org and their test rack, it will perhaps shed some light on the quality assurance they try to do. It is hard to argue with numbers, also check a recent kernel and a 'good' system. Some system have latency problems, but most are fine, atleast a worstcase of 50 usor so under hard load and normal times in the low 10 to 20 us range. Your in lala land. The Linux kernel, even with the RT patch has so much per CPU crap in it, there is no way to prevent it from steeling usecs from your application. The per CPU timer interrupt alone takes a few usecs away from your application every HZ. A hard RT env is one in which you can always, every time, do a predefined work in the same amount of time. Fast or slow isn't the key. It's determinism. The timer interrupt alone prevents that. And it's not the only thing. I've got 8 cpus on my machine but the kernel has to have a piece of every one of them. Until there is isolation from the kernel, there cannot be Hard RT. This is fact. Mark -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Crazy Talk [was: I am new here]
Which is why I have been trying to agitate for preempt-rt . it's now following mainline, and is available on ALL architectures since it's general ... Still sometimes there are driver problems, but check out osadl.org for ARM. / regards, Lars Segerlund. 2012/3/30 EBo e...@sandien.com: On Fri, 30 Mar 2012 11:36:04 -0500, Jon Elson wrote: Anders Wallin wrote: 2) How portable is the real-time code (ie: can it be compiled for Arm or PowerPC)? LinuxCNC uses the RTAI kernel/API. There are a number of architectures listed here https://www.rtai.org/ I don't know if anyone has made LinuxCNC work on other than x86 and x86_64 I sent Torsten Koschorrek of RTAI a Beagle Board about 18 months ago, and as you can see, there is no ARM Cortex-A8 RTAI available yet. I can't believe it has taken this long! There is an RT-Preempt kernel that was done by some French guys, but I don't know if it has suitable latency for LinuxCNC, but it almost certainly is good enough for a system with attached hardware (not software stepping). soapbox That is what I was planning to work on with artek's NURBS hardware. If you get similar stuff working with RT-preempt. The biggest problem with RTAI is that the patches are to invasive to the kernel and each time even a minor update to the kernel happens it needs to be majorly tweaked by hand and (from my experience) never just updates. Then there are all the bad feelings between the RTAI community and those using/promoting RT-Linux. Personally I was caught in the crossfire and was left with no love of RTAI. I am glad that there is a decent alternative. BTW, for technical correctness, RTAI and RT-Linux will *always* be faster and have less latency than the preemptive and similar approaches, but getting RTAI working is truly a pain unless you only use the precompiled CD/DVD version, and sometime that is not a realistic option. \soapbox EBo -- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] The preempt_RT vs RTAI question
I'm running preempt-rt ... It's good enough for steppers, as for changes to codebase, it needs some files for rt-api ( in EMC ) , but the Makefiel stuff is the real problem ... it's a mess to sort out. SO, the changes doesn't affect the rest of EMC , however performance is dependent on hardware and drivers, ( some network drivers suck ), but it's getting mainlined :-D . I'm all for incorporating it, ( makes my life easier :-D ). / regards, Lars. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Fwd: EMC2 Fest/Meeting
Nevermind, just forget it, it's not important. I read the thread again and it's off topic. / regards, Lars 2012/1/26 EBo e...@sandien.com: Sorry, I do not understand what you mean by get[ting] around 50 us On Thu, 26 Jan 2012 08:30:16 +0100, Lars Segerlund wrote: You should be able to get around 50 us ... / regards .. 2012/1/26 EBo e...@sandien.com: I was going to mention that, but wait until I get to beta test some new equiptment that moves the hard real-time to an FPGA so I can give some real numbers and results... EBo -- On Thu, 26 Jan 2012 08:08:54 +0100, Lars Segerlund wrote: But you can run preempt-rt on a Beagle board . if slightly higher latencies are acceptable 2012/1/26 Jon Elson el...@pico-systems.com: EBo wrote: who's joking ;-) Actually, there are some low-powered SOCs that run Linux, and if any of them can be made to run LinuxCNC nee EMC2, it would be replaceable. If you poke at this please let me/us know... The BeagleBoard is a good candidate, about 2W with an SD card for disk, USB ports, etc. No RTAI so far, but that might come soon. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Fwd: EMC2 Fest/Meeting
But you can run preempt-rt on a Beagle board . if slightly higher latencies are acceptable / ragards, Lars Segerlund 2012/1/26 Jon Elson el...@pico-systems.com: EBo wrote: who's joking ;-) Actually, there are some low-powered SOCs that run Linux, and if any of them can be made to run LinuxCNC nee EMC2, it would be replaceable. If you poke at this please let me/us know... The BeagleBoard is a good candidate, about 2W with an SD card for disk, USB ports, etc. No RTAI so far, but that might come soon. Jon -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Fwd: EMC2 Fest/Meeting
You should be able to get around 50 us ... / regards .. 2012/1/26 EBo e...@sandien.com: I was going to mention that, but wait until I get to beta test some new equiptment that moves the hard real-time to an FPGA so I can give some real numbers and results... EBo -- On Thu, 26 Jan 2012 08:08:54 +0100, Lars Segerlund wrote: But you can run preempt-rt on a Beagle board . if slightly higher latencies are acceptable 2012/1/26 Jon Elson el...@pico-systems.com: EBo wrote: who's joking ;-) Actually, there are some low-powered SOCs that run Linux, and if any of them can be made to run LinuxCNC nee EMC2, it would be replaceable. If you poke at this please let me/us know... The BeagleBoard is a good candidate, about 2W with an SD card for disk, USB ports, etc. No RTAI so far, but that might come soon. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] EMC preempt-rt
Hi all, Michael put up a github repository with changes for preempt-rt. It was previously discussed how we would bring them in, and it was said they would go in 2.4 something . My question is hot to go about this, am I correct in assuming the following workflow ? 1. I check out latest 2. I cherry pick an isolated change ( fx. rtapi for preempt-rt ) ( preferably one that doesn't break anything ) I don't know if it should be tagged or how to cherry-pick changes to specific files and such, I'm not that good at git. 3. I generate a patch and put on the list ? With a request to pull. Since you have to build with preempt-rt ( EMC ) , it doesn't really affect any parts already present, so I don't think there should be a problem. I don't see why we couldn't bring it all in without breakage, the makefiles and such is the only parts which could cause breakage. Comments ? / best regards, Lars Segerlund. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Preempt-RT ... where to put the patches ?
Hi everybody, Now that Michael have put up a git repository, how do we go about getting stuff pulled ? A ( for me ) logical way to do this would be to pull the rt-api parts, and after that the parts touching the makefiles . What is needed to get going ? / regards, Lars Segerlund. 2011/8/3 Michael Abel michael.a...@isw.uni-stuttgart.de: Hello Folks, Finally, the RT-Preempt adoptions of EMC are online at gitorious: They are available via this link: git://gitorious.org/emc-rt-preempt/emc-rt-preempt.git I hope that everything is OK there, since I'm still relatively new to git. The branch for the adoptions is called 2.4.4-rt-shm since the adoptions are based on the tag 2.4.4 and include rt-preempt as well as the shared memory interface to 3rd party applications. So this command should be sufficient for cloning: git clone git://gitorious.org/emc-rt-preempt/emc-rt-preempt.git -b 2.4.4-rt-shm I will also update the documentation soon, see http://www.bitmuster.org/projects/emc.html for updates. Kind regards, Michael On 07/27/2011 04:50 PM, Michael Abel wrote: Hello Pavel, Lars and all the others, I'm happy to see that there is some interest on porting to rt-preempt... at least it's worth for discussions :) On 07/27/2011 11:24 AM, Lars Segerlund wrote: Hi again, Se below I'll try to answer to the best of my ability. 2011/7/27 Pavel Shramovshra...@mexmat.net: On Wed, Jul 27, 2011 at 10:35:52AM +0200, Lars Segerlund wrote: Actually it's the patches from : http://www.bitmuster.org/projects/emc.html I spoke with Michael Abel, and the patches I had and the one he had done were from the same origin, ( check his page above ). You've used his patches or from origin? That's really not important but just for curiosity. I used both so far, but I decided on Michaels patches, they are 'identical' , but are made against current mainline. As far as the rt-preempt stuff they are identical, it's more that there has been changes to the source since my patches were made, and we both took the original code from below: We currently use a branch built on top of the EMC version 2.4.4 since the RT-Preempt patches from Michael Büsch and Jeff Eppler are still for this version (Thanks a lot for that work!). Here is the original location of the patch: http://bu3sch.de/patches/emc-linux-rt. The patches are not intrusive, and unless you build with RT-Preempt support they don't affect anything. Problem with patches vs public repo is that they lack 'origin'. You don't know what version you need to apply them, you can not reliably track changes etc... Micheal also added semaphores and shared memory to linux_rtapi. I am trying to put them through the paces right now on a parport interface and some steppers, so far so good. So patchset is changing... Another argument to settle it in some repo. Nope it's basicly the same, but Michael added some stuff he needed on top. However I agree on the conclusion about a repo. Me too :) I would like to ask, how do one go about becoming an EMC developer ? Heh, since you are working on it - you are EMC developer :) Also would it be ok to get the patches from above location ? If there is no other way to get them - yes. Is it possible for you (or maybe Michael) to setup repository with your patchset somewhere? github (or gitourious) are easy to start with and allow you to commit anything you want without threat of breaking main emc2 repository. But will provide others with good point to track your changes, review and maybe merge to mainline. If it's not an option somebody may merge theese patches for you but that will do more harm then good -- you won't be able to control that process and for example if merger has no linux-rt testbed may introduce untested bugs. It seems that everybody is happy with a public repository hosted somewhere. So I'm going to push my repository to a public location. I hope I find some time to setting up a repository and pushing at the weekend. And could there be a rt-preempt branch or does it go directly in mainline ? It depends on complexity of changes and probably should live in separate branch for a while. Perhaps the rt-preempt patches could go in mainline since they are quite simple and obvious ( I promise ) , and also won't affect any RT-Linux, RTAI setups ... I can honestly say I haven't looked at the shm/semaphore patches , but they won't affect anything if not used. Yes, except the build system :) It was quite tricky to get it compile :) It sounds like we have to go about setting up a repo on github as a first step. Thanks Pavel / Lars Pavel Regards Michael -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu
Re: [Emc-developers] Preempt-RT ... where to put the patches ?
Hi again, Se below I'll try to answer to the best of my ability. 2011/7/27 Pavel Shramov shra...@mexmat.net: On Wed, Jul 27, 2011 at 10:35:52AM +0200, Lars Segerlund wrote: Actually it's the patches from : http://www.bitmuster.org/projects/emc.html I spoke with Michael Abel, and the patches I had and the one he had done were from the same origin, ( check his page above ). You've used his patches or from origin? That's really not important but just for curiosity. I used both so far, but I decided on Michaels patches, they are 'identical' , but are made against current mainline. As far as the rt-preempt stuff they are identical, it's more that there has been changes to the source since my patches were made, and we both took the original code from below: We currently use a branch built on top of the EMC version 2.4.4 since the RT-Preempt patches from Michael Büsch and Jeff Eppler are still for this version (Thanks a lot for that work!). Here is the original location of the patch: http://bu3sch.de/patches/emc-linux-rt. The patches are not intrusive, and unless you build with RT-Preempt support they don't affect anything. Problem with patches vs public repo is that they lack 'origin'. You don't know what version you need to apply them, you can not reliably track changes etc... Micheal also added semaphores and shared memory to linux_rtapi. I am trying to put them through the paces right now on a parport interface and some steppers, so far so good. So patchset is changing... Another argument to settle it in some repo. Nope it's basicly the same, but Michael added some stuff he needed on top. However I agree on the conclusion about a repo. I would like to ask, how do one go about becoming an EMC developer ? Heh, since you are working on it - you are EMC developer :) Also would it be ok to get the patches from above location ? If there is no other way to get them - yes. Is it possible for you (or maybe Michael) to setup repository with your patchset somewhere? github (or gitourious) are easy to start with and allow you to commit anything you want without threat of breaking main emc2 repository. But will provide others with good point to track your changes, review and maybe merge to mainline. If it's not an option somebody may merge theese patches for you but that will do more harm then good -- you won't be able to control that process and for example if merger has no linux-rt testbed may introduce untested bugs. And could there be a rt-preempt branch or does it go directly in mainline ? It depends on complexity of changes and probably should live in separate branch for a while. Perhaps the rt-preempt patches could go in mainline since they are quite simple and obvious ( I promise ) , and also won't affect any RT-Linux, RTAI setups ... I can honestly say I haven't looked at the shm/semaphore patches , but they won't affect anything if not used. It sounds like we have to go about setting up a repo on github as a first step. Thanks Pavel / Lars Pavel -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Preempt-RT ... where to put the patches ?
I believe there is some information about the test load at the bottom of this page. https://www.osadl.org/?id=864 / regards, Lars Segerlund 2011/7/20 Jon Elson el...@pico-systems.com Lars Segerlund wrote: The new RT kernel is out, there is a test graph under load which should answer a lot of questions on latency. https://www.osadl.org/Single-View.111+M5acfc476362.0.html Yes, but that looks like an insanely high-end 8-CPU machine, I wonder what the results would be with a more generic motherboard? And, they don't say what the load is, does it include open-gl graphics, network activity, and maybe plugging in a USB memory stick? Jon -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 5 Ways to Improve Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Preempt-RT ... where to put the patches ?
Hi, Hyperthreading is actually really good, if you are running threaded interrupts, which linux 3.0 does, and that constitues one of the 'core' technologies in preempt-rt :-D , Lars Segerlund. 2011/7/21 Dave e...@dc9.tzo.com On 7/20/2011 9:41 PM, Jon Elson wrote: Yes, I think the extra CPUs are from hyperthreading, and disabling it should help. Rtapi on the D510 with hyperthreading enabled is pretty bad also... Why would they leave hyperthreading enabled on a Linux system? I thought hyperthreading was optimized for Windows thread manager? Dave -- 5 Ways to Improve Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 5 Ways to Improve Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Preempt-RT ... where to put the patches ?
I am trying to do something similar with a clocked output buffer ( USB ) , the USB chip clocks out the data from an internally clocked buffer, this way I get 100% accuracy on the pulses to the steppers, only way to do USB . You could turn it around, let EMC output 'next' data to a buffer, the hardware poll it , deliver position and set interrupt, then you would have overshoot detection :-D / regards, Lars 2011/7/21 Steve Stallings steve...@newsguy.com Peter, Good point about interrupt jitter mattering less if the actual sample time does not jitter. Unfortunately the current RTAI setup requires that the interrupt comes from the host interrupt timers. If we could get to a system model where the hardware could sample the data at the same time that it also requests an interrupt, then the actual interrupt latency would be much less critical. The PC system design does not bring out the interrupt request anywhere, so syncing with it in hardware is not possible, nor can RTAI (as best I know) accept an interrupt from external hardware as the system timer. I wonder if Preempt-RT may be more flexible. Steve Stallings (unrepentant top poster) -Original Message- From: Peter C. Wallace [mailto:p...@mesanet.com] Sent: Thursday, July 21, 2011 9:34 AM To: EMC developers Subject: Re: [Emc-developers] Preempt-RT ... where to put the patches ? On Wed, 20 Jul 2011, Jon Elson wrote: Date: Wed, 20 Jul 2011 20:41:44 -0500 From: Jon Elson el...@pico-systems.com Reply-To: EMC developers emc-developers@lists.sourceforge.net To: EMC developers emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] Preempt-RT ... where to put the patches ? Viesturs L cis wrote: Out of curiosity I tried to find results for D510 and D525 boards - they both are mentioned in the list of tested systems. This is D510: https://www.osadl.org/Latency-plot-of-system-in-rack-1-slot.qa-latencyplot-r 1s4.0.html?latencies=showno=slider=228 This is D525: https://www.osadl.org/Latency-plot-of-system-in-rack-4-slot.qa-latencyplot-r 4s7.0.html?latencies=showno=slider=228 Where did they get 4 cores? From hyperthreading? Do I understand correctly that disabling hyperthreading should improve latency figures? Yup, the D510 is a CATASTROPHE, the D525 is just really bad. You could probably run a servo machine Well 100 uSec of jitter should be perfectly acceptable _if_ the PID (or hardware stepgen) corrections were based on actual time instead of thread invocation time, heck even 500 uSec jitter might be OK. on the D525, but it isn't real good. Yes, I think the extra CPUs are from hyperthreading, and disabling it should help. Jon -- 5 Ways to Improve Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. -- 5 Ways to Improve Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 5 Ways to Improve Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Preempt-RT ... where to put the patches ?
The new RT kernel is out, there is a test graph under load which should answer a lot of questions on latency. https://www.osadl.org/Single-View.111+M5acfc476362.0.html I have a question on what to do with the Preempt-RT patches for EMC , where do they go ? 2.4 , 2.5 They are really not invasive, it's mainly rtapi ... and you have to do the build for preempt-RT, so there is NO impact for the other ones. Anyhow, can we agree if they go in a separate branch , and to which version ? so that we can get them included. Lars Segerlund. -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Preempt-RT ... where to put the patches ?
Hi, Still good enough for open loop systems . RT-Preempt is a work in progress, and this is rc0 , hopefully it will improve but it is unlekely that it will 'beat' rtapi ... or similar. Still good enough for a lot of stuff, and good enough for me at the moment. On a note, the other machines have good performance for being RT-Preempt, and less jitter than previous versions. I think that the phrase ' good performance compared to rtapi ' is wonderfull news, and a great step forward. It's not a competition, and the systems doesn't exclude each other, however RT-Preempt has a chance to be included in the mainline kernel, which rtapi never has, and that would probably be a big step for EMC uptake since that would enable a emc package in a distro as standard. This is the reason I am striving to have a preempt-rt enabled EMC. / regards, Lars Segerlund. 2011/7/20 Jonathan George geo01...@gmail.com On Wed, Jul 20, 2011 at 2:02 AM, Lars Segerlund lars.segerl...@gmail.comwrote: The new RT kernel is out, there is a test graph under load which should answer a lot of questions on latency. https://www.osadl.org/Single-View.111+M5acfc476362.0.html Great! sounds good. However, what about these two machines? https://www.osadl.org/Latency-plot-of-system-in-rack-4-slot.qa-latencyplot-r4s8.0.html?latencies=showno=slider=0 https://www.osadl.org/Latency-plot-of-system-in-rack-4-slot.qa-latencyplot-r4s8.0.html?latencies=showno=slider=0 Only one of the four machines being tested with the new kernel has good performance compared to rtapi? Jon -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC and RT-Preempt
I have a question about the code, If I am not mistaken , it binds to a specific cpu ? I was under the impression that this was counter productive as far as latency for newer preempt TR systems ? I think you mentioned it before, but I am curious, also 'if' we get one of the newer kernels, neetwrking is not bound to a specific processor for a specific interface ... a patch google dropped in the kernel, think it was 2.6.37 or something like that .. It would be interesting to se what you get with a 'default' linux kernel ( 2.6.39 or 3.0-rc3 ) built with realtime enabled ... and without the cpu binding ... Anyhow it wil take a bit of time for me to look through everything. / regards, Lars Segerlund 2011/6/19 Michael Abel michael.a...@isw.uni-stuttgart.de: Hi Lars, I walked a bit trough the code and tried some things out. There is already cleanup code to avoid this problem, but the cleanup works only when emc is started as root. It seems just like a problem with permissions. I recommend to start emc as root to avoid the problems. In case of problems it's also possible to remove the shm by hand with these commands: ipcrm -M 0x48414c32 #(hal shm) ipcrm -M 0xcafe #(shm interface) Can you please tell me more about the segfaulting shm_tester? I have no problems with this program here... Thanks! regards Michael Lars Segerlund lars.segerl...@gmail.com schrieb: I am seing the same thing, after running emc your shm_tester a couple of times, ipcs gets some cruft, and I can not start emc again ... shm_tester segfaults Trying to investigate / regards Lars Segerlund 2011/6/18 Michael Abel michael.a...@isw.uni-stuttgart.de: Hello Guys, I probably found the problem, why you sometimes have to call halcmd as root to get emc started again. But I don't have a bugfix up to now. It seems like the complete hal shared memory is not given back to the os when emc is closed and my shm_tester is still running. For that reason you can still access the memory when emc has quit. When halcmd is started from the root account, the memory is also still there, but its possible to start emc again. This is printed after emc has quit: $ halcmd -V status HAL: initializing component 'halcmd26165' HAL: component 'halcmd26165' initialized, ID = 26165 HAL locking status: current lock value 0 (00) HAL_LOCK_NONE - nothing is locked HAL memory status used/total shared memory: 48238/262000 active/recycled components: 1/12 active/recycled pins: 0/417 active/recycled parameters: 0/65 active/recycled aliases: 0/0 active/recycled signals: 36/0 active/recycled functions: 0/17 active/recycled threads: 1/0 HAL: removing component 26165 HAL: component 26165 removed, name = 'halcmd26165' One can also see that there is shared memory left with ipcs: ipcs -m -p | grep old_pid_of_rtapi_app Does somebody know, how the rtai version of emc is handling hal shared memory? Is it still there after closing emc? Greetings, Michael -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https
Re: [Emc-developers] EMC and RT-Preempt
Hi, check the text below.
2011/6/20 Michael Abel michael.a...@isw.uni-stuttgart.de:
Hello Lars,
Thanks for trying out...
On 06/19/2011 10:34 PM, Lars Segerlund wrote:
command line ...
root@smurf:/home/ls/src/emc/emc2-dev/src/hal# chrt 99 ./shm_interface_test
Error while shmget
Semaphore value is 0
Waiting one second, then until semaphore gets released
Segmenteringsfel
dmesg ...
[ 3579.723705] shm_interface_t[2462]: segfault at a76ad000 ip
00400d14 sp 7fff128c4600 error 6 in
shm_interface_test[40+2000]
I tried running with gdb but didn't get anything interesting, and it's
not a lot.
I tried strace also
arch_prctl(ARCH_SET_FS, 0x7fcf1a3d9700) = 0
mprotect(0x7fcf19b98000, 16384, PROT_READ) = 0
mprotect(0x7fcf19da8000, 4096, PROT_READ) = 0
mprotect(0x7fcf19fc, 4096, PROT_READ) = 0
mprotect(0x7fcf1a3f8000, 4096, PROT_READ) = 0
munmap(0x7fcf1a3dc000, 103274) = 0
set_tid_address(0x7fcf1a3d99d0) = 2483
set_robust_list(0x7fcf1a3d99e0, 0x18) = 0
futex(0x7fffd6bb89fc, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fffd6bb89fc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
1, NULL, 7fcf1a3d9700) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0x7fcf19daf860, [], SA_RESTORER|SA_SIGINFO,
0x7fcf19db8f60}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7fcf19daf8f0, [],
SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fcf19db8f60}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
shmget(0xcafe, 88, 0666) = 2883607
shmat(2883607, 0, 0) = ?
statfs(/dev/shm, {f_type=0x1021994, f_bsize=4096, f_blocks=127182,
f_bfree=127181, f_bavail=127181, f_files=127182, f_ffree=127179,
f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
futex(0x7fcf19fc52bc, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open(/dev/shm/sem.emcsem1, O_RDWR|O_NOFOLLOW) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=32, ...}) = 0
brk(0) = 0xc9f000
brk(0xcc) = 0xcc
mmap(NULL, 32, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7fcf1a3f4000
close(3) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fcf1a3f3000
write(1, Semaphore value is 0\n, 21Semaphore value is 0
) = 21
write(1, Waiting one second, then until s..., 55Waiting one second,
then until semaphore gets released
) = 55
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, 0x7fffd6bb8860) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmenteringsfel
And a small guess ... I'm running 64 bit ? ...
I don't know if 64 bit make problems in the EMC world. But I saw this in the
output you sent: Error while shmget. It seems like shmget fails for some
reason, but the strace seems normal. And I saw that I forgot the exit
statement in the error handler, this is probably the reason why it
Segmenteringsfels later.
@@ -93,6 +93,7 @@ int main()
id = shmget(key, size, SHM_PERMISSIONS);
if (id == -1) {
printf(Error while shmget\n);
+ exit(-1);
}
Can you maybe try to remove the two shm-memories with ipcrm?
This I have tried, even on rebooted system, but I can look into it
later. Doestn't help.
I have not had time to look to much at the code, since I have been ill
this week, but It seems to run.
I have mostly been busy trying to get an USB driver running for my
hardware, sorry but limited time.
I do believe that shm_interface_test ran a couple of times
Tell me if I can run any test, but at the moment I am actually more
concearned about RT-Preempt EMC :-D ... which is a reason to be really
happy.
Do you like to tell me what you intend to do with an RT_Preempted EMC? Doing
this seems kind of unusal :) .
Well , rt-preempt is almost in mainline now , and I have coded
embedded realtime systems, and I am a bit tired of patching and fixing
:-D ...
WIth realtime in mainline, there could be a 'out of the box' EMC for
open loop systems :D
VxWorks seems to be on it's way to RT-Preempt , RTDM drivers the
same, I think in time RT-Preempt will be the way to go.
If you look at the timing at http://osadl.org ( they have a graph of
all systems ... ), some get down to 8 us latency. Which would be good
enough for running a closed loop system on RT-Preempt. If you can
identify the latency source you can almost always fix it, most of the
time it's a driver.
For some systems a linux 3.0-rc3 gives better latency than 2.6.33-rt
I am going to use a USB interface with some steppers for a small lath
and mill since as a test platform, the USB chip can clock out data at
a constant rate on SPI, so latency doesn't
Re: [Emc-developers] EMC and RT-Preempt
command line ...
root@smurf:/home/ls/src/emc/emc2-dev/src/hal# chrt 99 ./shm_interface_test
Error while shmget
Semaphore value is 0
Waiting one second, then until semaphore gets released
Segmenteringsfel
dmesg ...
[ 3579.723705] shm_interface_t[2462]: segfault at a76ad000 ip
00400d14 sp 7fff128c4600 error 6 in
shm_interface_test[40+2000]
I tried running with gdb but didn't get anything interesting, and it's
not a lot.
I tried strace also
arch_prctl(ARCH_SET_FS, 0x7fcf1a3d9700) = 0
mprotect(0x7fcf19b98000, 16384, PROT_READ) = 0
mprotect(0x7fcf19da8000, 4096, PROT_READ) = 0
mprotect(0x7fcf19fc, 4096, PROT_READ) = 0
mprotect(0x7fcf1a3f8000, 4096, PROT_READ) = 0
munmap(0x7fcf1a3dc000, 103274) = 0
set_tid_address(0x7fcf1a3d99d0) = 2483
set_robust_list(0x7fcf1a3d99e0, 0x18) = 0
futex(0x7fffd6bb89fc, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fffd6bb89fc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
1, NULL, 7fcf1a3d9700) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0x7fcf19daf860, [], SA_RESTORER|SA_SIGINFO,
0x7fcf19db8f60}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7fcf19daf8f0, [],
SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fcf19db8f60}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
shmget(0xcafe, 88, 0666)= 2883607
shmat(2883607, 0, 0)= ?
statfs(/dev/shm, {f_type=0x1021994, f_bsize=4096, f_blocks=127182,
f_bfree=127181, f_bavail=127181, f_files=127182, f_ffree=127179,
f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
futex(0x7fcf19fc52bc, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open(/dev/shm/sem.emcsem1, O_RDWR|O_NOFOLLOW) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=32, ...}) = 0
brk(0) = 0xc9f000
brk(0xcc) = 0xcc
mmap(NULL, 32, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7fcf1a3f4000
close(3)= 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fcf1a3f3000
write(1, Semaphore value is 0\n, 21Semaphore value is 0
) = 21
write(1, Waiting one second, then until s..., 55Waiting one second,
then until semaphore gets released
) = 55
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, 0x7fffd6bb8860) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmenteringsfel
And a small guess ... I'm running 64 bit ? ...
I have not had time to look to much at the code, since I have been ill
this week, but It seems to run.
I have mostly been busy trying to get an USB driver running for my
hardware, sorry but limited time.
I do believe that shm_interface_test ran a couple of times
Tell me if I can run any test, but at the moment I am actually more
concearned about RT-Preempt EMC :-D ... which is a reason to be really
happy.
Have you tried the mailinglist for rt-preempt about the timing ? it's
on http://osadl.org/ , or lkml.org ... I knot the hpet timers have
undergone some work.
/ regards, Lars Segerlund.
2011/6/19 Michael Abel michael.a...@isw.uni-stuttgart.de:
Hi Lars,
I walked a bit trough the code and tried some things out. There is already
cleanup code to avoid this problem, but the cleanup works only when emc is
started as root. It seems just like a problem with permissions. I recommend
to start emc as root to avoid the problems.
In case of problems it's also possible to remove the shm by hand with these
commands:
ipcrm -M 0x48414c32 #(hal shm)
ipcrm -M 0xcafe #(shm interface)
Can you please tell me more about the segfaulting shm_tester? I have no
problems with this program here...
Thanks!
regards Michael
Lars Segerlund lars.segerl...@gmail.com schrieb:
I am seing the same thing, after running emc your shm_tester a
couple of times, ipcs gets some cruft, and I can not start emc again
... shm_tester segfaults
Trying to investigate
/ regards Lars Segerlund
2011/6/18 Michael Abel michael.a...@isw.uni-stuttgart.de:
Hello Guys,
I probably found the problem, why you sometimes have to call halcmd as
root to get emc started again. But I don't have a bugfix up to now.
It seems like the complete hal shared memory is not given back to the os
when emc is closed and my shm_tester is still running. For that reason
you
can still access the memory when emc has quit. When halcmd is started
from the root account, the memory is also still there, but its possible
to start emc again.
This is printed after emc has quit:
$ halcmd -V status
HAL: initializing component 'halcmd26165'
HAL: component 'halcmd26165' initialized, ID = 26165
HAL locking status:
current lock value 0 (00)
HAL_LOCK_NONE - nothing is locked
HAL memory status
used
Re: [Emc-developers] EMC and RT-Preempt
I am seing the same thing, after running emc your shm_tester a couple of times, ipcs gets some cruft, and I can not start emc again ... shm_tester segfaults Trying to investigate / regards Lars Segerlund 2011/6/18 Michael Abel michael.a...@isw.uni-stuttgart.de: Hello Guys, I probably found the problem, why you sometimes have to call halcmd as root to get emc started again. But I don't have a bugfix up to now. It seems like the complete hal shared memory is not given back to the os when emc is closed and my shm_tester is still running. For that reason you can still access the memory when emc has quit. When halcmd is started from the root account, the memory is also still there, but its possible to start emc again. This is printed after emc has quit: $ halcmd -V status HAL: initializing component 'halcmd26165' HAL: component 'halcmd26165' initialized, ID = 26165 HAL locking status: current lock value 0 (00) HAL_LOCK_NONE - nothing is locked HAL memory status used/total shared memory: 48238/262000 active/recycled components: 1/12 active/recycled pins: 0/417 active/recycled parameters: 0/65 active/recycled aliases: 0/0 active/recycled signals: 36/0 active/recycled functions: 0/17 active/recycled threads: 1/0 HAL: removing component 26165 HAL: component 26165 removed, name = 'halcmd26165' One can also see that there is shared memory left with ipcs: ipcs -m -p | grep old_pid_of_rtapi_app Does somebody know, how the rtai version of emc is handling hal shared memory? Is it still there after closing emc? Greetings, Michael -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC and RT-Preempt
I downloaded and built, how about getting this into a branch in git ? And starting to merge things from there ? There is still some 'funkyness' I run into, I am looking at it. / regards, Lars Segerlund. 2011/6/16 Michael Abel michael.a...@isw.uni-stuttgart.de: Hello Folks, a few days ago I promised to set up a site with my work on the RT_Preempt version of EMC together with patches. The patch has the RT_Preempt patch from Michael Büsch and Jeff Eppler already included. I also added and (hopefully) improved some things. I had even less time on the last days than I expected. Accordingly, there are still some uncorrected issues, but I try to fix them soon and post a new patch version. Our webspace admin is currently on holidays, so I put the site temporarily on my own page. Here it is: http://www.bitmuster.org/EMC/emcShm.html Greetings Michael -- Dipl.-Ing. Michael Abel Graduate School advanced Manufacturing Engineering GSaME - Universität Stuttgart Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen ISW - Universität Stuttgart Seidenstr. 36 70174 Stuttgart Tel.: ++49 (0) 711 685-82532 Fax : ++49 (0) 711 685-82808 michael.a...@isw.uni-stuttgart.de michael.a...@gsame.uni-stuttgart.de www.isw.uni-stuttgart.de www.gsame.uni-stuttgart.de -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC and RT-Preempt
If it doesn't interfere with the other stuff, why not in main developement branch ? That way it will be easier to test and get the same attention. / regards, Lars Segerlund 2011/6/17 EBo e...@sandien.com: We should be able to set up a separate sourceforge repository for the effort. If that does not work for people, I would be willing to host this on my github account https://github.com/ebo or mercurial via bitbucket https://bitbucket.org/john_david. For either short or long term. I would need to know the intent so I plop it in the correct places. Just let me know. EBo -- On Fri, 17 Jun 2011 14:52:58 +0200, Lars Segerlund wrote: I downloaded and built, how about getting this into a branch in git ? And starting to merge things from there ? There is still some 'funkyness' I run into, I am looking at it. / regards, Lars Segerlund. 2011/6/16 Michael Abel michael.a...@isw.uni-stuttgart.de: Hello Folks, a few days ago I promised to set up a site with my work on the RT_Preempt version of EMC together with patches. The patch has the RT_Preempt patch from Michael Büsch and Jeff Eppler already included. I also added and (hopefully) improved some things. I had even less time on the last days than I expected. Accordingly, there are still some uncorrected issues, but I try to fix them soon and post a new patch version. Our webspace admin is currently on holidays, so I put the site temporarily on my own page. Here it is: http://www.bitmuster.org/EMC/emcShm.html Greetings Michael -- Dipl.-Ing. Michael Abel Graduate School advanced Manufacturing Engineering GSaME - Universität Stuttgart Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen ISW - Universität Stuttgart Seidenstr. 36 70174 Stuttgart Tel.: ++49 (0) 711 685-82532 Fax : ++49 (0) 711 685-82808 michael.a...@isw.uni-stuttgart.de michael.a...@gsame.uni-stuttgart.de www.isw.uni-stuttgart.de www.gsame.uni-stuttgart.de -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC and RT-Preempt
check http://osadl.org .. if you can find some system resembling the beagle board in the test rack, they have a number of ARM versions. If not ... send a beagleboard :-D .. Anyhow, latency will not be better than what osadl are getting, sometimes a system gets worse latency from a driver, once found you can always fix the driver. EMC on the beagle board would be 'super nice' ... but I don't think the latency from RT-Preempt on ARM will be good enough for servo loops, it might be good enough for 'rep-rap' and similar ... ie. steppers ... / regards, Lars Segerlund 2011/6/17 Jon Elson el...@pico-systems.com: EBo wrote: Agreed. It just seemed that people were nto interested in that for some reason. My two cents would be to make a formal branch (in the same repository) and march along. The any changes would be easy to merge in. If people wanted a temp repository (basically a fork) to hack and then hand merge later, I could help provide one. As you suggest, a brach is a much easier thing to administer than fork and backport... We had some excitement about 1-2 years ago about migrating to the BeagleBoard with the TI version of the ARM CPU. We are still waiting for an RTAI port for the OMAP processors, the ARM maintainer for RTAI has had a BeagleBoard supplied by me for about a year now, he STILL doesn't have it done! So, a new path to getting an RT patch that has acceptable latency on the Beagle would be a good thing. Since the Atom has come out, the need for a small, low-power CPU is less, but the Beagle still beats the Atom on both counts. Yes, at first a branch would be good, then we can look at merging it when it is ready. Jon -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Utilizing FPGAs for CNC controller
I''m planning on using a ft2232H for a stepper setup, since it does buffering and clocking to spi ... Everyone is so negative to usb but you can have 'synchronous transfer' with limited bandwith but guaranteed transfer, so actual data looks quite positive. Check these links, linux realtime and real time device drivers. https://www.osadl.org/Migration-Portability.migration-portability.0.html#c1006 https://www.osadl.org/RTDM-native.howto-rtdm-native.0.html Using a microcontroller for fx. servo loop, and just data through USB changes the game, latency for the feedback to computer but acceptable. / regards, Lars Segerlund. 2011/6/15 Topi Rinkinen linuxcnc@topisoft.fi: Hi, I've been studying different DIY-CNC options for about a year now, and I feel that LinuxCNC is in pretty good shape to play with (have not played with it, though). I am a professional FPGA designer, and I would like to contribute to EMC if FPGA-design is needed. I feel that adding support for the following IO-card, better performance and scalability could be achieved: http://www.latticesemi.com/products/developmenthardware/developmentkits/machxo2picokit.cfm is evaluation card for Lattice's brand new CPLD/FPGA. And the best part for real-time system is FT2232H http://www.ftdichip.com/Products/ICs/FT2232H.htm chip, which can be utilized to transfer upto 40 Mbytes/second to the HW. The price of DevKit is only $29, which is a third compared to MORPH-IC-II http://www.ftdichip.com/Products/Modules/DevelopmentModules.htm (Which also could be used for EMC) How do you feel, could the USB+FPGA based IO expansion be utilized in EMC? Which kind of functionality should be embedded there? What constraints should I recognize? Other thoughts? BR, -Topi -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC and RT-Preempt
I got the original patches from the mail below, I will clean them up so that they apply to the developement release, which reminds me, to which release/tag should I make them apliable. Also due credit to : Michael Büsch m...@bu3sch.de SInce I basicly haven't done a thing more than apply his patches by hand and start testing. / regards, Lars Segerlund On Wed, 2010-09-15 at 08:11 +0200, Lars Segerlund wrote: I have a question about EMC and the underlying realtime kernel, since the Linux RT-Preempt patches are 'almost' included in the mainline now, is there any effort to port EMC to this platform ? http://bu3sch.de/patches/emc-linux-rt/LATEST/ These patches worked pretty well, about 9 months ago. I did not try them recently, though. It is even usable, to some degree, with software stepgen. -- Greetings Michael. 2011/6/9 Lars Segerlund lars.segerl...@gmail.com: Hi guys, A while ago ( se : http://permalink.gmane.org/gmane.linux.distributions.emc.devel/3470 ) , I asked about emc2 and RT-Preempt ... I got some patches, ( thsnks ! ) , which almost applied cleanly ... ( against latest ) .. Would it be ok to apply some patches since it would be nice tho have the build system, and the configuration option of RT-Preempt atleas in the developement branch. It builds , and I can run some simulation in RT-Preempt, but I haven't gotten to do some hardware testing yet. The time is quite nice now, since linux 3.0 is missing the BKL and more realtime stuff is on it's way. What I really want to say is that it would be convienient for me :-D , but also nice to have, and it doesn't interfer with anything ... In other words , if it builds and runs, where should we stick it ? / regards, Lars Segerlund. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC and RT-Preempt
It sounds like Michaels patches from sercos is the way to go, since they are current, enhanced and he plans a code drop. Also that code have been exercised with real gardware :) , what kind of latencies ? IMHO , Lars Segerlund On Jun 10, 2011 3:51 p.m., Michael Abel michael.a...@isw.uni-stuttgart.de wrote: Hi Lars, We also intend to port the patch to a recent EMC version. It would be nice if we find a way to cooperate on this topic. We are currently trying to use EMC in combination sercos III (www.sercos.org) (I asked about that a few weeks ago). We are using a proprietary sercos III communication stack which runs already on RT_Preempt. The stack is based on cosema (http://cosema.sourceforge.net/). To couple EMC with the stack I applied the patches from Michael Büsch and made some other enhancements. I also added a simple shared memory interface component to HAL and semaphore support to linux_rtapi. Which seems to run quite well. A lot of further changes are also planned. I'm planning to put the patches together with a bit of documentation and a few test results on a website within the next week. Greetings Michael On 06/10/2011 02:01 PM, Lars Segerlund wrote: I got the original patches from the mail below, I will clean them up so that they apply to the... -- EditLive Enterpri... -- Dipl.-Ing. Michael Abel Graduate School advanced Manufacturing Engineering GSaME - Universität Stuttgart Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen ISW - Universität Stuttgart Seidenstr. 36 70174 Stuttgart Tel.: ++49 (0) 711 685-82532 Fax : ++49 (0) 711 685-82808 michael.a...@isw.uni-stuttgart.de michael.a...@gsame.uni-stuttgart.de www.isw.uni-stuttgart.de www.gsame.uni-stuttgart.de -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] EMC and RT-Preempt
Hi guys, A while ago ( se : http://permalink.gmane.org/gmane.linux.distributions.emc.devel/3470 ) , I asked about emc2 and RT-Preempt ... I got some patches, ( thsnks ! ) , which almost applied cleanly ... ( against latest ) .. Would it be ok to apply some patches since it would be nice tho have the build system, and the configuration option of RT-Preempt atleas in the developement branch. It builds , and I can run some simulation in RT-Preempt, but I haven't gotten to do some hardware testing yet. The time is quite nice now, since linux 3.0 is missing the BKL and more realtime stuff is on it's way. What I really want to say is that it would be convienient for me :-D , but also nice to have, and it doesn't interfer with anything ... In other words , if it builds and runs, where should we stick it ? / regards, Lars Segerlund. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC and RT-Preempt
Hi, Definitive numbers are hard to give since it's quite system specific, also most of the work on RT-Preempt have been to bring it inte mainline, so last stable is 2.6.33-rtsomething. But the BKL is gone in linus 3.0 , and the really nice thing is that RT-Preempt gives nice performance on SMP systems and HT-Processors. osadl.org have a nice test farm with a varity of system and graphs , generally if youre 'lucky' and have hardware with 'nice' drivers ( which are the biggest offenders ), you 'should be able to get 10 - 20 u , now with a 'bad system youre running up agains 1 ms all of this is progressing. The biggest thing is that it's sneaking into mainline, and can give really good results on some systems, and it would be nice to run EMC on an unpatched kernel. For emc it's basicly an rt-api file and some makefile changes. / Lars Segerlund. 2011/6/9 Jon Elson el...@pico-systems.com: Lars Segerlund wrote: Hi guys, A while ago ( se : http://permalink.gmane.org/gmane.linux.distributions.emc.devel/3470 ) , I asked about emc2 and RT-Preempt ... Can you give some latency and jitter figures for this kernel patch? Thanks, Jon -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] rtai math strangeness
config NOHZ ... ie. tickless kernel ? ... / regards, Lars Segerlund. 2010/12/8 Jeff Epler jep...@unpythonic.net: The crash is in a function for converting counts to nanoseconds, but in your virtualized environment rtai has somehow detected a 0Hz clock for its counts: RTAI[sched]: hard timer type/freq = APIC/0(Hz); default timing: periodic; linear timed lists. I don't know what the solution to this is, it's an unfamiliar error and you're probably right that it's related to virtualization. I think the git commit you mention is probably unrelated. You could prove it for certain by doing a git checkout from before that commit and seeing that the error persists. Jeff -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Atom motherboard and EPP mode
This should be reported to the maintainer of the linux parport driver OR the maintainer of the pci setup code, it 'should' be written in the driver who that is, alternatively drop a mail on the kernel mailing list about it. Now would be a good time to get it fixed for 2.6.37 ... Regards, Lars On Oct 14, 2010 6:05 a.m., Jon Elson el...@pico-systems.com wrote: Jeff Epler wrote: Without changing emc2, the thing I would try next is to disable the linux parp... Of course, another alternative could be to put the pcisetup call in /etc/rc.local, which would m... Well, it seems to be a bug in the Linux enumeration of the port. It seems like we ought to report this to somebody, but I don't have any idea who that would be. Clearly, this works fine on a number of motherboards in 8.04. I don't have 10.04 running on anything here, so I can't test it. Anybody who has an EPP capable motherboard should be able to test it with 10.04 just by setting it in the BIOS for EPP and then checking /proc/ioports for the extra address field. So, I don't know for SURE that this only applies to certain Intel Atom motherboards, but I'm guessing we would have heard about it by now if it was a broader problem. Anyway, I got Don Stanley through creating a script that would run pcisetup before EMC, and setting the pcisetup executable so it had privileges to run. So, that ONE user is in good shape for now. Jon -- Beautiful is writing... -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] EMC limits .. and a suggestion ...
Hello, I saw in some old mails some limit of 8 axes in EMC, what exactly does this refer to ? Is it coordinate axes such as X,Y,Z or does it refer to something else such as degrees of freedom or actuators ( servos od. ). I am sorry if it'a a stupid question but the more I think about it the harder it is for me to understand what was meant. This is the link i refer to: http://www.orocos.org/forum/orocos/orocos-users/trajectory-planning-look-ahead-interpolation-nurbs#comment-4462 The second sugestion is that it is actually easy to setup gschem from the GEDA software suit to handle almost any symbols you can draw, for example HAL building blocks. I thought about this the other day when I used it to setup a simulation for gnucap, it might be a usable tool to setup and configure the HAL layer. Basicly draw the topology, and save, then use a post processign script to make some config files. Any thougts ? / regards, Lars Segerlund. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC limits .. and a suggestion ...
I don't know wether to laugh or cry :-/ ... but must admit that I should googled it beforehand, forgive a newcomer to EMC ... / regards, Lars 2010/10/12 Alex Joni alex.j...@robcon.ro: Hello, I saw in some old mails some limit of 8 axes in EMC, what exactly does this refer to ? The limit is for 9 axes: XYZABCUVW You can have more joints, but currently the code that allows that sits in a branch, which is not quite done yet: joints_axes3. Is it coordinate axes such as X,Y,Z or does it refer to something else such as degrees of freedom or actuators ( servos od. ). I am sorry if it'a a stupid question but the more I think about it the harder it is for me to understand what was meant. This is the link i refer to: http://www.orocos.org/forum/orocos/orocos-users/trajectory-planning-look-ahead-interpolation-nurbs#comment-4462 The second sugestion is that it is actually easy to setup gschem from the GEDA software suit to handle almost any symbols you can draw, for example HAL building blocks. I thought about this the other day when I used it to setup a simulation for gnucap, it might be a usable tool to setup and configure the HAL layer. Basicly draw the topology, and save, then use a post processign script to make some config files. Any thougts ? Yup, http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?HalSchematicsUsingGschem Regards, Alex -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC limits .. and a suggestion ...
Thanks, Then it's not a problem, I just wanted to make sure it was not joints. / regards, Lars Segerlund. 2010/10/12 Andy Pugh a...@andypugh.fsnet.co.uk: On 12 October 2010 13:36, Lars Segerlund lars.segerl...@gmail.com wrote: I saw in some old mails some limit of 8 axes in EMC, what exactly does this refer to ? It is a limit of 9, and really is inherent to G-code, which has A, B, C, U, V, W, X, Y, Z as command words to move an axis. There are not many (if any) letters of the alphabet unused, and the fact that G-code ignores spaces means that this is not an easy limitation to overcome. There is no inherent reason why this limitation of degrees of freedom has to mean a limitation in the number of joints, and this is being worked on, as Alex has already mentioned. There is no limit to the number of Stepgens or PIDs that you can have in HAL, so if you are happy to control joint positions from analogue output commands or custom M-codes in the G-code you can fiddle it that way (though such moves will not be coordinated with the 9 built-in axes) -- atp -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Quick question about naming ...
I looked at the 'old' patch for linux with preempt RT , and it actually aplied quite cleanly to emc2-2.4.3. However I was not to happy with the naming. bash-3.2$ ls rtapi/ README mathstubs.c rtapi_common.h rtl_rtapi.c Submakefile procfs_macros.h rtapi_ctype.h rtl_ulapi.c examplesrtai_rtapi.c rtapi_errno.h sim_common.h linux_common.h rtai_ulapi.c rtapi_math.h sim_rtapi.c linux_rtapi.c rtapi.h rtapi_math_i386.h sim_rtapi_app.cc linux_rtapi_app.cc rtapi_app.h rtapi_proc.h sim_ulapi.c linux_ulapi.c rtapi_bitops.h rtapi_string.h vsnprintf.h bash-3.2$ Where Submakefile linux_rtapi.c linux_rtapi_app.cc linux_ulapi.c linux_common.h are the files from the patch ... Wouldn't something like: rtpre_rtapi.c and so on be more consistent ? Any suggestrions. / Lars Segerlund. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
