Gene, I really appreciate the brain dump, and will go through it in detail. That said, I do have the 5i25 hooked to a 7i76. I moved from pncconf to vim about a week ago. I have all the pins mapped in my hal file and can turn things on and off on my machine (and see the spindle status pins) with halstatus.
Everything's working great, I'm just getting hung up on communicating with them from the python remap code. Looks like the suggestion of mapping to M64 commands is the way to go, although it seems a bit unsatisfying. I was really trying to do things in the most general way and the python remapping seems like a wonderful avenue. I actually had the M64/65 commands going and operating from Axis but thought that was the "wrong" way to do it in a python remap file. On Mon, Mar 31, 2014 at 4:48 PM, Gene Heskett <[email protected]> wrote: > On Monday 31 March 2014 15:40:56 Rod Fitzsimmons Frey did opine: > > > I've looked at this and see where the bitmask, but it seems I can only > > read pins with the hal component, not set them? > > > > How can I turn on my power drawbar valve, trigger the blow valve, etc? > > > > I feel like I'm missing some obvious insight... this feeling of > > incompetence is very uncomfortable. > > > [huge snip] > > You will likely need to hand (gedit) edit your *.hal file to add some logic > modules with a "loadrt", assign them to an execution loop "base-thread" or > "servo-thread" via the "addf" command (and this stuff would all be good in > the relatively slow servo-thread), doing that in the order you want them to > be executed, then locate spare output pins in your I/O breakout scheme, and > then tie it all together with "net" commands. You might even need a 2nd > parport for additional I/O, and despite its near vertical learning curve, I > think the dual port FPGA on a card, Mesa 5i25 Anything I/O would be the > cats meow for all that. For breakout boards, mesa makes quite a few, none > of which I have tried yet, having started out with CNC4PC C1G's here, (but > thats my fault) which have very heavy duty drivers (24 ma source or sink) > and a tally led on every line. > > So the first thing I would do is make a list of what parport pins are > currently in use by "grep parport my.hal" and put that down on paper so > you know whats now in use. That will give you a quick overview of whether > or not you'll need an additional port card like the 5i25. > > For a reference to the I/O available on a normal computer parport, see this > link and scroll down to the left hand graphic: > > <http://www.linuxcnc.org/docs/2.5/html/hal/parallel_port.html> > > Anything not in use now, can be added to your .hal file and used. Just be > sure and add its use to the list you just made of what is used too, else > you might try & reuse it again a year hence. I can predict that linuxcnc > will refuse to start, quoting the logic clashes in the failure report on > screen. :) > > You then need to physically wire that parport pin to the stuff that will do > your job, probably by booster relays to get enough power to bang the > solenoid valves that will actually do the work. > > I would also incorporate a final tally signal, needing an input pin, to > determine if the drawbar has responded, and do any error handling in case > it doesn't reclose properly because of swarf in the works or whatever. > > One could also tally the air pressure from a pressure switch as being > sufficient to run the drawbar. You could sit and wait till it comes up, > then do the tool change while the operator is refilling his coffee cup. > You could even put a small air pressure button driven by that signal in the > right panel of axis that turns red when the pressure is too low. > > IOW, let you imagination out to play, but observe and keep notes. :) In the > back of those ring binders I mention below is a good place so you know > where they are. > > At hookup time in the hal file: > > net name_of_signal source_of_signal where_to_send [where_to_send] [etc] > > and one can expend the output tree later in the hal file like this: > net name_of_signal where_to_send [where_to_send] [etc] > > which will send the previously named source_of_signal to several more > places. > > At this stage, I would also recommend the integrators manual and the users > manual be converted to double sided dead tree format & mounted in 3 ring > binders, there is tons of useful info in them. At my age & poor short term > memory, I still do that about every 2 years to keep up with the detail > changes. > > Trying to clear away some of the fog, I hope this helps. > > 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) > Genes Web page <http://geneslinuxbox.net:6309/gene> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
