Great! Thanks Charles! I'll try it as soon as you have it available. The reason you didn't get my reply to the mailing list is that replies have been "blocked from viewing by project administrator". I asked why but have not gotten a response.
Tom BTW: You might want to send a copy to Mark Tucker as well since he is looking for the same thing... On 1/10/2014 10:33 AM, Charles Steinkuehler wrote: > On 1/10/2014 7:42 AM, Thomas Studwell wrote: >> Charles, >> sorry to bother you directly with this. Attached is a reply I made to >> the maillist to your response. >> >> I was sort of surprised that you hadn't replied to it (given how quick >> you were to respond the first time). Today I saw a related posting (on >> pulse polarity) to which you also replied immediately. I replied to >> that note as well, but, on a hunch, I decided to check the archive and >> found that both of my reply emails had been blocked and I don't know why. > I didn't respond because as far as I can tell, the mail below never got > to me. Not that it's unknown for me to occasionally miss something I > should have responded to... :) > >> I'm working on that problem, but please read the attached and, re Mark >> Tucker's request, I agree with his request, including the comment that >> simply building two versions of the pru-generic module would be useful, >> one for positive output and one for negative so we could select in the >> HAL which to use would be extremely useful. > I can easily modify the PRU assembly and create a version that does > falling-edge step pulses for all step/dir generators. To use it, you > would simply point to the modified PRU binary in the HAL command that > loads the hal_pru_generic module. The longest part will be actually > testing the code to make sure it works as expected. > > I'll see if I can't get it banged out today. This will be a "one-off", > and will not get added to the builds, since I'm about to embark on a > somewhat major cleanup of the PRU and BeagleBone GPIO code so pin > numbers are consistent, and I'll add configurable step polarity in the > process. > >> Tom >> >> -------- Original Message -------- >> Subject: Re: Re: [Emc-users] How do you change polarity of Step >> Pulses in MachineKit stepgen? >> Date: Mon, 06 Jan 2014 07:43:49 -0500 >> From: Thomas Studwell<twstudw...@gmail.com> >> To: Enhanced Machine Controller (EMC)<emc-users@lists.sourceforge.net> >> >> >> >> On 1/5/2014 10:41 AM, Charles Steinkuehler wrote: >>> On 1/5/2014 8:57 AM, Thomas Studwell wrote: >>>> I am currently using debian-7.2-machinekit-armhf-2013-12-02 image, >>>> modified for the Xylotex BBB_DB25ee board and I want to change the >>>> polarity of the Step pulses (3 axis). Is there a configuration setting >>>> to do this? I tried updating my HAL to allocate the pins to GPIO so I >>>> could invert with setp but then the stepgen was not happy with this... >>>> >>>> The PRU driver configuration is: >>>> CONFIG=prucode=/home/linuxcnc/linuxcnc/rtlib/xenomai/pru_generic.bin >>>> pru=1 num_stepgens=3 >>> You can use a negative value for the position scale, which will move the >>> motor the other direction. If you actually want the step pin inverted >>> (ie: mostly high, with a step pulse causing the signal to go low), >>> you'll have to tweak the code. This isn't currently supported in the >>> PRU code (along with up/down mode, and a few other things you can do >>> with a hostmot2 stepgen). >>> >>> Also, since the PRU is running the "base thread", instead of the ARM, >>> you can't use HAL to play with the outputs like you could if it was a >>> typical x86 system. Anything dealing with timings faster than the servo >>> thread needs to be coded on the PRU. >>> >> Charles, >> thanks for the reply. I understand the need for the code to reside in >> the base thread (and, in fact, appreciate that you did this work). I >> was hoping that there might be an 'invert' control parameter that might >> be always xor'd with the output prior to setting the register. I've >> done a fair amount of programming in my life, both user code, embedded >> controllers, and real-time os, however, I've never built a real time >> component of this sort (or any other linux component for that matter). > Due to how the code is written and the way the GPIO pins are modified > (using set/clear registers instead of writing a value), it's not as > simple as just adding an xor. But it's not real hard, either (at least > if you're familiar with the code and the PRU). :) > >> On a scale of 1 to 10, where ten is that you need a cray with terabytes >> of disk space (and 1 is there is a build script that I can run on the >> BB), how would you rate the difficulty of 'tweaking' such a thing? I'd >> be willing to try to parameter-ize this so others could use it. >> Alternative is that I get out my soldering iron and insert an inverter >> in the path. > If you want to play, it's pretty simple. A one if you're already Linux > savvy and are familiar with ./configure& make. Just edit the PRU code > in linuxcnc/src/hal/drivers/hal_pru_generic/pru_stepdir.p then run make > and sudo make setuid. > >> Re negating the position scale, I hadn't thought of that. I simply >> reversed one of the windings in the stepper... :-) >> >> Thanks again, >> Tom >> >> > ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
