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
