Anybody ever convert the output from Mitutoyo gages through RS232?
I just started looking into it and it seems Mitutoyo does not use a standard RS232 protocol. They need a converter of some type. Anybody familiar with this?
Thanks in advance as any help would be appreciated.

This interface was engineered in Issue #41 of the Circuit Cellar Ink periodical. Jeff Bachiochi was the engineer working on the design. I believe it is a synchronous interface that is about 30 bits long.

There is some useful info on the protocol here (http://www.yadro.de/digital-scale/protocol.html)

hope this helps...

Anybody ever convert the output from Mitutoyo gages through RS232?
I just started looking into it and it seems Mitutoyo does not use a standard RS232 protocol. They need a converter of some type. Anybody familiar with this?
Thanks in advance as any help would be appreciated.

A couple years ago, I created a braille display using an 18 wheel calculator printer that connects to a pair of Mitutoyo calipers with the data output connector. I used the Parallax SX48 chip and programmed in SX assembly language. There is 52 bits in 13 nibbles and the data is output backwards.

There was an interface that Mititoyo had sold that converted the digimatic code to RS232 for SPC data collection software. I found a few on Ebay a few years back.

Here are a couple links that may help you.

Flexipanel interface (http://www.flexipanel.com/Docs/AN-080605%20Mitutoyo.pdf)

Tech Musings (http://www.tinaja.com/glib/muse145.pdf)

Link to digimatic protocol above (http://www.shumatech.com/support/chinese_scales.htm)

You might place a call to a corporate Mititoyo office and see if an applications engineer will email you a PDF document STD-005 technical information "Design Specifications of Digimatic Data output Interface" Lots of good info on pin outs, request signals and data timing. Several cable configurations to boot. 29pgs in all.

Most, if not all data collection/conversion I have seen done external of a PC due to the speed required of the processor to fetch and store the data stream after the gages request line is pulled low.

DC

Thanks to All for the help, links and suggetions, i really do appreciate it.

On of Many, I Love your signature. It rings very True for most of life!

Sorry I cannot help with VB. I've got a book, but never enough time or immediate ambition/need/motivation to work with it. For this application, the serial bus will be the bottle neck. Your best bet may be to look for a ready made converter then use VB to crunch the ascii data string as it comes in already converted. As I recall the Mitutoyo box was a DP1, but you may find several aftermarket digimatic to RS232 systems in a web search.

Good Luck.

DC

Assuming that you are looking at their 'standard' scales the raw bit data rate at say 40ipm will be something in excess of 100kbps. Converted to ASCII thats 6 digits of data at a sample rate of >3000 samples/sec or about 18000 char/sec or ~180kbps in RS232 terms. An external RS232 converter at 230kbps would be able to transfer the data but not many applications will be able to handle it and you'd never get that throughput from VB anyway (well not reliably).
If you were to convert to RS232 externally you'd need to consider a solution that threw away intermediate samples and had a fixed external, programmable data rate. This would be easily accomplished with a PIC or other single-chip microprocessor. Personally I'd go for a solution that used a USB interface to emulate a COM port, based around one of the FTDI USB chips interfaced to a PIC processor.

However a lot depends on what you plan to do with the data. If its just displaying it then you can afford to 'lose' data and a VB solution that captures the next available 'packet' by reading on demand against a timer interval would be fine. If you are looking for any sort of feedback control then the USB solution might be the only way to get the data in fast enough to be useful.

irving2008,

Thanks for the information!

My application would is very simple, and would not require any "real-time" sampling or feed back. I have a few Mit gages around the shop and want to interface them to some simple measuring software that we have developed. This would eliminate the "laborious" ... and some times error prone ... task of having a human enter the gage data manually into a Textbox.

Maybe this will help?

It's VB.NET 2003


http://www.microsoft.com/downloads/details.aspx?FamilyID=075318CA-E4F1-4846-912C-B4ED37A1578B&displaylang=en

.

irving2008,

Thanks for the information!

My application would is very simple, and would not require any "real-time" sampling or feed back. I have a few Mit gages around the shop and want to interface them to some simple measuring software that we have developed. This would eliminate the "laborious" ... and some times error prone ... task of having a human enter the gage data manually into a Textbox.
In that case you might get away with connecting the scale to a parallel port pin and reading it directly in VB on user command since you only need the one reading. You can afford to lock the thread and devote the whole CPU to the reading function for the time it takes to read the next incoming sample...

If I had a scale I'd knock something up for you...

Maybe this will help?

It's VB.NET 2003


http://www.microsoft.com/downloads/details.aspx?FamilyID=075318CA-E4F1-4846-912C-B4ED37A1578B&displaylang=en

.That would help if the data was already available in RS232 format.... but thats the easy bit (apart from its for VS2003 which is no longer supported, but porting to VS2008 isnt too hard)

In that case you might get away with connecting the scale to a parallel port pin and reading it directly in VB on user command since you only need the one reading. You can afford to lock the thread and devote the whole CPU to the reading function for the time it takes to read the next incoming sample...

If I had a scale I'd knock something up for you...

Irving,

What Proprocess is trying to do is grab digimatic code from a Mitutoyo gage, like calipers, mic's and indicators that have a data output port on the gage itself. This is a formatted code that comes out in a odd packet. This is not a scale encoder. The gage data is output in a 52bit string once the data request line is triggered. When the sequence starts, the CPU needs to be ready to take that stream of bits into a shift register 1 at a time and store it into a data string for restructuring into a usable ascii format for RS-232 output string. I made a typo there previously, as it should be 52bits in 13 bytes or more precisely 26 BCD nibbles.

The crux of the byte structure is in this screen shot.

It would be slick if this could be done direct through a few parallel port pins. I used a Data line, Clock line, Ready line, Request line to link the SX48 to the gage.

Here is an SX snippet of code I used to extract the data from the gage.


;*****THIS SECTION TAKES IN THE DATA STRING FROM THE DIGIMATIC GAGE

ANTI_TIE_DOWN
BANK $10 ;DOUBLE STROKE PREVENTION
JNB P_BUTTON,ANTI_TIE_DOWN
MOV MDELAY, #240
MOV MDELAY+1,#10
DEBOUNCE_SW

decsz MDELAY ; SETUP FOR DELAY OF MECHANICAL CONTACTS
JMP DEBOUNCE_SW ;DEBOUNCE TIME.
mov MDELAY, #240 ;
decsz MDELAY+1
jmp DEBOUNCE_SW


AWAIT_PB
BANK $10

;EXPECT 52 COUNTS FOR 52 BIT STRING
SNB P_BUTTON ;LOOK FOR FALLING REQ EDGE ON P_BUTTON
JMP AWAIT_PB

BANK $10


MOV FSR, #$07
CLEANUP
CLR IND
INCSZ FSR
JMP CLEANUP


clr $10
clr $11
clr $12
clr $13
clr $14
clr $15
clr $16
clr $17
clr $18
clr $19
clr $1a
clr $1b
clr $1c
clr $1d
clr $1e
clr $1f

BANK $10
MOV MDELAY,#$FF
MOV T3,#52
CLRb GAGE_REQ ;TELL GAGE TO SEND
CLKfe
SNB CLK_IN
jmp CLKfe ;LOOK FOR FALLING CLK EDGE OF RB.1
CALL SHIFTIN ;GO SHIFT THIS BIT INTO DATSTR
CJE T3,#0,SPLIT_DAT_STR
CLKre
SB CLK_IN
JMP CLKre ;LOOK FOR RISING CLK EDGE OF RB.1
JMP CLKfe

SHIFTIN
SETB GAGE_REQ ;RESET GAGE REQUEST
;CAPTURE DATA STRING ON DATA_IN AS IT COMES IN.
CLRB C ;CLEAR THE CARRY FLAG
SNB DATA_IN ;SKIP IF THE INCOMING BIT IS NOT HIGH
SETB C ;SET THE CARRY FLAG IF DATA BIT IS HIGH
RR (DATSTR + $00) ;ROTATE MIC BUFFER STRING HIGH/LOW BIT TO THE RIGHT
RR (DATSTR + $01) ;THIS TAKES THE CARRY BIT INTO THE STRING.
RR (DATSTR + $02) ;REGARDLESS OF ITS LEVEL.
RR (DATSTR + $03) ;EACH RR PUTS A BIT INTO THE CARRY FLAG
RR (DATSTR + $04) ;TO BE CONSUMED BY THE NEXT ROTATE RIGHT INSTRUCTION!
RR (DATSTR + $05) ;BASICALLY A SHIFTIN ROUTINE.
RR (DATSTR + $06)
DEC T3 ;COUNT DOWN T3 EACH BIT, SKIP IF T3 IS AT 0


DC

http://cnczone.com/forums/attachment.php?attachmentid=62875&stc=1&d=1215717710

Wow, lots of info from all Thanks again.

Switcher,
I'll be using VB2005 which has a nice Serial Port Component already built in. Thanks for the MSDN link though, as I always learn something from them.

One of Many,
Thanks for all the info. I will look through what you've provided and see what I can translate for my app.

I would like to see how this would be translated for VB. After some thought, I do believe Irving is right on with the parallel port as a com link via custom script software. The problem with the Serial port is it's structure dependency to 128byte blocks with bps, stop bit syncing etc. That is out of your control as a UART chip protocol. The parallel port will give you single bit control input. What tools you have in VB to capture the stream is where the challenge lies. Can you create code to capture it in 70-80Ms? I think so, but I have heard VB is very top heavy unless it can be EXE'd to machine language.

If you need more refined explanation of the assembler logic, I can document it better or clue you in to the what,where and why I took this route. This is a small portion of the full source code, so nothing is defined as I/O or variables. Hopefully not too confusing... "on the edge of obscure?" :confused:, but somewhat self explanatory if you can follow the archaic mnemonics instructions and labels along with the quirks that a small microcontroller needs for low level support in a powerful, but byte/word/page/bank stingy environment.

My secondary plan for this SX48 code was to go with an RS-232 output section for connection with the Emic text to speech unit Parallax distributes. Mitutoyo already has produced a Voiceman that we funded the development on. That unit is rather limited for use with the digimatic code only. The same limitations are on the voice box SPI put out for for our RS232 digital protractors. It only says xxx.xx degrees at the end of a text string. My version was to have several unit of measure options in the same device. Like pounds, ounces, feet, pieces, hours, what ever.

There are several other applications that we could use Blind adaptive voiced hardware already coupled with OEM RS-232 proprietary format output. Often the interface is all that is required to restructure the data to something either the voicing appliance or braille display can understand. In these applications, the devices must be portable and reasonable inexpensive to adapt. The SX48 proto board was a blessing at $10ea.

Too many other project have priority, so this one is collecting dust. Helping folks with similar interests keeps me cobwebs from getting fuzzy comfy!

DC

If you need more refined explanation of the assembler logic, I can document it better or clue you in to the what,where and why I took this route. This is a small portion of the full source code, so nothing is defined as I/O or variables. Hopefully not too confusing...
DC


Admittedly, I'm just a novice VBer and like to learn on projects that i can use, calculators and such. I have made some RS232 interfaces for other gages and I'm looking to do the same for the Mitutoyo as well. As I look into this it seems like I'll be pedaling up hill with VB and would be better suited in something lower level like C or C++, neither of which I know[obviously]. If you had some time to Doc/Explain your chosen path, that would be great. But you've graciously given much of your time to this point and I would understand if you did not have the time.

Again, thanks for all the help.
have a great weekend.

Ok, I hadn't appreciated these scales have a read on demand feature - in that case this is relatively easy to do in VB, although I would still do this in a tight routine which stops Windows threading while the read is going on.

One of the issues here is that the pulse width to read is 100uS so that rules out the use of the VB timer component as that only has a 1mS resolution so it would have to be done the same way as you do in the assembly code, by looping tight and watching for the clock edges.

The other issue is getting VB to look at parallel port pins directly. In the past I have done this with a third-party DLL that allows access to the hardware but here (http://http://support.microsoft.com/kb/823179) is a Microsoft KB note on accessing the parallel port directly.

further reading suggests this only allows writing to the port. Reading from it requires a bit more complexity and I would strongly suggest using a 3rd party DLL. the one I have used is free http://www.driverlinx.com/DownLoad/dnload.htm#Windows%2095/NT%20Port%20I/O%20Driver but there are commercial ones as well, such as http://www.zealsoftstudio.com/ntport/index.html

If you need any help with the porting (pun intended :) ) let me know...

Irving is has a good grasp of what is happening here. I am glad to see his support on the VB end of things.

Here is a shot at documenting the snippet of my code. The grouping of text could have been a bit better too. Just ask, if it needs further clarification.

DC

;*****THIS SECTION TAKES IN THE DATA STRING FROM THE DIGIMATIC GAGE

ANTI_TIE_DOWN ; This Label creates a loop to be certain the push button on the cable connector has been released BEFORE it will continue. This button is the data request button on the gage, but I am using it here as an input trigger for the microcontroller. This allows the microcontroller to trigger and track the gage output sequence
BANK $10 ;Ignore banks-chips memory storage command.
JNB P_BUTTON,ANTI_TIE_DOWN ;Jump to ANTI_TIE_DOWN labeled above if no bit is on P_Button. The input is active low when pressed. Just loop here until it is released. Some error handling could be included here to fault out with an error message?


MOV MDELAY, #240 ;These preset the Ms count down timer approx 10Ms
MOV MDELAY+1,#10

DEBOUNCE_SW ; Section Label Debounce the contacts being released. Prevents false triggering in the next section.
decsz MDELAY ; SETUP FOR DELAY OF MECHANICAL CONTACTS
JMP DEBOUNCE_SW ;DEBOUNCE SETTLING TIME.
mov MDELAY, #240 ;
decsz MDELAY+1 ;Decrement counter, skip the next step if ZERO goto AWAIT_PB
jmp DEBOUNCE_SW ;Go back to DEBOUNCE_SW


AWAIT_PB ;Section Label Watch for P_Button to go low
BANK $10 ;Ignore banks-chips memory storage command.
SNB P_BUTTON ;LOOK FOR FALLING REQ EDGE ON P_BUTTON Skip the next instruction if no bit (I.E. the P_Button input has been pressed.)
JMP AWAIT_PB ;loop to AWAIT_PB until no bit is on P_Button


BANK $10
MOV FSR, #$07 ;This whole section is used to clear out memory of the data from the previous read. It uses the File Select Register via a form of indirect addressing. May or may not apply to VB.
CLEANUP
CLR IND
INCSZ FSR
JMP CLEANUP


clr $10
clr $11
clr $12
clr $13
clr $14
clr $15
clr $16
clr $17
clr $18
clr $19
clr $1a
clr $1b
clr $1c
clr $1d
clr $1e
clr $1f

BANK $10 ;Ignore banks-chips memory storage command.
MOV MDELAY,#$FF Place a value of 255 in Ms counter
MOV T3,#52 ;EXPECT 52 COUNTS FOR 52 BIT STRING
CLRb GAGE_REQ ;TELL GAGE TO SEND by clearing bit on the GAGE_REQ output line
CLKfe Section Label Clock falling edge
SNB CLK_IN ;Skip next step if no bit on Clock input line in which a low input means clock is in process!
jmp CLKfe ; Go back and LOOK FOR FALLING CLK EDGE OF RB.1 again
CALL SHIFTIN ; Falling edge detected now GOTO SHIFTIN to SHIFT THE BIT on DATA_IN line INTO DATSTR and return to the next instruction after this(like a GOSUB?).
CJE T3,#0,SPLIT_DAT_STR ;Compare and jump to label "SPLIT_DAT_STR"(not included here) if counter T3=0
CLKre ;Section Label Clock rising edge
SB CLK_IN ;Skip next instruction if Clock input is high
JMP CLKre ; go back and LOOK FOR RISING CLK EDGE OF RB.1 until detected
JMP CLKfe ;Rising edge found, now look for falling edge again for the next bit.

SHIFTIN ;Section label, This section shifts the bit on DATA_IN line, synchronized with the clock CLK_IN line
SETB GAGE_REQ ;RESET GAGE REQUEST Reset the pin high on the GAGE_REQ line. Ready for the next request.
;CAPTURE DATA STRING ON DATA_IN AS IT COMES IN ONE CLOCK PULSE AT A TIME.
CLRB C ;CLEAR THE CARRY FLAG I.E. start with no bit in the carry flag
SNB DATA_IN ;Look at what is on the DATA_IN. SKIP the next instruction IF THE INCOMING BIT on DATA_IN IS NOT HIGH
SETB C ;IF DATA_IN is high, then SET THE CARRY FLAG high. The carry flag is pulled into the DATSTR buffer area via each RR instruction below. The carry flag emulates the DATA input
RR (DATSTR + $00) ;ROTATE MIC BUFFER STRING HIGH/LOW BIT TO THE RIGHT
RR (DATSTR + $01) ;THIS TAKES THE CARRY BIT INTO THE STRING.
RR (DATSTR + $02) ;REGARDLESS OF ITS LEVEL.
RR (DATSTR + $03) ;EACH RR PUTS A BIT INTO THE CARRY FLAG
RR (DATSTR + $04) ;TO BE CONSUMED BY THE NEXT ROTATE RIGHT INSTRUCTION!
RR (DATSTR + $05) ;BASICALLY A SHIFTIN ROUTINE.
RR (DATSTR + $06)
DEC T3 ;decrement counter T3 each bit through
RET

Other pieces of documentation I had found.

DC

proscale 950 MTI_GP_Manual.pdf (http://www.proscale.com/Downloads/General_Purpose/MTI_GP_Manual.pdf) This has some timing info, but the pinouts are specific to this device. You will need cables for your particular units. More than likely custom configured to connect to the port of your choice.

Mitutoyo Scales are awful. :-(
I interfaced the Mitutoyo 572 to a Milltronics Centurion VI,
with that control's MC68332 TPU.

At least the 572 Digimatic series with a five wire connector.
The voltage is 1.5 volts (battery), so you have to
use a 15k pull-up or better some translators to 5 volts.
Then, the five wires are:
GND: common
RDY: output from scale, user data/hold switch
REQ: hold low to request scale data (input)
CLK: signal data valid valid rising edge (output)
DATA: bcd data with framing. (output)

The bcd data has no checksum, the bit clock rate is 150us,
there are 52 clocks in the data, 13 nibbles
7.8 ms per sample, 8333 'baud', no start or stop bits.
The data is:
n0 n1 n2 n3 n4 n5 n6 n7 n8 n9 nA nB nC
F F F F sg dp b5 b4 b3 b2 b1 b0 un
sg=sign, dp=decimal points, un=units,
F= framing (1111 binary), b5..b0 bcd
digits of the data.

The Mitutoyo 572 serial data format is incompatible
with any conceivable UART or RS-232. 7.8 ms is too
slow for any solid positional control. 1.5 volts
gives no noise immunity to emi. yuck yuck yuck.

If you want to talk to it, I'd suggest a PIC
and some hands-on bread-boarding and programming.

Or look for better alternatives.

Good day. --krb

Here's a first pass at a VB equivalent. I make no representations as to whether this works, I haven't tried it....

I have wrapped the PortIO DLL in a class to make it easier to use. Its not fully implemented but you'll get the drift...

++++ cut here and paste into a new VB class file
Public Class PortIO

Declare Function DlPortReadPortUchar Lib "dlportio.dll" (ByVal Port As Long) As Byte
Declare Function DlPortReadPortUshort Lib "dlportio.dll" (ByVal Port As Long) As Integer
Declare Function DlPortReadPortUlong Lib "dlportio.dll" (ByVal Port As Long) As Long

Declare Sub DlPortReadPortBufferUchar Lib "dlportio.dll" (ByVal Port As Long, ByVal Buffer As Byte, ByVal Count As Long)
Declare Sub DlPortReadPortBufferUshort Lib "dlportio.dll" (ByVal Port As Long, ByVal Buffer As Byte, ByVal Count As Long)
Declare Sub DlPortReadPortBufferUlong Lib "dlportio.dll" (ByVal Port As Long, ByVal Buffer As Byte, ByVal Count As Long)

Declare Sub DlPortWritePortUchar Lib "dlportio.dll" (ByVal Port As Long, ByVal Value As Byte)
Declare Sub DlPortWritePortUshort Lib "dlportio.dll" (ByVal Port As Long, ByVal Value As Integer)
Declare Sub DlPortWritePortUlong Lib "dlportio.dll" (ByVal Port As Long, ByVal Value As Long)

Declare Sub DlPortWritePortBufferUchar Lib "dlportio.dll" (ByVal Port As Long, ByVal Buffer As Byte, ByVal Count As Long)
Declare Sub DlPortWritePortBufferUshort Lib "dlportio.dll" (ByVal Port As Long, ByVal Buffer As Byte, ByVal Count As Long)
Declare Sub DlPortWritePortBufferUlong Lib "dlportio.dll" (ByVal Port As Long, ByVal Buffer As Byte, ByVal Count As Long)

Private m_PortAddress As Long = -1

Public Sub New()
End Sub


Public Sub New(ByVal port As Long)
m_PortAddress = port
End Sub


Public Property PortAddress() As Long
Get
Return m_PortAddress
End Get
Set(ByVal value As Long)
m_PortAddress = value
End Set
End Property


Public Property ByteValue() As Byte
Get
If m_PortAddress = -1 Then Throw New Exception("I/O port not set up")

Return DlPortReadPortUchar(PortAddress)
End Get
Set(ByVal value As Byte)
If m_PortAddress = -1 Then Throw New Exception("I/O port not set up")

DlPortWritePortUchar(PortAddress, value)
End Set
End Property

End Class

++++

Now here is a Console app that calls it... in a real application this would be another class with a a 'ReadGauge' method. You can see the loops watching for clock low and clock high...

++++ Cut here
Sub Main()

Const PPort = &H3F8 ' LPT port, I'm guessing here, but look it up
Const Gauge_REQ = &H1 'LPT port bit 1
Const Clk_IN = &H2 'LPT port bit 2
Const Data_IN = &H4 'LPT port bit 3

Dim theData As New BitArray(52)
Dim bitcount As Integer = 0
Dim myPort As PortIO
Dim data As Byte

myPort = New PortIO(PPort)

'request data

data = myPort.ByteValue
data = data And Not Gauge_REQ
myPort.ByteValue = data

For bitcount = 0 To 51
' watch for clock low
While (myPort.ByteValue And Clk_IN) = Clk_IN
'tight loop
End While
'clocks gone low, data ready

data = myPort.ByteValue
theData(bitcount) = ((data And Data_IN) = Data_IN)

'reset data request

data = (data Or Gauge_REQ)
myPort.ByteValue = data

' watch for clock to go hi
While (myPort.ByteValue And Clk_IN) = 0
'tight loop
End While
Next

' OK now theData contains 52 bits, MSB at location 0

Dim myGaugeValue As Double

myGaugeValue = ConvertData(theData) ' left as an exercise for the reader! Convert 52bit datastream into a double value...

Console.Write("The value is {0:F3}", myGaugeValue)


End Sub

++++


Hope this helps....

I lifted this from the Mitutoyo site FAQ Hot Topics [first listing]...

...Mitutoyo, Digital, Serial output. It is not an industry standard output. You cannot typically send Mitutoyo output directly to a computer/pc/COM port.

irving2008,

Thanks for the code, I will give it a try when I get some free time.

Now that I see my code again, I claimed I made a typo on the 52 bits and 13 bytes. The image I posted states 13 bytes. It was their typo I repeated to correct myself by mistake :p. I defined 7 bytes in my DATSTR of which only 6.5 bytes are required and the last 4 bit nibble cast off as overhead.

In reading the VB version, it appears all pins are read in one step, then the data dissected from the byte value? Oh, the modern conveniences of high level languages and parallel transfer! LOL! I often wonder if there was a better code capture method than I chose. Mine works well, so I have not tried to optimize the code with alternate instructions and features the SX microcontroller has to offer.

One last heads up. With the SX48 chip, there is a feature for low voltage logic level inputs. I needed no logic level translator. As stated by KRB's note in my previous post documentation, a logic level translator will need to be between the gage and the parallel port. Preferably opto isolated. I'm guessing there are 14-16 pin chips made for this which could possibly be powered by the parallel port itself. No additional supply required.

As I had posted earlier. Mitutoyo does make an RS-232 interface.
One newer example? (http://cgi.ebay.com/New-MITUTOYO-PC-DATA-INPUT-DEVICE-TOOL-for-DIGI-RS-232C_W0QQitemZ280245662607QQihZ018QQcategoryZ12581QQrdZ1QQssPageNameZWD1VQQcmdZViewItemQQ_trksidZp1638Q2em118Q2el1247)


DC

Thanks for the code, I will give it a try when I get some free time.You're welcome. One thing I should add - the parallel port is an 8-bit output normally with 5 status inputs. You need to use three status inputs and set the port number (PPort) to the status port address OR add some additional code to turn the main dataport round to be an input (it involves writing to the parallel port config register address) and then using three of the main data lines. I'd go for option 1 as its easier.

You also need, in Windows, to ensure the Print Spooler service is disabled, otherwise it will keep playing with the port values, especially if you have a printer set up.


In reading the VB version, it appears all pins are read in one step, then the data dissected from the byte value? Oh, the modern conveniences of high level languages and parallel transfer!
VB doesnt have a bitwise operation so you have to do it this way, personally I'd love a data.setbit(n), data.clearbit(n) syntax. Of course you could do this in the PortIO class and have a myPort.setbit(bit, value) and a myPort.getbit(bit) - in fact I'd recommend doing that as it would greatly improve the readability of the code especially if overloaded so you could use 0, 1 and False, True interchangeably.

'send data request

myPort.setBit(Gauge_REQ, 0)

For bitcount = 0 To 51
' watch for clock low
While myPort.getBit(Clk_IN)
'tight loop
End While

'clocks gone low, data ready

theData(bitcount) = myPort.getBit(Data_IN)

'reset data request

myPort.setBit(Gauge_REQ, 1)

' watch for clock to go hi
While Not myPort.getBit(Clk_IN)
'tight loop
End While

Next


In C# you could declare a byte of bits and work as you have done in assembler.

Thanks to all for the suggestion, links and various code samples.
I think ater reading the Mitutoyo documentation and suggestions and some toying around this weekend I will go for the standard RS232C converter that they offer.
This will get me off the ground for my app and give me a chance toy with reading the data directly and converting later.
Though it sure seems like this will be tough to do with VB and tougher still without some intermidiate hardware such as PIC.

Again, thanks for all the great "input" and happy coding to all!

Purchased two input tools from Mitutouyo...
RS232C
USB

The USB is a dirct Keyboard wedge
The RS232C is not but I'm using

My.Computer.Keyboard.SendKeys(Data, True)

So far my app developement is going smoothly, the RS232 data needs slight manipulation but is straight forward.
Once it's off the ground, I'll straight toying with direct reading without the intermediate devices.


:)