Cheap Idea for a DRO

Quote:

---

Originally Posted by BillTodd

It sounds to me like the vernier is not being set to fast mode correctly my the PIC. and it is mis-reading the vernier as a binary version rather than a BCD type.

Fire up a serial comms package or hyperterminal, if ALL else fails :)

Set baud to 115,200, 8, n,1

Send 'i0' and the PIC (in position X) should respond with something.

;command line interpretor
;Commands: (case insensitive)
;rx - Read - reads and transmits abs position (x=x,y,z,w)
;sn - Sets sample rate (n=0,1,2) 0 =poll mode, 1 = 300mS (normal), 2 = 20mS (fast mode)
;zx - zero vernier display (x=x,y,z,w)
;vn - set vernier type (n=0,1) 0 = old, 1=decimal


send V1 to set decimal vernier, then S0 to set poll mode, then RX and the pic should respond with X00.000: (inches) or X000.00:
(mm). If it returns XH000000: then it is not reading the vernier as a decimal type.

I have one vernier here that has a similar problem , so if I can fine the time I'll look into it. In the mean time, you could try inserting an extra pulse clk in the setfast routine

Code:

---

setFaut bsf Mode,Auto
setFast bsf Mode,Fast
clrwdt
call zeronorm
clrwdt ;pulse clk again if decimal type
call Dly200
call Plsdata
btfss Mode,Vtype
return
clrwdt ;pulse clk again if decimal type
call Dly200
call Plsclk
call Dly200 ;exta pulse clk *******
call Plsclk
call txZero ;send zero message
return

---

A quick PIC to PC test:

disconnect serial lead from PC , disconnect vernier from PIC

Run VB application, select correct comm port

Connect serial lead, connect vernier to PIC - you should see a new frame appear for X, Y, Z or W - if this happens the serial port is working OK.

you should see the vernier be reset to zero then depending on type H (for hold) and F (for fast)

Press ZERO (and hold) on the vernier, this will stop the clock signal, after a second or less the PIC will signal the PC to remove the frame .

Releasing the zero will start the clock, the PIC will signal the PC and the PC will issue a reset to the Vernier.


If all of the above works the serial comm must be working fine.

---

Thanks Bill,

I'll try all that, its all very usefull info.

As I say in the word attachment I also have another vernier I can try and that one has the abs and rel 24bit packet output format. I'll wire that in first to try, then I'll try to adjust the asm code as you suggest for the BCD version.

What confuses me slightly is the need to run the vernier in fast mode. I thought this is just the update rate and should not cause corruption of the data. I know it is good to get the 40 updates per second for real use on the Mill or Lathe but for test purposes does it matter?

Cheers,

Quote:

---

What confuses me slightly is the need to run the vernier in fast mode. I thought this is just the update rate and should not cause corruption of the data.

---

No it shouldn't, but if the PIC is not able to change mode correctly, it probably wont detect the vernier type (binary/bcd) either. If you use a comms program you should be able to force the PIC to use poll mode (read and report when asked) and binary/bcd type which should confirm the data splicing and clock detection is working properly.

Does your vernier's data and clock signals look like (timing wise) those on the yadro site?
http://www.yadro.de/digital-scale/protocol.html [edit- just had a look at your word doc, all looks ok there]

I'm right in the middle of a job ATM, but I'll try to have a look at my errant vernier (looks and behaves very much like your one) at the weekend.

Quote:

---

Originally Posted by BillTodd

No it shouldn't, but if the PIC is not able to change mode correctly, it probably wont detect the vernier type (binary/bcd) either. If you use a comms program you should be able to force the PIC to use poll mode (read and report when asked) and binary/bcd type which should confirm the data splicing and clock detection is working properly.

Does your vernier's data and clock signals look like (timing wise) those on the yadro site?
http://www.yadro.de/digital-scale/protocol.html [edit- just had a look at your word doc, all looks ok there]

I'm right in the middle of a job ATM, but I'll try to have a look at my errant vernier (looks and behaves very much like your one) at the weekend.

---

OK Bill you have been more than helpfull on this problem there is no rush at all.

As you have seen in the word doc the vernier I am trying looks very much like it is the same as the 7 BCD protocol as per the YA DRO site. According to that site to get to fast read needs a single data then a clock pulse from the PIC so this is where the difference may be as this vernier is not going straight to Fast Read mode.

I'll try the othet Vernier I have at home this evening which is definitely the 2 packet 24 bit binary protocol and I'll see how that performs before fiddling with the PIC code.

I was thinking it may be worth developing a simple emulator coded PIC just to put in the socket for testing the COMS from Interface to PC, i.e one that just generates known values and responds to abs zero controls etc. Putting two or more of these test PICs on the interface board could also be used to test the data splicing - just a thought and you may well have thought of this and rejected it for good reasons.

Quote:

---

Originally Posted by BillTodd

It sounds to me like the vernier is not being set to fast mode correctly my the PIC. and it is mis-reading the vernier as a binary version rather than a BCD type.

Fire up a serial comms package or hyperterminal, if ALL else fails :)

Set baud to 115,200, 8, n,1

Send 'i0' and the PIC (in position X) should respond with something.

;command line interpretor
;Commands: (case insensitive)
;rx - Read - reads and transmits abs position (x=x,y,z,w)
;sn - Sets sample rate (n=0,1,2) 0 =poll mode, 1 = 300mS (normal), 2 = 20mS (fast mode)
;zx - zero vernier display (x=x,y,z,w)
;vn - set vernier type (n=0,1) 0 = old, 1=decimal


send V1 to set decimal vernier, then S0 to set poll mode, then RX and the pic should respond with X00.000: (inches) or X000.00:
(mm). If it returns XH000000: then it is not reading the vernier as a decimal type.

I have one vernier here that has a similar problem , so if I can fine the time I'll look into it. In the mean time, you could try inserting an extra pulse clk in the setfast routine

Code:

---

setFaut        bsf    Mode,Auto
setFast        bsf    Mode,Fast
        clrwdt
        call    zeronorm
        clrwdt            ;pulse clk again if decimal type
        call    Dly200
        call    Plsdata
        btfss    Mode,Vtype
        return
        clrwdt            ;pulse clk again if decimal type
        call    Dly200
        call    Plsclk
        call    Dly200  ;exta pulse clk *******
        call    Plsclk
        call    txZero        ;send zero message
        return

---

A quick PIC to PC test:

disconnect serial lead from PC , disconnect vernier from PIC

Run VB application, select correct comm port

Connect serial lead, connect vernier to PIC - you should see a new frame appear for X, Y, Z or W - if this happens the serial port is working OK.

you should see the vernier be reset to zero then depending on type H (for hold) and F (for fast)

Press ZERO (and hold) on the vernier, this will stop the clock signal, after a second or less the PIC will signal the PC to remove the frame .

Releasing the zero will start the clock, the PIC will signal the PC and the PC will issue a reset to the Vernier.


If all of the above works the serial comm must be working fine.

---

Bill, I have not tried the Hyperterminal test yet or tried adding another pulse to the code. I have not had time yet to try another vernier type either but i did try the simple comms port diagnostic test you describe. When you hold the zero button it stops the clock and the VB app clears the vernier off the display window, Y in my case. On releasing the zero button the Y display returns. The clock and data line LEDs to the vernier flash in a sequence, the vernier display zeroes but in general it leaves it in th H (hold) mode, never in the F.T Fast Read mode. Sometimes the clock and data pulsing sequence repeats a few times till it settles down to the Hold mode. Sometimes it leaves the vernier in the slow mode but this is rare.

I must try and test the other Vernier I have and give an update before trying the other tests.

Cheers.

Quote:

---

Originally Posted by 1113562

Bill, I have not tried the Hyperterminal test yet or tried adding another pulse to the code. I have not had time yet to try another vernier type either but i did try the simple comms port diagnostic test you describe. When you hold the zero button it stops the clock and the VB app clears the vernier off the display window, Y in my case. On releasing the zero button the Y display returns. The clock and data line LEDs to the vernier flash in a sequence, the vernier display zeroes but in general it leaves it in th H (hold) mode, never in the F.T Fast Read mode. Sometimes the clock and data pulsing sequence repeats a few times till it settles down to the Hold mode. Sometimes it leaves the vernier in the slow mode but this is rare.

I must try and test the other Vernier I have and give an update before trying the other tests.

Cheers.

---

Update: I Tried the other vernier which was very recently bought from Aldi but this just caused the PC VB6 App to go nuts with overflows and crash. This vernier is quite different from the older one I fist tried in that the interface pulsing on the clock and data lines at connection detect do not appear to change the setting modes at all on the vernier. Also when you push and hold the zero button on the vernier it just pulses the clock line for about 1/2 second it doesn't hold it off continuously while the button is depressed.

I then tried using hyperterminal with the older BCD type vernier as per the diagnostics tests recommended but this was not good. When the vernier I/F is plugged into the PC COM1 port hyperternial complains it cant open the com port. I think I am correct in setting HT to 'no flow control'? I did try 'hardware control' mode but that suffered the same fate. I thought then that I did have a wiring problem either in my serial link cable or the I/F driver circuit but I checked both and they seem to be correct to drawing - strange.

I'm not sure what to try next!!!

Cheers - John

Hi John,

Ok I found some time this morning to look at my other verniers...

There seems to have been an explosion of vernier types since I wrote the PIC code; I have half a dozen different verniers here with five different output formats! (including Mitotoyo, which is completely different) With your two that makes at least six 'chinese' formats. I have a one I bought in the USA with fractional inch display (very handy) that outputs fast 25mS pulses and, like your Aldi one, does not respond to clk or data switching.

I think the best way forward, is to drop the automatic device detection from the PIC code and add some manual set up commands and a configuration page to the VB prog. (I want to add a DRO to my Haighton at sometime so it is something I will have to sort out).

It would help, to know the switching sequences for your BCD one, so if you get the chance to work them out.... :)

Bill

Quote:

---

Originally Posted by BillTodd

Hi John,

Ok I found some time this morning to look at my other verniers...

There seems to have been an explosion of vernier types since I wrote the PIC code; I have half a dozen different verniers here with five different output formats! (including Mitotoyo, which is completely different) With your two that makes at least six 'chinese' formats. I have a one I bought in the USA with fractional inch display (very handy) that outputs fast 25mS pulses and, like your Aldi one, does not respond to clk or data switching.

I think the best way forward, is to drop the automatic device detection from the PIC code and add some manual set up commands and a configuration page to the VB prog. (I want to add a DRO to my Haighton at sometime so it is something I will have to sort out).

It would help, to know the switching sequences for your BCD one, so if you get the chance to work them out.... :)

Bill

---

OK Bill, I will do a controlled test of my BCD vernier to get the sequence and report back. I'll just code up a simple pulse generator in one of the PICs.

I'm glad you mentioned that the mitutoyo verniers have a completely different protocol as I nearly bought a 24" one a few days ago on eBay. It was mainly for the bar/PCB but using the reader would also be good.

btw. Good idea about having a manually selectable Vernier type in the VB app.

Cheers, John

You wouldn't want to cannibalise a Mitutoyo, they are generally thought to be top end of the market and also unlikely to work with someone elses reading head...

Quote:

---

Originally Posted by irving2008

You wouldn't want to cannibalise a Mitutoyo, they are generally thought to be top end of the market and also unlikely to work with someone elses reading head...

---

Yes thanks for that. There is an 18" one going for £20 +£10 post but the machining company has ground off the points on the jaws, otherwise all is good so they say.

Hi Chaps
This problem of the multiplicity of digital verynear[§] protocols has been discussed at some length on Scott Shumate's group on Yahoo:http://groups.yahoo.com/group/ShumaTech/

The Spherosyn and Mitutoyo protocols are especially, er, non-trivial, but some of the newer ordinary calipers are not easy to decode, either. The C-code for the decoding and autoselect algorithms for his 'OpenDRO' are open source on Sourceforge here:
https://opendro.svn.sourceforge.net/...dro/trunk/src/
so it might be worth a look. Can't help directly, 'cos I know SFA about programming:redface:.

-- 'course, you prob'ly know all this anyway, in which case apols -- suck eggs--- etc.

Cheers,

John


§ ©JS

Quote:

---

Originally Posted by 1113562

OK Bill, I will do a controlled test of my BCD vernier to get the sequence and report back. I'll just code up a simple pulse generator in one of the PICs.

Cheers, John

---

OK I have done a test on the BCD vernier which is a Workzone 6" bought from Lidl or Aldi, can't remember which. I have attached an image of the state diagramAttachment 2203.

It starts always at power up in Slow Read mode. To get from switch on to Fast Read (F.T) needs a Data then a Clock Pulse. To Zero at power up on route to F.T then its Clock then Data then Clock. When in F.T. to Zero needs a Data then CLock then Data then Clock. There are other states as shown in the diagram that are of no interest to our use I suggest.

John.

Quote:

---

Originally Posted by z3t4

Hi Chaps
This problem of the multiplicity of digital verynear[§] protocols has been discussed at some length on Scott Shumate's group on Yahoo:http://groups.yahoo.com/group/ShumaTech/

The Spherosyn and Mitutoyo protocols are especially, er, non-trivial, but some of the newer ordinary calipers are not easy to decode, either. The C-code for the decoding and autoselect algorithms for his 'OpenDRO' are open source on Sourceforge here:
https://opendro.svn.sourceforge.net/...dro/trunk/src/
so it might be worth a look. Can't help directly, 'cos I know SFA about programming:redface:.

-- 'course, you prob'ly know all this anyway, in which case apols -- suck eggs--- etc.

Cheers,

John


§ ©JS

---

Hi John. Whats the message number of the thread that discusses different protocols on that Shumatech forum? I had a quick look but couldn't find it. Loads of stuff on positive earth grounding etc.

Quote:

---

Originally Posted by 1113562

Hi John. Whats the message number of the thread that discusses different protocols on that Shumatech forum? I had a quick look but couldn't find it. Loads of stuff on positive earth grounding etc.

---

Try 17121. It's worth doing a search on 'protocol' and seeing what comes up. I think a look through Scott's code on Sourceforge might yield more than the forum, though.

HTH

John

Quote:

---

Originally Posted by 1113562

OK I have done a test on the BCD vernier which is a Workzone 6" bought from Lidl or Aldi, can't remember which. I have attached an image of the state diagramAttachment 2203.

It starts always at power up in Slow Read mode. To get from switch on to Fast Read (F.T) needs a Data then a Clock Pulse. To Zero at power up on route to F.T then its Clock then Data then Clock. When in F.T. to Zero needs a Data then CLock then Data then Clock. There are other states as shown in the diagram that are of no interest to our use I suggest.

John.

---

This version of Vernier seems to be virtually the same state diagram as that on the YADRO site but they do not show some of the hold states.

Quote:

---

Originally Posted by BillTodd

Hi John,

Ok I found some time this morning to look at my other verniers...

There seems to have been an explosion of vernier types since I wrote the PIC code; I have half a dozen different verniers here with five different output formats! (including Mitotoyo, which is completely different) With your two that makes at least six 'chinese' formats. I have a one I bought in the USA with fractional inch display (very handy) that outputs fast 25mS pulses and, like your Aldi one, does not respond to clk or data switching.

I think the best way forward, is to drop the automatic device detection from the PIC code and add some manual set up commands and a configuration page to the VB prog. (I want to add a DRO to my Haighton at sometime so it is something I will have to sort out).

It would help, to know the switching sequences for your BCD one, so if you get the chance to work them out.... :)

Bill

---

Just to get the record straight, I found by inspection that I had reversed clock and data from the vernier to the PIC processor inputs. A BASIC SCHOOLBOY error. On correction of the error Bill's HARDWARE & SOFTWARE works perfectly with dead stable values on the PC display and also fast update rate. Its a neat and dead cheap solution if you have a PC to hand with a serial COM port.

I'm now going to sort out 2 more verniers that respond to clock and data mode pulsing so I can get X Y & Z working simultaneously. I'll then make a proper PCB for the interface rather than a veroboard prototype to make it a bit more robust. The next step will be to get it all installed on the mill with the full length PCB beams for each axis.

A big thank you to Bill Todd, he is a genius and a gentleman in equal proportions.

Bill, many thanks for your design, I have it built and almost working...

Set up just now with a single PIC in the X position, no callipers connected. The PIC appears to respond to commands, i0 returns data, zx flashes the LED and returns data and then a little more data if I stroke the board. Problem is the returned data is garbled though strangely repeatable.

I've tried two different PNP's 2n5401 and bc556.

I've tweaked the base resistor, 12k and 6k.

As my LED was producing about 1.9v (1) it left only 3v to drive the TX which is a little too close for comfort. I've swapped out the psu LED for a diode string giving about 1.5v/3.5v but data corruption remains identical.

I am using a Prolific USB to serial adaptor, think this could be the problem?

(1) 1.9v worries me as this will power the callipers, should be ok? I can always substitute little diode chains to bring the volgate closer to battery spec.

Hi ecat,

Make sure your terminal is set to receive 115,200 baud, 8 bit, no parity, 1 stop bit. You may have to force DTR (pin4 to -ve) in order for the interface to work, since it supplies the negative for the Txd line.

The USB serial port is the same as I use here.

As long as there's about 5v across the PIC, the comparitor thresholds should be OK (I think John found that his 3v powered vernier put out 1.5v data)

Bill

Thanks for the reply,

Comms settings are good, the PIC appears to receive the correct data.
DTR is negative volts

An example of the reply to i0, in hex :)

0918 0820 0802 494E 4162 7908 094E 4340 ..INAby.NC@
3A

And zx command

0018 3A
0318 3A02 103A ::

looks like I have a bit missing, literally.

1.9V power to the callipers is ok?

Anyway, back to playing :)

Can you check the PIC is running at 4MHz? And that the trim byte is correctly set (my code may be using the wrong value).

Try pulling GP4 high with a 10k resister (it should use the internal weak pull-up but...)

>1.9V power to the callipers is ok?
As long as the scale works at that voltage and the output signal is about 1.5v peak, it should be OK.

If there is a scale connected, Zx should respond withRx: ( the colon : is used as the line terminator) and Ix should respond with Ix,[mode number e.g. 0],[vernier type string Decimal or Binary], [measuement type Inch or MM]:

Without a scale it should send Nack (15h) each time the watchdog times out.

Have you tried it with a scale connected?

Bill

Thanks again Bill, I'll check the speed and try the pullup.

The Zx reply was quite easy to work out :) As you can see in from the two sample replies in my previous post, Rx: appears as 0018 3A and Ix, appears as 0918 08. 'x' appears consistent, returning 18h, ':' is 3A which is correct, ',' appears as 08h.

Consistent, by this I mean that consecutive replies to a given request are often the same, or they fall into a pattern. Over time the values and patterns do change, with the possible exception of the ':'. Looks like a baud rate or level issue, or my Prolific is marginal.

No scale connected until I stop messing around and verify 1.9v operation, too costly to risk. What the PIC thinks it can see is another matter, stroking the component side of the board is enough to fool it into thinking something is there.

Can you confirm the value of the LED series resistor in the 1.5v supply part of the circuit ?

R? is selected to give about 1v5 across the red LED (probably in the region of 330R) this only necessary because the 1v5 scales have the cell +ve connected to the metal body, so to avoid grounding problems I've shifted the PICs Vss supply (and the scales own Vss) 1v5 below the system (PC and Machine) ground.

If your scale has a 3v lithium cell you may have to rethink the power supply, because I'm not sure if the 3v scales have their metal body connected to the +ve end of the cell or not (none of mine are 3v) .

The other LEDs in the outputs are just to limit the voltage to the scale when the PIC output commands.

Double post caused by this bloody snow!

k,

All callipers are 1.5v.
Maybe I have some wack LEDs, don't think I've measured less than 1.7v across the one in the power section and that was with >1k resistor, not good for maintaining voltage stability at those values. I thing the vf of my reds is around 2v

Try a couple of forward biased silicon diodes (e.g. 1n4148, or even 1n4000 series would do), they should give you about 0.7v each .

YaY

Progress of sorts.... Or maybe just chance!

43 48 3A 49 58 0C 30 0C 44 41 43 49 4D 41 4C 0C CH:IX.0.DACIMAL.
49 4E 43 48 3A 49 58 2C 30 2C 44 65 63 69 6D 61 INCH:IX,0,Decima
6C 2C 49 6E 63 68 3A 00 18 3A 03 18 3A 02 18 3A l,Inch:

May not look like much bit it makes me happy...

Had a dodgy scope and a very old Thurlby storage adaptor on it, it looked very much like the transistor was slow in turning off. The above is the first time I've seen anything approaching English, trick was to half the value of the 3k3 collector resistor.

Unfortunately the above was looking like a 1 off :(

Undeterred I added a 2nd and 3rd parallel 3k3 ending up with 825r collector resistance. heh. It's alive :)

49 58 0C 30 0C 44 45 43 49 4D 41 4C 0C 49 4E 43 IX.0.DECIMAL.INC
48 3A H:

My Prolific dongle is only giving about -4v on DTR, problem?

Hmm. -4v seems low, but if it works... I know I'm abusing the serial port, but I've used this circuit many times may be the prolific device is different to mine???

BTW are you driving it from a PC or laptop? (laptop USB ports seem to lack the ooomph required for most USB devices)


You could try sticking a 10u cap between the DTR line and Vss just to stiffen the -ve rail a bit.

Bill

More progress \o/

The sharp eyed would spot the problem in my previous post, I had no commas! That's right, every comma, 2Ch, was coming through as 0Ch which is form feed :( I tried reducing the collector resistance a little more and the comma appeared but so did the occasional funny in the rest of the message :( :(

A little reading showed me another trick, adding a resister between base and emitter is a common way to speed things up. 3k3 between b and e and things appear to be working beautifully :) :)

Quote:

---

Originally Posted by BillTodd

Hmm. -4v seems low, but if it works... I know I'm abusing the serial port, but I've used this circuit many times may be the prolific device is different to mine???

BTW are you driving it from a PC or laptop? (laptop USB ports seem to lack the ooomph required for most USB devices)


You could try sticking a 10u cap between the DTR line and Vss just to stiffen the -ve rail a bit.

Bill

---

Indeed Bill, -4v does look poor, not much margin for error. I'm connecting to a PC but via a powered hub. Another experiment perhaps.

The DTR line looks quite solid, at least it did before my latest changes, heh. A cap certainly wouldn't hurt, thanks for the tip.

As of now your PC app is mostly happy with the board. A couple of range errors when I simulate the calliper with a finger swipe but no data errors so far. Thanks again for your help :)

Not wanting to damage my actual scales I decided to risk my cheap but incredibly useful callipers at 1.88v. On the up side I know the meter I was using reads about 0.03v over actual, on the down side 1.85v is still around 20% above the voltage of typical fresh SR44 type battery :eek:. I'd normally consider 10% over to be a maximum safe(-ish) voltage but so far so good :tongue:, I have the PC app working and I've set the scale to -6.66mm for luck. I'll leave it running for a couple of days and see how it goes.

Thanks again Bill, elegant circuit and nicely crafted software :tongue:

Gosh you are a busy bee Sean!...

I love the idea of absolute position feedback, should all but eliminate concerns about backlash. I also love the sound of pneumatic drive, well if it sounds like the doors from StarTreck :)

How are you planning to address the problem of overshoot? The nice thing about steppers (and servos?) is that you can never overshoot by more than 1 step (or the error response time of the closed loop in the servo?). I know nothing about pneumatics but I imagine it to be a 'springy' sort of drive which, when coupled with the 20ms response time of the callipers could lead to problems?

One note on your circuit: If I understand your description correctly, the metal work of the callipers will be +1.5 Volts above USB ground. USB ground is of course at PC/PSU ground. I've just tested a spare PC PSU I have lying around and it appears the PSU ground is connected directly to mains earth, could be a problem if the bed is earthed and the callipers also make an electrical connection to the bed? You look to be using a laptop and I think the power brick used by most laptops usually float with respect to mains earth, I'm never sure if this is a good or a bad thing, so I guess you'll be ok for now.


Quick update on my 1.8v test:
All looks good though I'm still cautious of trying out the real scales. I do like the LED's so I'll investigate swapping in some high brightness red devices which appear to have a lower forward voltage drop. The only problem I did notice was the occasional jumping of the measured value, a 100uf capacitor fitted close to the calliper end of the cable fixed that nicely :)

Irving,
If you're still interested, the sensor PCB is available as a spare part for the Wixey saw bench

two 31" lengths for $35 :)

http://www.wixey.com/fence/spareparts/index.html

Quote:

---

Originally Posted by irving2008

i reckon the combs should be easy to mill out on a CNC PCB mill. They are 0.6mm thick PCB double sided but the reverse is plain. On the top side is the T-comb structure and a ground strip. Since the mechnaism is a capacitive vernier it would seem perectly reasonable to manufacture this in say 150 or 200mm approx lengths where the end is exacly halfway through a 'T' and then end butt them together ensuring electrical conductivity across the join with a solder infil. getting positional accuracy on the second or subsequent 'comb' is the critical factor (as well as the basic accuracy of the comb). Some sort of jig might do the job.

Alternately, buy 3 cheap ones and look to join the PCB together as per above. Milling a new channel from stainless might be tricky, but aluminium might do just as well.

It worth an experiment don't you think?

---