Quote Originally Posted by BillTodd View Post
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.