I have not followed the discussion but "volatile" keyword for variables might help. It will not force atomic operations but it will force a real read or write probably with correct order. The compiler usually output warnings about ordering not defined then accessing several "volatile" variables on the same row.
Nicklas Karlsson On Wed, 22 Jul 2015 06:20:09 +0000 [email protected] wrote: > Send Emc-developers mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Emc-developers digest..." > > > Today's Topics: > > 1. Re: Rotary axis motion too slow (Gene Heskett) > 2. Re: jepler/hm2-eth-multiple: support multiple hostmot2 > ethernet cards (Jeff Epler) > 3. More trouble for LinuxCNC's memory model on ARM (Jeff Epler) > 4. Re: More trouble for LinuxCNC's memory model on ARM (Chris Lesiak) > 5. Re: More trouble for LinuxCNC's memory model on ARM (EBo) > 6. Re: More trouble for LinuxCNC's memory model on ARM > (Sebastian Kuzminsky) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 Jul 2015 08:18:58 -0400 > From: Gene Heskett <[email protected]> > Subject: Re: [Emc-developers] Rotary axis motion too slow > To: [email protected] > Message-ID: <[email protected]> > Content-Type: Text/Plain; charset="iso-8859-1" > > On Wednesday 15 July 2015 02:22:06 Marius Alksnys wrote: > > On 07/15/2015 08:59 AM, Gene Heskett wrote: > > > Trying to learn something here, I see the use of several of the ddt > > > modules, which appear to be used for detecting the slope, or change > > > velocity, its output. > > > > > :) No, these ddt and hypot are not needed here. They where used to > > : trace > > > > velocity - just for testing, derived from TP testing config, which > > tracked max acceleration of each axis and had nice side panel: > > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NewTrajectoryControl > > Lots of stuff there I'll have to study. Hopefully that will be in the > printable pdf's at some point after 2.8.x is declared usable for all. > > I had to switch to it because the 2.6.x stuff had turned into a > crashomatic on both of my atom board. > > I've found that the 2.8.0-pre's have been usable, and rock solid stable. > I do have a bit of trickery in the hal for the spindle servo, a bias so > the creep speeds were similar in both directions, but stop is off, no > servo so it coasts. Yesterday, when I was trimming that sleeves > in .05mm increments, hoping I didn't end up making 2 pieces out of it by > cutting thru the sides of the 2 thru holes for its mounting bolts, that > I could click stop then get a much faster stop by reclicking the fwd > button, but its creep speed (about 5 rpm) was backwards! Stop it again, > and click fwd a second time, and its normal, creeps fwd. > > Unforch, I think that also wrote a fini to that plastic drive timing > pulley, so I find I now have to ask for 500, get about 475 that drops to > 350 when shaving .05mm of alu from a nominally 38mm bore. But I have not > found a timing pulley maker that can make for that old style belt, that > number of teeth and a 9mm shaft bore, that doesn't want $200 for it. > > I have looked at the other choices in smaller machines, and NONE of them > have drive parts capable of surviving a full cut of steel at their rated > and advertised swing. Or the horsepower to do the cut at that swing. > > Needing some fresh brushes for the toy mill, I just bought 3 belts and 5 > more of those pulleys along with some QC tool holders so I can have more > tools premounted, all from LMS. > > I have plans to ditch the jackshaft and the backgear, and use a > polygroove pulley about 6" in diameter directly on the rear of the > spindle. Which should result in a machine that can actually remove half > a mm of metal from any diameter the toolpost can reach. This S.O.B., as > shipped doesn't have the power or drive to cut steel above .75" in > diameter. So the 7" swing they gave it is pure bull shit. With sharp > enough tooling, it might be able to cut balsa at a 3.5" radii, but I'd > have to see it do it. > > Yeah, I am P.O.ed and tired of replacing $4.65 bits of plastic because I > can't buy a suitable metal version... > > > > OTOH, I haven't any experience with velocity driven servo's, and if > > > I were to do a servo driven machine, I would automatically use > > > position desired, and position feedback to achieve the desired > > > result, a near vanishing position error. > > > > > > Where can I learn how a velocity servo achieves the positioning > > > accuracy that allows it to do as good, or perhaps even better, > > > working accuracy compared to a position servo? Surely there is a > > > tut on this? > > > > Yes, having velocity and position loops increases trajectory following > > accuracy and eases PID tuning. If you have only torque or PWM mode > > servo amplifiers, then you can create velocity pid in LinuxCNC. It > > should track axis velocity (you can use encoder-velocity output or ddt > > here), directly control the amplifier and get command from position > > PID. Velocity PID might have only Igain non-zero. > > This helps a lot in certain setups. > > So you were subbing the ddt outputs for an assumed perfect encoder on the > axis output. > > Makes sense as a troubleshooting tool. > > > What I found: > > http://www.anderswallin.net/2008/04/x-axis-test/ > > http://gnipsel.com/linuxcnc/tuning/servo.html > > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Tuning_LinuxCNC/HAL_PID_Loops > > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?PiD > > These I have seen & studied before and have arrived at PID settings that > seem to work. But I'd be the first to say they may not be perfected. > > Thank you Marius. > > Cheers, Gene Heskett > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > Genes Web page <http://geneslinuxbox.net:6309/gene> > > > > ------------------------------ > > Message: 2 > Date: Wed, 15 Jul 2015 20:20:05 -0500 > From: Jeff Epler <[email protected]> > Subject: Re: [Emc-developers] jepler/hm2-eth-multiple: support > multiple hostmot2 ethernet cards > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > I updated the branch slightly. > > The following changes since commit 641e98acefe8619faf23bb94e1e5f24b4cfc171a: > > uspace: must advise user to set RTAPI_FIFO_PATH (2015-07-15 20:08:51 -0500) > > are available in the git repository at: > > git://git.linuxcnc.org/git/linuxcnc.git jepler/hm2-eth-multiple > > for you to fetch changes up to 7be45d776c9b109dc29fed466fa1da411263a9ef: > > hm2_eth: make unrecognized boards work (2015-07-15 20:16:24 -0500) > > ---------------------------------------------------------------- > Jeff Epler (4): > hm2_eth: allow multiple instances (up to 4) > hostmot2: support split reads > hm2_eth: in case of failed recv(), show an error > hm2_eth: make unrecognized boards work > > docs/man/man9/hm2_eth.9 | 2 - > docs/man/man9/hostmot2.9 | 14 + > src/hal/drivers/mesa-hostmot2/hm2_eth.c | 320 > ++++++++++++++------- > src/hal/drivers/mesa-hostmot2/hm2_eth.h | 29 +- > src/hal/drivers/mesa-hostmot2/hostmot2-lowlevel.h | 7 + > src/hal/drivers/mesa-hostmot2/hostmot2.c | 33 ++- > src/hal/drivers/mesa-hostmot2/hostmot2.h | 1 + > src/hal/drivers/mesa-hostmot2/tram.c | 11 +- > 8 files changed, 295 insertions(+), 122 deletions(-) > > > > ------------------------------ > > Message: 3 > Date: Tue, 21 Jul 2015 19:16:27 -0500 > From: Jeff Epler <[email protected]> > Subject: [Emc-developers] More trouble for LinuxCNC's memory model on > ARM > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > A year ago I wrote about how ARM's memory model is not strong enough to > reliably transport double-precision floats across HAL pins: > http://mid.gmane.org/20140702141237.GB65254%40unpythonic.net > > Today after looking at rare ARM-only buildbot failures, some of us > researched the ARM memory model a bit more, and found some unfortunate > assumptions that seem to hold up on x86 but not on ARM. > > You can find the lengthy PDF document "ARM Architecture Reference Manual > ARMv7-A and ARMv7-R edition" by your favorite search engine. Down in > appendix G.2.2 is a nice section explaining the observed failures, all > of which seemed to happen only on ARM, the impact being that sometimes > halsampler prints 0 instead of an expected value. > > Weakly-ordered message passing problem > P1: > STR R5, [R1] ; set new data > STR R0, [R2] ; send flag indicating data ready > > P2: > WAIT([R2]==1) ; wait on flag > LDS R5, [R1] ; read new data > > In the absence of barriers, an end result of P2: R5=0 is > permissible > > The fix is to use "barrier instructions", "DMB [ST]" and "DMB" on the > writer and reader sides respectively. ("DMB [ST]" seems to mean '"DMB" > or "DMB ST"; "DMB" is the strongest barrier, "DMB ST" is a specific kind > of weaker barrier) > > It appears that the gcc built-in function __sync_synchoronize will > generate the required instruction on ARM. On x86 this generates the odd > instruction 'lock orl $0, (%esp)' and on x86_64 (or x86 with > -march=pentium4), the 'mfence' instruction which will cause a small > performance hit and as far as I know is not necessary. In particular, > it's not required in this case according to this summary of the Intel > SDM in http://www.cl.cam.ac.uk/~pes20/weakmemory/cacm.pdf : > Example 8-1 Stores are not reordered with other stores > > Proc 0 Proc 1 > MOV [x] <- 1 mov EAX <- [y] > MOV [y] <- 1 mov EBX <- [x] > > Forbidden final state: Proc 1:EAX=1 and Proc 1:EBX=0 > > We identified some locations in LinuxCNC where these barriers definitely > need to be added: > streamer/sampler > halscope > task/motion > nml shared memory regions > mutex operations (may already be right) > but probably we will not immediately identify all such places and fix > them all. I hope to work up a branch this weekend for further testing, > particularly if I can reproduce the behavior on my ARM board (which is > the odroid u3, same as in the buildbot farm). If it's not too invasive, > I'll propose it for inclusion in 2.7, but I'm likely to make it > cumulative with my rework of streamer/sampler since it centralizes what > was 2 distinct sets of code before. > > ... since I first tried to send this message, sourceforge had their > little meltdown and I did further research. > > First, I did targeted testing on my ARM and found that with a new test I > coded up, the sampler bug showed up on average more than once per > minute; and that with the addition of barriers it went way down to zero, > or at least less than once per 16 hours. I have not placed this work on > a tree on git.linuxcnc.org yet, but I plan to rework the basic fix for > streamer/sampler *not* on top of the experimental library-ized streamer > but in a way that is suitable for 2.7. I also now believe that nml > shared memory regions are safe, due to use of OS mutexes which should > already contain the required barriers. > > Jeff > > > > ------------------------------ > > Message: 4 > Date: Wed, 22 Jul 2015 02:51:44 +0000 > From: Chris Lesiak <[email protected]> > Subject: Re: [Emc-developers] More trouble for LinuxCNC's memory model > on ARM > To: EMC developers <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > Instead of using __sync_synchronize, would you consider requiring --std=c11 > so that stdatomic.h can be used? > > That can give you just as much ordering as you require. > > ------------------------------ > > Message: 5 > Date: Wed, 22 Jul 2015 00:14:08 -0600 > From: EBo <[email protected]> > Subject: Re: [Emc-developers] More trouble for LinuxCNC's memory model > on ARM > To: <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On Jul 21 2015 6:16 PM, Jeff Epler wrote: > > A year ago I wrote about how ARM's memory model is not strong enough > > to > > reliably transport double-precision floats across HAL pins: > > http://mid.gmane.org/20140702141237.GB65254%40unpythonic.net > > > > ... > > That was a very good find. Congrats! > > Your test code might also be nice to have in an archive some place as > an example and further study. > > EBo -- > > > > ------------------------------ > > Message: 6 > Date: Wed, 22 Jul 2015 00:19:51 -0600 > From: Sebastian Kuzminsky <[email protected]> > Subject: Re: [Emc-developers] More trouble for LinuxCNC's memory model > on ARM > To: EMC developers <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252 > > On 07/21/2015 08:51 PM, Chris Lesiak wrote: > > Instead of using __sync_synchronize, would you consider requiring --std=c11 > > so that stdatomic.h can be used? > > > > That can give you just as much ordering as you require. > > I don't see any memory barrier functions in stdatomic.h. > > http://en.cppreference.com/w/c/atomic > > The problem isn't about non-atomic memory access, it's about limiting > memory access reordering. > > Intel (i386 and amd64) has strong memory ordering, so stores done by one > processor will be seen by other processors in program order. ARM has > weak memory ordering, so the stores may be seen by other processors in a > different order than they were programmed. > > A special memory barrier instruction prevents reordering, and is > required for correct execution of some of our code on ARM. > > https://en.wikipedia.org/wiki/Memory_ordering > https://en.wikipedia.org/wiki/Memory_barrier > > Or am I missing something about your suggestion? > > > -- > Sebastian Kuzminsky > > > > ------------------------------ > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > > ------------------------------ > > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > End of Emc-developers Digest, Vol 111, Issue 6 > ********************************************** ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
