Mitutoyo gage to RS232 with VB.Net

[ProProcess]

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.

[One of Many]

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?" , 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

[ProProcess]

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.

[irving2008]

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 is a Microsoft KB note on accessing the parallel port directly.

[edit] 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/d...20I/O%20Driver but there are commercial ones as well, such as http://www.zealsoftstudio.com/ntport/index.html [/edit]

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

[One of Many]

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

[One of Many]

Other pieces of documentation I had found.

DC

proscale 950 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

[irving2008]

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

[ProProcess]

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.

[One of Many]

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


DC

[irving2008]

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.

[ProProcess]

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!

[ProProcess]

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.