I've got a couple of questions if you have a minute
dunno if I can answer, but somebody might - usually its better to just ask - people might be lurking in the background
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
I've run Linux for years and have done some programming in it as well.
I would like to get our newest products working in EMC2 and I think it will need some programming, but I'm not sure
what is a CandCNC
First, our new breakout board uses a shift register for outputs, so with 3 parport pins we can toggle eight individual outputs
CandCNC is a company that makes breakout boards, torch height controllers, and power supplies etc.
Anyhow, what do I need to do to make a driver to shift out a series of bits to our breakout board?
that shouldn't be too hard if you are already a programmer
I wrote a plugin in Mach3 that works well.
Yep. I write the firmware for our products as well as PC side software.
I'd start with the parport HAL driver, rename it to candcnc-ubob or something
then add the shift register code, and export some additional HAL pins
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
Ok. Then I can tie the outputs to stuff like the mist and flood and spindle outputs?
that would be up to your users
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
I have several linux PC's! I just set one up with Xubuntu and installed EMC2 with the setup script.
then the user or configurator can connect those software pins to whatever they want
Haven't read much on HAL yet.
that will be step 1 then, lemme get you a URL
read this one first: http://www.linuxcnc.org/docview/html//hal_intro.html
then at least the first part of this one: http://www.linuxcnc.org/docview/html//hal_drivers.html
Ok, so I can create HAL output pins that don't necessarily correspond to physical pins and users can connect to those?
you want to create hal pins that _do_ correspond to physical pins
I'll check those out. I've done some cursory reading and I've looked through some of the EMC code before.
(pins on your breakout board, not on the parport - those would include the magic "extra" muxed pins
Ok, that's what I meant.
The other thing our board does is mux inputs based on an output signal.
That way we get 8 inputs on 4 parport pins.
same thing - you can write driver code that hides the muxing and makes them looks like 8 simple inputs
In Mach we're using the charge pump signal to switch which inputs are read.
2 sets of 4, selected by one particular output?
Ok. I'll have to get back to reading!
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)
Art made a modification to the Mach engine to switch which inputs are read for each pulse of the 12Khz charge pump signal.
that stuff would be done in your driver for EMC
one of the fundamental goals of HAL is that I/O is not application specific
yeah, you have to have charge pump turned on all the time for it to work right.
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
you could just set it up for 4 inputs
the user can select any pin as a charge pump, a step, etc
ok. that sounds about like Mach
lemme give you one more link:
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
you should get a cvs checkout of the source code, per instructions on that wiki page
Thanks. I actually compiled EMC from CVS a year or so ago, but I have had a machine to use it on!
when you have your driver working, submit a patch, and we'll commit it to CVS (after review and approval)
RTAI gave me problems at the time because it wasn't up to date with the latest kernel.
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)
Ok! I'm hoping to get drivers for all our products at some point.
looking at the products, I'm trying to figure out what some of the more complex ones are
Hmm, like the SPSC power supplies packages?
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
The spindle speed package is just about that.
One of the first products was the Torch height controller, which has a powered breakout board, front panel and THC controller.
what is in the THC? you implement the control loop in there? or is it I/O with the loop in the PC?
The MP1000-Basic is the same thing without the torch height controll
the THC reads tip volts and send up and down signals to Mach3
how does it decide up/down? basically just a comparator? or does it implement things like special treatement for starting, corners, etc?
then mach can move the torch up and down
Mach does special treatment for starting and corners etc
oh, so really it is a digital meter + a window comparator, and returns two bits to the PC
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
I'm not a plasma guy, so I only know what I've overheard
Our current units have completely isolated analog tip voltage inputs.
Plasma is noisy stuff.
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
yep - I'm not sure what hardware he used, and how he dealt with noise - I certainly hope it was isolated
There's one guy that uses an older THC that Tom made with EMC2
in any case, the A/D hardware and the THC control logic are independent - you could use _any_ A/D with his THC logic
I plan on looking at some of that when I get some time. I stay way too busy!
I know the feeling
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
that is intended to work with the existing parport driver?
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
that would mean less HAL connections, easier for the user
I'll look at that.
There are only four input pins on the parport, but 8 on the bob
each pulse of the charge pump pin switches which bank of inputs are sent to the parport
jepler's HAL component has 4 inputs that you connect to the corresponding HAL pins of the parport driver
it has 8 outputs (two sets of 4)
and one more output that you'd connect to the charge pump pin of the parport
outputs or inputs
(all these connections are hal connections)
outputs: out of the component and into HAL
for example, a normal parport has 4 physical inputs
the driver exports 4 output pins to HAL
the driver reads the physical inputs and writes that data to the HAL pins
the HAL pins are outputs from the driver, even though they are inputs from the outside world
dunno if you've gotten to http://www.linuxcnc.org/docview/html//hal_drivers.html
but take a quick look at the first set of drawings on that page
each of those big boxes represents an instance of the HAL parport driver
and the small pointed boxes on the left side of each are the HAL pins
Ok. haven't looked at anything yet, I've got company here.
jepler: thanks for that code. I'll try it out on our board next week if I get a chance.