-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adding emc-users to cc: since this might help other folks, and direct email to Troy is being bounced.
I noticed in several of my configurations I have I/O pins being driven by both the bb_gpio module and the PRU. This is a bad thing...it doesn't cause any physical harm to the circuitry, but it creates very confusing output results. NOTE: I have been fixing these issues as I find them...please pull the latest MachineKit branch from git. Make sure that any PRU PWM pins are not assigned to the bb_gpio module and your problems will probably go away (or at least you'll be on to the next one!). :) Yes, I've seen the issue with overlapping ADC reads here. I really need to see if I can migrate the ADC reads into HAL and talk directly to the hardware (instead of using the current python script), but I still want to "play nice" with the kernel ADC module because I plan on using a touch-screen at some point. On 7/4/2013 3:07 PM, Troy Jacobson wrote: > Thanks for the numbering info. That helped at lot at > understanding parts of the configuration files. I have X,Y, and Z > working. Haven't tried an extruder yet (waiting to get temperature > stuff nailed down first). Home switches for all thre axes are > working. I can read 2 thermistors. M104 and M140 commands work > within LinuxCNC. Where I am now stuck is that I can only get 1 PWM > output to work, an that is P8.46. P8.45 seems to refuse to do > anything, and P8.36 looks to have a PWM signal coming from > somewhere else. > > A couple of things I added were turing the pid on and off when the > temperature was set. Without it, there was along delay between > setting the temp and the heater being turned on. I also increased > the sleep time between reads of the ADC. There was a post > somewhere about a kernel bug that would show itself if reads of > the ADCs overlapped. > > More after the holiday. > > Thanks, Troy > > > On Sun, Jun 30, 2013 at 7:17 PM, Charles Steinkuehler < > char...@steinkuehler.net> wrote: > > On 6/30/2013 11:26 AM, Troy Jacobson wrote: >>>> Hi Charles, and all, >>>> >>>> My BBB is making my printer move, and I'm almost to a place >>>> I can use it to make something. The system consists of a >>>> bunch of jumper wires from the BBB to a RAMPS board. >>>> Functional, but messy. >>>> >>>> The next steps are: 1) Tweaking the temperature code to >>>> match the thermistor circutry on the RAMPS. I like that the >>>> thermistor table Charles made is based on the resistance at >>>> a temperature. I'll also need to add a second temperature >>>> input, but I think most of the framework is in place for >>>> that. 2) Outputs for a fan and two heaters (hot end and >>>> print bed). 3) Home/limit switches. I have a good idea what >>>> needs to be done here, except that I can't find out how to >>>> map to the pin on the BeBoPr. >>>> >>>> I mostly need help with #3. I see the >>>> [PRUCONF](Driver).stepgen.00.enable type lines, but how does >>>> that map to an actual pin on the BBB? It also looks like >>>> more pins on the BeBoPr might need to be added in the dts >>>> file. As an alternative, I might try to use the K9 >>>> configuration as a starting point, since there seems to be >>>> more pins that I can use. > > There are more available pins on the K9 config, because the K9 is > tied to just about every available I/O. :) > > I have just recently started trying to support more than one ADC > on my BeBoPr config (to read extruder and bed temperature), and I > have had issues with the Python ADC temperature code failing > (apparently, the ADC "helper" driver isn't very robust and doesn't > like being pestered by multiple user-mode programs at the same > time). :( > > As for pins, there are several different schemes in use on the > BeagleBone and within my config files: > > The Kernel GPIO naming convention: (GPIO_Bank * 32) + bit > > The hal_bb_gpio HAL module convention: P8 Pin = 100 + Pin number > P9 Pin = 200 + Pin number > > The hal_pru_generic convention, which is similar to the kernel > naming convention but off by one, so "zero" results in no output: > > ((GPIO_Bank + 1) * 32) + bit --or-- ( 5 * 32) + PRU_bit > > The home/limit switches are intended to be used with the > hal_bb_gpio component. It should be resonably obvious how to > connect these if you poke around in HAL a bit (I have the > component loaded so it should export the pins you need, you just > have to hook them to something!), but holler if you have any > questions or problems setting up a configuration. > >> >> > - -- Charles Steinkuehler char...@steinkuehler.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHWLgwACgkQLywbqEHdNFz2swCgtpGNA75Qqu1QMPYJI30JQBFS PIEAoPflEEabakhE6epgdK4BZZyHUrw6 =FQfB -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
