Cheap Idea for a DRO

[1113562]

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

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,

[BillTodd]

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.

[1113562]

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.

[1113562]

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

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.

[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

[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

[1113562]

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

[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...

[1113562]

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.

[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.

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

Cheers,

John


§ ©JS