From: Charles S. <ch...@st...> - 2014-01-10 15:33:53
Attachments:
signature.asc
|
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 <TWS...@gm...> > To: Enhanced Machine Controller (EMC) <emc...@li...> > > > > 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 > > -- Charles Steinkuehler ch...@st... |
From: Charles S. <ch...@st...> - 2014-01-10 17:33:40
Attachments:
signature.asc
pru_generic_fall.tgz
|
On 1/10/2014 9:33 AM, Charles Steinkuehler wrote: > On 1/10/2014 7:42 AM, Thomas Studwell wrote: >> > 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. OK, here's the quick and dirty version of the PRU code that just inverts the step signal. I've verified it moves motors on my 3D printer and the default step state is high (the step pulse is a falling edge, followed very briefly by a return to the default high state). Just drop it in the linuxcnc/xenomai directory and adjust your ini/hal file to load the new file (pru_generic_fall.bin). The debugging files are included just in case you feel _really_ adventurous! :) cc'd directly to the two interested parties in case the list strips the attachment. If it does, and someone else is interested in a copy of this as well, just e-mail me directly. WARNING: This is for short-term use ONLY! I expect to have updated code that will support setting the step polarity via HAL within a week or two, along with many other changes that will require significant modification to any existing configurations (but will make pin numbering a whole lot more consistent and understandable!). -- Charles Steinkuehler ch...@st... |
From: Chris M. <chr...@ho...> - 2014-01-11 01:49:56
|
WARNING: This is for short-term use ONLY! I expect to have updated code that will support setting the step polarity via HAL within a week or two, along with many other changes that will require significant modification to any existing configurations (but will make pin numbering a whole lot more consistent and understandable!). -- Charles Steinkuehler ch...@st... Looking forward to this as I have been working on BBB pages for stepconf - I will wait for your changes Chris M |
From: Charles S. <ch...@st...> - 2014-01-11 02:59:50
Attachments:
signature.asc
|
On 1/10/2014 7:49 PM, Chris Morley wrote: > Looking forward to this as I have been working on BBB pages for > stepconf - I will wait for your changes One of the reasons there's not much documentation for how things currently work is the pin numbering is so messed up I didn't actually want to document it. I think I've come up with a reasonable solution that will still work with HAL's limitations (only bit, integer, and float data types, so no strings). I'm working on a system that uses integer values where digit places represent various parts of the pin ID. The base number would be the pin number on the connector (ie: 01-46), you'd add 800 or 900 for P8 or P9, and you'd add 1000 (or 2000, or 3000) for special purpose use (ie: direct PRU I/O, hardware PWM, or some other non-GPIO setup). I can code up the HAL components to translate these values into the numbers the hardware needs, then no one has to worry about them but the programmer. I'm pretty sure I can also handle this translation in the startup shell script...if not, I can always switch from bash to python or something. Comments welcome, and I've updated my spreadsheet to include the proposed numbering scheme: https://github.com/cdsteinkuehler/beaglebone-black-pinmux/blob/hal_pru_generic/pinmux.ods -- Charles Steinkuehler ch...@st... |
From: andy p. <bod...@gm...> - 2014-01-11 04:19:42
|
On 11 January 2014 02:59, Charles Steinkuehler <ch...@st...> wrote: > I think I've come up with a reasonable solution > that will still work with HAL's limitations (only bit, integer, and > float data types, so no strings). Wacky idea, why not add strings to HAL? (if you do, then I suggest _not_ zero-terminated) it could be useful for all sorts of config type stuffs -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto |
From: Charles S. <ch...@st...> - 2014-01-11 06:56:32
Attachments:
signature.asc
|
On 1/10/2014 10:19 PM, andy pugh wrote: > On 11 January 2014 02:59, Charles Steinkuehler <ch...@st...> wrote: >> I think I've come up with a reasonable solution >> that will still work with HAL's limitations (only bit, integer, and >> float data types, so no strings). > > Wacky idea, why not add strings to HAL? (if you do, then I suggest > _not_ zero-terminated) > > it could be useful for all sorts of config type stuffs I agree, strings would be useful for all sorts of things and Forth style strings would work better than zero-terminated. Ironically, the C folks who bashed Forth strings back in the day, now have new "safe" library calls using the same counted string mechanism to avoid stack buffer overflow attacks. :) The main reason not to add strings is AFAIK HAL doesn't currently work gracefully with items that are not basically atomic in nature. This is in the process of changing with the zeromq and queuing changes Michael's working on, but it's a bit much for me to want to tackle just to release an easier-to-understand pin numbering scheme. -- Charles Steinkuehler ch...@st... |
From: Michael H. <ma...@ma...> - 2014-01-11 10:43:43
|
Am 11.01.2014 um 05:19 schrieb andy pugh <bod...@gm...>: > On 11 January 2014 02:59, Charles Steinkuehler <ch...@st...> wrote: >> I think I've come up with a reasonable solution >> that will still work with HAL's limitations (only bit, integer, and >> float data types, so no strings). > > Wacky idea, why not add strings to HAL? (if you do, then I suggest > _not_ zero-terminated) > > it could be useful for all sorts of config type stuffs yes it would, but as Charles says: it would break the atomic update requirement assumed by HAL data types. You cant guarantee a string copy will not be interrupted; for the basic types you can. This guarantee maxes out at 8 or 16 byte sized values, depending on architecture, so it's unsafe territory beyond 8 and architecture dependent. HAL assumes sizeof(double) can be updated atomically as largest object (8). This means strings may travel to/from RT components on a message queue, but not as pins the difference between sending/receiving a message and updating a HAL pin is that the message creation/interpretation code may be interrupted as long as the enqueue/dequeue operations are atomic, which they are in Pavel's ringbuffer code; interruption may not happen for pin updates in the ringbuffer variant this is the sequence 'reserve space in queue', and 'enqueue'; both are atomic - any interruption between the two permitted the legacy code does not have an atomic enqueue operation but checks on the receiving side that enqueue operation is complete (in case you've ever wondered what the SPLIT_READ stuff is - that is detecting 'enqueue commit' on a queue which must be size one, so it's really just a shared buffer) -- if you are just dying to transport a short string of max size 8, you can recycle a HAL_FLOAT, interpret as char[8] and it would be atomically updateable _by storing/reading a double (not using memcpy() etc!), but it's royal wart and it stinks. The solution to this will be making messaging interactions between components trivial, then the issue goes away. Right now it's jumping the hoops. - Michael |
From: Thomas S. <TSt...@to...> - 2014-01-11 23:47:39
|
On 01/11/2014 05:43 AM, Michael Haberler wrote: > Am 11.01.2014 um 05:19 schrieb andy pugh <bod...@gm...>: > >> On 11 January 2014 02:59, Charles Steinkuehler <ch...@st...> wrote: >>> I think I've come up with a reasonable solution >>> that will still work with HAL's limitations (only bit, integer, and >>> float data types, so no strings). >> Wacky idea, why not add strings to HAL? (if you do, then I suggest >> _not_ zero-terminated) >> >> it could be useful for all sorts of config type stuffs > yes it would, but as Charles says: it would break the atomic update requirement assumed by HAL data types. You cant guarantee a string copy will not be interrupted; for the basic types you can. This guarantee maxes out at 8 or 16 byte sized values, depending on architecture, so it's unsafe territory beyond 8 and architecture dependent. HAL assumes sizeof(double) can be updated atomically as largest object (8). > > This means strings may travel to/from RT components on a message queue, but not as pins > > the difference between sending/receiving a message and updating a HAL pin is that the message creation/interpretation code may be interrupted as long as the enqueue/dequeue operations are atomic, which they are in Pavel's ringbuffer code; interruption may not happen for pin updates > > in the ringbuffer variant this is the sequence 'reserve space in queue', and 'enqueue'; both are atomic - any interruption between the two permitted > > the legacy code does not have an atomic enqueue operation but checks on the receiving side that enqueue operation is complete (in case you've ever wondered what the SPLIT_READ stuff is - that is detecting 'enqueue commit' on a queue which must be size one, so it's really just a shared buffer) > > -- > > if you are just dying to transport a short string of max size 8, you can recycle a HAL_FLOAT, interpret as char[8] and it would be atomically updateable _by storing/reading a double (not using memcpy() etc!), but it's royal wart and it stinks. > > The solution to this will be making messaging interactions between components trivial, then the issue goes away. Right now it's jumping the hoops. > > - Michael > > > As an admitted neophyte to this space, you can tell me to go to my corner and be quiet, but I can't help asking why configuration data, which is what the pin info is all about - startup setup information that can get stored locally in the driver once received - why this needs to be atomic. I can certainly understand 'operating' parameters requiring an atomic characteristic, but I'm trying to see the reason in this case. Seriously, I do NOT want to steal bandwidth from this important work so 'quiet' will be taken respectfully. |
From: andy p. <bod...@gm...> - 2014-01-12 00:50:00
|
> As an admitted neophyte to this space, you can tell me to go to my > corner and be quiet, but I can't help asking why configuration data, > which is what the pin info is all about - startup setup information that > can get stored locally in the driver once received - why this needs to > be atomic. I think you might have a point there. Perhaps not the point you think you have, but still a point. HAL makes a distinction between "pins" that are links between modules and "parameters" which are one-eay data into a module (or, in some cases, out to Userspace) HAL string _pins_ are likely to cause problems, but hal string _parameters_ could be a real boon for config (and re-config) work. In practice I am not sure how important atomicity is anyway. The problems only arise when a base-thread function tries to read a HAL pin while a servo-thread function is writing to it. I can't think of many examples of a servo-thread pin that might be linked to a base-thread pin, except perhaps for some parallel-port IO and it is hard to see how bit-type values can have an atomicity problem. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto |
From: Charles S. <ch...@st...> - 2014-01-12 02:38:39
Attachments:
signature.asc
|
On 1/11/2014 6:49 PM, andy pugh wrote: >> As an admitted neophyte to this space, you can tell me to go to my >> corner and be quiet, but I can't help asking why configuration data, >> which is what the pin info is all about - startup setup information that >> can get stored locally in the driver once received - why this needs to >> be atomic. > > I think you might have a point there. Perhaps not the point you think > you have, but still a point. > > HAL makes a distinction between "pins" that are links between modules > and "parameters" which are one-eay data into a module (or, in some > cases, out to Userspace) > HAL string _pins_ are likely to cause problems, but hal string > _parameters_ could be a real boon for config (and re-config) work. > > In practice I am not sure how important atomicity is anyway. The > problems only arise when a base-thread function tries to read a HAL > pin while a servo-thread function is writing to it. I can't think of > many examples of a servo-thread pin that might be linked to a > base-thread pin, except perhaps for some parallel-port IO and it is > hard to see how bit-type values can have an atomicity problem. Well, from what I know about HAL, the primary difference between a pin and a parameter is how the memory address pointer is passed. All the atomic restrictions apply equally to both pins and parameters, and there is no mechanism for "configured once prior to startup and not changed at runtime", which is what you'd need to implement a string longer than 8 bytes. And using a double type as an 8-byte string is just all kinds of wrong, IMHO. I'll stick with an integer numbering scheme for now, thanks! :) -- Charles Steinkuehler ch...@st... |
From: Thomas S. <tst...@to...> - 2014-01-12 19:19:35
Attachments:
Y_Step_Neg.png
Y_Step_Pos.png
|
On 1/10/2014 12:33 PM, Charles Steinkuehler wrote: > On 1/10/2014 9:33 AM, Charles Steinkuehler wrote: >> On 1/10/2014 7:42 AM, Thomas Studwell wrote: >> 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. > OK, here's the quick and dirty version of the PRU code that just inverts > the step signal. I've verified it moves motors on my 3D printer and the > default step state is high (the step pulse is a falling edge, followed > very briefly by a return to the default high state). > > Just drop it in the linuxcnc/xenomai directory and adjust your ini/hal > file to load the new file (pru_generic_fall.bin). The debugging files > are included just in case you feel _really_ adventurous! :) > > cc'd directly to the two interested parties in case the list strips the > attachment. If it does, and someone else is interested in a copy of > this as well, just e-mail me directly. > > WARNING: This is for short-term use ONLY! I expect to have updated > code that will support setting the step polarity via HAL within a week > or two, along with many other changes that will require significant > modification to any existing configurations (but will make pin numbering > a whole lot more consistent and understandable!). > Charles, sorry it took so long to get back to you on this, apparently others found 'better' uses of my time ;-) The driver works as advertised! I've attached two scope traces, one taken with the original driver (Y_Step_Pos.png) and the second (Y_Step_Neg.png) taken with the new driver. The only oddity, which doesn't affect the motion but does affect power consumption, is that the signals are not initialized to high (AKA inactive state) on program startup. The signals do go high and remain there after the first step, however. The motors are energized at high level when the signal is left low. Thank you for building this! I'll use this until your new, improved, version is available. Tom |
From: Charles S. <ch...@st...> - 2014-01-12 19:37:13
Attachments:
signature.asc
|
On 1/12/2014 1:19 PM, Thomas Studwell wrote: > The only oddity, which doesn't affect the motion but does affect > power consumption, is that the signals are not initialized to high > (AKA inactive state) on program startup. The signals do go high and > remain there after the first step, however. The motors are energized > at high level when the signal is left low. You can fix this by editing the setup*.sh script in your configuration directory. At the end of the file is a list of GPIO pins (using the Linux Kernel numbering scheme) and their desired mode (typically out). The default initial value for output pins is low. If you replace the "out" in setup*.sh with "high" for the appropriate pins, the GPIO pin will be initialized to a high value which it will keep until LinuxCNC fully starts up and begins to twiddle the pins. If you need to figure out the proper kernel GPIO values to change, you may find the following spreadsheet useful: https://github.com/cdsteinkuehler/beaglebone-black-pinmux/blob/hal_pru_generic/pinmux.ods -- Charles Steinkuehler ch...@st... |
From: Thomas S. <tst...@to...> - 2014-01-12 20:44:56
|
On 1/12/2014 2:36 PM, Charles Steinkuehler wrote: > On 1/12/2014 1:19 PM, Thomas Studwell wrote: >> The only oddity, which doesn't affect the motion but does affect >> power consumption, is that the signals are not initialized to high >> (AKA inactive state) on program startup. The signals do go high and >> remain there after the first step, however. The motors are energized >> at high level when the signal is left low. > You can fix this by editing the setup*.sh script in your configuration > directory. At the end of the file is a list of GPIO pins (using the > Linux Kernel numbering scheme) and their desired mode (typically out). > > The default initial value for output pins is low. If you replace the > "out" in setup*.sh with "high" for the appropriate pins, the GPIO pin > will be initialized to a high value which it will keep until LinuxCNC > fully starts up and begins to twiddle the pins. If you need to figure > out the proper kernel GPIO values to change, you may find the following > spreadsheet useful: > > https://github.com/cdsteinkuehler/beaglebone-black-pinmux/blob/hal_pru_generic/pinmux.ods > Charles, I didn't see any reference to 'high' being a valid 'direction' using the virtual GPIO pins, so I added these to the end of the setup.sh file. If I get time later today or tomorrow, I'll update the script to process an optional 'level' parameter to the pin list rather than hardcoding it like this. Included text: sudo -A su -c "echo 1 > /sys/class/gpio/gpio44/value" sudo -A su -c "echo 1 > /sys/class/gpio/gpio46/value" sudo -A su -c "echo 1 > /sys/class/gpio/gpio48/value" Tom |
From: Charles S. <ch...@st...> - 2014-01-12 20:58:09
Attachments:
signature.asc
|
On 1/12/2014 2:44 PM, Thomas Studwell wrote: > Charles, I didn't see any reference to 'high' being a valid 'direction' > using the virtual GPIO pins, so I added these to the end of the setup.sh > file. If I get time later today or tomorrow, I'll update the script to > process an optional 'level' parameter to the pin list rather than > hardcoding it like this. > > Included text: > sudo -A su -c "echo 1 > /sys/class/gpio/gpio44/value" > sudo -A su -c "echo 1 > /sys/class/gpio/gpio46/value" > sudo -A su -c "echo 1 > /sys/class/gpio/gpio48/value" Making me provide references, eh? Well, OK: https://www.kernel.org/doc/Documentation/gpio/gpio-legacy.txt ...scroll down to "Paths in Sysfs" where you will find: /sys/class/gpio/gpioN/ "direction" ... reads as either "in" or "out". This value may normally be written. Writing as "out" defaults to initializing the value as low. To ensure glitch free operation, values "low" and "high" may be written to configure the GPIO as an output with that initial value. Note that this attribute *will not exist* if the kernel doesn't support changing the direction of a GPIO, or it was exported by kernel code that didn't explicitly allow userspace to reconfigure this GPIO's direction. -- Charles Steinkuehler ch...@st... |
From: Thomas S. <tst...@to...> - 2014-01-13 00:05:57
|
On 1/12/2014 3:57 PM, Charles Steinkuehler wrote: > On 1/12/2014 2:44 PM, Thomas Studwell wrote: >> Charles, I didn't see any reference to 'high' being a valid 'direction' >> using the virtual GPIO pins, so I added these to the end of the setup.sh >> file. If I get time later today or tomorrow, I'll update the script to >> process an optional 'level' parameter to the pin list rather than >> hardcoding it like this. >> >> Included text: >> sudo -A su -c "echo 1> /sys/class/gpio/gpio44/value" >> sudo -A su -c "echo 1> /sys/class/gpio/gpio46/value" >> sudo -A su -c "echo 1> /sys/class/gpio/gpio48/value" > Making me provide references, eh? Well, OK: > > https://www.kernel.org/doc/Documentation/gpio/gpio-legacy.txt > > ...scroll down to "Paths in Sysfs" where you will find: > > /sys/class/gpio/gpioN/ > > "direction" ... reads as either "in" or "out". This value may > normally be written. Writing as "out" defaults to > initializing the value as low. To ensure glitch free > operation, values "low" and "high" may be written to > configure the GPIO as an output with that initial value. > > Note that this attribute *will not exist* if the kernel > doesn't support changing the direction of a GPIO, or > it was exported by kernel code that didn't explicitly > allow userspace to reconfigure this GPIO's direction. > My bad. Thank you for the reference AND the gentle reminder that the GPIO world doesn't revolve around BBB documentation :-) Tom |
From: Thomas S. <tst...@to...> - 2014-01-10 17:10:20
|
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<TWS...@gm...> >> To: Enhanced Machine Controller (EMC)<emc...@li...> >> >> >> >> 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 >> >> > |