Re: [Emc-developers] More trouble for LinuxCNC's memory model on ARM
my debian box does not show stdatomic.h. so maybe read the faq at http:/infocenter.arm.com/help/topic/com.arm.doc.faqs/ka14041.html ? cheers, j. On Wed, Jul 22, 2015 at 5:12 PM, Sebastian Kuzminsky s...@highlab.com wrote: On 7/22/15 8:03 AM, Chris Lesiak wrote: I THINK that you don't actually need full sequential consistency. Use atomic_load_explicit with memory_order_acquire and atomic_store_explicit with memory_order_release. Ah, that's what i was missing, the optional memory_order argument to the _explicit load store functions. I just built 2.7 on Wheezy (gcc 4.7.2) with -std=gnu11 (for C) and -std=gnu++11 (for C++) and it compiled and passed all the tests. -- 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] EtherCAT
So perhaps this is the right time for the ultimate solution: --lets stop lusting after the idols of Beckhoff.-- I have and I burned badly. Lots of good productive time down the drain, because I liked the IgH stack so much. And of course I still respect that piece of software. But in my experience the Beckhoff attitude, the Beckhoff hardware and Beckhoff service are bad news. The hardware changes version every 5 minutes (read the configuration files) and when you need real service you get the Disperin solution. A while back I spend some very expensive money (i.e. lots of it) sorting out an intermittent problem in a 10 axes machine running on a Beckhoff NT computer. Beckhoff in Verl could not tell me (at any price) how to monitor the Sercos loop in a case like this. I had to find it out myself. In an Opensource environment that is off course quite acceptable, but THIS WAS NOT. (And I dont think it even fair on the local agent to talk about them) In my experience that company has sold its soul to Microsoft, which is good for business, but bad for technological exellence. Perhaps this is a good solution to the communities dilemma: http://www.ethernet-powerlink.org/ The opensource stack might be configured as a master or a slave (good for building your own io) and WAGO and a few others sell io off the shelf. cheers, j. On Fri, Oct 25, 2013 at 2:57 AM, EBo e...@sandien.com wrote: On Oct 24 2013 2:23 PM, John Morris wrote: On 10/24/2013 02:06 PM, andy pugh wrote: On 24 October 2013 19:55, John Morris j...@zultron.com wrote: I believe that these restrictions mean that neither the LinuxCNC project nor anyone else may distribute EtherCAT drivers in source code form or otherwise, since with EtherCAT drivers, the software would essentially become an 'EtherCAT device' subject to Beckhoff's licensing requirements. Does it matter that the HAL driver in question is not itself an EtherCAT master, but simply a glue layer between HAL and a third-party EtherCAT Master? (An inexact analogy would be a GPL filter to save a document in Microsoft Word format) I'm no authority at all, of course, just trying to interpret these matters for myself. I was becoming involved with packaging EtherCAT before this topic was raised, so it affects me personally. I'm focusing on the paragraph of Gerd's email following the title 'For product /device manufacturers'. He writes, 'Making, marketing and sale of a product making use of the EtherCAT technology requires membership in the ETG and licensing of the technology'. This sounds like LinuxCNC would qualify as such a product, and therefore those of us engaged in those activities (most all of us here in emc-developers) would be bound by those requirements, were EtherCAT to be included. A bit further down, he writes, 'if a product is a master stack software, a vendor of the master stack or the master device does require a technology license agreement for the master product'. I don't understand what 'master device' means or when the term would apply to LinuxCNC or systems it runs on. In any case, it does apply to IgH's EtherCAT Master for Linux implementation, and is a 'further restriction' explicitly prohibited by the GPL. We are going to run around and around and around wasting time on this until someone 1) emails both IgH and FSF and ask for a determination on a) will LinuxCNC require to have such an agreement, and b) if their added requirement is a violation of the GPL; or 2) someone hires a copyright lawyer to sort it out. All us arguing about it is a wast of time unless somone here IS actually a lawyer, hired one, or emailed the two principal determining parties. -- 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=60135991iu=/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=60135991iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EtherCAT
Perhaps you have to register for those screens Gene, I forget, it is a
while ago I went through it.
There are lots of pdf's available also.
The software stack comes from here:
http://www.systec-electronic.com/html/index.pl/en_download_OpenPOWERLINK
it is not as nice as IgH, bu it is manageable.
It will work with shop hardware but this is always a bit of a 2sided coin.
to get it working at a predictable speed the eth driver might need some
polishing as they did for the IgH stack. That issue will always be with us.
cheers,
j.
On Fri, Oct 25, 2013 at 6:54 PM, Gene Heskett ghesk...@wdtv.com wrote:
On Friday 25 October 2013 12:51:37 Jan de Kruyf did opine:
So perhaps this is the right time for the ultimate solution:
--lets stop lusting after the idols of Beckhoff.--
I have and I burned badly. Lots of good productive time down the drain,
because I liked the IgH stack so much.
And of course I still respect that piece of software. But in my
experience the Beckhoff attitude, the Beckhoff hardware and Beckhoff
service are bad news.
The hardware changes version every 5 minutes (read the configuration
files) and when you need real service you get the Disperin solution.
A while back I spend some very expensive money (i.e. lots of it) sorting
out an intermittent problem in a 10 axes machine running on a Beckhoff
NT computer. Beckhoff in Verl could not tell me (at any price) how to
monitor the Sercos loop in a case like this. I had to find it out
myself. In an Opensource environment that is off course quite
acceptable, but THIS WAS NOT. (And I dont think it even fair on the
local agent to talk about them)
In my experience that company has sold its soul to Microsoft, which is
good for business, but bad for technological exellence.
Perhaps this is a good solution to the communities dilemma:
http://www.ethernet-powerlink.org/
The opensource stack might be configured as a master or a slave (good
for building your own io) and WAGO and a few others sell io off the
shelf.
cheers,
j.
Sounds interesting Jan, but the site isn't 100% functional. I ran into 2
links that gave me black screens forever.
And I was not able to determine if it works using OTS hardware for the
ethernet itself.
On Fri, Oct 25, 2013 at 2:57 AM, EBo e...@sandien.com wrote:
On Oct 24 2013 2:23 PM, John Morris wrote:
On 10/24/2013 02:06 PM, andy pugh wrote:
On 24 October 2013 19:55, John Morris j...@zultron.com wrote:
I believe that these restrictions mean that neither the LinuxCNC
project
nor anyone else may distribute EtherCAT drivers in source code
form or
otherwise, since with EtherCAT drivers, the software would
essentially
become an 'EtherCAT device' subject to Beckhoff's licensing
requirements.
Does it matter that the HAL driver in question is not itself an
EtherCAT master, but simply a glue layer between HAL and a
third-party
EtherCAT Master?
(An inexact analogy would be a GPL filter to save a document in
Microsoft Word format)
I'm no authority at all, of course, just trying to interpret these
matters for myself. I was becoming involved with packaging EtherCAT
before this topic was raised, so it affects me personally.
I'm focusing on the paragraph of Gerd's email following the title
'For
product /device manufacturers'.
He writes, 'Making, marketing and sale of a product making use of
the EtherCAT technology requires membership in the ETG and
licensing of the
technology'. This sounds like LinuxCNC would qualify as such a
product,
and therefore those of us engaged in those activities (most all of
us here in emc-developers) would be bound by those requirements,
were EtherCAT to be included.
A bit further down, he writes, 'if a product is a master stack
software,
a vendor of the master stack or the master device does require a
technology license agreement for the master product'. I don't
understand what 'master device' means or when the term would apply
to LinuxCNC or systems it runs on. In any case, it does apply to
IgH's EtherCAT Master for Linux implementation, and is a 'further
restriction'
explicitly prohibited by the GPL.
We are going to run around and around and around wasting time on this
until someone 1) emails both IgH and FSF and ask for a determination
on a) will LinuxCNC require to have such an agreement, and b) if
their added requirement is a violation of the GPL; or 2) someone
hires a copyright lawyer to sort it out. All us arguing about it is
a wast of time unless somone here IS actually a lawyer, hired one, or
emailed the two principal determining parties.
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application
Re: [Emc-developers] EtherCAT
read this thread carefully! http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16824 j. On Wed, Oct 23, 2013 at 12:47 AM, Jeff Epler jep...@unpythonic.net wrote: On Tue, Oct 22, 2013 at 11:18:53AM -0500, John Morris wrote: You mean it's possible to ship the driver sources in tarballs distributed by the LinuxCNC project? I think so. IIRC, Seb's buildbots build and test the source separately from .debs. The .deb pkg builds would need to disable the EtherCAT build, since the build results are 'distributed' from the buildbot web page. No, I mean that this ethercat driver should live in its own git repo and/or .tar.gz file not shipped from linuxcnc.org in source or binary form. This is technically possible (or if it isn't, we'd want to fix it), because we ship Makefile.modinc in our -dev package to ease building userspace and realtime HAL components outside of the linuxcnc source tree. That way whoever thinks that there is not a GPL conflict here can ship source (and binaries if they see fit) from their own website. But no, I was emphatically *not* suggesting to ship GPL-incompatible source via linuxcnc.org even if we take care not to ship the corresponding binaries. Jeff -- 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=60135991iu=/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=60135991iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Back to my fried controller
74LS240 = 74HCT240 it also gives a 74HC240 but that one has different threshold levels. j. On Fri, May 31, 2013 at 8:49 PM, Gene Heskett ghesk...@wdtv.com wrote: Greetings to yee who are following my sob story.. It appears the MOC3052 at least has an led in it, so I replaced the led in series with it, with no joy. Then, trying to use that pocket scope to trouble shoot, I took the hook off the probe, which leaves the ground ring around the tip exposed, so of course it accidentally had to touch a real ground, tripping the breaker in the service box. And of course now the C41 isn't working. So I ordered up enough parts to shotgun both twice from digikey, including socketing the LM324's in the MC60 controller, the MOC3052 and all its 2n440x transistors. Except one chip on the C41 board, digikey says the 74LS240 is an obsolete part and didn't suggest a replacement. I think I need a beer, this is discouraging. Before I start again when the chips get here, I need to make an insulator for the end shell of the pocket scopes probe. Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) My web page: http://coyoteden.dyndns-free.com:85/gene is up! My views http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml Kissing a fish is like smoking a bicycle. A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] rt-preempt-integration
Hallo, Why is this Charles: If you are using Debian Wheezy, make sure you use gcc 4.6 instead of 4.7! Is it because of some new behaviour of Gcc? ( http://gcc.gnu.org/gcc-4.7/porting_to.html ) or is there more? Cheers, j. On Tue, Oct 9, 2012 at 8:28 PM, Charles Steinkuehler char...@steinkuehler.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/8/2012 10:43 AM, Michael Haberler wrote: to get this ball rolling, I have set up the rt-preempt-integration and xenomai-integration (off yesterday's v2.5_branch) in my repo: http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/rt-preempt-integration Many thanks to Michael for setting this up! The rt-preempt-integration branch is now ready for use. The latest patch set from John Morris has been applied, and the code is ready to check out and use. If you are using Debian Wheezy, make sure you use gcc 4.6 instead of 4.7! While the code is usable as-is, at least two areas need some attention: * Modification of the debian/ directory to enable building preempt-rt packages allowing easy testing on modern Debian/Ubuntu systems that ship with the preempt-rt kernel as an option. * Review of permissions and the setuid bits required to run. At the moment if HAL ever crashes or doesn't load properly, it is fairly ugly trying to get things cleaned up so you can run LinuxCNC again. NOTE: If you would like to experiment but do not have a preempt-rt kernel, I believe you should be able to build and run as-is, you will just experience nasty latency values until you run under a preempt-rt kernel. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlB0bLMACgkQLywbqEHdNFzzDACgug6oP3N+sXzNUI3r9k4mndMn BWwAoJ2HwqJk+YYrprD8H42ikPYrbLg5 =evNh -END PGP SIGNATURE- -- 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] wiki page PreparingContributions (was: Re: sim-parport)
man ld is a good start. Then, I think in the top make file, you add some interesting warning switches to $LDFLAGS. (line 180 or 182 depending what you are upto) Like--verbose --warn-common --warn-unresolved-symbols and so on. By the looks of it there is a symbol problem of the third kind, i.e. not the regular missing symbol because a missing lib. Have fun, j. On Sun, Oct 7, 2012 at 3:26 AM, andy pugh bodge...@gmail.com wrote: I don't know where to go from here. I can build LinuxCNC including my new component using make in both realtime and sim modes. I can create debs in realtime mode. I can't create debs in sim mode. But the error messages give no clue why. My work is currently in a branch off of 2.5. I can build sim-2.5 debs. I really don't know where to go from here. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- 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
[Emc-developers] secure boot article
For those who have not seen this yet: https://lwn.net/Articles/514985/#Comments it seems relevant. j. -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? 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] secure boot article
It looks to me, no more direct access to parport etc. Only throug a signed kernelmodule. That is why I posted it. Dont know when it will become common practice, but obviously the evil empire MUST have this to keep the dogs off the door. j. On Sat, Sep 15, 2012 at 8:35 PM, Jon Elson el...@pico-systems.com wrote: Jan de Kruyf wrote: For those who have not seen this yet: https://lwn.net/Articles/514985/#Comments it seems relevant. Can anyone interpret this for us? Jon -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? 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
Michael, as far as I am aware that is in the code, but obviously somewhere is a slip up. j. On Fri, Sep 14, 2012 at 8:15 AM, Michael Haberler mai...@mah.priv.atwrote: 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
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 -- 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
Re: [Emc-developers] parport user mode question
http://pyserial.sourceforge.net/ Near the bottom of the page is pyparallel. Enjoy, j. On Mon, Sep 3, 2012 at 9:44 AM, Michael Haberler mai...@mah.priv.at wrote: the range of options to talk to a parport device is bewildering what would the parport-in-the-know suggest for a userland hal_parport driver: - use ppdev and peruse /sys/class/ppdev/parport%d/device/resources to figure out whats available - just use the ioperm() call and believe the user hit the right port - any other options? - 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] parport user mode question
http://people.redhat.com/twaugh/parport/html/parportguide.html dunno if there is an up to date version. Otherwise ask Tim. I dont think he moved yet. j. On Mon, Sep 3, 2012 at 12:21 PM, Michael Haberler mai...@mah.priv.atwrote: Am 03.09.2012 um 11:32 schrieb Jan de Kruyf: http://pyserial.sourceforge.net/ Near the bottom of the page is pyparallel. this uses ppdev, and I wanted to retain direct register read/write instead of an ioctl -m Enjoy, j. On Mon, Sep 3, 2012 at 9:44 AM, Michael Haberler mai...@mah.priv.at wrote: the range of options to talk to a parport device is bewildering what would the parport-in-the-know suggest for a userland hal_parport driver: - use ppdev and peruse /sys/class/ppdev/parport%d/device/resources to figure out whats available - just use the ioperm() call and believe the user hit the right port - any other options? - 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] LinuxCNC RT OS underpinnings
I fully share the urgency Michael feels about the issue, but I think that the RT issue is not easily tackled from LinuxCNC2. So in LinuxCNC2 I would rather vote for getting Xenomai to work (again) as a real time alternative. If you look in the building scripts there always was that option, it has been neglected a bit lately. On top of it, there is the issue of the software stepgeneraration for a majority of systems, for which RTPREEMPT is not the perfect vehicle yet, unless you invest in a high-end board. My experience with other systems shows that RTPREEMPT is quite stable on the 3 series kernel, provided some rules are followed in your design. So personally I am not prepared to fantasize about backhacking RT into LCNC2, a few people have been at it now and nothing was finished into a workable product or perhaps the interest of the community is not there, I do not know. cheers, j. On Mon, Aug 27, 2012 at 10:04 PM, Michael Haberler mai...@mah.priv.atwrote: 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] [ emc-Feature Requests-3558022 ] Python gui-land access to set and get emc.var parameters
Michael, hallo. Here is a way out question: In a distributed system would you see your way clear to do the whole setup of a headless station from the database? I.e. store (pointers to) the specific HAL code, ini files, etc in the database and distribute on power-up? j. On Fri, Aug 17, 2012 at 8:21 PM, Michael Haberler mai...@mah.priv.at wrote: Am 17.08.2012 um 19:03 schrieb Kenneth Lerman: On 8/17/2012 12:42 PM, Kent A. Reed wrote: pardon me for cherry-picking points from your message. Anything I ... Don't take the lack of a hearty response from the developer community negatively. Most of us will speak up if we disagree. At any rate, using a database seems fine to me. A noSQL database seems appropriate. An if *you* (Michael) think Redis is the one to use, I trust your judgement. (Particularly since Kent seems to agree.) Regards, Ken That's very good noises;) So I think step one is this branch: http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/redis-integration This will be the basic Redis development environment until the packages are available. When this is a safe bet, everything under src/redis/redis and src/redis/redis-py can be dumped. This includes snapshots of redis-server and C API, and the redis-py Python bindings, integrated with LinuxCNC configure and build. Also, a C example including Submakefile, and a simple Python sample. It does not modify any LinuxCNC code to actually use it - this is the plumbing branch. Currently the configuration options WRT to redis are 'yes' and 'yes', but that can be patched. the linuxcnc startup script starts/stops the server automatically. The branch is off master; tested on 10.04 and 8.04, both RT and simulator, 2 machines. README: http://git.mah.priv.at/gitweb/emc2-dev.git/blob_plain/f4e198cfc1d9f73556b6364f485a7df346f638ec:/src/redis/README to run the demos, see src/redis/examples - the C example integrates with build. --- this is a LOT of code - I would appreciate a few other eyeballs before merging this into master. - 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
Re: [Emc-developers] future plannig was: LinuxCNC (EMC2) with RCS
Hallo, - what features should LinuxCNC3 have - when, how, and after which preconditions ticked off should planning and work on LinuxCNC 3 start To guide these 2 processes I think I should quote something I found in Edsger Dijkstra, long ago: The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay. Sir Antony Hoare, 1980 So I guess lets leave the holy cows out on the grass for a bit, and think this issue through, little bit by little bit. Mindful of Sir Antony Hoare. Lets take each part of EMC and strip it to the bare minimum requirements. See how we could implement it in such a way that it will be easy to acommodate wishes from another quarter, or indeed embellishments that exist at this moment inside EMC. After we have found this minimum implementation (even if it is only in block diagram form) we might make a list for each part of EMC of te various embellishments that people feel they cannot live without. And see how that could easily be implemented into the minimum structure in such a way that the *utmost simplicity* and thus the *reliability* are not compromised. (I repeat: the criterium will not be: but I need this! rather the criterium will be: how is this *simple* and *reliable*!) A few cycles of this process will reveal the most beautiful CNC software ever written. Cheers, j. On Sat, Aug 11, 2012 at 3:04 PM, Michael Haberler mai...@mah.priv.atwrote: I think we have at least two discussions going on in the same thread: - what features should LinuxCNC3 have - when, how, and after which preconditions ticked off should planning and work on LinuxCNC 3 start It is wonderful and lusty to muse on the first item on end, but my point to start with was: I by now firmly believe there are some not-so-lusty preconditions and decisions to be looked at (2), and work done, before (1) becomes more than a blue-sky exercise without much consequence. This conclusion is driven by the following observations: 1. there are several software parts in the software which are a legacy 2. there are several structural and design decisions which may have been warranted at the time, but are due for review 3. the two of the above restrict the development model to a - lets call it 'very incremental change' - model; others might call less friendly 'patching around' 4. the LinuxCNC license situation puts severe restrictions on how 1) can be addressed without scratch rewrite of a replacement component - in the face of existing viable alternatives. I am happy to outline in detail why I arrive at these conclusions but I probably should do that in separate email, or a wiki page. With respect to 4), let me only say that I'm not putting the blame on someone's doorstep here; things just happen and much of this issue at hand derives from the bizarre license compatibility situation in the FLOSS space. I do have an opinion on these wars, and some of the acting persons, and not necessarily positive - but that's irrelevant. The only thing which counts is to remove any roadblocks wrt to the LinuxCNC future, and I feel that cannot be done without movement on our side. As I said, I'm willing to take on a bit of a study which triages and gauges the issues, like - which parts are essential carrying forward; which might need a license change, which size of developer consent would be required to achieve that. That can be a basis for an informed decision to go forward. A quick preview actually shows that HAL and RTAPI come from very small subsets of the developers; component infrastructure: a bit more but 'looks doable'. I need to do this more thorough. I will tag the next thread clearly whether it belongs to the first or second issue at the top. - Michael --- ps: wrt to the performance discussion it is instructive to read http://git.mah.priv.at/gitweb/emc2-dev.git/commit/645bcebd3382c1686367b686c3b815372f071b78, which in essence says: up to Sept 1 2006 your hypothetical 100-million-lines-a-second interpreter was limited to an actual speed of about 30 blocks/second by the way task scheduled the interpreter. Historians: was there a sigh of relief after this patch? I wasnt around at the time. -- 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] future plannig was: LinuxCNC (EMC2) with RCS
Thank you Alexey I sort of forgot a little bit about them. j. On Sat, Aug 11, 2012 at 8:07 PM, Alexey Starikovskiy aysta...@gmail.comwrote: May I remind you about orocos.org project -- they are linux/xenomai/rt-net/lua based and solve similar problems... On Sat, Aug 11, 2012 at 9:50 PM, Javier Ros j...@unavarra.es wrote: On Thu, Aug 9, 2012 at 8:21 AM, EBo e...@sandien.com wrote: On Thu, 9 Aug 2012 13:22:58 +0200, Javier Ros wrote: ... ... I don't know a lot about the internals of LinuxCNC but, as has already argued in this list, I want to favor the idea that HAL on itself is a very nice piece of software that can be used very well for users not interested at all in machining. If you add to this GladeVCP, you have a kind of LabView. From this perspective having support for RTAI and PREMPT-RT patch looks like a very good idea. to turn it into a open source labview you would need to build a simple interface that non-programmers can easily understand. GladeVCP would go some way towards that, but you really need something similar to Khoros'es old Cantata http://www.cs.colostate.edu/cameron/khoros.html , VisTrains http://www.vistrails.org, or similar. (please note that Khoros is defunct, was sold off, and the opensource license was basically pulled -- which still pisses me off 10 years after the fact)... I agree but nevertheless the combination GladeVCP + HAL in really really nice, and fills a very big hole. Wouldn't be interesting to have HAL as a independent set of packages upon which LinuxCNC depends?. I think GladeVCP could ideally be a package independent of linuxCNC depending upon HAL. I think that this phylosophy already exist, even for the documentation -atl least to some extent-. So taking these packages appart could be not too time consuming. Another issue, may be a bit out of context, is the entering into the scene of low price PC like platforms (beagle, raphsberry,...). I dream of such a plaform combined with a FPGA. For example a platform similar to Labview's Rio platforms that basically have a processor running VxWorks and a programable FPGA interfaced to it. I think it could make sense to think how such a paradigm can be adopted in the context of HAL / linux CNC without drastically changing the actual paradigm. have you taken a look at MiniEMC2? http://code.google.com/p/miniemc2/ Maybe hack that to include some stuff along a PLC, SCADA, etc., and other projects could get behind it. As a ntoe, I have not chased down all the licensing issues, but this would give you a thought. But this is basically a linux box with Xenomai from which the user interface has been removed, in favor of performance and web interface. I recognice that this is a possible path, that is strip out a linux distribution until you get the bare minimum to get HAL running, then you can interface it using the network, may be AXIS can use some level of absraction that allows it to interface with remote systems. I think this is the philosophy underliying lots of comercial RT systems like the LabView Rio family, so it can not be a bad idea. Within this paradigm I was wondering if it could be posible to get HAL running not only on Linux / RTAI / preempt-RT / Xenomai, but in a different RT OS, like VxWorks, or better on a GPL RT alternative if there is something else available / foreseable. Probably this is nonsense, or too much complitated to be worth the effort. Nevertheless making intefaces abstract enough so they can comunicate with HAL through the network looks reasonable to me. May be this requires some additions to HAL, not sure about this. This can even get AXIS runnig in windows :-)) . Just thinking aloud (sorry for the bandwidth). Cheers, Javier -- 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
Re: [Emc-developers] future plannig was: LinuxCNC (EMC2) with RCS
Daniel, I would say that you hit it right on the head here. I will add to it that CAM operators often are not quite aware of the relationship between accuracy of the cut and size of program / length of the individual segments. And so they have not set the CAM parameters optimally. Michael is in deep thought at the moment. Something has stirred him . . . . . . . [?] cheers, j. On Fri, Aug 10, 2012 at 8:08 PM, Daniel Rogge dro...@tormach.com wrote: I did some torture testing for a potential customer a long time ago. The test was a 2 circle of 1 G01 moves. On a 600 MHz Pentium II (or would that have been a PIII?) I got some 780 blocks/second. I have no idea how much of that was due to the interpreter and how much in the trajectory planner. Also, it was not clear how much was due to raw processing speed and how much due to the 1-block lookahead. Much of this experiment was to see what the G64 Pxx could do for contouring work. Well, I think even a 3:1 slow down would not be a good thing, unless the interpreter is a TINY part of the total block processing time (which it may well be, I just don't know.) Jon, The interpreter is nowhere near the bottleneck that the 1-block lookahead is. To satisfy my own curiosity I wrote a 1000-line long program (1000 lines is the default interpreter lookahead, set in emccfg.h) that started with M3 S500, ended with S1000, and consisted solely of .01mm G0 moves. Since active_settings[] lives in interpreter time, not motion time, the displayed S word in the Active Gcodes field of Axis tells you when the interpreter hits the S1000 line. It's nearly instantaneous - the interpreter is at the end of the file before motion even starts. Previous posts have defended the one-block TP lookahead (or more properly put, the requirement that the machine be able to come to a controlled stop during any one move). Most defenders of the current TP point the blame at cheap CAM for outputting small line segments instead of G2/G3. This doesn't help moldmakers much, who by the nature of the part need small line segment code. Furthermore as more CAM companies implement constant tool engagement strategies we will see more and more small line segment code. The big controls compete on the ability to handle small line segments - HAAS charges an extra $2000 to go from 40 to 80 blocks of lookahead. While bigger accelerations help ameliorate this lookahead restriction, they don't fix the problem. I would love to see improvement in this area, but I'm hesitant to dive into development until I have a better feel for the underlying code. Michael seems to be intimate with this code after some of his thought experiments with VPT - perhaps he would be willing to provide an outline on he thinks it would take to change the TP to better handle small line segment code. Rogge -- 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 B56.gif-- 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] future plannig was: LinuxCNC (EMC2) with RCS
Even I cannot find fault with this argument! [?] Cheers, j. On Thu, Aug 9, 2012 at 1:22 PM, Javier Ros j...@unavarra.es wrote: Just listening to this interesting conversation. I just would like to comment on this 1) is the dealbreaker IMO - redoing the HAL, RTAPI, component infrastructure basically for license purposes is out of reach IMO. Is that doable? Assume this can be achieved, a first great milestone would be to have the brushed-up gladevcp run a HAL-only application; maybe low-level talk to motion through a revamped API (Python). Actually I think LinuxCNC kindof 'misses a market' - I see use for HAL-only applications with GUI. I don't know a lot about the internals of LinuxCNC but, as has already argued in this list, I want to favor the idea that HAL on itself is a very nice piece of software that can be used very well for users not interested at all in machining. If you add to this GladeVCP, you have a kind of LabView. From this perspective having support for RTAI and PREMPT-RT patch looks like a very good idea. Wouldn't be interesting to have HAL as a independent set of packages upon which LinuxCNC depends?. I think GladeVCP could ideally be a package independent of linuxCNC depending upon HAL. I think that this phylosophy already exist, even for the documentation -atl least to some extent-. So taking these packages appart could be not too time consuming. Another issue, may be a bit out of context, is the entering into the scene of low price PC like platforms (beagle, raphsberry,...). I dream of such a plaform combined with a FPGA. For example a platform similar to Labview's Rio platforms that basically have a processor running VxWorks and a programable FPGA interfaced to it. I think it could make sense to think how such a paradigm can be adopted in the context of HAL / linux CNC without drastically changing the actual paradigm. Have a nice day, Javier -- 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 4F4.gif-- 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] CSMIO Eth motion controller + EMC2
its halting state is 43 68 72 69 73 20 52 61 64 65 6b Is the Carry wire connected up? j. On Thu, May 31, 2012 at 12:56 AM, Michael Haberler mai...@mah.priv.atwrote: Am 30.05.2012 um 16:51 schrieb Viesturs Lācis: 2012/5/30 Łukasz Prymula luk...@cs-lab.eu: For me, most interesting thing is that in what method planner transfers trajectory to HAL layer. As you see I need points buffer. AFAIK it is done with NML messages. I think that Michael Haberler would be most knowledgeable about this. thanks, but on that issue you might be overlooking the fact that I own intellectual property on the Haberler 88-bit high-speed blame shifter device its halting state is 43 68 72 69 73 20 52 61 64 65 6b -m -- Viesturs -- 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, RTAI, and Ubuntu long term support releases
Just a quick note here: Xenomai has kernel 3 support for a while already And they have started making true on their roadmap regarding Xenomai3. since the Russian with the Arm board already uses Xenomai it will be VERY worthwhile investigating that road also! Other than that on the way out scene: nobody stops the learned among us to pick up the bits and pieces here http://opencores.org/projects and start playing some lego. Cheers, j. On Sat, May 19, 2012 at 6:23 AM, EBo e...@sandien.com wrote: On Fri, 18 May 2012 18:42:53 -0700, dave wrote: Matt and I were talking the other day about a next-gen linuxcnc processor and wandered into the area of a decent processor coupled to an fpga for all the stuff that a normal processor doesn't do well. have you taken a look at Yishin Li's work through www.araisrobo.com? I hope to start playing with this soon. 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, RTAI, and Ubuntu long term support releases
Oh, thanks for that. You got me excited! look here (I did not up to now, just waffled in general as usual) http://git.xenomai.org/?p=xenomai-forge.git;a=summary and here: http://git.xenomai.org/?p=xenomai-forge.git;a=blob;f=doc/txt/cobalt-skin.txt;h=bf00eb2c792b7894b0270bb0cb77147563cdd2e2;hb=master so it smells like work going on there!. I will look at it a while later in detail. At the moment I am committed to RT_PREEMPT, but it looks like a seamless transition from there. And yes latencies are a bit worse, but still the interface makes me drool Cheers, j. On Sat, May 19, 2012 at 4:48 PM, Moses McKnight mo...@texband.net wrote: On 05/19/2012 03:50 AM, Jan de Kruyf wrote: Just a quick note here: Xenomai has kernel 3 support for a while already And they have started making true on their roadmap regarding Xenomai3. Where do you see that? I have browsed their git repos several times and just did again, and have not found any kernel patch for x86 higher than 2.6.38.8 They have patches for ARM 3.x but that does not help us for the general user. since the Russian with the Arm board already uses Xenomai it will be VERY worthwhile investigating that road also! Xenomai is interesting in my opinion as well. They seem to support more architectures than RTAI, but the latencies are reportedly not as good. Moses -- 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
Viesturs: Pray tell me which, I like to see what they did then to make the motherboard hardware perform better. j. On Fri, May 18, 2012 at 10:27 AM, Viesturs Lācis viesturs.la...@gmail.comwrote: 2012/5/18 Jan de Kruyf jan.de.kr...@gmail.com: In any case: from the grumbles in this thread we might perhaps deduct that there is money in a good micro stepping board, that takes position or speed input every msec or so; for the stepper people. Yes, and the problem is that for serious stepper machines it is ok to add another piece of hardware, but for total diy hobby machine, which is built from whatever there is in the corner of the room, adding such a piece of hardware could be too much of an additional cost, which could lead to some users switching to other cnc controllers that can handle software step generation on existing PC hardware. OTOH I guess that in situation, when there are no other paths to take, taking this path (switching to rt_preempt with higher latencies) would provide some progress instead of having no progress at all. -- Viesturs If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- 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
velocity at 20msec intervals with a wel tuned analog drive (torque loop inside a speed loop) to do a real proper job you would adapt the torque (current!) loop to the inductance of the motor, and the P and the I of the velocity loop to the machine at hand. There was some autotune magic in the position loop in the computer that I have never seen again, but boy did it work well on a properly adjusted mechanical system. and yes I am aware of that. j. On Fri, May 18, 2012 at 12:15 PM, andy pugh bodge...@gmail.com wrote: On 18 May 2012 09:05, Jan de Kruyf jan.de.kr...@gmail.com wrote: when I started working in the CNC field we had 20msec loops and they worked(cutting steel) from pure fanciness we would upgrade to 10msec Was that a 20mS torque loop, or a 20mS velocity command loop? I would imagine what you are describing there was a system with a servo drive with a bandwidth of several kHz (probably analogue) being given velocity commands at 20mS intervals. It is not at all unusual in a LinuxCNC setup to be controlling the motor current and commutation in the software domain. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- 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
Lars, I have been following the RTPREEMPT scene for quite a while now. The people at SSAB (Proview) run their plants on it, so they have a vested interest and they are very clued up on it (their software is much more polished than LCNC by the way, mainly because they get paid to keep it that way off course) In any case, They found that in their tests a looptime of 1 msec is no problem. I take it that this is with a purposely selected motherboard / cpu. This is very good off course. The lowest figure I have heard in the CNC world is 500Usec. But that I would consider nonsense for the market LCNC is operating in. 5 millisecs servo looptime is ample in almost all cases. My own work on the subject sugests that all this is only possible with a well tuned computer. If the tuning is not perfect you might see some unexplained latencies happening at odd times like the middle of the night. this would make PREEMPT_RT useless for steppers, even if we do find a board with low enough latencies. (And they exist already, there is no doubt about that) So this is how I come to the conclusion that there is a lot of merit in keeping the micro-kernel / interrupt pipe with linux on top alive. It will be a right royal fest of failing installations when all of a sudden LCNC would change to PREEMPT_RT only, nobody wants that. At the same time for industrial installations with Sercos or Profibus or Ethercat servo loops PREEMPT_RT will ease the development cycle since a lot of the drivers that are around already will intergrate easier. cheers, j. On Thu, May 17, 2012 at 12:25 AM, Lars Segerlund lars.segerl...@gmail.comwrote: 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.com wrote: 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
Re: [Emc-developers] LinuxCNC, RTAI, and Ubuntu long term support releases
Andy Until we do proper tests: see the OSADL numbers for the various board / cpu setups And this is what I get from the LCNC Integrator book (and agree with): - So, what do the results mean? If your Max Jitter number is less than about 15-20 microseconds (15000-2 nanoseconds), the computer should give very nice results with software stepping. If the max latency is more like 30-50 microseconds, you can still get good results, but your maximum step rate might be a little disappointing, especially if you use microstepping or have very fine pitch leadscrews. 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 EMC, regardless of whether you use software stepping or not. - With a very good setup that is tuned to perfection, for steppers you will be just on the limit with PREEMPT_RT. The 1 msec answer was very much off the cuff, and quite a while back already, and for PLC / SCADA work, which is much less demanding at least at SSAB Oxelesund. So the boards will be better today, but also our demands are higher, for steppers at least. j. On Thu, May 17, 2012 at 1:31 PM, andy pugh bodge...@gmail.com wrote: On 17 May 2012 08:30, Jan de Kruyf jan.de.kr...@gmail.com wrote: In any case, They found that in their tests a looptime of 1 msec is no problem. I take it that this is with a purposely selected motherboard / cpu. 1mS loop is typical for a LinuxCNC servo / external hardware stepper system. However, the question is what the jitter is on that 1mS loop time. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- 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
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
Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port
Goody goody, see what a promise of beer at the hottest of the day can do. Enneh. . . . ., this is nonsense: we drink beer, and *everything* gets slow. In Africa we certainly talk much faster, and LOUDER after a good refreshment! (And we talk very well as it is, you know that. In fact I wonder wether we do anything else) Now for the scary stuff: there IS a PROBLEM with ulibc and PREEMPT_RT. Even more scary: I forgot where I read it! but I am quite positive about it. I will try to re-read all my stuff and see where it is. The stack problem is well known in literature, but normally the other way round: You run out of memory space assigning too many and too big. So John since you are soo good with yr toolbelt: rip out the dynamic stack measuring tool and measure, than double the size. Or maybe how about tripling the old size (since it worked a while back still) And lastly I think that the whole business of error reporting by the program needs careful consideration. the problem came about when Epler broke out the error reporting to the operator and through a fifo to the user interface so he/we can internationalize it. Which is good off course. So here is a thought: Why is not all error reporting done that way! Some errors are then just marked system error xx which would almost automatically cause a bug report to be filed. Last question to you experts: what latencies are you measuring? cheers, j. On Fri, May 4, 2012 at 11:29 PM, Charles Steinkuehler char...@steinkuehler.net wrote: On 5/4/2012 4:07 PM, John Morris wrote: Hi list, I'm simultaneously happy and embarrassed to present a possible fix, which I have tested about 3 times only. Verified it works here THANKS!!! I also don't really care much about the new huge stack-size. I might at some point, but right now I'm running on systems with 4-12G of RAM, most of which is just sitting around idle. :) If it is decided to switch out libc, I may be able to help a bit. One of the other projects I worked on was (at the time) a floppy-disk based linux router (LRP or Linux Router Project, which later became LEAF): http://leaf.sourceforge.net/ The LEAF project is now using uClibc for space reasons, and is beginning to port the system to arm cores (IIRC someone here was making noise about running on a Beagle Board). -- Charles Steinkuehler char...@steinkuehler.net -- 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, and dietlibc
fom here: https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application -- A real-time system *cannot* be real-time if there is no solution for priority inversion https://rt.wiki.kernel.org/index.php/Priority_inversion, this will cause undesired latencies and even deadlocks. (see [2]http://en.wikipedia.org/wiki/Priority_inversion) On Linux luckily there is a solution for it in user-land since kernel version 2.6.18 together with Glibc 2.5 (PTHREAD_PRIO_INHERIT). So, if user-land real-time is important, I highly encourage you to use a recent kernel and Glibc-library. Other C-libraries like uClibc do not support PI-futexes at this moment, and are therefore less suitable for realtime! -- So I did find it. And I switched to this thread. j. On Sat, May 5, 2012 at 5:19 AM, Charles Steinkuehler char...@steinkuehler.net wrote: On 5/4/2012 10:08 PM, John Morris wrote: I suppose that 2x-4x the original setting might possibly be enough, probably don't need 256x. I'll wait to see if the list suggests any heuristics for picking a good number. The two main approaches I've seen used are to either rigorously prove the maximum stack size by analyzing the code (complex and generally not worth the hassle unless lives are at stake), or by filling the stack region with known values, running the code, seeing how much stack _actually_ got used, and adding a fudge factor. There are many other ways to tweak stack size, but since I doubt there is a strong need to minimize memory usage, adding a fudge factor (even 2x or 4x or more expected usage) seems reasonable. -- Charles Steinkuehler char...@steinkuehler.net -- 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, and dietlibc
This is on embedded, but I have seen the same note about STDIO and prinf also for realtime on big platforms (somewhere, as usual): http://ez.analog.com/docs/DOC-1988 so yes maybe it is time to carefully look in the messaging on the PREEMPT_RT port. j. On Sat, May 5, 2012 at 12:20 PM, Jan de Kruyf jan.de.kr...@gmail.comwrote: fom here: https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application -- A real-time system *cannot* be real-time if there is no solution for priority inversion https://rt.wiki.kernel.org/index.php/Priority_inversion, this will cause undesired latencies and even deadlocks. (see [2]http://en.wikipedia.org/wiki/Priority_inversion) On Linux luckily there is a solution for it in user-land since kernel version 2.6.18 together with Glibc 2.5 (PTHREAD_PRIO_INHERIT). So, if user-land real-time is important, I highly encourage you to use a recent kernel and Glibc-library. Other C-libraries like uClibc do not support PI-futexes at this moment, and are therefore less suitable for realtime! -- So I did find it. And I switched to this thread. j. On Sat, May 5, 2012 at 5:19 AM, Charles Steinkuehler char...@steinkuehler.net wrote: On 5/4/2012 10:08 PM, John Morris wrote: I suppose that 2x-4x the original setting might possibly be enough, probably don't need 256x. I'll wait to see if the list suggests any heuristics for picking a good number. The two main approaches I've seen used are to either rigorously prove the maximum stack size by analyzing the code (complex and generally not worth the hassle unless lives are at stake), or by filling the stack region with known values, running the code, seeing how much stack _actually_ got used, and adding a fudge factor. There are many other ways to tweak stack size, but since I doubt there is a strong need to minimize memory usage, adding a fudge factor (even 2x or 4x or more expected usage) seems reasonable. -- Charles Steinkuehler char...@steinkuehler.net -- 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] EMC2 RT_PREEMPT patch: ioctl, printf an mutexes
John, some incoherent thinking --- which link was that: rt.wiki.kernel? dietlibc will be wrong until proven right, unfortunately. I scanned through the website but did not find any mention of it. What is the great urge anyway? Are you going to build on embedded? I understand we must just have no ioctl, printf and friends in the realtime parts to solve the problem you experienced. OK I got my thinking confused again, I thought Epler did it right and ze germans muddled it. But I just looked in funny.diff and saw that with that diff the muddle came. This is the right way: -/* call the normal library vnsprintf() */ -vsnprintf(buffer, BUFFERLEN, fmt, args); -rtapi_msg_handler(RTAPI_MSG_ALL, buffer); and this was made of it: +rtapi_msg_handler(RTAPI_MSG_ALL, fmt, args); and the messagehandler is then a printf friend that causes sheit. The trolls were over it again. that is why the stdout/stderr fix worked, there should have been no need for that. OK so 1. the message handling must be fixed. Please make a specification proposal, duly taking into consideration the fifo construction Epler introduced for operator errors. And taking into account that we URGENTLY need to LOG all errors with time of occurence. So the human interface might have a button to recall the log. 2. The MUTEX construction needs to be checked. Michael Abel believes they should do the right thing automatically, but I have reason to believe that I am not sure at all. I spend the aftenoon finding the right 'pthread.h', I hope: http://linux.die.net/include/pthread.h The way my modern brain reads this ancient code is that it is left to the user to ask for priority inherance. (this is also the prob with dietglibc, we do not know if they even provide that feature) 3. The Epler fifo, I would think, needs mutexes here and there, cause there will be more threads capable of spitting out error messages simultaneously I would say. 4. Please read the osadl.org wite-up on tuning your system/kernel. there are some useful hints there about processor speed and sleepstates that you need to take into consideration. I got excellent latencies running the osadl test, until I looked the next morning: DISGUSTING. The thing must have dozed of and had a rude awakening that took a bit more time than usual. So now I will continue to set up my system and your patches, and otherwise consolidate: collect my thoughts and put them into some order and all that. And tomorrow I will go and sing in the choir. And not about computers or beer for that matter ;) Hey it will be so beautiful! cheers j. On Sat, May 5, 2012 at 7:31 PM, John Morris j...@zultron.com wrote: Hi Jan, In Africa we certainly talk much faster, and LOUDER after a good refreshment! (And we talk very well as it is, you know that. In fact I wonder wether we do anything else) Our Texas drawls prevent us from talking faster, but we do talk loudly and a lot after a few long-necks. Now for the scary stuff: there IS a PROBLEM with ulibc and PREEMPT_RT. Yep, nice link. Wonder about dietlibc? That's a completely unrelated code base according to something I read. The stack problem is well known in literature, but normally the other way round: You run out of memory space assigning too many and too big. So John since you are soo good with yr toolbelt: rip out the dynamic stack measuring tool and measure, than double the size. Or maybe how about tripling the old size (since it worked a while back still) Well, after all that work, I still don't have a good handle on understanding where things are in the stack and how full it is. You're right that it probably needn't be too much bigger. As you point out, the change that put things over the edge was switching from vsnprintf; fputs; to vfprintf;. In the old version, the formatting routine and printing routine were serialized, so they didn't occupy the stack simultaneously. In the new version, vfprintf takes care of both functions, and worse, when it sees stderr is unbuffered, it creates a buffer and essentially calls itself again. I'd bet 4x/64k would do it. And lastly I think that the whole business of error reporting by the program needs careful consideration. the problem came about when Epler broke out the error reporting to the operator and through a fifo to the user interface so he/we can internationalize it. Which is good off course. So here is a thought: Why is not all error reporting done that way! Some errors are then just marked system error xx which would almost automatically cause a bug report to be filed. Yes, this sounds like the right way to do it. Also, the Buesch patches have some plain ol' 'printf' statements in there, not indented properly, not running through the rtapi msg facility. I bet those were debugging statements that weren't removed. Last question to you experts: what latencies are you measuring? 50uS on my x86_64 workstation with no
Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port
Right, back from away.
John:
You answered my question quite adequately. And I referred to
PREEMPT_RT when writing RT. Jus t my fingers are so thick.
All:
I seem to miss the stacktrace leading up to the crash in the
reports. So, sadly, there is little help I can offer since you guys are
all so wrapped up in the idea that there is perhaps an underlying problem
in the kernel or in glibc. In my debuggerless experience, however, the
fault is in 99% of all cases in the newly written code (a.k. the diff I
produced) So is it possible to get a few stacktraces please? And from what
you guys describe I still think there is a process lock problem with
variables that dont seem to update! That we will only see when we analise
the code. The debugger is only in the way, trying to find those (at least
in my experience).
So now since it is friday afternoon lets have a small intermediate beer, to
get the spirits up again ;) Maybe if we lubricate the electrons a bit
things will become clearer.
Cheers
j.
On Fri, May 4, 2012 at 3:42 PM, Charles Steinkuehler
char...@steinkuehler.net wrote:
On 5/4/2012 1:33 AM, John Morris wrote:
I'm not clear what the 'watch' you're setting on *stderr is for. The
'stderr' pointer points to the first word of stderr's _IO_FILE struct,
'_flags':
(gdb) p stderr
$75 = (struct _IO_FILE *) 0x39fc5b2160
(gdb) p *stderr
$76 = {_flags = -72537977, _IO_read_ptr = 0x39fc5b21e3 , [blah blah]}
In your gdb listing, the watch point detects the value of stderr-_flags
changing twice; should that not happen normally?
I honestly have no idea about the writes to the stderr structs and what
would be 'normal'. This could easily be a red herring.
The segfault occurs in vfprintf.c:1278 on my system:
f = lead_str_end = __find_specmb ((const UCHAR_T *) format);
(At this point, it hasn't tried to write to stderr yet; it's still
computing the output.)
Hitting the electric fence seems more likely to be a real problem, but
I'm not familiar enough with the glibc library and C to crawl through
the code or determine if this is a root cause or just another
down-stream side-effect of the initial issue (most likely memory
corruption).
--
Charles Steinkuehler
char...@steinkuehler.net
--
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
Thanks, thanks and thanks again, This is what happens when you sleep late every day: The sun starts to get slow also! In Africa we get up early, so we get to drink the beer early! As the sun gets hot, that is the right time. Now about the beer: I am much more clever in drinking someone else's, so thanks for the traces. I am about to dig into them to prove my own theory wrong. So in other words I trust you guys good work, it would take me quite some time to set it all up. Time much better spend by reading and analyzing code. John: Are we still convinced that the system ran before you gitdiffed the offending commit out? j. On Fri, May 4, 2012 at 7:33 PM, John Morris j...@zultron.com wrote: Hi Charles, Here's a stack trace for two different cases: * Running rtapi_app using electric fence * Running hal_cmd and following the child on fork (the crash happens in rtapi_app, launched by hal_cmd) Of possible interest: If you run rtapi_app on it's own without electric fence, it doesn't crash. I've done both these scenarios. halcmd and following the child, the crash happened in rtapi_app; that's why I've been focusing on it so intently. Without electric fence, running rtapi_app on its own, I could get it to segfault only sometimes. It would segfault more if running in 'record' mode, probably because it missed more deadlines and spewed more output, tickling the bug more. Another trick is to run rtapi_app in gdb, then from a shell, call halrun -U. If rtapi_app hasn't crashed before this point, it has always segfaulted here. These crashes have always occurred in malloc() for me, whereas the early crash with rtapi_app+EF occurs in vfprintf(). 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
Re: [Emc-developers] 'queued MDI execution does not work in master'
Michael, dont get too excited, we do understand you are busy, and this can of worms causes issues, now that you have taken off the lid. As it should, because any oldish project has issues like this. And they do need to get resolved!! there is no doubt about that. At the same time I personally *highly value* your time and contibution that you freely give to the project. So that out of the way: This is my considered input to the issues I have seen coming past my eye. (And I probably missed some, but never mind) 1. The matter of old Gene feeling ignored: This is at least in part caused by silly SourceForge that has ideas. I also failed to log a bug report when I tried just now Partly my set up, partly Source Forge, partly wrong info on the wiki page. (*Please drop me a note whoever is maintaining this part of the business*) If I myself were pushed in a corner like he is at the moment, I would probably have exploded a bit louder, with your permission. 2. The program vs MDI issue: operators love to quickly do something and not write a big program, so that is why there is MDI. It is a human interface concept, nothing more. But a very important one. In general it is used slowly and not concurrent with a program, except by code-breaking specialists like me and you. But then again we dont stand behind a real machine all that often. From architectural point of view it is just another file that needs executing, you are right about that. 3. I understand that the present situation is not at all SAFE from a conceptual point of view. But in practice people have not noticed it. It is not worse than taking all safety switches off a machine, as is often done when they get in the way of expediency. (Yes I know that is shocking!) 4. So I would vote to revert to a release before you disabled the faulty code, and publish a formal warning from the directors of the project on the users list. 5. At the same time someone(two, three) might volunteer to be the active maintainer(s) of the specs of the project, and also be the safety officer(s), since we deal with real, powerful and dangerous machines here. If you have ever seen pieces of casting fly though the workshop because of a faulty control you will know what I mean!. And safety laws are definitely not getting any easier. 6. MOST IMPORTANT. Would the board please pay attention to the state of the project. You people did a wonderful job getting all this started and bringing it where it is today, but at the same time life went by, smoothly and without a ripple; we all lived off the glorious past. But now that there is some real and very needed development going on, to get LCNC up to todays standards, the stress cracks start to show. So lets get focussed and not into each others hair! Regards, Jan de Kruyf. On Thu, May 3, 2012 at 9:14 PM, Michael Haberler mai...@mah.priv.at wrote: Am 03.05.2012 um 17:35 schrieb Chris Radek: On Thu, May 03, 2012 at 01:35:13PM +0200, Michael Haberler wrote: note I proposed handling proper queuing of MDI commands by modifying Axis to have a queue of MDI commands, and feed them to task one by one within the interpreter state constraints. I have said this before but maybe not plainly enough - No I havent heard it, and I didnt find it in the linuxcnc requirements/API spec document either. Where is google search with useful results when we need it I think this isn't something to fix in AXIS because if we want MDI queueing to work (and I hope we do, somehow) it should work for all UIs. Considering that this may be a valid argument, under which light it behooves to specify: - the interpreter input handling needs a queue, which will reside in task for now and have some configurable maximum size - that queue shall be flushed on any interpreter abort - task needs a way to report queue state, (size, and full condition) - emcmodule needs to enabled to report said state to a caller - task will drive dequeuing and feeding of interp commands from that list - the UI's shall observe the 'input queue full' status to disable any input facility The above shall be added to the core linuxcnc requirements/API spec, in other words: fed into the #linuxcnc-dev IRC channel. While mhaberler is away, said IRC channel is tasked to deliberate and decide the following question: - does it make any sense to differentiate input handling mechanisms wrt 'auto mode' and 'MDI mode' AT ALL, OR is it ok to have the interp input queue carry any command of the types 'open ngc file', 'execute ngc file' and 'execute a string (aka MDI mode)'? mhaberler can think of no valid reason for two interfaces right now, as he has never understood the conceptual difference between auto mode and MDI mode in the first place except for 'string' versus 'file', which obviously at some distant past was meant to mean 'single block' versus 'several blocks in a file' - Michael style reference: http://static.mah.priv.at/public
Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port
I have also been looking at that part of the code. But I am sorry to say I am still to dumb to come with definite You see I told you so. I have a very valid (I hope) question though: RTAI knows to run real time sections in kernel space, later on they also got RT in user space to go. So where does the original RT section of LCNC run -- in userspace or in kernel space? If the section you look at is still in kernelspace vprintf will definitely break and also gdb will have issues I would say. . . . j. On Thu, May 3, 2012 at 8:44 PM, Charles Steinkuehler char...@steinkuehler.net wrote: On 5/3/2012 12:25 AM, John Morris wrote: Yep! I discovered the 'record' feature in gdb. Start up gdb on rtapi_app, then run the following: start load threads name1=fast period1=5 record c I haven't been able to get the record feature of gdb to do much of anything useful, because it keeps stopping on an unsupported instruction (0xc5). I don't know if this is related to the crashing or not. :-/ I was, however, able to turn up what might be a useful clue using electric fence. I used the .gdbinit example from the debian package, which sets two environment variables prior to running rtapi_app: set environment EF_PROTECT_BELOW 1 set environment LD_PRELOAD /usr/lib/libefence.so.0.0 When run this way, the application *ALWAYS* segfaults on line 131 of linux_rtapi.c: the call to rtapi_print_msg call in the rtapi_reset_pagefault_count function (although it is the vfprintf in default_rtapi_msg_handler that is actually causing the segfault). I still don't know _why_ this is happening, but it feels like at least the root issue may be getting closer to the surface. -- Charles Steinkuehler char...@steinkuehler.net -- 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
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. 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? 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. 3. Did you, at the time, check that all RT memory was locked in place? since there are some funny paging faults at 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. 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. Thanks again, j. 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 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. -- Live Security Virtual Conference Exclusive live event will cover
Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port (Was: Re: One-liner patch)
Hard-working priests of the god IBM, Here is my news: I had a very hard look at the diff between the 2 commits that John so diligently found by bisecting the non-working one has basically only one addition: Jeff Eppler did this (the commit message): defer formatting of realtime motion messages to userspace this enables userspace to provide translations of messages printed by motion, and in the future will allow floating-point values to be included in these messages. and in the process he made a shared memory area to catch the messages from realtime, so you can read them from the user interface. So I have the itch that we are not going to find the issue by gdb etc. but only by getting learned on the issue of 1. rtai interfaces 2. rt_preempt interfaces and how to go from the one to the other. I can see where John fixed the original patch to accommodate the changes by Jeff, but I have not been able to identify the trouble spot / area / thinking. Mainly because my dull brain. So unless you guys have a good reason to convince me otherwise I will continue on this road of figuring out how the changing over process aught to work. I have added the diff for the interested parties. j. On Sat, Apr 28, 2012 at 10:45 PM, Charles Steinkuehler char...@steinkuehler.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/28/2012 1:53 PM, John Morris wrote: snip From the debugging side, neither of my tacks have gotten very far. I've never done anything terribly difficult with C, gdb or assembly before, so I've been reading docs at every step. I'm in the same boat, I typically don't code on linux and dubug with gdb. Normally, I'm writing VHDL (for Altera FPGAs) and debugging via a few blinking LEDs (and by staring at the code for a long time! :). The two tacks: - Use the debugger to understand why test_and_set_bit returns 0. I don't know what the 'tsbbl' instruction is, and haven't figured out how to examine memory yet. - Find some way to log function calls and argument values as the execution progresses. I hope to (dis)confirm that the pre-problem and problem versions are taking the same path up to the point where the problem version starts spinning. Stepping through with gdb is, of course, too painful. I read that valgrind might be able to help with this, but it doesn't seem to be a common usage. Charles, have you heard of using valgrind for that purpose? I wasn't able to get anywhere easily with gdb, so I switched to the GUI front-end program nemiver. It's been pretty easy to use so-far, but I'm sure I'm missing out on some of what gdb is capable of. It is reasonably easy to monitor memory and the call stack (at least most of the time...I've had times where the call stack appears empty even though there should be something there). As for valgrind, the on-line manual (not the man page) indicates a few tests geared at multi-threaded code to find potential race conditions and deadlocks. I haven't tried running any of these yet, as it appears to assume you are using the available library mutex functions while the linuxcnc code in question is running with custom locking functions (which you can 'teach' valgrind about, but that is beyond my current skill level). Also, I doubt there is a serious problem with the locking code, as it is the same code that is used successfully without the linux-rtapi patch. Instead, it seems like there is some form of memory corruption happening, which is why I pulled out valgrind to begin with (or at least that's what googling crash in malloc leads me to believe). I suspect the change in how message strings are being handled has caused some portion of memory to get corrupted or overwritten, but I still don't understand the code well enough to start figuring out exactly what's going wrong. I think I need to step back and start looking at the program flow instead of the diffs between versions, and see when anything related to messaging might be running and causing a problem. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+cVtAACgkQLywbqEHdNFxhbwCgpVT0jUjE0Ze5wum2Tr88gMI/ 6KYAn04mouf8z4tiJtwTWdRLdp8s89js =EJZ0 -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
Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port (Was: Re: One-liner patch)
thanks, Ken
I am not such a C light to spot these things instantly.
there are probably also some mutex problems in the combination of this with
the rt-preempt patch.
(by the way this is the UNPATCHED patch, if you see what I mean)
And now it is bedtime for little children.
Cheers all of you,
j.
On Sat, Apr 28, 2012 at 11:59 PM, Kenneth Lerman
kenneth.ler...@se-ltd.comwrote:
I started looking at funnydiff.txt and found something funny with it:
The man page for stdarg (man stdarg) says (in part):
=
va_start
The va_start() macro initializes ap for subsequent use by
va_arg() and
va_end(), and must be called first.
=
The following code uses the va_arg macro without first calling
va_start(). I don't know if that is a problem, but it is not proper
usage. I'm reasonably certain that it will fail on some architectures
with some compilers.
Regards,
Ken
===
+
+int vstashf(struct dbuf_iter *o, const char *fmt, va_list ap) {
+int modifier_l;
+
+dbuf_put_string(o, fmt);
+
+while((fmt = strchr(fmt, '%'))) {
+int code = get_code(fmt, modifier_l);
+
+switch(code) {
+case '%':
+break;
+case 'c': case 'd': case 'i': case 'x': case 'u': case 'X':
+if(modifier_l) {
+case 'p':
+dbuf_put_long(o, va_arg(ap, long));
+} else {
+dbuf_put_int(o, va_arg(ap, int));
+}
==
On 4/28/2012 5:34 PM, Jan de Kruyf wrote:
Hard-working priests of the god IBM,
Here is my news:
I had a very hard look at the diff between the 2 commits that John so
diligently found by bisecting
the non-working one has basically only one addition:
Jeff Eppler did this (the commit message):
defer formatting of realtime motion messages to userspace
this enables userspace to provide translations of messages printed
by
motion, and in the future will allow floating-point values to be
included in these messages.
and in the process he made a shared memory area to catch the messages
from
realtime, so you can read them from the user interface.
So I have the itch that we are not going to find the issue by gdb etc.
but
only by getting learned on the issue of
1. rtai interfaces
2. rt_preempt interfaces
and how to go from the one to the other.
I can see where John fixed the original patch to accommodate the changes
by
Jeff, but I have not been able to identify the trouble spot / area /
thinking. Mainly because my dull brain.
So unless you guys have a good reason to convince me otherwise I will
continue on this road of figuring out how the changing over process aught
to work.
I have added the diff for the interested parties.
j.
On Sat, Apr 28, 2012 at 10:45 PM, Charles Steinkuehler
char...@steinkuehler.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/28/2012 1:53 PM, John Morris wrote:
snip
From the debugging side, neither of my tacks have gotten very far.
I've never done anything terribly difficult with C, gdb or
assembly before, so I've been reading docs at every step.
I'm in the same boat, I typically don't code on linux and dubug with
gdb. Normally, I'm writing VHDL (for Altera FPGAs) and debugging via
a few blinking LEDs (and by staring at the code for a long time! :).
The two tacks:
- Use the debugger to understand why test_and_set_bit returns 0. I
don't know what the 'tsbbl' instruction is, and haven't figured
out how to examine memory yet.
- Find some way to log function calls and argument values as the
execution progresses. I hope to (dis)confirm that the pre-problem
and problem versions are taking the same path up to the point
where the problem version starts spinning. Stepping through with
gdb is, of course, too painful. I read that valgrind might be
able to help with this, but it doesn't seem to be a common usage.
Charles, have you heard of using valgrind for that purpose?
I wasn't able to get anywhere easily with gdb, so I switched to the
GUI front-end program nemiver. It's been pretty easy to use so-far,
but I'm sure I'm missing out on some of what gdb is capable of. It is
reasonably easy to monitor memory and the call stack (at least most of
the time...I've had times where the call stack appears empty even
though there should be something there).
As for valgrind, the on-line manual (not the man page) indicates a few
tests geared at multi-threaded code to find potential race conditions
and deadlocks. I haven't tried running any of these yet, as it
appears to assume you are using the available library mutex functions
while the linuxcnc code in question is running with custom locking
functions (which you can 'teach' valgrind about, but that is beyond my
Re: [Emc-developers] jog-while-paused in auto: video
Either by pressing button (Jan would like that) Bitter experience with the human race, and more particularly the subspecies that habitually operates machines: The are very good at confusing computers. And at the same time a properly implemented switch needs the supervisor to attend the correction of the overtravel, so there are 4 eyes watching. . . . j. On Fri, Apr 27, 2012 at 3:56 PM, Viesturs Lācis viesturs.la...@gmail.comwrote: 2012/4/27 EBo e...@sandien.com: but I can see joint mode being useful for setting up and calibrating. Just like You mentioned - for setting up, calibration. I would add also troubleshooting and debugging. IMHO all of these things are outside normal everyday use realm. Actually, this makes sense. How about this for safety then -- disable joint mode in the normal interface and have a separate interface/program for setup that can do joint mode? I think that this would over-complicate the implementation. I think that all is needed is a special INI file setting and, if that is true, then make GUI or whatever place switch to teleop mode as soon as all joints are homed. There are HAL pins for that (halui.joint.n.is-homed), I tried to do this in HAL, but did not get it right. The idea was to take these is-homed pins and feed them through and gate (I had 5 joints in that machine, so I created and5 module). If and gate output is linked directly to halui.mode.teleop, then it will request that all the time. Also when there is attempt to execute g-code file. Basically it is needed to do this only once after the machine is homed, so I tried to do this on rising edges of is-homed pins, but this approach failed as I could not predict, how long time would be between first and last joint to get homed. So then I created homing sequence and added this only to last joint in sequence, but it still was not good. I could not figure out, what was wrong, so in the end I gave up on that idea. Is there a HAL module that would work as set-reset trigger? Rising edge on set input would set output true until there is rising edge on reset pin. I tried to find something like that, then I tried to create something like that, but also failed... I think that this could work - if the output of such trigger is passed through oneshot component to create a short signal (to halui.mode.teleop) on rising edge, then it would not repeat such a request until user specifically created a signal on reset pin. Either by pressing button (Jan would like that) or by some linking it to some M65 command to be activated in MDI or whatever. Viesturs -- 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, sounds good. The work will deminish with more insight. I thought I was going to set up a system this weekend, but at the moment I lean to rather digging the code and the diffs. Since I do not think that me repeating your and Charles' findings will help, unless you think different. As a besides: I have a theoretical understanding of the issues, but little practical exposure. At the same time I am a professional faultfinder (my wife agrees with that statement ;), also plenty experience doing it by remote control. So that is why I took the liberty to impose myself. It is of course not to sit here and feel good about commenting on yr work. Only if you experience it as helpful. You think you could blog your doings on zultron.com, then I will volonteer to go through it with a fine comb to see what might surface. And believe it or not: THE SUN SHINES TODAY! cheers j. On Thu, Apr 26, 2012 at 9:49 AM, John Morris j...@zultron.com 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. 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
[Emc-developers] wierd list behaviour
Sorry people, I sent the last message twice, but sourceforge told me my ip was blocked and the message was refused: because of abuse yet the messages go through . . . . must be that I put my rabbit foot in the wrong pocket this morning. j. -- 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] jog-while-paused in auto: video
yes, but hexapods and robots are a problem j. On Thu, Apr 26, 2012 at 3:42 PM, Dave e...@dc9.tzo.com wrote: If you were running a gantry, I would think that it would still be pretty obvious which way you would need to move even in coordinated mode with non trivial kinematics. Dave On 4/26/2012 9:08 AM, Jan de Kruyf wrote: Makes sense to me. Except inthe case of an emergency, how do you want to jog away from a limit switch Viesturs? It is ultimately a joint that is out of bounds then. j. On Thu, Apr 26, 2012 at 2:57 PM, Viesturs Lācisviesturs.la...@gmail.com wrote: 2012/4/26 Michael Haberlermai...@mah.priv.at: so what's the idea? Do you want to have the option to jog in coordinated mode in manual? Ideally - INI file option for automatic switching to teleop mode as soon as all joints are homed. So that user does not interact with joint mode - they tend to forget about switching to world mode (me too) and that poses a risk of breaking machine. The thing is that _all_ of the LinuxCNC implementations I have done is non-trivial kinematics. Most of them - gantry machines. There was one implementation by Frank Tkalcevic, this is the only reference I can find - Andy's reply. The whole thread seems disappeared (but I think I do have downloaded his patch somewhere at home): http://www.mail-archive.com/emc-users@lists.sourceforge.net/msg30409.html Unfortunately Frank stated that this way works correctly ~50% cases. Not very reliable. Viesturs -- 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 (Was: Re: One-liner patch)
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: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ZfDYACgkQLywbqEHdNFwX9gCeJXuvLLocqO5aBiu0bDjNiRO6 HsIAoPzNwVxCYNyVlGen+5HWXXr9cUzu =Nsof -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)
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 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
Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port (Was: Re: One-liner patch)
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 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
Re: [Emc-developers] jog-while-paused in auto: video
Mmm, yes you might be very right. I postulated a theoretical case there, since I have no real experience to speak of on those machines. OK, so what about the old trusted way of supplying a springloaded key-switch in the electrical cabinet that allows joint mode. But at the same time travel in the wrong way is blocked!! so the operator cannot make the problem worse. j. On Thu, Apr 26, 2012 at 8:46 PM, Viesturs Lācis viesturs.la...@gmail.comwrote: 2012/4/26 Jan de Kruyf jan.de.kr...@gmail.com: yes, but hexapods and robots are a problem There is no way to jog single joint on hexapod without causing damage to the construction of machine! Jogging in joint mode is dangerous with machines with parallel kinematics, including gantries. It is awkward for serial kinematics machines (puma robots etc), but not that dangerous, although still very risky for unsuspecting operator. One of my clients is company with hundreds of employees and they usually are rotating their tasks, so AFAIK the number of people that are working with my machine is at least 10. There is no way I can ask everyone of them to instruct, how to work with LinuxCNC. And I do not have illusions that they would read written instructions. So the only option - KISS, remove any chance to mess something up. And jogging in joint mode for non-trivial kinematics is one of them. Regarding gantries - if only one side has hit the limit switch, I see 2 general cases: 1) gantry is still straight, limit switches on both sides are not at the same coordinates for each joint or something else. Jogging each joint separately _not_ necessary, as it will rack the gantry and actually make things worse. 2) gantry is not straight, one joint has traveled more than the other. Jogging each joint separately _is_ necessary for both moving off the limit switch and (more or less) line up gantry. There is some problem with machine to be solved for gantry joints having different travel distances. The second case needs jogging in joint mode as there is a problem with the machine, so it lies outside normal operation of machine realm. That is why I think INI option to enable/disable joint mode availability to user would be great. In second case operator could close LinuxCNC, set INI value to enable joint mode, start LinuxCNC, jog off the limit switch, home the machine (which would be needed anyway, since previously LinuxCNC's coordinate of that joint did not match the actual position, otherwise gantry would still be straight) and solve the cause. Viesturs -- 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)
Hey just go and sell it to that investor, and just make double sure to please your family. So you will be all fresh when you come back. I will put in some more code reading and see what gives. (and please my wife off course!) j. On Thu, Apr 26, 2012 at 9:38 PM, John Morris j...@zultron.com wrote: Hi Andy, git bisect will probably allow you to narrow things down a lot more quickly than you imagine. I was so anxious to get a head start on your suggestion that I began yesterday! The commit where the problem begins is 8868436313c34eaf60a14f5c930f0f2035b9ee48. After saying this was not a problem I introduced, I'm not so sure anymore. The biggest hunk of the forward-ported patches that originated with me changes rtapi/linux_common.h to compile with this commit, where function prototypes for realtime motion messaging change. It's broken out into linux_common.h.patch in the tarball linked below. Here's a recipe to demonstrate the problem's non-existence in the previous commit and the problem's existence in the following commit. It's not well-tested, and it WILL FAIL if you just try to source it from a shell. Otherwise it should be easy to follow and reproduce. Unpack this into /tmp, probably, and look at the README: http://www.zultron.com/static/2012/04/linuxcnc-bitmuster-bisect.tgz I won't have much more time to work on this until next week, since I have both family and an investor in town over the weekend. I'll be excited to monitor any progress, though! My greatest gratitude for everyone's help and encouragement. The sun is indeed shining today. ;) 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
Re: [Emc-developers] Q: how to jog-while-'paused' in coord mode
practical consideration: When milling or turning, if I pause to do 'something' I would want to be able to retract the tool in the direction of the tool axis so no damage is done to the tool or the workpiece. Normally on a 3 axis machine joint mode = coordinatemode as far as jogging goes, so there is no difference. But on a hexapod and perhaps some other configs I would most definitely like to jog in coord mode, Z-axis first in general. Hope this helps the thinking. j. On Wed, Apr 25, 2012 at 8:36 AM, Michael Haberler mai...@mah.priv.atwrote: Unsure how to adress this: Jogging assumes free mode. during the 'jog while paused' thing I posted yesterday motion is in coordinated mode, so jogging normally wouldnt work. to make it work, I see the following options: 1. just jog in cartesian space (any obvious reason why this shouldnt be possible, except for confusion?) 2. use inverse kins to translate cartesian pos into joint space, apply jog increment, use forward kins to produce jog end position in cartesian, add move 3. Make it work for trivkins only where this isnt an issue to start with 2) assumes forward kins is available which might not be the case. 3) a hack. What you'd suggest? coming to think of it - any idea why linuxcnc has no coord mode jog? I would think this is the natural mode of jogging for non-trivkins machines? - 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] pagefaults ...
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
Re: [Emc-developers] Q: how to jog-while-'paused' in coord mode
I have scratched myhead some more, this is my take on the user / operator side of things . . . . (And to me this is the bottom line, although it might not produce elegant code) Jogging in joint mode would only be used in practice to move off a physical limit condition. Like a hardware switch or where the travel limit of the joints is limited in software. For inspecting during machining and for setting up a job you definitely need to jog in coordinate mode. And even for measuring length of a cutter by 'touching off' you need coordinate mode. Unless someone has additional examples of practical use . . . . .? j. On Wed, Apr 25, 2012 at 2:30 PM, Michael Haberler mai...@mah.priv.atwrote: Am 25.04.2012 um 12:43 schrieb andy pugh: On 25 April 2012 07:36, Michael Haberler mai...@mah.priv.at wrote: 2) assumes forward kins is available which might not be the case. What are the other limitations of an inverse-only kins machine? I wish I fully understood; there's a bit of comment in src/emc/motion/control.c near do_forward_kins() Is it reasonable to say that such machines simply aren't allowed to jog in retract mode? well thats one option, but I think coord mode jog is straightforward to do so that could be a fallback I dont quite understand why this isnt in place anyway, it could have other uses during auto -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] pagefaults ...
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 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 -- 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)
Charles, John, 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? j. On Wed, Apr 25, 2012 at 10:41 AM, Charles Steinkuehler char...@steinkuehler.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/25/2012 3:17 AM, John Morris wrote: 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 I get the same results as with the previous set, still hanging in hal_init waiting for the hal_data-mutex. I've looked around a bit but am not yet familiar enough with the code to figure out what's wrong. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+XuLQACgkQLywbqEHdNFwUIwCgv2Rcwim/j/dsalp27mcWEN0x P+0An2YwKuDP2cwZeC7SLwM4PVX/uPpw =xaXp -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] pagefaults ...
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.comwrote: I should point out that I haven't tun RT on this specific machine before, and it can be machine related. 2012/4/25 Jan de Kruyf jan.de.kr...@gmail.com: 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 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 -- 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
Re: [Emc-developers] pagefaults ...
Ja, OK. Just trying to tie up the loose ends in MY brain. And see if there is somewhere a common denominator, so the debug cycle can be shortened. Let my try to set something up this weekend and see what I get on this jukebox. cheers, j. On Wed, Apr 25, 2012 at 9:20 PM, Charles Steinkuehler char...@steinkuehler.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/25/2012 1:51 PM, Jan de Kruyf wrote: I get that but we now have 2 debian installations giving crap and a fedora installation looking vaguely right. (scratch scratch. . . . .) If you're counting me as one of those two debian installs, please note that I have a 2.4.4 version from bitmuster running well on Debian Wheezy with the stock 3.2.0-rt kernel, although I have yet to hook it to any real hardware. It's getting the PREEMPT_RT patches forward-ported to apply and run on 2.5 that's causing me issues. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+YTmMACgkQLywbqEHdNFwLxgCeLCkwsyVsMVoGGf+6roTMCURF h40An2VJ0G83pKByIZKIOjJ5NVWLjdYz =1lCa -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
[Emc-developers] Real-Time Linux Wiki
For those interested here is the link: https://rt.wiki.kernel.org/index.html The FAQ and the RT PREEMPT HOWTO are quite pertinent. j. -- 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] JA3 / Gentrivkins
how many axes simultaneously Viesturs?
j.
On Mon, Apr 23, 2012 at 6:52 PM, Viesturs Lācis viesturs.la...@gmail.comwrote:
2012/4/23 andy pugh bodge...@gmail.com:
Whilst idly poking about in JA3 I noticed:
struct data {
22 hal_s32_t joints[EMCMOT_MAX_JOINTS];
...
34 for(i=0; i9; i++) {
35 switch(data-joints[i]) {
Which seems like it might cause trouble if EMCMOT_MAX_JOINTS was ever
to change to be other than 9.
(and I would have expected a much larger number to be eventually
possible in JA3)
Is kinematics module the only place, that limits max number of joints?
The thing is that I suspect that there are other places as well that
have hardcoded max number of joints to be less or equal to 9.
LinuxCNC still has only 9 axis words (I have been wishing for more - I
have a client, who might be interested in LinuxCNC, if it was capable
of handling production lines with up to 40 independently moved joints
(I have seen and climbed one of their beasts with 36 joints), but that
is whole different story), so 9 axes/more than 9 joints are not
trivial kinematics, which means that gentrivkins probably is not the
place to change that.
I do not see a problem for integrator of LinuxCNC on such a special
machine tool to get source code, change that number and rebuild
kinematics module, if that is the only place that limits it.
Viesturs
--
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] manuals: what has changed? viewing the difference of two versions of a HTML page
in the absence of a good change-log perhaps git-difftool? j. On Thu, Apr 5, 2012 at 9:28 AM, Michael Haberler mai...@mah.priv.at wrote: Fabian doxygen is all fine, but I am adressing a completely different problem: How do I find out what has changed recently? -m Am 05.04.2012 um 08:11 schrieb Saccilotto Fabian: Hi michael, having a diff to the previous html is not a bad idea. But from my point of view it doesn't pretend you from duplicating functionality. What about creating a good index over all your documentation in order to find the functionality you need? Or using a tool like doxygen (http://www.stack.nl/~dimitri/doxygen/) to create an overview over your source code? I created a documentation of emc2/src with doxygen on a linux Ubuntu 10.04 with doxygen and graphviz (took about 3 min). The package is about 80 MB big and I don't have any webspace or FTP where I can post it to you all. If anyone interested in this, how can I share it with you? Regards Fabian -Ursprüngliche Nachricht- Von: Michael Haberler [mailto:mai...@mah.priv.at] Gesendet: Donnerstag, 5. April 2012 00:49 An: EMC developers; Enhanced Machine Controller (EMC) Betreff: [Emc-developers] manuals: what has changed? viewing the difference of two versions of a HTML page I regularly see folks reinventing stuff which has been done, and implemented and documented, including myself ;). No wonder, because the manuals are big, and we have no change bars or such in place. Looking around I found this, and is very useful to quickly view the difference of two html pages - it highlights old text in red and new text in green: http://www.aaronsw.com/2002/diff/ Here is the diff from the G-code overview of between 2.5 and master: http://static.mah.priv.at/public/html/Overview-diff.html generated from the above links with inputs: http://www.linuxcnc.org/docs/2.5/html/gcode/overview.html http://www.linuxcnc.org/docs/devel/html/gcode/overview.html It's not flawless but I think it does a pretty good job for 66 lines of Python. I think that would be a great addition to have on http://www.linuxcnc.org/docs/*/html/ : for each html document, a link nearby 'difference to previous version' - Michael -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] manuals: what has changed? viewing the difference of two versions of a HTML page
Hey you clever Schweinchen, I took it you were on about the code. . . I am immersed at the moment in the European culture and all my family, it is hard at times. So I am jealous . . . Cheers j. On Thu, Apr 5, 2012 at 6:45 PM, Michael Haberler mai...@mah.priv.at wrote: Viesturs - Nothing is impossible to the determined coder! Here is your starting point to realize your dreams: http://static.mah.priv.at/public/walk.py and here is how output currently looks: http://static.mah.priv.at/www.linuxcnc.org/docs/devel/html/changes.html You wont fail to note the enormous room for improval in this !§$%§%! kludge, so prop up the editor and prove I'm a whimp ;) It's also a great opportunity to get sneak away from family ceremonies during the holidays. -m Am 05.04.2012 um 17:31 schrieb Viesturs Lācis: 2012/4/5 Dave e...@dc9.tzo.com: How do I find out what has changed recently? That is a problem. Would it be possible for user to specify, which is the reference version, the base, against which current docs are compared for changes? I guess that this basically reduces to: are the 2 sources compared for differences on fly, automatically, or does somebody specially have to prepare such a comparison with the tools mentioned before? Viesturs -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] adding araisrobo (aka artek) branch:
good! j. On Sun, Apr 1, 2012 at 10:48 AM, Michael Haberler mai...@mah.priv.atwrote: for the experimentally inclined, I've built the artek branch with the simulated spindle encoder thrown in see notes here: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ArtekBranch changes from here: http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/arais-mah -Michael Am 01.04.2012 um 08:12 schrieb Michael Haberler: Am 01.04.2012 um 06:54 schrieb Jon Elson: Yishin Li wrote: ... All you need is an encoder with index on the spindle. which might even be a simulated one to start with; Jeff came up with one and I merged it, also all the sim configs use this simulated encoder: http://git.mah.priv.at/gitweb/emc2-dev.git/commit/01448f442e1b4e45e5659dd0e4b9a38946b411a1 - Michael -- 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 -- 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] I am new here
Fabian, Am I right in saying then that this is going to be done in quite a few undergraduate semester projects and a few post graduate studies? By the way I am overwelmed by the size of the total effort, probably because I lived too long in the 3rd world. The question about testing contained some enlightened self interest.: For a real CNC today you will use SERCOSIII or equivalent drives. So I was wondering what your plans are about the hardware, since EMC2 / LCNC has a bit of a deficiency at the moment in that field. I would like to know wether you will build a real hardware setup and then how you are going to handle this deficiency. I think support could be drummed up in the community to do some work on that but we do not have uncles that present us with motors and drives. I think basically that is where the support will stop, so we would have to look to you for that. And the last question: Would your total effort be donated back into the community or will there be sections that will stay proprietary. This is now on the machine controller side. I understand that STEP generation will slowly percolate back into the CAD market. cheers, j. On Fri, Mar 30, 2012 at 8:48 AM, Saccilotto Fabian fabian.saccilo...@ntb.ch wrote: Dear all, who were interested in the discussion about FoFdation and EMC2* *** ** ** I am very surprised that you are so much interested in our work. I didn’t expect as much response and I wasn’t at the office yesterday to enter the discussion. ** ** To answer Jan’s questions **- **How much time we people have and how we test our effort The FoFdation project has about 40 partners involved (among them are Agie-Charmilles, Airbus, Fidia, Siemens and some smaller companies) and consists of 9 Work Packages. My work is in Work Package 4 were we try to find ways to optimize machining in the scope of the controller and the machine. Other work packages are at different levels (i.e. Plant-Scope Manufacturing Planning). For this task I work together with CADCamation SA (Work Package Leader) and the university of Nantes () which supports us with manufacturing know how and different kinds of machines. Fidia provides us with controller knowledge and Artis will help to monitor the manufacturing process. We support them with knowledge about developing CAD Systems and Computer Science. As far as I know our work package takes about 3 years. ** ** Comment about STEP, Tools and Projects: STEP is not perfect but it’s what our partners use. Because there are so many partners involved there are (from my opinion too) many different requirements and you are right that the work is not as productive as it would be if a smaller group would do it. The point we are told from our project leaders is that the companies involved should put something into the project but also profit by including the development in their own things. **- **Cadcamation SA: http://www.cadcamation.ch/ ECN / Irccyn : http://www.ec-nantes.fr/version-francaise/recherche/laboratoires/irccyn/ Fidia : http://www.fidia.com/ Artis : http://www.artis.de ** ** I am looking forward to a great collaboration with you all and thank you very much for all the replies. ** ** Kind regards Fabian -- 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] I am new here
Stuart, The devil's advocate has always had the ear of God ;) j. On Fri, Mar 30, 2012 at 12:13 AM, Stuart Stevenson stus...@gmail.comwrote: On Thu, Mar 29, 2012 at 3:01 PM, emc-developers-requ...@lists.sourceforge.net wrote: Send Emc-developers mailing list submissions to emc-developers@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/emc-developers or, via email, send a message with subject or body 'help' to emc-developers-requ...@lists.sourceforge.net -- Message: 8 Date: Thu, 29 Mar 2012 22:01:30 +0200 From: Jan de Kruyf jan.de.kr...@gmail.com Subject: Re: [Emc-developers] I am new here To: EMC developers emc-developers@lists.sourceforge.net Message-ID: CAA85NCj-4V+zhYQ0=yQKiVjjHF=QVc5rH1Wj8uJ_Q53YzzBW= q...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hallo, good people, I see that I have started yet another religious war! (sigh) So now the first principle, I would think we all agree on, is that where you STAND determines what you SEE. I have no doubt that the people who commented here are quite genuine in what they perceive to be reality. But at the same time, if you move over a bit you might see quite different things happening. So here is my comment on your observations: Jan, I in no way wish to discourage you. My comments ARE a result of where I stand. I almost discarded my reply because I did not want to inject a negative tone into the project. I thought about this for a while and decided to send it (with personal reservations) in the attempt to shed some light on problem areas. I think this project is possible if you have a very restricted surface set and not try to be everything to everyone. About the only negative thought I have on this is as follows: If good and capable people spend valuable time on a project that has little chance of success then would that time have been better spent on other projects? My hope is that my comments will contribute to the success of the project thereby making the time spent much more valuable. My religious position about this project is - go for it. I will help any way I can. I see a lot of 'gotchas' but learning how things will not work is part of the process of learning how to make things work. Have fun with it. thanks Stuart -- dos centavos -- 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] [!! SPAM] Re: I am new here
Kirk, what you see on Ebay is last years technology. Personally I would see if the SERCOSII interface cannot be stripped out of the drives and wether they can be used with a 0-10V interface. Kollmorgen drives for instance have that possibility. I know it sound strange after my comment earlier, but SERCOSII is an old beast that works, but only just. once it gets sick it takes a lot of doctors to get it right. I believe it has to do with wether you wear your rabbit's foot in your left pocket or your right pocket, but I never found out which. Further The drive software will have to be either reverse engineered or we have to buy the spec from the sercos organisation. Even the interface chip to the serial link has only partially published specs. The rest is to be bought. SERCOSIII on the other hand has GPLed software on sourceforge, and it used ethernet, probably because of market pressure from Beckhof. j. On Thu, Mar 29, 2012 at 11:31 PM, Kirk Wallace kwall...@wallacecompany.comwrote: On Thu, 2012-03-29 at 07:15 -0700, Peter C. Wallace wrote: On Thu, 29 Mar 2012, Jan de Kruyf wrote: ... snip Quite correct, not until you would like to see something running / use LCNC to actually retrofit a machine. On the one side you need a modern drive interface for a high-speed machine (the market this development is aimed at) Actually I rather doubt this. Can you explain why this would be? I directly connected PCI/PCIE card can have much better latency than any of the serially connected drives (loop rates in the 100s of KHz are possible (we are doing this now) At first I thought the Sercos market was beyond the LinuxCNC market by quite a bit, so I searched Sercos on eBay and there are plenty of used Sercos I and II PLC's, drives and PCI cards in the low hundreds of US dollars. I suspect machines using Sercos drives, waiting to be converted, will be coming to the list in the not too distant future, if LinuxCNC can convince owners that it is worthy of a $10,000+ well used machine. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- 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] adding araisrobo (aka artek) branch:
I did that already on my machine, but I did not have the time to dig into it. I was hoping to do some diffing to see what is cooking there. I did not get any git conflicts by merging into a copy of my (pre-LinuxCNC) 2.6-pre master did not try yet with the latest. At the same time development is going quite fast on both branches at the moment of course. cheers, j. On Fri, Mar 30, 2012 at 9:47 AM, Michael Haberler mai...@mah.priv.atwrote: I think some features in Yishin Li's code would be an interesting addition to linuxcnc, in particular those: ..Just want to let you know that we've implemented NURBS motion and S-Curve velocity profile for TRAJ and JOGGING on our git repository at https://github.com/artek/emc2 I plan to add https://github.com/artek/emc2:master as branch joints_axes3_arais to git.linuxcnc.org, as a start to bring it back into the fold Any issue with that? - Michael -- 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] I am new here
Hallo, good people, I see that I have started yet another religious war! (sigh) So now the first principle, I would think we all agree on, is that where you STAND determines what you SEE. I have no doubt that the people who commented here are quite genuine in what they perceive to be reality. But at the same time, if you move over a bit you might see quite different things happening. So here is my comment on your observations: Stuart - STEP is better than IGES. STEP has not arrived at perfection, YET. No and it will not either for some time to come. BUT Boeing keeps pushing for some solution, already for all these years, AND is prepared to throw money at it And this latest trick is a clever one: get as many universities involved as possible. (Mickeysoft is on the same trail by the way, already for years!) Some time or the other the penny will drop with some of these bright young kids and something good will come of it. And the other trick: make it open source. That community is much more open to new ideas than the big software houses. They will pick up afterwards, whatever becomes profitable and polish it. Now in my experience clever deep pockets will always win out over poor me sitting here preaching my belief. Peter - Actually I rather doubt this. Can you explain why this would be? You are quite correct in your observation about latency. But unfortunately there are many more factors that determine what is experienced in practice by an engineer trying to set up a new drive system or trying to troubleshoot a misbehaving system. The whole science of (analog) signal transmission, which involves noise, cable impedance, filtering and what not, is for most young engineers very much a black art. So the result were many lousy systems, which never got fixed properly because good field service engineers have always been few and far inbetween. So along came digital, al pre-configured by the manufacturer and lo and behold everything became plug and play (eh well, almost!) The computer just tells you what to do thats what I get here (South Africa) from service technicians. And on a high speed machine the newer drive systems are genuinely much better because the motors are much faster and it is possible to delegate lots of stuff to the drive, including the closure of the position loop. At the same time the application software and the electrical cabinet are very much simpler than in the olden days. I just brought a 9 axes system back up, that had some digital loop problem that was unsolvable for many months. In any case, I would not dream to do a system like that with analog technology. The risks are much too big. One sloppy drive and the whole Glockenspiel would collapse with accompanying noises of broken toys. Some of you might remember, when I first got to know LCNC, that I was after a 5 axis mill retrofit. Which I did not get! Not because LCNC was not capable! But because customer got pig ears sown on about what the computer all does for you!!! And so aquired himself a grossly inferior system and had massive mechanical damage done to his machine in the process. All because I was in no position to pull of the same smoke and mirror display my competitor did. So here again: I might insist that the earth is flat and all this bull about a round earth is made up in Hollywood, because after all that is what I see every day. . . Yet it does not go down with quite a few other people, because their vantage point is different. AND unfortunately they have money!!! So I would yet say that some fun is to be had and perhaps some money is to be made if we get up and at least are seen to cooperate with this initiative, after all the deep thinking will presumably be done by Fabian and his friends. Besides that, one or two modern drive interfaces WILL benefit the project and us. And will not steal bread out of Peter's or Jon's mouth because they operate in a totally different market! A sercos drive will in general be rather expensive in that market. Ok nuff said. Time to listen to music now. Cheers, j. On Thu, Mar 29, 2012 at 5:18 PM, Kirk Wallace kwall...@wallacecompany.comwrote: On Thu, 2012-03-29 at 08:15 -0500, Stuart Stevenson wrote: Gentlemen, I have seen this project for over two decades. It WAS the next 'greatest' answer to part production. This 'answer' was initiated in the late 1970's. Iges was going to be the main tool to machine parts directly from geometry ie (no programmer). ... snip We have not arrived at the point of removing the programmer. thanks Stuart While going through the Steptools documents I had the impression that the CAD person would design the shape, specify the material, all of the processes, tooling, consumables, fixtures, and everything else including the process of recycling or disposal of the part. All of this would be contained in one big part database, from which all processes would pull their bit. It seems likely that mistakes would be
Re: [Emc-developers] I am new here
They do certainly give very strange and new-fangled names to diseases Plato in The Republic. (according to Don Knuth) Thank you Kent for your learned exposition. and yes they are all Tools. Nothing more, also nothing less. Cheers, j. On Thu, Mar 29, 2012 at 10:23 PM, Kent A. Reed knbr...@erols.com wrote: On 3/29/2012 9:15 AM, Stuart Stevenson wrote: Gentlemen, I have seen this project for over two decades. It WAS the next 'greatest' answer to part production. This 'answer' was initiated in the late 1970's. Iges was going to be the main tool to machine parts directly from geometry ie (no programmer). The project driver is 'cost savings'. The 'stockholders' ultimate dream is for the design engineer to input the design rules describing the object desired and the machine tool then internally creates the geometry and creates the part. For thirty years design engineers have spouted the mantra 'In a couple years NC programmers will no longer be needed'. For the most part the design engineers do not realize once the CAM of CAD/CAM is automated then CAD will be the next automation project. Iges is a graphics exchange standard. I was a peripheral player in some of the testing during the late 1980's. Surface definition has always been the achilles tendon of the automatic geometry to manufacturing project. Boeing was a driver. Wichita was one of Boeing sites so we saw Iges projects and development AND foibles. As computer power increases, surface definition becomes more complex/powerful. This complexity/power resulted in surface integrity problems for the Iges translator. The surface designed in system A, iges translated out of system A and then iges translated into system B was not the exact same surface. Sometimes system B would not be able to describe the surface and a hole would exist in the system B model. It is so bad (within the last ten years with system A being the top aerospace CAD/CAM software) I have seen a surface created in system A, iges translated out of system A and immediately iges translated into system A (same computer, same software) result in two different surfaces. The iges IN/OUT translator was unable to recreate an identical surface. This led to STEP, which changed the moniker of the automatic programming project to STEP-NC. STEP is better than IGES. STEP has not arrived at perfection, YET. There are many parameters to consider during the manufacturing process. We have not arrived at the point of removing the programmer. thanks Stuart - Stuart: I don't dispute your closing statement nor your theme that successive technologies have been promised as The Answer since the beginning of usage of computers in manufacturing applications. These are correct. I do feel the need to insert several caveats. 1) Yes, IGES stands for Initial Graphics Exchange Specification, the name of the original NBS/GE/Boeing project that began more than 30 years ago. In part, that's because the genesis of the idea came through NCGA (National Computer Graphics Association) conferences and in part because the very moniker CAD stood for Computer Aided Drafting at that time. Never the less, IGES incorporated 3D geometry almost from the get-go. Over the years, wireframe, surfaced, and CSG representations were perfected. There was never any intent within the IGES Committee or its successor, the IGES/PDES Organization to address automated CAM programming. There were some DoD-driven projects in that area that chose IGES to represent their product definition data. 2) Even within CAD-to-CAD exchange, the use of IGES, like all other data exchange representations suffered real world failure until CAD buyers started holding the feet of their translator writers to the fire. Even a perfect specification means nothing unless the translators implement it correctly, and if not correctly, at least in the same way. [NB- this translator-vs-specification problem exists in every technical arena, not just CAD/CAM. Finite element modeling and analysis programs suffered from the same problem as early as the 1960s.] 3) The definition of surfaces is one of the trickiest bits in any CAD system. Every aerospace manufacturer maintained a stable of applied mathematicians to help deal with their problems in their in-house systems and many employed a patchwork quilt of programs to deal with different aspects (notably healing the intersections of different surfaces, such as at the root of an airfoil). 4) Some things were done better in STEP and some perhaps not so much. It is still my personal belief is that early successes in information interchange using STEP application protocols were as much the result of many CAD system vendors basing their translators on the work of only a few speciality translator-writing houses plus big bucks being shoveled from DoD projects to make the demonstrations happen. 5) STEP-NC is, to the
Re: [Emc-developers] I am new here
Fabian, Welcome. On emacs: install it run it go to Help and open the tutorial. My wife prefers it any time over *?*-office, although it seems a bit heavy at first when you start out. What linux distribution do you use? Happy hacking j. On Wed, Mar 28, 2012 at 1:23 PM, Saccilotto Fabian fabian.saccilo...@ntb.ch wrote: Hi Michael, thank you for your fast reply. I never used Emacs really, do you have any good source of a manual? Kind regards Fabian -Ursprüngliche Nachricht- Von: Michael Haberler [mailto:mai...@mah.priv.at] Gesendet: Mittwoch, 28. März 2012 12:28 An: EMC developers Betreff: Re: [Emc-developers] I am new here Hi Fabio, since I dabbled with Eclipse for a while, and switched back to using Emacs: I found Eclipse not worth the effort and overhead except for a few rare cases, which are: - the Python debug plugin by Aptana is great - refactoring support for some basic tasks, like renaming global variables, defines etc is very useful. The downsides were: - after a change, or git pull, the reparsing (c/c++ indexer) times are plainly pathetic. - git support was moderate for a long time, and I basically ran out of patience on it - autotools and make support is also so-so, and I'm not surprised you ran into that issue - getting Eclipse to use a consistent source indentation handling I found next to impossible. - the Eclipse plugin hell made me weep so my suggestion for a dev environment is - get out that emacs manual, and get yourself a git version from kernel.org, the stuff in lucid (or whatever you're using) is outdated, and it is very easy to forget to check in files. In src, 'make tags' and you get most of what eclipse gives you with less hassle and a *lot* faster. I usually run compile within Emacs as '~/emc2-dev/src; make -k OPTS=-O0'. In a few rare cases I use Eclipse on my emc2 dev directory, refactoring and remote debugging of Python scripts being really the only decent use case. Personally I feel way too young to use Vim.. I have no opinion on Gedit. re: your NC-Step plans - I dont know whether this is a 'compile to G-code' or 'run instead of a G-code interpreter' thing. If the latter, you will potentially find the 'pluggable interpreter feature' useful, it was recently added to master. Do not expect a quick win here, the interpreter internals and their machine API arent very well documented and a lot of source reading is requited. The way I read your message I suspect you might make use of the Canon interface. good luck, Michael Am 28.03.2012 um 10:46 schrieb Saccilotto Fabian: Hello everyone, my name is Fabian Saccilotto, I work for the Interstate University of Applied Science NTB (Switzerland) at the Department of Computer Science. I am working on a European Research project called FoFdation ( http://www.fofdation-project.eu/Pages/Default.aspx if you're interested). The part of the team I am working in is trying to improve the manufacturing process by bringing more sophisticated information (Surfaces and Curves instead of GCode) to the machine controller. As the project should be more or less open afterwards we would like to use EMC2 as controller. The idea is to use STEP-NC (http://en.wikipedia.org/wiki/STEP-NC) to define manufacturing features of a workpiece (such as pockets and wholes) and interpret them directly on the controller to move the axes. This meta-level information could help the controller to make the right decisions (i.e. correct movements) when the manufacturing is not as usual (i.e. tool break). The first goal for our partners is to make a proof of concept for free form surfaces. The surface is sent (NURBS, BSpline) to the controller and is evaluated there to a toolpath (Curve with surface normal) in the non-real time part of the controller. All informations needed for tool movement can then be extracted in real time more or less directly from the toolpath (Evaluate the curve and its derivatives). A feedback loop from the machine correlates desired and actual process (tool movement, workpiece shape, torque etc.) and applies toolpath transformations if necessary. My first steps with EMC2: I pulled EMC2 from git/master and would be interested how you develop the source. I tried to set up an eclipse CDT project with autotools support but didn't get it to work and couldn't find any information on homepage nor wiki either. I run configure / make and was able to run emc2 successfully. è Is there any IDE you use or do you develop emc2 with Gedit/Vim Make? Any help, tips or opinions are appreciated ;o) Thank you very much, kind regards Fabian Saccilotto BSc. in Systemsengineering FHO Scientific Assistant Interstate University of Applied Sciences NTB Department of Computer Science NTB Campus Waldau St. Gallen Schönauweg 4 / Postfach 9013 St. Gallen CH-Switzerland Tel. +41 81 755 32 41 Fax +41 81 755 32 01
Re: [Emc-developers] I am new here
You also did find the read the emacs manual thingy I take it. Fore code browsing I use a thing called cscope, which integrates reasonably well in emacs. But perhaps Michael has a better idea? . . . j. On Wed, Mar 28, 2012 at 4:37 PM, Saccilotto Fabian fabian.saccilo...@ntb.ch wrote: Hi Jan, ** ** already installed emacs and do my first steps with those lots of shortcuts ;o) ** ** I am using Ubuntu Lucid Lynx 10.04 LTS Version at the moment. ** ** Kind regards Fabian ** ** *Von:* Jan de Kruyf [mailto:jan.de.kr...@gmail.com] *Gesendet:* Mittwoch, 28. März 2012 16:32 *An:* EMC developers *Betreff:* Re: [Emc-developers] I am new here ** ** Fabian, Welcome. On emacs: install it run it go to Help and open the tutorial. My wife prefers it any time over *?*-office, although it seems a bit heavy at first when you start out. What linux distribution do you use? Happy hacking j. On Wed, Mar 28, 2012 at 1:23 PM, Saccilotto Fabian fabian.saccilo...@ntb.ch wrote: Hi Michael, thank you for your fast reply. I never used Emacs really, do you have any good source of a manual? Kind regards Fabian -Ursprüngliche Nachricht- Von: Michael Haberler [mailto:mai...@mah.priv.at] Gesendet: Mittwoch, 28. März 2012 12:28 An: EMC developers Betreff: Re: [Emc-developers] I am new here Hi Fabio, since I dabbled with Eclipse for a while, and switched back to using Emacs: I found Eclipse not worth the effort and overhead except for a few rare cases, which are: - the Python debug plugin by Aptana is great - refactoring support for some basic tasks, like renaming global variables, defines etc is very useful. The downsides were: - after a change, or git pull, the reparsing (c/c++ indexer) times are plainly pathetic. - git support was moderate for a long time, and I basically ran out of patience on it - autotools and make support is also so-so, and I'm not surprised you ran into that issue - getting Eclipse to use a consistent source indentation handling I found next to impossible. - the Eclipse plugin hell made me weep so my suggestion for a dev environment is - get out that emacs manual, and get yourself a git version from kernel.org, the stuff in lucid (or whatever you're using) is outdated, and it is very easy to forget to check in files. In src, 'make tags' and you get most of what eclipse gives you with less hassle and a *lot* faster. I usually run compile within Emacs as '~/emc2-dev/src; make -k OPTS=-O0'. In a few rare cases I use Eclipse on my emc2 dev directory, refactoring and remote debugging of Python scripts being really the only decent use case. Personally I feel way too young to use Vim.. I have no opinion on Gedit. re: your NC-Step plans - I dont know whether this is a 'compile to G-code' or 'run instead of a G-code interpreter' thing. If the latter, you will potentially find the 'pluggable interpreter feature' useful, it was recently added to master. Do not expect a quick win here, the interpreter internals and their machine API arent very well documented and a lot of source reading is requited. The way I read your message I suspect you might make use of the Canon interface. good luck, Michael Am 28.03.2012 um 10:46 schrieb Saccilotto Fabian: Hello everyone, my name is Fabian Saccilotto, I work for the Interstate University of Applied Science NTB (Switzerland) at the Department of Computer Science. I am working on a European Research project called FoFdation ( http://www.fofdation-project.eu/Pages/Default.aspx if you're interested). The part of the team I am working in is trying to improve the manufacturing process by bringing more sophisticated information (Surfaces and Curves instead of GCode) to the machine controller. As the project should be more or less open afterwards we would like to use EMC2 as controller. The idea is to use STEP-NC (http://en.wikipedia.org/wiki/STEP-NC) to define manufacturing features of a workpiece (such as pockets and wholes) and interpret them directly on the controller to move the axes. This meta-level information could help the controller to make the right decisions (i.e. correct movements) when the manufacturing is not as usual (i.e. tool break). The first goal for our partners is to make a proof of concept for free form surfaces. The surface is sent (NURBS, BSpline) to the controller and is evaluated there to a toolpath (Curve with surface normal) in the non-real time part of the controller. All informations needed for tool movement can then be extracted in real time more or less directly from the toolpath (Evaluate the curve and its derivatives). A feedback loop from the machine correlates desired and actual process (tool movement, workpiece shape, torque etc.) and applies toolpath transformations if necessary. My first steps with EMC2: I pulled EMC2 from git/master and would
Re: [Emc-developers] [!! SPAM] Re: I am new here
I finally had some time to look properly: I would say I am excited about this development. This is most certainly the way industry is going. It has been in the works for at least 5 years. (Of course I was declared crazy at the time when I vented this opinion in front of my boss) Big names like Airbus and Boeing are crying out for it, thats quite clear. This is not some kid playing with a tabletop machine, it is not even Artek writing jerk limitation. It is much much bigger than that. Can you see the marketing potential? On the down side: there is going to be some major hacking and breaking, both in the parser (obviously) and also real-time motion will not be the same at all after this surgery. On the up-side: al our wishes will come true if and when this is pulled off. This then leads to the question: How many man-months did Fabian get available to him? Next question: What drive interface does Fabian need / want / is he willing to develop. So far nothing much has been done on that side except some work on a Beckhof / Ethercat interface. Everything else works fine but is not really state of the art. Perhaps we should have a serious look at SERCOSIII. the cnc-side code is opensource. And it is certainly popular in Europe. But I suppose I have waffled enough now, lets get some answers first. Cheers to all of you j. -- 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] [!! SPAM] Re: I am new here
I'm not sure that drive interfaces would come into play by adding STEP-NC and non-linear motion planning to LinuxCNC, or am I missing something? Quite correct, not until you would like to see something running / use LCNC to actually retrofit a machine. On the one side you need a modern drive interface for a high-speed machine (the market this development is aimed at) On the other hand, customers got talked a hole in the head about these beautiful modern drive systems. I assure you very few machines leave the factory in Germany with anything less than a SERCOSIII interface. Enjoy your day. j. On Thu, Mar 29, 2012 at 12:17 AM, Kirk Wallace kwall...@wallacecompany.comwrote: On Wed, 2012-03-28 at 22:40 +0200, Jan de Kruyf wrote: ... snip Next question: What drive interface does Fabian need / want / is he willing to develop. So far nothing much has been done on that side except some work on a Beckhof / Ethercat interface. Everything else works fine but is not really state of the art. Perhaps we should have a serious look at SERCOSIII. the cnc-side code is opensource. And it is certainly popular in Europe. But I suppose I have waffled enough now, lets get some answers first. Cheers to all of you j. I'm not sure that drive interfaces would come into play by adding STEP-NC and non-linear motion planning to LinuxCNC, or am I missing something? -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- 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] HTML5 HMI
Beautiful solution for perhaps eh . . . . the wrong problem? The machine shop does not really cry for a more beautiful and quicker process display. I fact The only sour point I pick up from lurking here is that every now and again someone needs a more FUNCTIONAL ui (In the sense that he/she/it has problems interacting with the process in a meaningful way.) Otherwise there are plenty of loose ends still that people on and off cry about, to get your teeth into. Happy Hacking. j. On Tue, Mar 13, 2012 at 4:32 AM, Brad Murry bradod...@hotmail.com wrote: Hello all, With all the html talk going back and forth. I develop machine software and have been tossing the idea around of creating an HMI framework based on HTML5+Websockets. The result would be to have a lean and mean web socket server running and tied to EMC hooks in a similar way to the GTK interface. EMC would be in place to do all of the work, and the web socket server is only for interaction with the HMI. Several methods would need to be supported for getting/setting Axis, IO, G-code operations as well as configuration/system debugging stuff. The graphics and UI tools available via HTML5+CSS3+Javascript are amazing and platform agnostic. Web sockets bring Web UI performance pretty darn close to native. Is there anyone already working on something like this? Any pointers for hooking into the various methods for HMI integration?(Might be nice to have a developer manual geared specifically for UI stuff) Thoughts? Thanks in advance for any help, -Brad -- 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] automated GUI testing
Hallo, I was only the info junkie that found it (cause I was curious, the concept intrigued me) In fact I amamazed that such old software just ran without major surgery. Unfortunately I am a bit busy at the moment and my tcl knowledge about matches yours. So we need another specialist, sigh . . . . cheers, j. On Fri, Nov 18, 2011 at 11:50 PM, Michael Haberler mai...@mah.priv.atwrote: Jan thanks - I gave it a try and semi-enjoyed it;-) I managed to record a touchy session after some massaging of the android tcl and the emc.sh script the emc script needs to honor and pass on DISPLAY when run from under android, I cludged around it to get it to work The sceendump compare is actually useful, with computing difference images it's easy to spot something xscope isnt good enough to trace Axis though - it seems to go into a loop, I'm not sure what the issue with Axis is, I am not into X11 a lot xscope cannot track window manager events - it just sits between the X11 server and the GUI, but that would be ok for automated testing the whole Tcl stuff is beyond me and needs some Tcl-aware person which I'm not so - a starting point but needs work - Michael Am 18.11.2011 um 10:29 schrieb Jan de Kruyf: This bug clearly shows the limits of the component-based testing approach with runtests. I think we shoud consider some user-level testing tool which includes GUI record/replay. maybe based on http://drdobbs.com/tools/184404691 . http://web.archive.org/web/20040604025740/http://www.wildopensource.com/larry-projects/android.html enjoy. j. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] another serious O-word bug: m2 in subroutine wreaks havoc with potential for undesired code execution
This bug clearly shows the limits of the component-based testing approach with runtests. I think we shoud consider some user-level testing tool which includes GUI record/replay. maybe based on http://drdobbs.com/tools/184404691 . http://web.archive.org/web/20040604025740/http://www.wildopensource.com/larry-projects/android.html enjoy. j. On Fri, Nov 18, 2011 at 10:05 AM, Michael Haberler mai...@mah.priv.atwrote: every tried to exit from an oword subroutine with an M2 and wondered what happened? this is what happens: - assume interpreter is executing a named oword sub in a separate file - when the interpreter switches from the main ngc file to the sub, it changes the filename to the sub's filename - the interpreter executes M2 and does NOT return from the sub, leaving the open filename the sub's filename - running the program again now executes the sub ngc file, with potentially undesired code execution To exercise, an Axis config is needed: - fetch http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/fix-m2-oword - pick 515be6 - cd to configs/sim/bug and execute 'emc bug.ini' - hit the run button twice For the fix, pick the second commit fb8698e and build; it seems m2 can now safely be used to terminate program execution from a sub This is basically the same horror bug as the one below (fixed in 009b76630), just triggered from a differnt corner of the interpreter (note the message created by '(debug, should not happen!)' in fail.ngc on the second execution: http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/failed-oword-regression-test http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/fix-failed-oword-procedure Howeber, this bug cannot be tested for with a rs274-based regression test because the state must be viewed with a debugger or within a complete gui based application - rs274 exits before it gets interesting Actually I suspect bug 1734309 to be related since this can cause accidential code execution I'll push this one right away to master; I'll look into redoing this with v2.5_branch which needs a different approach - This bug clearly shows the limits of the component-based testing approach with runtests. I think we shoud consider some user-level testing tool which includes GUI record/replay. maybe based on http://drdobbs.com/tools/184404691 . -Michael -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Linear scales
20 or 25um with a multiplierbox to make 1um has been pretty much standard for many years. j. On Sun, Sep 4, 2011 at 4:48 PM, petr ruzicka ru...@rocketmail.com wrote: Thank you for the post, in the past I've implemented a 5 axis Router , working in torque mode , AC servos (yaskawas ) all all-round with harmonic reductions on the 2 rotaries., without any probs, however the linear encoders give an extra piece to the problem. What resolusion (microns) should the scales be to be able to work properly? --- El Sáb 3/9/11, Viesturs Lācis viesturs.la...@gmail.com escribió: De: Viesturs Lācis viesturs.la...@gmail.com Asunto: Re: [Emc-developers] Linear scales Para: EMC developers emc-developers@lists.sourceforge.net Fecha: Sábado 3 de Septiembre de 2011, 11:48 2011/9/2 Jon Elson el...@pico-systems.com: If you have a lot of backlash between the motor and the scale (mostly would be worn ball nuts) then you will have a problem with a lot of servo hunting. The only linear scale systems I am familiar with is on some of Stuart Stevenson's large machines at MPM in Wichita, Kansas. I am sure they work well for him. One of his machines has linear scales PLUS shaft encoders on the motors. That system is also working well. I am in progress of implementing feedback from linear scales. Since there is significant (significant for closing feedback loop successfully) backlash in planetary gearbox, I am following Stuart Stevenson's wiki page on implementing 2 feedback devices for single joint. I also have resolvers on motors. I think that this might be useful also for You: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Combining_Two_Feedback_Devices_On_One_Axis Viesturs -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] CUI encoders
resistor vs. cable capacitance. - line speed suffers. sensitive to noise, in my experience. j. On Mon, Jun 20, 2011 at 12:00 PM, andy pugh bodge...@gmail.com wrote: On 20 June 2011 10:10, Topi Rinkinen linuxcnc@topisoft.fi wrote: The only drawback I see is O.C. output, but it can be overcame by placing TTL=LVDS transmitters very close to the encoder. Or resistors at the PC interface to use current-loop signalling? -- atp Torque wrenches are for the obedience of fools and the guidance of wise men -- 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] CUI encoders
Jon, the problem is that the delay between reality and the Z domain of the encoder is variable, so good tuning will be something somewhere in fairyland unless you lower the bandwidth of your drive right down so that the delay jitter becomes insignificant in respect to the bandwidth of your system. j. On Sat, Jun 18, 2011 at 5:46 PM, Jon Elson el...@pico-systems.com wrote: Jan de Kruyf wrote: Jon, I see exactly this in yr pictures: (from the faq on their website) 9. How does angular acceleration affect pulses and error? Angular acceleration does not cause missing pulses. But it does cause some lag in position, proportional to acceleration and T^2. (with T= 100, 50, 25, 13 µs at resolution settings D2, D1 = 11, 10, 01, 00, respectively). The internal position follower will have no problem with acceleration as long as the resulting position error stays within 256 increments (4 increments per quadrature period) for resolution 2048 PPR, with the limit being proportional in other resolutions. The position follower will catch up at the end of acceleration. Decreasing the basic resolution will reduce acceleration error, if that is of concern for fast loops or removing the SF jumper as described in section 3 above. --- Yes, I read this and it didn't sound too bad. But, I think the lag is a LOT more than 100us, up to several milliseconds, or maybe 30 times worse than what they state. so I would give that rubbish a miss. It is good for a position readout, but definitely not for a high speed feedback loop. I may experiment some more at different resolutions, and see about that jumper setting. 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] spindle control discussion
EMC V2.5 Integrator Manual Chapter 11. HAL Examples 11.3 Soft Start This example shows how the HAL components lowpass, limit2 or limit3 can be used to limit how fast a signal changes. HAL_gearchange HAL_classicladder HAL_siggen to rock your baby if the gears dont want to engage. Have fun. Jan de Kruyf. On Mon, Nov 22, 2010 at 9:01 AM, Chris Morley chrisinnana...@hotmail.comwrote: Hi guys. While working on pncconf to set up controlling a spindle, some questions have come up: - Would it not be a good idea to limit rpm and acceleration of the spindle in EMC's motion module? - it would be nice to have g96 max rpm setting as a HAL pin, so an LED could show that rpm is maxed out because of gcode setting and also to override up-to-speed (not sure if that is necessary) I was thinking of gear changes too. would it not be good to have a scheme like tool changes to aid adding gear ranges? I'm thinking like an m code that : stops spindle puts up a HAL gear change request number (taken from m code ?) sets a gear change request bit signal waits for a gear change finished signal. Thoughts ? Chris Morley -- 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/msIE9-sfdev2dev ___ 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/msIE9-sfdev2dev___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
