Back
[18:00:04] <mozmck> Anyone here?
[18:01:50] <jmkasunich> nope ;-)
[18:02:09] <mozmck> I've got a couple of questions if you have a minute
[18:02:44] <jmkasunich> dunno if I can answer, but somebody might - usually its better to just ask - people might be lurking in the background
[18:03:44] <mozmck> Ok. I work for Tom at CandCNC. We use Mach3 at the shop, but I'm getting a router table soon here at my shop and will be setting it up with EMC2
[18:04:12] <mozmck> I've run Linux for years and have done some programming in it as well.
[18:04:57] <mozmck> I would like to get our newest products working in EMC2 and I think it will need some programming, but I'm not sure
[18:05:37] <jmkasunich> what is a CandCNC
[18:05:42] <mozmck> First, our new breakout board uses a shift register for outputs, so with 3 parport pins we can toggle eight individual outputs
[18:06:18] <mozmck> CandCNC is a company that makes breakout boards, torch height controllers, and power supplies etc.
[18:06:23] <mozmck> www.candcnc.com
[18:06:30] <jmkasunich> looking now
[18:07:23] <mozmck> Anyhow, what do I need to do to make a driver to shift out a series of bits to our breakout board?
[18:07:48] <jmkasunich> that shouldn't be too hard if you are already a programmer
[18:07:50] <mozmck> I wrote a plugin in Mach3 that works well.
[18:08:12] <mozmck> Yep. I write the firmware for our products as well as PC side software.
[18:08:14] <jmkasunich> I'd start with the parport HAL driver, rename it to candcnc-ubob or something
[18:08:39] <jmkasunich> then add the shift register code, and export some additional HAL pins
[18:09:13] <jmkasunich> I don't know how many steps you've taken so far - do you have a linux PC running? do you have a RT kernel (ours or another), do you have EMC2 installed? etc
[18:09:41] <mozmck> Ok. Then I can tie the outputs to stuff like the mist and flood and spindle outputs?
[18:09:51] <jmkasunich> that would be up to your users
[18:10:21] <jmkasunich> dunno if you've read anything about HAL yet - but the goal of drivers is simply to provide HAL "pins" that correspond to the physical outputs and inputs
[18:10:27] <mozmck> I have several linux PC's! I just set one up with Xubuntu and installed EMC2 with the setup script.
[18:10:39] <jmkasunich> then the user or configurator can connect those software pins to whatever they want
[18:10:46] <mozmck> Haven't read much on HAL yet.
[18:11:10] <jmkasunich> that will be step 1 then, lemme get you a URL
[18:11:32] <jmkasunich> read this one first:
http://www.linuxcnc.org/docview/html//hal_intro.html
[18:11:53] <jmkasunich> then at least the first part of this one:
http://www.linuxcnc.org/docview/html//hal_drivers.html
[18:11:54] <mozmck> Ok, so I can create HAL output pins that don't necessarily correspond to physical pins and users can connect to those?
[18:12:23] <jmkasunich> you want to create hal pins that _do_ correspond to physical pins
[18:12:27] <mozmck> I'll check those out. I've done some cursory reading and I've looked through some of the EMC code before.
[18:12:42] <jmkasunich> (pins on your breakout board, not on the parport - those would include the magic "extra" muxed pins
[18:13:06] <mozmck> Ok, that's what I meant.
[18:13:12] <jmkasunich> ;-)
[18:13:47] <mozmck> The other thing our board does is mux inputs based on an output signal.
[18:14:07] <mozmck> That way we get 8 inputs on 4 parport pins.
[18:14:15] <jmkasunich> same thing - you can write driver code that hides the muxing and makes them looks like 8 simple inputs
[18:14:33] <mozmck> In Mach we're using the charge pump signal to switch which inputs are read.
[18:15:04] <jmkasunich> 2 sets of 4, selected by one particular output?
[18:15:07] <mozmck> Ok. I'll have to get back to reading!
[18:15:13] <mozmck> Yes.
[18:15:51] <jmkasunich> if that output is also brought to a terminal for customer use, then I guess it is dedicated to charge pump (and even there you have some caveats - when the pump isn't pumping, 4 of your 8 inputs are useless)
[18:16:07] <mozmck> Art made a modification to the Mach engine to switch which inputs are read for each pulse of the 12Khz charge pump signal.
[18:16:23] <jmkasunich> that stuff would be done in your driver for EMC
[18:16:38] <jmkasunich> one of the fundamental goals of HAL is that I/O is not application specific
[18:16:39] <mozmck> yeah, you have to have charge pump turned on all the time for it to work right.
[18:17:21] <jmkasunich> a parport simply provides N inputs and M outputs, and _all_ the driver does is transfers values from the HAL pins to/from the physical ones
[18:17:29] <mozmck> you could just set it up for 4 inputs
[18:17:34] <jmkasunich> the user can select any pin as a charge pump, a step, etc
[18:18:09] <mozmck> ok. that sounds about like Mach
[18:18:25] <jmkasunich> lemme give you one more link:
[18:18:36] <mozmck> I'll just have to make a charge pump on the right pin for our board
[18:18:48] <jmkasunich> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#On_Ubuntu_6_06_or_8_04_from_source
[18:19:17] <jmkasunich> you should get a cvs checkout of the source code, per instructions on that wiki page
[18:19:39] <mozmck> Thanks. I actually compiled EMC from CVS a year or so ago, but I have had a machine to use it on!
[18:19:43] <jmkasunich> when you have your driver working, submit a patch, and we'll commit it to CVS (after review and approval)
[18:20:05] <mozmck> RTAI gave me problems at the time because it wasn't up to date with the latest kernel.
[18:20:20] <jmkasunich> I'll be happy to answer any driver related questions once you've read the hal doc (I'm the HAL architect, and one of the driver writers)
[18:20:41] <mozmck> Ok! I'm hoping to get drivers for all our products at some point.
[18:21:04] <mozmck> Great!
[18:23:19] <jmkasunich> looking at the products, I'm trying to figure out what some of the more complex ones are
[18:23:42] <mozmck> Hmm, like the SPSC power supplies packages?
[18:23:50] <jmkasunich> they seem like mostly a box and front panel for a breakout board (and maybe some other boards, like the spindle speed one provides one D to A converter channel
[18:25:00] <mozmck> The spindle speed package is just about that.
[18:25:48] <mozmck> One of the first products was the Torch height controller, which has a powered breakout board, front panel and THC controller.
[18:26:25] <jmkasunich> what is in the THC? you implement the control loop in there? or is it I/O with the loop in the PC?
[18:26:28] <mozmck> The MP1000-Basic is the same thing without the torch height controll
[18:26:54] <mozmck> the THC reads tip volts and send up and down signals to Mach3
[18:27:28] <jmkasunich> how does it decide up/down? basically just a comparator? or does it implement things like special treatement for starting, corners, etc?
[18:27:33] <mozmck> then mach can move the torch up and down
[18:27:57] <mozmck> Mach does special treatment for starting and corners etc
[18:28:32] <jmkasunich> oh, so really it is a digital meter + a window comparator, and returns two bits to the PC
[18:28:44] <mozmck> We use a microcontroller to read the voltage, and compare to a preset voltage which can be changed from the front panel or sent from Mach3 via serial port
[18:28:58] <jmkasunich> I see
[18:29:10] <jmkasunich> I'm not a plasma guy, so I only know what I've overheard
[18:29:37] <mozmck> Our current units have completely isolated analog tip voltage inputs.
[18:29:53] <mozmck> Plasma is noisy stuff.
[18:29:54] <jmkasunich> we have a user who implemented a fairly complex THC using HAL blocks - I think he used an A/D channel to get the torch voltage into the PC, then he did everything else (settings, up/down, piercing, corners) in HAL
[18:30:26] <jmkasunich> yep - I'm not sure what hardware he used, and how he dealt with noise - I certainly hope it was isolated
[18:30:31] <mozmck> There's one guy that uses an older THC that Tom made with EMC2
[18:30:52] <jmkasunich> in any case, the A/D hardware and the THC control logic are independent - you could use _any_ A/D with his THC logic
[18:31:05] <mozmck> I plan on looking at some of that when I get some time. I stay way too busy!
[18:31:12] <jmkasunich> I know the feeling
[18:36:17] <jepler> pardon me for barging in, but the "input doubler" sounds interesting and it's also a fairly simple HAL component to write -- so I wrote it. I haven't tested it, of course. documentation (automatically generated from .comp file):
http://emergent.unpy.net/index.cgi-files/sandbox/idoubler.txt code:
http://emergent.unpy.net/index.cgi-files/sandbox/idoubler.comp
[18:57:15] <jmkasunich> that is intended to work with the existing parport driver?
[18:58:04] <jmkasunich> I was assuming that the demux would become part of their dedicated parport driver, and would read all eight in one execution of the function
[18:58:15] <jmkasunich> that would mean less HAL connections, easier for the user
[18:59:50] <mozmck> I'll look at that.
[19:00:15] <mozmck> There are only four input pins on the parport, but 8 on the bob
[19:00:47] <jmkasunich> right
[19:01:00] <mozmck> each pulse of the charge pump pin switches which bank of inputs are sent to the parport
[19:01:09] <jmkasunich> jepler's HAL component has 4 inputs that you connect to the corresponding HAL pins of the parport driver
[19:01:20] <jmkasunich> it has 8 outputs (two sets of 4)
[19:01:34] <jmkasunich> and one more output that you'd connect to the charge pump pin of the parport
[19:01:37] <mozmck> outputs or inputs
[19:01:42] <jmkasunich> (all these connections are hal connections)
[19:01:59] <mozmck> ?
[19:02:01] <jmkasunich> outputs: out of the component and into HAL
[19:02:18] <jmkasunich> for example, a normal parport has 4 physical inputs
[19:02:33] <jmkasunich> the driver exports 4 output pins to HAL
[19:02:51] <jmkasunich> the driver reads the physical inputs and writes that data to the HAL pins
[19:03:06] <jmkasunich> the HAL pins are outputs from the driver, even though they are inputs from the outside world
[19:04:03] <jmkasunich> dunno if you've gotten to
http://www.linuxcnc.org/docview/html//hal_drivers.html yet
[19:04:14] <jmkasunich> but take a quick look at the first set of drawings on that page
[19:04:49] <jmkasunich> each of those big boxes represents an instance of the HAL parport driver
[19:05:02] <jmkasunich> and the small pointed boxes on the left side of each are the HAL pins
[19:06:31] <mozmck> Ok. haven't looked at anything yet, I've got company here.
[19:09:39] <mozmck> jepler: thanks for that code. I'll try it out on our board next week if I get a chance.