LinkBack URL
About LinkBacks
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.
| | |
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
hope this helps...
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.Originally Posted by ProProcess
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
Tech Musings
Link to digimatic protocol above
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
Learn cause and effect through experience. Mastering those relationships is the "Common Sense" ability within the art of any trade.
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
Learn cause and effect through experience. Mastering those relationships is the "Common Sense" ability within the art of any trade.
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/d...displaylang=en
.
Free DXF Files - myDXF.blogspot.com
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...
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)
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
Last edited by One of Many; 07-10-2008 at 04:20 PM.
Learn cause and effect through experience. Mastering those relationships is the "Common Sense" ability within the art of any trade.
Posting Permissions
| | |
